考えるスキルを持つエンジニアを育てるなら組織はフラットにチームは小さくしなければならない

on


指示待ちエンジニアとは、自分の灰色の脳細胞で意思を持って考えることを放棄したエンジニアである。この指示待ちエンジニアは、言われた、指示されたことはそのとおりするのだが、その指示に間違いあっても疑問に思うことも、止めることもしない。なぜなら、意思を持って思考していないからだ。


これは本当に困る。いつ困るのかと訊かれれば、全てにおいて困る。何せ、自分で思考しないのだから、考えるところからアイデアを出すことはない。作業をするにしてもその手順と実機の環境で差異があっても疑問に思うこともなく進めてしまうのだ。これは作り話じゃない。なんどとなく目の前で繰り返されてきた事実だ。


ワタシは階層構造の少ない組織が好きだ。権限分掌がわかりやすいし、分掌をまたがることも少なく調整が少ないからだ。そして、最終権限を持つマネージャまで自分でアプローチできるからだ。多段構造になればなるほど分掌は細分化され、インタフェースを取るためのオーバヘッドが重たい。多段になればなっただけ、最終権限を持つマネージャにたどり着くまでに改装分だけバイアスが掛かる。階層構造の分だけ、ワタシの意思は削がれてしまう。


だからワタシの組織は可能な限りフラットにしてきた。組織のルール上、裁量で設けることのできた下位構造を頑として作ることを拒否した。複数ある同列の組織は吸収した。これで、エンジニアというリソースをプール化して、プロジェクトのチーミングの幅を持たせるのだ。


組織は細分化するとそれだけしかできないエンジニアを作ってしまいがちになる。それは、その組織が専門のソリューション領域を持たされてしまうからだ。OSだったり、アプリケーションサーバのミドルウェアだったり、データベースだったり、ハタマタ、パッケージアプリケーションだったり。


プロジェクトのチームが大大規模のときも注意が必要だ。その状態が長く続くならよりリスクは高まる。それは、インフラでもアプリケーションの開発でも起きる。大勢のチームでは、役割が機能単位に細分化されやすい。そのため、自分で考える幅が制限されるのである。一担当の領分だけ、の仕事をするのだ。プロジェクトが大規模ならその構造は段階を生み、作業は上から落ちてくるようになる。それはエンジニアとして唯一の裁量である考えるという領域を侵食するのである。そしてやがて、考えないエンジニアを醸成してしまう。


それが長い時間、何度も繰り返されることで人であるエンジニアはその環境に慣れてしまう。人はパターンが均衡した状態になってしまった環境下で意思の有無にかかわらず仕事を繰り返してもdeliverableが生産されるためにそれで良しとしてしまう。そこには現状を維持しようとする意思しか働かない。その環境には変化を求めるための意思も思考も働かない。


作業が細分化されると、工程の分担においてロールの硬直化が起きやすい。限られた裁量であるから故、それ以上を知ることもないし、其れに慣れてしまうと知ろうともしなくなるのである。プロジェクトが終わればそのままの同じようなプロジェクトで同じようなロールの経験だけを買われ、同じようなロールを担うのである。それは、何か外的要因か強い意志が働かない限り同じ役割分担を踏襲してしまうことで部分最適化が働くためだ。


エンジニアは、新しい技術、未経験なことをするときに一番思考をするものだ。なら、いつも同じメンバで同じロールで仕事していて何時思考するのだろうか。一担当としてずっとやっていたらいつ自らが意思を持って考えようとするのだろう。人は楽な方に流れてしまう生き物だ。それを忘れてはいけない。


組織をフラットにしてプール化することで、プロジェクトの情況によりチーミングを柔軟に組み合わせてチームというパズルを組み上げないといけないシチュエーションがまま起きる。エンジニアの自己伸長の機会を与えるために、ロールのステップアップを考慮したアサイメントをするときもある。何れのケースも、プール化することで母体としての幅を生むから組織の継続的な人材育成とエンジニアの成長の機会を作れるのである。エンジニアの成長帳に合わせ、新しくチーミングをしたチームはしばらくは同じ組み合わせにして成長をウォッチするのである。


組織でプロジェクトのチーミングの幅を持たせることも大切だけれど、チームは可能な限り、小さくした方が良い。必要なスキルセットの一パートしかできないエンジニアを安くかき集めるより、マルチスキルエンジニアを少数集めてチームを組み合わせた方が何倍もいい。


チームの人数が少ないということは、それだけメンバ一人ひとりが当事者になって自分の頭で考えさせられる場を作るということと同じなのである。限られたタイムボックスの中で、求められるdeliverableを完了させる実地での訓練に勝るものはないのである。


結局、エンジニア自身が責任ある当事者として振る舞わないといけない場を用意し、それを幾度となく挑戦させるほかないのである。