少しずつ読み進めていた本が読み終わったので感想を書いてみる。
IT/Webエンジニア界隈で結構有名な「世界一流エンジニアの思考法」という本。
アメリカでマイクロソフトのエンジニアとして働く著者が、日本とアメリカのIT企業の労働環境や開発文化、考え方の違いについて自身の経験をもとにまとめている。
こういう本って意外と今までなくて、これまで僕はネットの情報をもとになんとなく「アメリカのソフトウェア開発は日本より進んでそう」みたいな先入観しか持っていなかった。
一応触れておくと、この書籍が紹介しているのはあくまでマイクロソフトという一つのアメリカを代表するIT企業の開発文化（の一部）なので、それがイコール、アメリカの開発文化のすべてってわけではないと思う。
例えば同じアメリカの会社でも、僕が携わってるようなモノづくり業界は（日本が世界を牽引していることから考えても）日本に少し近いところがあるんじゃないかな、と僕は想像している。
この点についてはあとで少し言及する。
この本は読んでいて思うことがたくさんあった。
全部書き出すとキリがないので、ひとつだけ。
「第5章 生産性を高めるチームビルディング」に絞って、感想とか自分の意見みたいなものをつらつら述べていこうと思う。
僕はこの章がこの本のキモだと感じた。
なお本記事では、めんどくさいので「アメリカ」と「マイクロソフト」って言葉は区別しないで使う。
ほぼ同義だと思ってください。
第5章の概要と感想
第5章では、はじめに日米のマネジメントスタイルの違いについて次のように言及している。
日本はコマンドアンドコントロール型マネジメント
リーダーが部下に指示を出し、部下の状況を把握、確認し、管理していく。
日本の会社でも一般的な、いわゆる「マイクロマネジメント」だ。
アメリカはサーバントリーダーシップ型マネジメント
リーダーは＜ビジョンとKPI＞は示すが、実際にどのように働くかは、チームが主体的に考えて意思決定していく。
ビジョン、戦略、KPIの三つは明確だが、誰も指示をすることはない。
日本企業と比べると、現場のメンバーがかなりの権限を与えられて、どう実行するかを各自で考えている。
その上で、アメリカの開発文化の特徴として次のようなことを挙げている。
- 基本的にメンバー各自がやりたい仕事を「自分がやるよ」と選択していく
- メンバーが「楽しんでいるか」が非常に重要視される
- マネージャが「あれしろ、これしろ」と細かく指示することがない
- 納期がなく、マネージャも急かさない
ウラヤマシイナア！！
こんな労働環境で働けるなら、
そりゃあ日本出てアメリカで働くよなあ！！
これが読後の僕の正直な感想である。
次に、これらについて僕の意見をつらつらと書いていく。
自分の意見みたいなもの
まず、サーバントリーダーシップ型って要するに日本でいうところの「仕事の丸投げ」のことだよなーと思った。
日本のSIer（受託開発会社）でおなじみの「請負契約」とかもそう。
もともと日本でも、クライアント企業とSIerとの関係はサーバントリーダーシップ型なんだ。
だけどアメリカでは請負契約に規定されているような「納期厳守」や「瑕疵担保」などの厳しい法的責任はない。
ここがアメリカの開発文化の大きな特徴だと感じた（ただしアメリカの企業では、成長がなかったり向いてなかったりするとクビになるみたいけど）。
ある意味これらの厳しい法的責任を達成するために、日本のSIerは自社や協力会社（SES企業）のエンジニアに対してコマンドアンドコントロール型にならざるをえないってのが実情だろう。
加えて、納期内に少ない工数で納品できた方が利益率が高くなるので、自分たちで考えてより良いものを作っていこうという意識も生まれづらい。
必然的に「開発効率」がもっとも重視されるようになる。
そういう背景もあり、昨今では日本でも「準委任契約」によるアジャイル開発を推すようになってきているよね。
でもフリーランスエンジニアとして現在、準委任契約でのアジャイル開発の案件に携わってる身としては、これもそこまでうまくいってない印象がある。
どういうことかというと「コマンドアンドコントロール型でマネジメントされてる感」があるんだよね。
こうなってしまうのには、いくつか理由があると考えている。
ひとつには、業務を依頼する側のエンジニアが、協力会社のエンジニアへの「仕事の丸投げ」はよくないという先入観を持ってるパターン（プレーヤーとして優秀な若手に多い）。
言い換えると「マイクロマネジメントが正しいマネジメント」だと思ってる傾向があるってこと。
もしくは「仕事の丸投げでは舐められる」と思ってるのかもしれない。
もうひとつは（たぶんこっちが根本的な問題だと思うけど）クライアント企業の部署間での力関係などにより、部署間で「請負契約」みたいな関係が発生しちゃってるパターン。
企画とかマーケみたいな上流工程を担当してる部署って、開発を担当している部署より力関係で上になりがちだよなーってはたから見て思うことが多い。
企画やマーケ主導で勝手に納期や仕様などが決められてしまい、開発は「納期厳守」と「瑕疵担保」の責任を果たすためにSIer同様、コマンドアンドコントロール型にならざるをえないって感じ。
そのため日本企業が、書籍で述べられているようなアメリカの開発文化的なサーバントリーダーシップに移行するには、商流元企業の組織文化ごと変わらないとだめなんだろうなと感じる（この点に関しては書籍でも言及されているね）。
日本企業の中でもスタートアップやベンチャー企業に比較的欧米的な文化の会社が多いのは（僕が以前勤めていたベンチャー企業もそうだった）、「組織ごと」変わるのが大企業や中小企業に比べて容易だからってのがあると思う。
とはいえ、冒頭で少し触れたようにモノづくり業界は（ハードウェア開発が関わってくるため）事情がIT/Web業界とは少し異なる。
ハードウェア開発はアジャイル開発よりウォーターフォール開発の方が適しているので、そういうのが組織文化にも影響しているように感じる。
ハードウェア開発の文化が根付いている企業に、先進的なソフトウェア開発の文化を導入しようともがいている、現状そんな印象を受ける。
今後も業界人として動向を見守っていきたい。
ばいちむ
(*´︶`*)♡Thanks!
本記事で紹介した本。
エンジニアやIT業界の人でなくても分かるように解説してくれているので、興味あればぜひ手に取ってみてね。
第5章だけでも読む価値あり。
