開発組織の「事業貢献」を証明する、定量化の設計術【キャディ株式会社 VPoE 藤倉成太】

マネージャーになると、開発組織の状況や成果を「定量化・可視化」し、上長や経営層にわかりやすく伝えることが求められるようになります。しかし、その取り組みは一筋縄ではいきません。指標の設計やレポートの構成に悩んだ末、やっと作った資料に「で、これって結局何が言いたいの？」とダメ出しが入る。そんな経験をした方も多いのではないでしょうか。

キャディ株式会社のVP of Engineeringである藤倉成太さんも、過去には同じ壁にぶつかっていたといいます。その後、開発組織の成果を経営陣へ適切に伝える方法を模索した結果、「経営課題から逆算して考える」スキルを身につけたのです。

どうすればエンジニアリングの価値を、エンジニアではない人にも納得感を持って届けられるのでしょうか。本記事では藤倉さんの実践知をもとに、開発組織の“見える化”を成功させるヒントを探ります。

• keyboard_arrow_down 報告しても伝わらないのは、“経営視点”が抜け落ちていたから
• keyboard_arrow_down 経営と現場で板挟みのマネージャーを救う、「定量化」設計術
• keyboard_arrow_down 「ひたすら打ち返す毎日」から脱却。権限委譲は「要素分解」から始まる

――マネージャーになったばかりの方は、「上長へのレポートがうまく伝わらない」「何を報告すればいいのかわからない」といった悩みを抱えることが多いと思います。藤倉さんご自身は、マネージャーになりたての頃、レポーティングはうまくできていましたか？

藤倉：正直なところ、最初はまったくできませんでした。前職で開発部長になった頃、組織の状況を直属の上司にレポートする必要があったのですが、何度も「これだとわからないよ」と突き返されていましたね。

――伝わらない原因は何だったのでしょうか？

藤倉：いちエンジニアとしての守備範囲を前提とした思考のままでいたことが、上長との認識のズレにつながっていたのだと思います。「経営層が何を課題と捉えているのか。その課題に対して、エンジニアリングとして何を提示できるのか」といった視点が、抜け落ちていました。

マネージャーになった当時の私は、事業への貢献も意識していたつもりでしたが、あくまで“現場”起点の発想だったんです。本来であれば、部長という立場になった時点でスタンスを速やかに切り替えるべきでした。

たとえば、プロダクトを非連続的に成長させる必要があり、短期間で次々と機能をリリースしなければならない経営のフェーズに入ったとします。そのような状況で社員のエンゲージメントの状況を経営陣へと丁寧にレポートしても、きっと「今、その情報って必要？」と返されてしまいますよね。経営層にとって「今」最も必要なのはプロダクトの成長だからです。

これは極端な例ですが、マネージャーがボトムアップの視点しか持っていないと、「何をなぜ伝えるのか」が上長と噛み合わなくなるということです。

思い返すと私が部長になったばかりの頃、社長から「うちの会社で部長になるということは、経営メンバーの一員だという自覚を持ってほしい」と激励されたことがあります。これはおそらく、経営の課題を自分ごととして捉え、それにどう応えるかを考えてほしいという意味だったのだと、今となっては思います。

――確かにその通りです。とはいえ、そうした視点を身につけることは簡単ではないと思います。どのようなアプローチが有効でしょうか？

藤倉：「自分が経営者だったらどうするか」を、日頃から徹底的に想像することが重要です。たとえば、全社会議で社長が「今期は売上を2倍に伸ばす」と発表したとします。その状況下で「もし自分が経営者だったら、どうやって売上を2倍にするか？」をリアルに考えてみる。それが、経営視点を身につけるための第一歩です。

私の場合、ある「癖」があったことが、経営的な思考を培ううえで役立っていました。私は、誰かが何かを話しているときに、「この人はなぜこの言葉を選んだのか？」「なぜこの語調だったのか？」と、発言の裏側にある意図や状況をつい考えてしまうんです。たとえば、普段は全社会議で特定の話題を出さない人が、今回はあえてその話題に触れたとします。表向きは穏やかな口調だったとしても、「これはかなりクリティカルな経営課題なのではないか」と推測できます。

つまり、「何を言ったのか」だけでなく、「なぜそれを言ったのか」にも目を向けることで少しずつ視座が上がり、見えてくる風景が変わってくるんです。

――開発組織の活動を定量化する際、出した成果がより経営層に伝わりやすくするため、何を大切にされていますか？

藤倉：基本的には、経営指標からの“逆算”で考えます。事業として目指している目標があるとして、それに対して、エンジニアリングがどのように貢献できるかを検討するわけです。場合によっては、「一般論として良いとされる指標」をむやみに追ってもあまり意味はないこともあります。

仮に、自社が事業の急拡大を目指しており、システムの安定性に一定のリスクを負ってでも、とにかく開発速度を上げなければならない場面だとします。そうした状況ならば「開発速度を高める施策とは具体的にどういうことか」「何の数値が向上すれば、開発速度が上がったと定義できるか」という観点で、とるべき施策や指標、計測方法を整理していきます。

この際に「課題に対して明確な目標値を設定し、その達成に向けて施策を積み上げているか」「時間の経過に伴う変化量が、目標と照らし合わせて妥当か」などを念頭に置いています。

そのプロセスを経ることで、「今期は事業目標として○○を掲げているから、開発速度も○○まで引き上げたい。そのために、○○という施策を行う」「自社の場合、これらの指標が改善していれば開発速度が上がったと言える。数カ月前は指標がこの数値だったが、いまは同じ人数でより高い数値を出している」といった説明ができるようになります。

逆に、システムの安定性のように優先度を下げた領域に関しては、「現時点では経営目標にそれほど寄与しないことや○○という技術の登場によりリスクは相対的に下がっており、あえてリソースを割かない判断をしています」などと伝えれば、「なるほど、筋が通っているね」と理解を得やすくなりますよね。

単に指標を設定するだけでなく、なぜその指標を使うのか、どういう意図で設定されているのかを、関係者全員が納得できる状態をつくることが、マネージャーの重要な役割だと考えています。これは上長や経営陣に対してだけではなく、組織で働くメンバーたちに対しても同様です。

――複数の開発チームに指標を設定しなければならないケースもありますよね。その場合のコツはありますか？

藤倉：組織をまたいで共通の指標を作るのは、正直なところ難しいです。プロダクトの特性、メンバー構成、課題の性質や難易度も異なるため、単純な比較は向いていません。それよりも、特定のチームが過去と比べてどう変化したかを見るほうが、基本的にはわかりやすいです。

とはいえ、どうしても組織横断の比較が必要になる場面もあります。その場合は、なるべく特定のメンバーが全チームの指標を設定・評価するほうがよいと思います。各チームのリーダーがそれぞれ数値を出してしまうと、目線や精度にバラつきが出て、比較としての意味を持たなくなってしまうからです。

――技術的負債の解消のように、経営への貢献度が見えづらい領域もあります。こうしたテーマについては、どのように定量化を工夫していますか？

藤倉：たとえば、施策の経済的価値を試算して、金額という指標で評価可能にする方法があります。仮に、特定の技術的負債を解消することで将来的に300万円ほどのリターンが得られる見込みだとします。負債解消のために正社員のエンジニアが4人月稼働する必要があるとして、1人月あたりの人件費が約100万円であれば、およそ400万円の投資になります。この場合、投資に対してリターンが見合わないため、着手は難しいかもしれません。

しかし、優秀な業務委託エンジニアに依頼でき、かつその方であれば月額150万円で2カ月程度で完了する見通しが立つならば、コストは300万円で済みます。これであれば、投資に見合うと判断できる可能性がありますよね。

開発組織のマネージャーは、経営陣からは「早く機能開発をしてほしい」と言われ、現場のメンバーからは「技術的負債を解消させてほしい」と求められるなど、板挟みになる場面も多いはずです。そうした時は、現場のメンバーと一緒に「この技術的負債を解消すると、具体的にどれほどのリターンが得られるのか」を明確にしてほしいです。

その過程で、新しいアイデアが生まれるかもしれません。あるいは「なぜ技術的負債の解消を今は優先できないのか」が明確になり、メンバーの納得感につながることもあります。そうした建設的な議論ができれば、チームのモチベーションも高まっていくはずです。

――総じて、マネージャーになった方はプレイヤー時代とは異なる視点で、事業貢献の方法を考えることが必要なのですね。

藤倉：そうですね。ただ、その状態を実現するには、まずマネージャー自身が余裕を持って、事業や組織の未来を考える時間を確保できるようにする必要があります。

私自身がマネージャーになったばかりの頃は、仕事時間の95％ほどを「来た仕事をひたすら打ち返すこと」に費やしていました。でも、そのスタンスだと、永遠に仕事が終わらないんですよね。

マネージャーとして本当に必要な仕事に時間を割くためには、自分から「すぐやらなければならないこと」を意識的に引き剥がしていく必要があります。そして、それができると驚くほど“暇”になります。私は、それくらいまで余白をつくって初めて、マネージャーとしてのスタートラインに立てると思っています。

――ただ、なかなか手持ちの仕事を手放せないマネージャーもいるはずです。仮に藤倉さんの配下のマネージャーがそうなっている場合、どのようなコミュニケーションを取っていますか？

藤倉：そのマネージャーがとても優秀で頼れる存在であれば、当然、重要な仕事をどんどん任せていきたいわけですよね。その際は、ストレートに「あなたの後任を早く育てて、仕事を渡してください。そうしないと、この組織全体の成長が止まってしまいます」と伝えます。それでもなかなかタスクを手放せない場合には、「○月には○○を任せるので、その予定で引き継ぎなどを進めておいてください」と、明確な期限を設けることも多いです。

そのうえで、マネージャーから1on1などで「この仕事は難易度が高くて、どうしても他のメンバーに渡せないです」と相談された場合には、「その仕事はどんなスキルの組み合わせで成り立っているのか」を一緒に要素分解していきます。分解してみると、この部分はAさん、この部分はBさんという感じに、複数人で分担すれば割り振れることがわかるかもしれません。そうやって、委譲のプロセスを設計しています。

――藤倉さんは、問題の性質に応じてアプローチを柔軟に変えること、そして大きな問題を小さく分解することを徹底しているように感じます。最後に、最近マネージャーになったばかりの人に伝えたいことを教えてください。

藤倉：この20年ほどで、IT業界の中には「エンジニアリングを通じて事業に貢献したい」「自社のプロダクトを成長させたい」というマインドを持つ方が本当に増えたと感じています。一方で、「経営課題から逆算して考える」という手法は、まだそれほど定着していません。そうした視点を持つ方が、もっと増えていくといいなと思っています。

私自身、技術も好きですし、コードを書くことにも楽しさを感じます。でもそれ以上に、事業が大きく成長していく様子や、開発組織が活性化していく瞬間を見ることに、すごく面白さを感じています。エンジニアリングとはまた異なる醍醐味がそこにはあります。

そして何より大切なのは、マネージャーになったとしても、エンジニアとしての経験やスキルを捨てる必要はまったくないということです。エンジニアとして培ってきた知識や、構造を設計する力は、経営やマネジメントの領域でも確実に活かされます。ぜひ、今ある土台の上に、新しい層を積み上げていってください。

取材：中薗昴、光松瞳
執筆：中薗昴
編集：光松瞳
撮影：山辺恵美子