SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2024 セッションレポート

Four Keysでも生産性は測れない?──DMM 石垣氏に学ぶ、開発生産性向上のための組織戦略

【15-B-4】開発生産性の現在地点について~エンジニアリングが及ぼす多角的視点~

  • X ポスト
  • このエントリーをはてなブックマークに追加

事業責任者の理解が開発投資における「摩擦」を防ぐ

 ペインポイントとしては、事業サイドとエンジニア組織側の摩擦が挙げられる。

 開発において、技術負債やコードの複雑さが原因で見積もりなどの予測が外れることはままあることだ。一方で事業側は、たとえ不確実であろうとも、その見積もりや予測を信じて計画を作るしかない。そして、ひとたび施策がディレイすれば事業計画の変更が余儀なくされる。アプローチとしては人件費を投入してメンバーを増やすという解決が多く用いられる。

 ところが人員投入について、エンジニアは「人を追加しても開発は速くならないのに」と不満を抱えがちだ。これに対して石垣氏は、「人を増やすくらいなら、内部品質の向上に開発費用を使いたいと考えるエンジニアが多いのは自然なことだ」と共感を示す。ちなみにこうした見積もりの予測において、開発を理解しているEMと現状のシステムを知っている現場のエンジニアで見積もりが差異が出てきたら技術負債が溜まってきている危険信号である。

「失敗とは、見積もりの失敗である」(マーティン・ファウラー)
「失敗とは、見積もりの失敗である」(マーティン・ファウラー)

 また開発投資については、キャンペーンやエンハンスの施策など「これをやれば売り上げが上がる」という性質を持つものや、予算のリクープがしやすいといった「見やすく測りやすい」施策はわかりやすく映る。

 しかしリファクタリングやリプレイスなど効果が見づらいものや、数年単位でリターンが返ってくる施策は理解を得にくい面がある。とりわけリプレイスは、「膨大な予算をかけて、元の状態に戻す作業」であるため、事業責任者の理解が必須だという。

半年後、1年後、数年後を見据えたタスクは効果が測りづらく、リターンも不確かだ
半年後、1年後、数年後を見据えたタスクは効果が測りづらく、リターンも不確かだ

 石垣氏はさらに、エンジニアとマネージャーの間に生まれる摩擦についても話を展開する。

 エンジニアのパフォーマンスを高めるには、「フロー状態」(タスクに熱中している時間)の確保が欠かせない。ところがここにも、それぞれの働き方の違いから生まれるミスコミュニケーションがある。

 というのも、ある研究結果によれば、開発者は1時間に約13回タスクを切り替えることでタスクに集中しているという。一方でマネージャーは1時間区切りのミーティングを挟み、半日単位でタスクをこなすことが多い。この差を意識しないままにエンジニア参加のミーティングなどを設定してしまうと、せっかくのフロー状態が損なわれる。これもまた、エンジニアの開発生産性を下げてしまう一因だという。

マネージャー側がエンジニアの働き方を理解していないと、せっかくの集中を削いでしまうことになりかねない
マネージャー側がエンジニアの働き方を理解していないと、せっかくの集中を削いでしまうことになりかねない

対策はあれど、「信頼関係」に勝るものなし

 一筋縄では行かない開発生産性の向上。バリューストームや各種モニタリングの仕組みなど具体的な対策は数あれど、「1番はエンジニアとビジネスユニットの信頼関係だ。信頼関係があれば、開発速度ばかりに気を取られることはなくなる」というのが石垣氏の持論だ。

Four Keysよりも重要な「信頼関係」
Four Keysよりも重要な「信頼関係」

 こうした心持ちに関する話として、最後に石垣氏は、生産性の低いチームを強くする方法について言及した。チーム力を高めるには「開発生産性を上げるべき(アウトプット量を増やすべき)」「無駄なものを作る可能性を下げるべき」という2つの論が対置されることが多いが、石垣氏の結論は「アウトプット量を増やしてから無駄をなくすべき」である。

 これは責務とコミットの問題である。生産性には付加価値生産性と呼ばれる「価値があるものを作る生産性」と物的生産性と呼ばれる「生産量」の2つがある。PdMや事業責任者を中心に何を作るべきか、なぜ作るべきか議論は行われており、当然エンジニアもそれを理解している(コミット)ことが前提で、役割の責務を考えたときに、一定の確率が当たる施策をいかに早く回転数を上げながら開発できるかが大事である。そのため、無駄なものを作らないという観点で言えばプロダクトチームとしてそれができていればOKで、エンジニアは回転数(アウトプット量)を上げることに責務を持っていると言えるだろう。

 さらに、Four Keysなどの数値向上を目的に据えることは、「いたずらに数字にこだわってしまい、いざ大局を見てみると対して生産性が向上していないこともままある」。これらの数値はあくまでも状態のモニタリングに使うべきであって、絶対的な指標にすべきでないというのが同氏の見解だ。

 これをグットハートの法則といい、数値を目標にすると数値を上げることだけに目が向き、時にハックすることを考え出し、本来の価値があるものを作りユーザーエクスペリエンスをあげていくという目的から外れてしまう。

 最後に石垣氏は、他者・他社との比較の無意味さについても触れる。「SNSなどを見ていると、他社の開発組織がとてもスピーディで生産性も高いように見えるかもしれない。しかし実際には、事業環境や人材などの前提条件が大きく異なることも多い。比べるべきは常に過去の自分たち。改善幅を見ながら予測ベースで開発するべきだ」。

 定義から運用、そして改善策まで、すべてが単純ではない開発生産性。それでも最後に大切になるのは、地に足をつけた組織の運営なのかもしれない——そんな知見を示唆しつつ、講演は締めくくられた。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2024 セッションレポート連載記事一覧

もっと読む

この記事の著者

中島 佑馬(ナカシマ ユウマ)

 立命館大学卒業後、日刊工業新聞社にて経済記者として勤務。その後テクニカルライターを経て、2021年にフリーランスライターとして独立。Webメディアを中心に活動しており、広くビジネス領域での取材記事やニュース記事、SEO記事の作成などを行う。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

川又 眞(カワマタ シン)

インタビュー、ポートレート、商品撮影写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19768 2024/07/10 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング