あるVPoEの心の中 - 株式会社ヘンリーエンジニアブログ

VP of Engineeringの id:Songmu です。さて、ここ1年くらいプロダクト開発に直接携わっていないので、価値提供に直接繋がらなくなったような、なんとなくの不安感があります。これまでの職場では無理矢理でも何らかの形でプロダクト開発に携わっていたので初めての感覚です。

ただ、採用やエンジニアリング組織周りへのフォーカスは、私自身が望んでいることです。自分が過去所属した組織でやりきれなかったことに対するリベンジであり、ありがたいことに、VPoEとして組織開発の当事者としてそれらの課題に主体的に関わるチャンスを与えられているということです。そのあたりの話は、去年末のエントリにも書きました。

それに、あまり表に出してきませんでしたが、私はなんだかんだ、ここ10年くらいマネジメントだったりエンジニア採用に取り組んできたので、そこに関する発信などもしたいとも思うようになっています。

ちなみに、ヘンリーではもう一人のVPoEである張が、今は現場に入りながら価値デリバリーに軸足を置いて活動しています。VPoE間の役割分担は状況に応じて変化させていますが、このユニーク性については別途お話できると面白いと思っています。

フォーカスの危険性

さて、私がプロダクト開発を兼務していた組織では「今はここまで組織開発をやるとやりすぎだな」とバランスを取れました。「今現場はそれどころじゃない」タイミングが分かり、様子見できたのです。しかし、組織開発にフォーカスしている今はバランスを取るための判断材料が乏しく、物差しが壊れていないかが心配になることもしばしばです。

だから「やりすぎてしまう」組織的ビルドトラップ(作りすぎ)を恐れています。組織のバリューストリームを阻害する、無駄な制度、イベント、ワークショップ等の割り込み業務を作り込んでいないかが怖いのです。それに、価値提供に直接繋がっていないと感じるが故に、なおさら成果を出そうと焦って無駄なことをやりすぎてしまわないか、という懸念もあります。

これは、現場感が薄れて局所最適に陥っているというよくあるやつです。変にSNS等での露出ばかり増やしてチャラチャラせず、価値創造・価値提供にフォーカスしていたい。全社員がそれを意識できている組織こそが理想なのに、私自身がその実感が薄れていることは由々しき事態です。

そんな中で、私がバリューストリームとの接続を感じ、ビルドトラップを避けながら、適切に施策を打つための心構えや考えを再整理したのがこの後の内容です。

築城ではなく船団運営

組織の「土台」や「基盤」という言葉が良く使われます。ただ、こういう言葉は「しっかりしていればいるほど良い」という印象を持たせ、作り込む大義名分を発生させてしまう危うさをはらんでいます。そこに無駄な作り込みが生まれやすくなる。ちなみにシステムプラットフォームに対しても同様の印象を持っています。

これはいわば「築城」のメタファーと言え、そういう建築的なメタファーが悪影響を招く例です。築城であれば一箇所にとどまることが前提ですが、実際の組織が一箇所にとどまることは硬直化のリスクが高いです。

組織開発は築城より船団運営に近いのではないでしょうか。船団の船をどういう構成で組むか、乗組員をどのように分散させるか。例えば、大きい船一つだと一直線に速くは進めるけど、方向転換が極めて遅くなるし、進めない海路も増え、転覆時のリスクも高い。しかし、小舟ばかりになると推進力が弱くなる。そういう制約の中で、船団を実際に運行しながら船を増減させ、変化・適応させていく。そちらのほうが動的な組織運営にフィットしたメタファーであると感じます。

適切なメタファーを意識して、土台や基盤をいたずらに太らせて組織を鈍重にすることを防がないといけません。

支援ではなくエンパワーメントフライホイールを駆動する

組織開発では「支援」や「下支え」といった言葉も良く使われます。もちろんそういう側面もありますが、それが全てではありません。また、開発者以外の職種の人から「自分は開発者・クリエイターではないから価値を生み出す『側』ではない」と言った発言を聞くことがあります。文脈もありますが、個人的には少し寂しく感じます。そんなことはなく、社員全員がフラットに価値を生み出すサイクルに加わっているし、各自がそう思える組織が強いと思っているからです。

例えば、私の場合、人材採用、組織開発、技術広報が現状の大きなミッションですが、組織開発にまつわる活動が組織の価値提供とどのようにつながっており、自分の活動がどこに位置するのかを俯瞰するために整理したのが以下の図です。(まだ整理しきれてないのですが公開します)

これをエンパワーメントフライホイールと呼んでおり、これが滞り無く回り続けることが第一だと考えています。そのサイクルの中での自分の位置づけを意識し、サイクルの中での過剰な部分を削り、手薄になっている部分へテコ入れしながら、サイクルを回し続ける。なので、自分の担当領域をいたずらに固定せず、ポジショニングを変えていくことが前提です。

このように、全体を俯瞰してバリューストリームとの接続を認識しながら、手薄なところを見極めて適切に動き方を変えていきたい。自分の今の領域だけをきっちりやっていれば良いなどと考えて、一部分が過剰にサイロ化するような状況を避けたいと思っています。

コーポレート機能や人事制度は後回しで良いのか？

結局、組織開発もアジャイル開発と同じで必要最低限のことをやりましょう、ということになります。

ただ、スタートアップ界隈ではコーポレート機能や人事制度への軽視も感じます。もちろんミニマムに保つことは必須ですが、プロダクト開発における「当たり前品質」が年々上がっているように、組織に対する「当たり前品質」も年々上がっており、自分たちが意識しているよりかは早めに手を打ったほうが良いと考えるようになりました。

これは、一昔前のスタートアップにおける「SREは後回しで良い」「テストは書かなくて良い」といった風潮に似ているように思います。このあたりは早めに手を付けておかないと、負債が大きくなり、開発速度に影響することが認識されるようになりました。更に、枯れたプラクティスを最初期から導入することで、無駄な負債の発生を防げるようになってきています。

コーポレート機能や人事制度も少し遅れて同様の状況が進行していくと考えています。スタートアップにおいて、コーポレート部門が「これをまだやらなくて大丈夫かな？」と不安を抱えながら、声を上げられない、という状況はよく見られます。もちろん、エンジニアがオーバーエンジニアリングを志向してしまいがちなのと同様に、実際はそこまできちんとやらなくても良いことも多いかもしれません。ただ、それらを俎上に載せて必要性の議論の機会を与えられないと腐るだけです。それらが後々返却困難な負債として襲いかかってくるかもしれません。後回しにされている「組織制度上の負債」には早めに向き合っていく必要があります。