MicrosoftのAzureはどのようなチームによって支えられているのか――「世界一流のエンジニアの思考法」
本書は、MicrosoftのAzure Functionsプロダクトチームで働いている著者とその同僚たちとのエピソードをとおして、一流のエンジニアの思考法を紹介するものである。したがって、Microsoftのエンジニアを世界一流だと思うなら、書籍名は決して誤大広告ではない！
自己啓発な分野の本はめったに読むことはないのだが、タイトルにつられて買ってしまった。
私が最も面白いと思ったのは――皮肉なことに「世界一流のエンジニアの思考法」とは関係ないかもしれないが――チームビルディングの章だ。本書で述べられているように、日本企業はマイクロマネジメントがすぎる傾向にあると思う。
日本の企業では「これをやれ、あれをやるな、○○するときは必ず上司に許可を得てから…」といったスタイルで、主体的に考えて動くことは求められなかった。大企業に勤めるある人は「事業部長クラスでもたかだか100万円の決裁権もない」と嘆いていた。
このように、リーダーが部下を制御するマネジメントスタイルのことを「コマンドアンドコントロール」という。筆者の職場では、リーダーはビジョンとKPIのみ示して、どのように達成するかはチームが主体的に考えて意思決定をするという。このようなマネジメントスタイルのことを「サーバントリーダーシップ」という。詳しくは本書に譲りたいが、サーバントリーダーシップの方がクリエィティブな分野ではよい仕事が成し遂げられる確率は高いのは間違いないだろう。参考文献として挙げられていた「日本企業の社員は、なぜこんなにもモチベーションが低いのか?」という書籍が面白そうだったので後で読んでみたい。
以下の引用からも、本当にチームに裁量があることが分かる。
マイクロソフトには作業上の統一プロセスはなく、基本的にチームをどう回すかもそのチーム次第だ。どんな大きなプロジェクトであっても、少人数から成るスモールチームの集まりで構成される。日本で大規模プロジェクトというと大勢の人がいるのが普通だが、世界的な巨大なクラウドを開発・運用するのに各チームは10人程度と本当に少ない。しかも、実際それぞれの機能を開発するのは「各個人」にまかされている。
多数の少人数からなるスモールチームによって、大きな仕事を成し遂げる。という方法も、Brooksの古典「人月の神話」によって示されているように非常に合理的な方法であるといえる。
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
人月の神話 -- Frederick Phillips Brooks, Jr.
肝心の思考法について、本書では「Be Lazy――怠惰であれ」や「早く失敗する」など紹介されていたが、この業界では割と周知の事実として認知されているような気がしていて、少なくとも私には新鮮味がなかった。非エンジニアにとっては新しい発見があるかもしれない。
他には、コードリーディングに関するエピソードが印象に残っている。私はコードを書くことに比べて、他人の書いたコードを理解することがあまり得意ではないことに長年悩んでいた。筆者も同様の悩みがあったようだが、その職場の一流のプログラマーたちもそうだったというものだ。これを読んでちょっと嬉しくなった笑
全体的に楽しく読ませていただいたものの、結局のところ自己啓発本であり、読んだだけでは読み手が何か変わるわけでもない。再現性に対する疑問もある。一番気になったのは文化の差だ。本書の内容をそのまま伝統的な日本企業で実践するのは困難だと思うし、実践できる場合は、そもそも一流の職場で働けている一流のエンジニアな気がするので、結局誰向けの本なのかわからない気もしなくもない笑
例えば、以下のようなエピソードは文化の差を感じるかもしれない。こんな対応をしていたらお客様に怪訝な顔をされてしまうだろう。
日本で私がアジャイルのコンサルタントをやっていた頃、こんな事件があった。マイクロソフトのソフトウェアエンジニアプロセスの専門家サム・グッケンハイマーが来日し、私がアテンドする中、大手企業を相手に開発プロセスの説明をしていたときのこと。「ウォーターフォールとアジャイルのメリット・デメリットは何ですか？」と尋ねたお客さんに、彼はこう言い放った。
「ウォーターフォールは一切メリットがないのでやめておきなさい」
最後の章に、COCOAアプリにまつわる日本の「批判文化」について言及があったが、筆者自身も文化の差による思考法の適用の制限は感じているのではないだろうか。
他にも「納期がなく、マネージャーもせかさない」という話もあったが、これもMicrosoftのAzureの開発チームのような特殊な職場だから可能なのだと言えるだろう。これまたBrooksが言っているとおり非常に効果的な手法に違いないのだけれど。
時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
人月の神話 -- Frederick Phillips Brooks, Jr.
本書で紹介されている思考法が、あらゆる読み手に対して適用可能な方法かはかなり懐疑的だが、筆者が世界一流のエンジニア達と働いていることは紛れもない事実である。Microsoftのようなインターナショナルなチームで働く予定のある方はぜひ一読しておきたい書籍だ。