「効果計測が当たり前のデジタル広告、計測が当たり前じゃないエンジニア生産性」社内プロジェクトマネジメント勉強会第4回の内容を公開します

こんにちは、リチャード 伊真岡です。私が勤務しているマーベリック株式会社でプロジェクトマネジメント勉強会というものをシリーズで開催していて、今回の記事はその第4回の内容です。 ただ、私の個人的な事情によって第4回は勉強会自体を開催しなかったので、予定していた内容をブログ記事として公開します。

• 第1回はこちら - 「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」
• 第2回はこちら - 「アジャイル開発から要件定義・設計重視な開発への回帰」
• 第3回はこちら - 「並行作業とスキーマ駆動開発」

以下勉強会の発表内容です。

Google Developer AdvocateがTrelloを使ってブログ執筆工程を管理

最近見て感心した動画があったので、その紹介を入り口に今回の発表を始めます。

この動画はGoogle Developer Advocateによる発表で、彼らの書くブログ記事の費用対効果を分析するツールの組み合わせとして、Trello、Google Spreadsheet、Google Analytics、Google Data Studioを紹介しています。Google AnalyticsとGoogle Data Studioはマーケターのみなさんにもおなじみのツールですね。

GoogleのDeveloper Advocateは社外に向けてGoogleのプロダクトを周知する仕事です。講演、動画作成、そしてブログ記事執筆などが主要な仕事です。Developer AdvocateはGoogle内で多くの人数が属する組織なので、個人のブログ執筆スピードに頼るだけでなく、組織として効率よく記事を公開していく仕組みが整っています。動画ではTrelloのリスト分けを使って、「アイデア出し」「下書き」…など工程を区切ってタスクを管理し、各タスクが各工程でどれくらいかかったかをGoogle Spreadsheetに出力して集計する方法を紹介しています。

一方成果の計測として、ブログ記事は沢山の人に見てもらいたいのでGoogle Analyticsで閲覧数を計測、そしてGoogle Data Studioに出力して見やすいレポートにすることで、上司に向けてリソース再分配をうながす報告材料とします。

Developer Advocateはエンジニアのように技術職の色合いが強いので、そういった人々がマ―ケター的な手法で効果を計測していることに、とても感心しました。

エンジニアの世界では自分たちの生産性を測らない

なぜ動画に感心したかといえば、裏を返せばエンジニア職一般では自分たちの仕事の生産性をしっかり計測していないからです。ちゃんと計測しているところもあるので、組織よって状況は違いますが、デジタル広告配信のように「業界として測ることが当たり前」にはなっていないはずです。

エンジニアの世界では、過去に生産性を測ろうとする試みにより開発の現場が混乱してきたことから、そういった計測指標に強い抵抗があります。有名な例として「人月」という単位があり、スキルの高低を反映しない、割り込みタスクを反映しないなど、さまざまな欠点が知れ渡っています。人月は今もしぶとく生き残り、当然ながら多くの場合機能しません。他にも、エンジニアが書いた「コード行数」で成果を測る試みは何十年も前に否定されました。不必要にコード行数を増やすより、適切な設計や技術選択でコード行数を減らすほうがよいソフトウェアが作れるからです。GitHubなどの「イシュー消化数」を成果指標にすると、イシューの粒度が個々に違いすぎるため一律に計測できず、またイシュー消化を急ぎすぎてソフトウェアの長期的品質を落とすこともよくあるため、これも適切ではありません。

今のところ有効で、かつ生き残っている指標はアジャイル開発で利用されるストーリーポイントが代表例です。有効なのですが、相対指標であるため自チーム内で長期間運用を続けないと比較対象となるデータが溜まっていかず、少し導入のハードルは高いです。長期間ストーリーポイントを用いた開発がうまくいっているチームだと機能するのですが、開発がうまくいっていないチームが立て直しのためにストーリーポイントを導入するのは難しいというジレンマがあります。

ここまで見てきたようにエンジニアの生産性計測にはデファクト・スタンダードとなる指標は存在しません。デジタル広告の世界には「ページビュー」「コンバージョン」「CPA」などがあるのと対照的です。

これは業界で発言力と実績のあるエンジニアたちが、間違った生産性計測による弊害を長年注意喚起し続け、それが浸透した結果得られた勝利であるとも言えます。ただ一方で、発言力も実績もないエンジニアまでもがポジショントークとしてその主張に乗っかり、給与に見合う成果を上げられていない、チームの活動を阻害してしまうエンジニアまで都合よく自分たちの生産性の低さを隠してしまった面もあります。エンジニアの地位を守るため必要だった「不当な計測の否定」という戦いも、行き過ぎて自分たちの仕事の中身を隠し、適切な評価を困難にするのだとしたら好ましくありません。自分たちに都合が良い主張を繰り返す人々は当然他者から信用されることはないのですから。

エンジニアにとっては幸運なことに、ここ数年エンジニア雇用に対する需要は高まり続け、またしばらくの間大きく落ち込む気配はありません。長い間高給取りの典型といえばウォール街に代表される金融従事者たちでしたが、最近では企業によっては往時のウォール街の水準に迫るか、もしくは超えるような給与をエンジニアに支払っているところもあります。これは歓迎すべき状況である一方、エンジニアには成果を求める厳しい目が向けられ、高い給与水準が保たれる限りそれが弱まることはないでしょう。

エンジニアの生産性を計測する取り組みは少しずつ始まっている

生産性を計測する取り組みがまだ浸透していないとはいっても、そういった開発者文化もここ数年ようやく変わる気配を見せています。エンジニアが使う開発ツールチェインは自動化が大きく進み、Continuous Integration、Continuous Deliveryは当たり前、ログの収集も自動化・高度化、アプリケーションやそれを支えるコンピューティング・リソースの自動監視ノウハウも大きく進化しました。

また、近年のエンジニア文化の大きな潮流としてDevOpsがあり、そこでも計測は重要なトピックとして扱われます。以下のNew Relicの記事でも紹介されているように、コンピューティングリソースの計測だけでなく、「先週リリースした機能Xはどれだけ新規ユーザ獲得率を増やしたのか？」など、ビジネスの成果と開発活動を直接つなぐ計測が広まってきています。

DevOpsはデジタル広告の会社であるGoogleも強く推しています。GoogleはDevOps Research & Assesmentという団体と協力してState of DevOps reportというサーベイを年一回発表していますし、動画や記事、教材などを含め様々な啓蒙活動を積極的に行っています。DevOpsの計測を重視する姿勢がデータ志向ながGoogleの姿勢とよくマッチしたのではないかと思います。

まだまだ肌感覚としては、ほとんどの企業は「重要なビジネス上の指標を自動取得できていない」段階にあると感じていますが、デジダル広告配信やマーケティングの分野で培われたノウハウと組み合わせられれば、ビジネス指標と開発活動を結びつける取り組みはあっという間に進化する可能性を秘めています。

生産性を割り算だと捉えるなら、ここまではDevOpsによって生産性の「分子」にあたる成果の計測が進んできたことをお話ししました。ここからは生産性の「分母」に当たるコスト、労力の計測の話です。この部分はまだまだ指標や計測手法のコンセンサスが形成される様子も見受けられず、手探りの状態が今後も続きそうです。

将来有望な取り組みの1つは、ワークフロー管理の進化です。ここ10年ほどでGitHubの利用が広がったことなどから「開発を始める際イシューを作成する」「開発が終わったらレビューリクエストを作成する」という統一感のあるワークフローが浸透しました。

今の若いエンジニアには信じられないかもしれませんが、10年ちょっと前はソースコードのレビューを実施するのも一苦労で、ファイルのDiffをメールで送ってレビューしてもらうような時期もあったのです。

これはデジタル広告の状況にも似ていて、ソフトウェア開発という仕事において、大まかなワークフローができあがってきた状況です。ワークフローが出来上がれば、どのステップがボトルネックになっているのか分析出来ます。

しかし先程述べたように、GitHubやJIRAなどのプロジェクト管理ツールは、全ての起票単位が「イシュー」となるので、大小10倍、100倍も作業量の違うものがひとつのイシューとして扱われる難しさがあります。「エピック」など規模感を表すラベルを付けも提唱されていますが、エンジニアは面倒な手作業を最も嫌う美徳を持っている人々なので、なかなか浸透しません。

解決策としては、より細かいステップにワークフローを分割することだと私は考えていて、それにはアニメ制作がヒントになります、私が単にアニメ好きなこともあるのですが(笑)。アニメ制作は専門性や作業工程が非常に細かく別れ、

• 企画、脚本、デザイン、絵コンテ、レイアウト、原画、動画、色指定、彩色…

など分類が2桁に及ぶほど細かく別れた工程を

• 監督、プロデューサー、進行、脚本家、キャラデザイナー、原画担当、作画監督、アニメーター…

など様々な役割の人々が協力し合いつつ担当します。アニメ制作の工程については、アニメSHIROBAKOのウェブサイトに記載された「アニメーション制作の流れ」を参考にしました。

ソフトウェア開発においても先程図示したような5段階の単純なものではなく

• UIワイヤフレーミング、UIコンポーネント設計、API設計、DBスキーマ設計、設計レビュー、テストシナリオ作成、…

と細かく作業工程を分解していくことが精密な計測には不可欠です。現在の開発は「進みながらこの先必要なステップを思い出す、コードレビュー直前までいってテストシナリオを考え始める」ような場当たり感の強い仕事をしているエンジニアが多いと思います。もう少し事前に工程を決める方針に寄せるほうが混乱が少なくなります。

今流行っているTrelloのようなカンバンスタイルのダッシュボードだと、作業工程が10を超えるような場合の管理は少し見づらいので、カンバンダッシュボードのGUIが進化するか、別の何らかのツールがそれを支援してくれると、一気に作業工程全体の可視化が進むはずです。このあたりの視覚表現もアニメ制作のツールを参考にできるかもしれません。

今の時代は開発ツールチェインの自動化がすっかり進んでしまったので、いったん開発者の作業量計測をするきっかけが出来てしまえば、どんどん計測・収集手法が進化していく素地は整っています。

Continuous Integrationによって、一日に何回ビルドを回しているのか、ビルドの各工程当たりどれだけ時間がかかっているかも取得できるようになりました。例えばScalaのバージョンを挙げることによってコンパイル速度が大きく向上することは知られているので、これによりビルド待ち時間を削減した場合の費用対効果も検討できます。

Continuous Integration環境だけでなくローカル開発環境でのコンパイル時間の合計も取得できれば、より効果の高い作業効率改善策に繋がります。たとえば「コンパイルが速いからGoに乗り換えたい！」という提案も、定量的な分析を伴って検討できるのです。

まとめ

エンジニア文化の中で、自分たちの生産性を計測することが根付かなかったのは、過去の発言力がある有力なエンジニアたち必死で戦ってくれた、間違った計測の弊害から私達エンジニアを守ってくれた結果です。私もエンジニアの一人として、今の状況を作ってくれた先人たちには大きく感謝しています。

今は時代が変わってデータ分析の手法やツールも進化しました。ここで今一度我々エンジニアの生産性を定量的に評価できる時代に来ていると私は感じています。私は未来の予想はだいたい外すのですが、重要なのは「エンジニアの生産性を測るのが当たり前の未来が来る」かどうかではなく、「自分たちがそれを実現できる組織になれば他者の何歩も先をいける」ということです。

エンジニア自身が適切に生産性を測り、自分たちが費用以上の大きな成果を組織にもたらすことを示せるようになれば、より私達エンジニアが働きやすく、より一層事業に貢献できる未来が実現できるでしょう。

• 第1回の記事はこちら - 「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」
• 第2回前半の記事はこちら - 「アジャイル開発から要件定義・設計重視な開発への回帰」(前半)
• 第2回後半の記事はこちら - 「アジャイル開発から要件定義・設計重視な開発への回帰」(後半)
• 第3回の記事はこちら - 「並行作業とスキーマ駆動開発」