こちらの記事は、カケハシ Advent Calendar 2022の25日目の記事になります。
こんにちは、四番隊隊長とは声が低いこと以外何一つ共通点がないCTOの海老原です。
すみません、タイトルは釣りタイトルです。何故こんな釣りをアドベントカレンダーのラストに持ってきたかですが…しばしばスタートアップの経営陣の最大のミッション・役割の一つとして採用が挙げられますが、ご多分に漏れず私も日常の時間のかなり多くの部分をソフトウェアエンジニアやデザイナー、プロダクトマネージャーのような開発系職種のカジュアル面談での事業説明やオファー面談に割いています。
その中でよく候補者の方からご質問を頂くわけですが、会社として外に発信している内容の特徴的な部分に関する質問になるため共通の質問も多く頂きます。それらについて、特に頻出且つ重要な事柄について記事化することで事前に会社・組織に関する考え方を知って頂けること、改めて言語化することで自分自身整理すること、酷使によって慢性的に調子の悪い喉の負担を少しでも減らすことを意図しています。では、今回取り上げる頻出質問とは一体どんな質問なのか?
「組織の規模が拡大してもフラットな組織を維持できるんですか」
はい出た。特に最近非常によく聞かれるようになった質問で、これについて以下で述べていきたいと思います。他にも頻出質問はあるので、それらについても今後何らかの形で出していけたらと思っています。
まず結論
先に私自身が件の質問について端的にどう考えているかを書いてしまうと、
難しいができるしやっていこうと思っているが、「フラットな組織」が意味するのが組織のグルーピングやそのネスト、グループごとのリーダーシップが存在していないことを意味するならそもそも既にカケハシはもうずいぶん前からそういう状況ではない。「フラット」的な何かはそういう形式や構造の話ではなく、合意形成の際の考え方やリーダーシップを担うもののメンタリティに関するスタンスの問題である。ということになります。
現状の組織設計がどうなっているか
まず組織の最大単位としてdivisionがあり、私の管掌範囲であるサービス開発divisionは(直接私へのレポートラインがあるチームもいくつかありますが)その中で事業ドメイン、プロダクト、スクラムチームという風に分割されていきます。私はそういう認知フレームの形成を避けるために普段描き方としてはしませんが、これは普通に描いたらいわゆる階層構造的な設計です。
「フラット」が意味することを「権力勾配の傾斜の小ささ」と捉えた時に、通常の組織・制度設計で必ず発生するのが給与(昇給)を確定するために評価する・されるという権力勾配の傾斜でしょう。実際一切の評価制度が無い組織設計も時々検討したりかなりそれに近いことをやったこともありますが(その当時のやり方が今でも内部の評判は一番良かったりする)、現在の規模感における破綻のない設計が難しくこの傾斜については所与のものと受け止めています。そして、傾斜が所与のものである以上、それを最大限活用するためにこれまで曖昧だったピープルマネジメント領域の要件やマネージャーロールの明確化を進めています。これについてはまた別途発信することもあるのではないかと思います。
今はスクラムチーム内で評価・被評価という関係性は無いですが、これもプロダクト内のスクラムチームの数が増えればプロダクトを見ている評価者のキャパシティの問題で各スクラムチームに評価者を置いていく設計になっていく可能性は非常に高い。それ以上階層が増えることは現状あまり想像していないですが、いずれにしても事業部・部・課のような分けと見た目としてはたいして変わらないものです。総じて、マネージャーロールの明確化やある程度多段化された組織階層は「フラット」という単語から直感的に受けるイメージとは既にやや隔たりのある設計と言えるでしょう。
そもそも「フラットな組織」は神託ではない
当たり前すぎて書くまでもないかもしれないがおさえておきたい前提として、「フラットな組織」は単なる手段であって目的ではありません。顧客や市場により良い価値を素早く提供するためという合目的性の立場からそのような進め方をしているのであって、「そっちの方がなんかいいから・好きだから」ではない。何故こんな当たり前のことをわざわざ強調するかというと、「フラットな組織」という概念についてよく発生する2つの両極端なスタンスがいずれも印象先行でこの前提から遠ざかっていると感じることが多いからです。ではその2つのスタンスとはどんなものか。
「フラット」=スピードが出ない?
一つは、「フラット」はトップダウンに比べてスピードが出ないという言説。実際、元々上意下達な組織で指示・命令によって業務を進める文化に慣れ親しんだ人、自分の仕事に自信を持っておりその通りに進めることが最適解であるという認識が強い人から入社後に「仕事が進めにくい」と陰に陽に抗議を受けることはあります。「フラット」でイメージされる進め方は議論・対話を重んじるため、直感的には「上が考えて決め下が従い実行する」やり方の方が速いということはありそうです。ただ、この「速い」ということに罠があります。
原始的な集団作業のような個人の認知能力でその工程と結果の全てを把握できるケースであればその個人が細かい具体のやり方まで検討し作業者がその意を受けて実行することで特に大きな問題も起きませんが、複数の高度な専門性の協働が必要で構造が複雑なソフトウェア開発ではそのような世界観は通用しにくい。実践の手段における課題を考慮しない企画・仕様の検討は実現可能性や工数のリアリティを失いますし、やろうとしていることの本質に対する丁寧な認識合わせを欠いたままの実践は本当に実現したかったことを反映しないものになりがちです。これらはいずれも後の多くの手戻りを予感させるものであり、現実に起こったとしたらそれは本当に「速い」ことになるのか?ということです。実際、これまで在籍した多くの職場で、個人として非常に有能で自分の考えの正しさに強い自信があるが故に探索的姿勢や認識同期よりも見かけ上の速さを優先した結果却って遠回りになっている事例を見てきました。有能ではなかったですが、自分自身も多くの同様の反省があります。
見た目上のスピードを根拠に否定するのは、「フラット」に対する印象が先行して「価値あることを素早く」という本質から遠ざかっているように見えます。実践的な価値と素早さのために自身の無謬性に疑いを持ち集合知への信頼を持つ、ということは難しいが価値のあるトライだと思います。
「フラット」=リーダーシップの不在?
もう一つは、逆に「フラット」に進めようという意識が目的化して「決めて実行する」機能がおろそかになるケースです。皆から広く意見を募り、反対意見も十分に慮って結論を出すのは集合知を重んじる観点から基本的には良さそうなアプローチに見えます。ただ、これには程度の問題があり、「進める」側「受け止める」側それぞれなりのずれがあることが多いです。
「進める」側としては、何らかの仮説設定や考え方の起点レベルでの最低限の詰めがない状態から皆の意見を取りにいってしまうこと。発散のためのブレストであれば目的に適っていますが、そうでなければ「何のためにそれを行おうとしているのか」「何を行おうとしているのか」というビジョン・方向性のベースはまずは合議というよりも主体者が明確化してから人を巻き込まなければ無用の発散を招きます。また、「決める」局面で反対意見への配慮が強くなりすぎて議論をこね回していると意思決定に遅延を招きます。
「受け止める」側としては、上記の裏返しですが「フラット」という概念・進め方にこだわり自身の意見の受け入れ、そのための議論の継続を要求し続けるようなケースがままあります。これはむしろ当事者意識の強さの発露として発生することが多いですが、去年も引き合いに出した「LEADER'S LANGUAGE」の中の「反対意見も取り入れて考慮するのは重要だが、一つの反対意見を理由に決断が下せない状況は反対意見の持つ権力が強すぎる(大意)」という考え方に尽きると思っています。これも、「進める」側「受け止める」側両面において自分自身も多くの同様の反省があります。
見た目上のフラットさに足を取られて個人によるスタート地点の定義や決定機能を弱めるのは、「フラット」に対する印象が先行して、「価値あることを素早く」という本質から遠ざかっているように見えます。総じて組織に関する概念はそれ単体で成立することは少なく、一見対立するように見える補佐的な視点の同居が必要というのが私の実感です。集合知への信頼をベースにして全員で同じ方向を向いて目的を達成するためには、明確な意志を持って始め決断をする個人の強いリーダーシップが同時に必要です。
「フラット的な何か」によって何が得たいのか?
既に組織の設計としてあまり通常の会社組織と変わらず、そもそも形式としての「フラット」が求めているものではないとしたら残るものは一体なんでしょうか。これは、ややもすれば言葉遊びのように感じられることもあるかも知れませんが、合意形成や意思決定における組織としての考え方・受け止め方に「フラット」的な何かが体現されている状況を作りたいということになります。
昨年の記事にも書いた通り、私はVUCAな世界への対抗策としての「思考と実践の一体化」への欲求が強いです。これは企画と実装のような開発の現場でもそうですし、経営陣と従業員、より抽象化すればある意思決定の主体者とそれをサポートする側の全てのケースで同様です。この相互の距離が遠くならず、フィードバックによってお互いの思考や行動が常により良く改善し続けていくような状態が望ましい―つまりそれが私にとって「フラット的な何か」によって実現したいこと―と考えています。
そのためには、リーダーシップを発揮する側は強い意志を持ちつつも一緒に実現化を行う人々からの意見による方針変更の可能性を強く意識し周りにも示していくことが必要であり、周囲には自身の優先順位をリーダーシップ発揮者にフィットさせつつ自身の言動によって重要な方針変更も起こしうるのだという信頼とその実践が必要になります。更に重要なのは、これを個々人の心がけとして頑張ってくださいねという議論で終わるのではなく、組織の設計や様々な施策がこのような認知フレームを形成することを意図して行われていること、つまり組織のアーキテクチャとして実現されている=経営の課題として解決していくことだと捉えています。
"勇気"を持って歩み続ける
去年に引き続きあまり具体性の無い心意気レベルの記事になってしまいましたが、「開発だけでも100人超えてフラットな組織なんて現実味あるの?」という疑問に対して、少なくとも私がどう感じ考えているかについてはある程度回答できたのではないかと思います。
正直に言って、実現したい状態のところで述べているようなことはややもすれば矛盾しかねない複数の考え方を併せ持つ必要があり認知負荷が高いです。苦労を考えればマネージャーが考えてメンバーが粛々と実行するような組織の方がシンプルで分かりやすい。しかし、私自身これまで見聞きした組織の中で規模や時期の局所性はあれどまさに「フラット的な何か」が体現された素晴らしい顧客価値創造の瞬間を実感しており、まだ規模を理由に諦めるにはできていないことが多すぎる。四番隊隊長の最終回のお言葉を胸に、"勇気"を持って歩み続けたいと思います。
もう少しカケハシにおける具体が聞きたいとか、言うて色々失敗していることもあるんじゃないのなど、割と聞きにきた方が驚かれるぐらい率直に赤裸々に良いも悪いも含めてお話していたりもするので、ご興味持って頂けたら是非カジュアルにお声がけ頂ければと思います。
