事業責任者の理解が開発投資における「摩擦」を防ぐ
ペインポイントとしては、事業サイドとエンジニア組織側の摩擦が挙げられる。
開発において、技術負債やコードの複雑さが原因で見積もりなどの予測が外れることはままあることだ。一方で事業側は、たとえ不確実であろうとも、その見積もりや予測を信じて計画を作るしかない。そして、ひとたび施策がディレイすれば事業計画の変更が余儀なくされる。アプローチとしては人件費を投入してメンバーを増やすという解決が多く用いられる。
ところが人員投入について、エンジニアは「人を追加しても開発は速くならないのに」と不満を抱えがちだ。これに対して石垣氏は、「人を増やすくらいなら、内部品質の向上に開発費用を使いたいと考えるエンジニアが多いのは自然なことだ」と共感を示す。ちなみにこうした見積もりの予測において、開発を理解しているEMと現状のシステムを知っている現場のエンジニアで見積もりが差異が出てきたら技術負債が溜まってきている危険信号である。
また開発投資については、キャンペーンやエンハンスの施策など「これをやれば売り上げが上がる」という性質を持つものや、予算のリクープがしやすいといった「見やすく測りやすい」施策はわかりやすく映る。
しかしリファクタリングやリプレイスなど効果が見づらいものや、数年単位でリターンが返ってくる施策は理解を得にくい面がある。とりわけリプレイスは、「膨大な予算をかけて、元の状態に戻す作業」であるため、事業責任者の理解が必須だという。
石垣氏はさらに、エンジニアとマネージャーの間に生まれる摩擦についても話を展開する。
エンジニアのパフォーマンスを高めるには、「フロー状態」（タスクに熱中している時間）の確保が欠かせない。ところがここにも、それぞれの働き方の違いから生まれるミスコミュニケーションがある。
というのも、ある研究結果によれば、開発者は1時間に約13回タスクを切り替えることでタスクに集中しているという。一方でマネージャーは1時間区切りのミーティングを挟み、半日単位でタスクをこなすことが多い。この差を意識しないままにエンジニア参加のミーティングなどを設定してしまうと、せっかくのフロー状態が損なわれる。これもまた、エンジニアの開発生産性を下げてしまう一因だという。
対策はあれど、「信頼関係」に勝るものなし
一筋縄では行かない開発生産性の向上。バリューストームや各種モニタリングの仕組みなど具体的な対策は数あれど、「1番はエンジニアとビジネスユニットの信頼関係だ。信頼関係があれば、開発速度ばかりに気を取られることはなくなる」というのが石垣氏の持論だ。
こうした心持ちに関する話として、最後に石垣氏は、生産性の低いチームを強くする方法について言及した。チーム力を高めるには「開発生産性を上げるべき（アウトプット量を増やすべき）」「無駄なものを作る可能性を下げるべき」という2つの論が対置されることが多いが、石垣氏の結論は「アウトプット量を増やしてから無駄をなくすべき」である。
これは責務とコミットの問題である。生産性には付加価値生産性と呼ばれる「価値があるものを作る生産性」と物的生産性と呼ばれる「生産量」の2つがある。PdMや事業責任者を中心に何を作るべきか、なぜ作るべきか議論は行われており、当然エンジニアもそれを理解している（コミット）ことが前提で、役割の責務を考えたときに、一定の確率が当たる施策をいかに早く回転数を上げながら開発できるかが大事である。そのため、無駄なものを作らないという観点で言えばプロダクトチームとしてそれができていればOKで、エンジニアは回転数（アウトプット量）を上げることに責務を持っていると言えるだろう。
さらに、Four Keysなどの数値向上を目的に据えることは、「いたずらに数字にこだわってしまい、いざ大局を見てみると対して生産性が向上していないこともままある」。これらの数値はあくまでも状態のモニタリングに使うべきであって、絶対的な指標にすべきでないというのが同氏の見解だ。
これをグットハートの法則といい、数値を目標にすると数値を上げることだけに目が向き、時にハックすることを考え出し、本来の価値があるものを作りユーザーエクスペリエンスをあげていくという目的から外れてしまう。
最後に石垣氏は、他者・他社との比較の無意味さについても触れる。「SNSなどを見ていると、他社の開発組織がとてもスピーディで生産性も高いように見えるかもしれない。しかし実際には、事業環境や人材などの前提条件が大きく異なることも多い。比べるべきは常に過去の自分たち。改善幅を見ながら予測ベースで開発するべきだ」。
定義から運用、そして改善策まで、すべてが単純ではない開発生産性。それでも最後に大切になるのは、地に足をつけた組織の運営なのかもしれない——そんな知見を示唆しつつ、講演は締めくくられた。
