エンジニア組織戦略を構築する上での6つのポイント

最近色々な方と話していて、組織運営上戦略が必要という話をしているんだが、私の説明力が足らずなかなか伝わりづらく、言葉だけで話すのは難しいなと思い、整理する必要性を感じた。ということで、まずは主に全体像であり概要をアウトプットしてみた。やってみると、自分の頭の中の整理にもなり、足りないこともわかった。アウトプット重要。今後はこの図と説明があれば、話をするときにはどの話をしているかがわかりやすくなりそう。

なお、番号をつけたが、この順番で考えればいいとは限らない。もちろんレイヤーが大きいところから決めていったほうが変更のコストは低いが、物事はそんなに簡単ではない。常にすべてのレイヤーで考え続け、それぞれにフィードバックをかけ続け、変更し続けなければ組織は成長しない。

今回書いたのはあくまで枠組みの話なので、この中に取り入れる何かは組織や人によって違うべきであると考えている。ただ、私なりにこの方がいい、みたいな話はあるので、詳細についても連載的に少しずつ書いていきたいと思う。

1.経営方針/戦略及び（プロダクトがあれば）プロダクト方針/戦略の明確化

すべてのエンジニア組織戦略の目的はここにある。エンジニアが好きなようにやるためではなく、会社や事業の目的を達成するためだということを忘れてはならない。まずは会社としてどのような方向に向かいたいのかというのを前提に、エンジニア組織戦略をつなげていくという事が必要である。組織戦略を策定するメンバーはおそらく経営層の一部として稼働していることが多いと思うので、その議論にも参加し、エンジニア組織戦略と経営戦略を結びつけるということを行っていくとよりつながりやすい。

2.エンジニア組織として「どうなりたいか、どうしたいか」の明確化

経営戦略とつなげる前提として、我々としてどうしたいかというのを明確にする。経営戦略があれば方程式的にエンジニア組織としてどうすべきかが導き出せるわけではない。そこにいるリーダーがどうしたいか、どういうスキルや性格のメンバーが居るか、どういうプロダクトを創っているか、現状どういう技術を使っているかなど、多くのパラメーターがある。最終的には、例えばCTOのようなリーダーの決めの問題の領域なので、強い思いや実力がそのまま出る。リーダーは最終的には批判を覚悟で決めなければらない。そして結果は自分の実力として受け止めねばならない。リーダーは辛いよ。

とはいえ、一人で全てを決められるわけではない。例えばエンジニアチーム全員、もしくは主要メンバーで合宿をすると良い。何泊か温泉でも行って、深く長く話し合い、同じ釜の飯を食って、実際実行するメンバーと方向性を決めることができると、メンバーが方向性を理解して動けるので、その後も相当やりやすくなる。

3.実現する手段に分解

どうなりたいかを言語化した後は、どういう手段を選択すればそれが実現するかを明確にする。どの粒度まで分解するかは、組織のフェーズや状態にもよるし、初めて戦略づくりをやるのであれば、まずはざっくりでも良い。ざっくり作ってやってみて、1ヶ月後か3ヶ月後かに軌道修正すれば良い。わからなければ決めて動くとフィードバックが得られて、常に組織が成長することができる。ただ、何も考えずにただ決めると学びも薄くなるので、少なくともリーダーはこれ以上考えられないというレベルまで考え尽くした上で決めたほうが良い。

ここからの作業が最もリーダーの実力を問われる。これは「設計」である。ソフトウェア設計と同じだ。目標を実現するために、組織全体をどう設計するか。現状、未来、課題、すべてを頭のなかに叩き込んで咀嚼し、全体像を構成し、整理し、現状の結論を出す。ここからのフェーズをちゃんとできる人はあまり見たことがない。私はこの作業は「右脳」の仕事だと思っている。情報は出来る限り集め、ロジカルに分析することは必須ではあるが、ロジックだけでは結論は出ない。なぜなら、全てロジカルに整理することなど不可能だからだ。課題は無限にある。どうしたいかなんてのは人によって違い、自分の中にしか無い。最後は価値観や倫理観、想いで決める。

4.現状の課題設定と施策

方向性が見えたら次は現状分析である。いくら素晴らしい目標を立てても、そこに到達するには、今の自分達の状況を見つめるしかない。スタートラインは常に「今」だ。そこから何をやっていくのか、何をやらないのか、明確にしていかなければならない。現状の課題を見ると、結構辛くなる。愚痴も言いたくなる。なんでこうなっているんだと過去を責めたくなる。しかし、その時間はすべて無駄だ。現状や過去を嘆いても何も変わらない。合宿等でその気持ちを一旦吐き出す場を作ることは、未来に向かっていくには重要な事だが、それが終わったら忘れて未来を見よう。

ここで一番むずかしいのが「何を捨てるか」である。すべての課題を解決することはできない。にも関わらず、多くの課題が重要だ。ただ、経営リソースや人数には限りがある。全てを解決することは不可能だ。自分たちの行きたい方向と照らし合わせながら、解決すると最も効果的にその方向に向かえる課題を選択しなければならない。課題の断捨離。これもリーダーの決めの問題である。リーダー頑張れ。

5.マイルストーン、スケジュール

方向性と解決すべき課題が明確になったら、マイルストーンである。いつまでに何をやるかを立ててみるのは非常に重要だ。計画というのは基本的にその通りにならない。でも、計画を立ててみると、見えることがたくさんある。絵に描いた餅であること、思ったより早くできるかもしれないこと、費用対効果が合わなそうなこと、など色々だ。もし、何か不測の事態が起こった場合は、変えることを躊躇してはならない。自分は未来を予測できるんだ、という自惚れはすぐに捨てなければならない。自分たちは常に未完成だ。問題があればすぐ変えよう。

私の大好きな言葉を紹介しよう。
agnozingdays.hatenablog.com

6.組織運営プロセス（チーム構成等人事含む）

戦略は実行されなければならない。それこそ絵に書いた餅になる。実行できるチーム構成を明確にし、日次もしくは週次で行うミーティングなどを明確にし、情報が行き渡り、課題が共有され、解決するサイクルが回るようにならなければならない。

レイヤーを書いて表現したのだが、これは上下関係を作りたいのではない。組織が大きければ大きくなるほど、問題の粒度が変わるので、すべての視点で問題を捉え、解決策を考える必要がある。例えば、何かメンバーから見て会社のルールがあり、それが問題だったとして、経営レベルではそのルールを変えられてしまう。問題を解決するのではなく、無くしてしまうことができるのだ。また、経営レベルで見えなかったとしても、ユーザを見ている現場では大きな問題が見えることもあるかもしれない。それは優劣ではなく、問題の種類が違う。そのため、すべてのレイヤーで課題と解決策を流通し続けなければ根本的に組織の問題は解決しないのだ。

また、もう一点重要なのは、組織や課題は生モノだということだ。放っておくと腐ってしまう。課題を一つのところに滞留させてしまうと腐りやすくなる。一つ腐ると周りにも腐敗はでんぱする。常にきれいな水を流し続け、きれいにし続けなければならない。だからプロセスはとても重要なのだ。プロセス自体も当然腐る（マンネリ化など）ので、常にきれいな状態にしなければならない。

最後に：書いてみて思ったこと

ここまでざっくり書いてみた。考慮すべき点はこの中に大量にあるのだが、それはまたの機会にアウトプットしてみようと思う。

私はこの内容はエンジニア組織だけではなく使えるのではないかと思う。少なくとも、過去に私が一緒にやっていたデザイナーの組織には使えると思った。デザインの方針というのも会社の戦略上はとても重要だ。

戦略を作るのは簡単ではない。常に悩みながらやってきていて、まだまだ力不足な部分も多い。ただ、色々見ていて思うのは、

• 戦略を作り実行できることと、技術的に優れていることは別
• 戦略を作り実行できることと、人のマネジメントができることも別

ということだ。共通点としてリーダーシップが必要だということはあると思う。行きたい方向も戦略も最終的には「決めの問題」である。いくら優れた戦略を作れても、決められないのであれば実行できない。批判を覚悟で決める、というか基本的に批判はされるもんだ。でもそれはただ闇雲に決めることではない。自分としてはある意味自信をもって決める必要がある。それには、今無いものを創っていく想像力と、そのイメージを言語化すること、時間軸上で組み立てる設計力が必要。

とても難しい。だからこそ価値があるなぁと思う今日このごろでした。