エンジニアリングリソースを有効活用することについて考える
はじめに
「技術を財務で表現する」という素晴らしい記事を見かけました。
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
GP（総生産力）。GPってのは僕が勝手に名付けた名前で「Gross Productivity」の略にしています。要するにエンジニアチームの総生産力を表しています。
僕の視点からすると、現代のIT企業の内製エンジニアチームって凄く特殊で、バランスシートにやってくる「システム」資産を作る力のことと言っても過言でない。もう少し言葉遊びすると「作る」というより「作り続ける」力。流量のようなイメージでしょうか。
Gross Productivity（総生産力）という言葉、いいなぁと思いました。昨今のエンジニアリング組織の生産性向上はまさにここの数字をあげることかと思います。
そして「作り続ける」という言葉選びも重要です。一般的に人的なエンジニアリングリソースはコストが高いため、エンジニアやデザイナーなどがより専門性を発揮できるように、無駄を省いて専門分野にフォーカスする時間を確保するというアプローチは、リソースを有効活用するという観点から言うと自然ではあります。しかし、限られたプロジェクトスコープ内で徹底的に無駄を省くよりは、この「作り続ける」ということを意識して、時間軸踏まえて考えるほうが良いと私は考えます。「きれいな水を一定量、常に流し続ける」というイメージです。
今回はこういった専門職の人たちのモチベーションややりたいことを一旦分けて、「きれいな水を一定量、常に流し続ける」ということを考えてみます。
きれいな水を一定量、常に流し続ける
私の言う「きれいな水」というのは、価値のあるプロダクトインクリメントです。ユーザーがプロダクトに求めている価値そのものです。ときにはそれは技術的負債の返済にあたることもありますが、間接的にこれも価値のあるプロダクトインクリメントとすることができるでしょう。
そして「量」は開発スケールであり、アジャイル開発においてよく用いられるチームのVelocityを意味します。
私は今までこれを「ゴールに向かって正しい方向に一定スピードで走る車」と表現していました。今回は「きれいな水を一定量、常に流し続ける」という表現にフォーカスします。
プロダクトにおけるスタートからゴールまでの水量の合計
プロダクトの開発をスタートしてから、そのプロダクトの一生を終えるまで、常に最大限にエンジニアリングリソースを有効に使えた場合はこの図の用になると思います。
この青色部分の面積が大きければ大きいほど、プロダクトに価値を提供できたということになります。この場合面積がMAXなので最高の例となります。
厳密には、チームを増やして流量のキャパシティ自体を増やしていくこともあるので、縦軸を%ではなく、流量[ml]とかで表現したほうが直感的かもしれません。しかしここでは財務という観点から、限られたリソースを有効に活用するということを考えるため、%で考えます。
ところが実際このようにうまくは行きません。プロダクトに所属する、掛け持ちをしていないチームを想定した場合、例えばこんなふうになったりはしないでしょうか。
青色部分の面積は先の例と比較してかなり小さくなっています。これでは財務的に有効に活用しているとは言い難い状態です。当然、あらゆる組織にはそれなりの制約条件があり、なるべくしてなるという状況は多々あると思います。しかしこれは仕方ないからと見過ごせるほどの差ではありません。文字通り、何倍もの差が出てしまうことになります。解決できるところは解決したほうが良いということは間違いないでしょう。
短期プロジェクトでしか、流量を確保できないパターン
施策を短期プロジェクトでしっかり何をやるかを考え、無駄を省いてスピーディにプロダクトインクリメントをデリバリーすることは悪いことではありません。プロジェクトもうまくいき、そのプロジェクトは無事成功だったとしましょう。
しかしプロジェクトが走っているとき以外はきれいな水の流量は比較的少なくなってしまいます。繰り返しますが、プロダクトに所属する、掛け持ちをしていないチームを想定した場合の話です。もちろん、チームのレベルやプロセス、カルチャーなどに依存するといってしまえばそれまでですが、それでもプロダクトに対する視座という観点でいうと、プロジェクトを構成していた人員のスキルセットと比較すると劣ってしまうことが多々あります。
また、プロジェクトではしばしば期限を設定し、プロジェクトマネージャーはそれを守るためにいかに工夫するかというところにも労力が割かれます。
要件に優先順位をつけ、期限に間に合わないものはやらないという決断は立派な働きだと思います。ときには、「今回は技術的負債には目を瞑ろう」と判断して期限を短くすることもあるかもしれません。その努力の結果、プロジェクトは成功し、期限内に必要なものをリリースすることができました。これはプロジェクト成功と言っても良いでしょう。それではそのプロジェクトのあと、次何をやるのかをしっかりと考えなくなったとすると、Productivityはどのようになるかというと、下がります。
せっかく短縮した期限、プロジェクトは成功したのにも関わらず、中長期的な視点でプロダクトに対する価値提供は最大化できているかどうかは疑問です。
繰り返しますが、これはチームのレベルやプロセス、カルチャーなどに依存するものなのでこのセオリーが全組織に適応されるものではありません。
また、制約条件により、プロジェクトの期限を守ることがかなり重要なケースもあると思います。
回避可能な場合において、短期プロジェクトでプロダクトを作っているときに、こうならないように対策が必要であるということです。
※職能組織編成でプロジェクトのみでプロダクトを動かすし掛け持ちも当たり前のような状態はこのような想定にはなりませんが、それはそれで別の問題があります。*1*2
スクラム&プロダクトチームで流量が保てないパターン
スクラム＆プロダクトチームを考えた場合、プロダクトバックログにおいてWhat to doは常にメンテナンスされ、毎週のようにプロダクトインクリメントをデリバリーされる状態が、比較的担保されやすいと考えられます。しかしながらプロセスやフレームワークは銀の弾丸ではないというのはまさにそのとおりで、図のようにうまく行かないパターンも当然あります。
この場合のパターンは見積もりが甘く予定していたVelocityを発揮できなかったとか、技術的難易度が予想以上に高かったとかそういうものから起因する場合を除いて考えることにします。というかその場合、全員が全力で戦ったっけどだめだったということでありエンジニアリングリソースは有効に活用していたということですもんね。
クロスファンクショナルチームとプロダクトインクリメント
スクラムチームを構成する場合、クロスファンクショナルチームを構成するのが理想です。これはプロダクトインクリメントを優先度の高いものから順番にデリバリーできるようにするためというのは理由の一つですが、当然この背景には、プロダクトインクリメントをデリバリーするために必要な職能は単一のものであることはほとんどない、という事実があります。
例をあげながら説明すると、このような要件があったとします。
可視化はされていませんが、それぞれの要件について必要な職能は異なってきます。
一方で現在のチームはこのような構成であるとします。実際他にも職能が必要そうですが、簡単のため、これをクロスファンクショナルチームとしてみます。
もうおわかりかと思いますが、人と職能を紐付けてしまうことによって、それぞれの要件で必要な人、必要でない人が出てきます。
例えば「ユーザーがアプリ内でタイマー機能を使うことができる」、「ユーザーが仕事帰りに電車でおすすめのレシピをpush通知で受け取ることができる」要件に対してはアプリの開発だけで良いかもしれません。一方で、「ユーザーが電車でテキストでレシピを検索することができる」は全員フル稼働が必要かもしれません。それぞれの人の稼働状況に偏りが出てきます。
したがって、リソースを100%有効活用しているかどうか、という観点で見ると、素直にYesとは言えない状態です。
個人レベルでのクロスファンクショナル
この例では極端な話、人＝職能と考えてしまう場合に起こってしまいます。この４人のスキルセットをそれぞれ図で表してみるとこのようになります。
それぞれのスキルセットは専門分野ではレベル100と非常に高く、立派な専門性を持っていると言えます。しかしこの状態だと上記のように不安定な流量となってしまいます。Back endの負担が多いからBack endエンジニアをもっと増やそう、という解決法でも一時的に解決できるかもしれませんが、世の中はわからない上に変化しますし、要件もそれに従い変化します。よって不安定な状態は続くと考えられます。
ということで個人レベルでのクロスファンクショナルという事を考えてみます。
そんなもんレベル100マルチスタックがいいなんてわかっとるわ！って声は聞こえてきそうですが、注目していただきたいのは、一旦短期的にそれぞれレベル60程度を目指しているというところです。
レベル100とかレベル60って実際どんなもんなのか？という議論は置いておいて、ここで私が言いたいのは、業界のエキスパートにならずとも、スキルレベルはレベル60あれば、高品質で満たせる要件もまぁまぁあるということです。さらに、0->60への成長のほうが60->100への成長よりも難易度が低いと考えられます。これは世の中にある情報やスキル習得者の数、解説のしやすさから考えてもその様になるのかなと思います。
仮にこの仮設が正しくなかったとしても、重要なのは、人＝単一職能と考えないことによって生まれてくる、Productの視座向上だったり、タスクテイカー感からの脱却、そして責任感といったカルチャー的な側面で好循環が生まれて来ます。*3
以上のことから、スクラム＆プロダクトチームにおいても、個人レベルでのクロスファンクショナルにすることによって、少なくともプロダクトの価値提供能力つまり今回で言うきれいな水の流量が増え、長期的にプロダクトの価値が高まっていくと考えられます。
やっぱり大事なのはWhat to doが常に考慮されている状態を作る
常に価値のあるものを、継続的に提供するためには、常に価値のあるWhat to doを、文字通り積んでおく必要があります。単純に開発スピードを上げたいからと言ってエンジニアを採用エンジニアを採用というのは、一旦立ち止まって少し深く考えたほうが良いのではないかという場合もあるでしょう。プロダクト開発に必要なのはプロダクトマネジメントだったりプランニング、デザイン、品質管理、カスタマーサポートなど多岐にわたります。その中で例えばWhat to doがボトルネックになっているのであれば、職能としてのエンジニアを強化しても逆効果になり得ます。
What to do がボトルネックになり、管理されていない状態となっている場合、ボトムアップ的なアプローチで委託するとか、明確に権限移譲を行うとかでケアする必要があります。
そのためにはそもそもチームの存在意義と明確に定義し、ミッションや目標を定義し、それに向かって自立的に走っていける環境を作り、障害となるものは取り除いたり、オフィシャルなプロセスを設定したりするなど組織としての基礎の部分をきっちり固めてやる必要があるかと思います。
こういったことを考え出すと、より一層Gross Productivityの最適化を考える場合、エンジニアリングというのはエンジニアのアウトプットではなく、プロダクト開発組織全体のアウトプットということになり、スコープは決してエンジニアにとどまらないということになってきます。
そもそも人は変化して成長できる
ある程度確かに特定分野のエキスパートも必要ですし、この人はこれが得意といったイメージが生まれるのは良いことだと思います。
しかしながら、人＝この技術、つまり人の職能フォルダ分けから、人への職能ラベル付けへ考え方を変えることで、組織はより柔軟な動きができ、全体のGross Productivityを向上させることができます。上記の例ではソフトウェアエンジニアに関する複数のスキルセットについて述べましたが、そもそもこれもエンジニアというフォルダに入っているので、このエンジニアと言う枠組みからの脱却ももちろん考えるべきことかと思います。もしかするとデザインや品質管理、人事、プロダクトプランニング、など幅を広げられる可能性もあります。
しかもその人達が、やりたいという思いがあるならこんなに幸せなことはありません。長期的な視点を持ち、この時期はプロダクトに対するインクリメントがどうしてもできないといった状況の場合、新しい分野への学習の時間をガッツリ取るのも、長期的には将来Productivityを向上させることに有効に働きます。
おわりに
今回は、財務で表現するという話から、エンジニアリングリソースを数字的な概念として捉えて有効活用する考えを書いてみました。
振り返ってみると言ってることは非常にシンプルで、要約すると「継続して何をやるかを考えよう」と「人を単一職能の人とかんがえるのをやめよう」みたいになってしまいますね。確かにこういう文言はどこかしらで見かけるものでありますが、それだけ言ってもなかなか伝わらないと思います。私自身も、人に伝えるという経験をすればするほど、今までの抽象的な理解では不十分だったと反省する日々です。
そしてこのセオリーですが、エンジニアやデザイナーなどの専門的な人たちは決して機械ではなく、人なので、これだけでは不十分でしょう。
その前に組織ビジョンやカルチャー、そしてそれが影響を受ける組織構造、さらに基礎となる事業や会社のミッション、ビジョン、バリューなどしっかりとした土台が必要になります。
