カオスの世界が秩序の世界を圧倒してるかもしれないという話
私は米国でマイクロソフトのクラウドのサーバレスプラットフォームの開発者をしている。今日はふと気づいた「良い」と思っていたことがもしかするとソフトウェア開発だとちょっと違うかもということに気づいたのでシェアしたいと思いました。
私の意見は自分のものであり所属会社とは関係ありません。
日本はめっちゃくちゃきっちりしている国
アメリカに来て思うのは「日本はめっちゃくちゃきっちりしてる国だなぁ」ということだ。電車は時間通り来るし、宅配を頼んでも荷物がボコボコではないし、サポートの対応がめっちゃ適当なことも無い。仕事においても、本人がどういう性格であれ、とりあえず「きっちり」することが求められる。資料は整理され（もしくはしようとは一応頑張る）いろんなことを順序だてている。これは素晴らしい事だ。個人レベルではとても素晴らしことだと思う。物事が整理がついているというのは生産性の面でも素晴らしい…はずである。
アメリカのソフトウェア開発
コンピュータサイエンスの世界で断トツの No.1 であるアメリカはさぞかしきっちりとして…いません。各個人が責任をもって個人商店の集まりの様だし、細かい計画なんて立てないし、見積もしない。最新の情報はドキュメントに整理…されているわけではなく人の頭にあったりチームのスレッドにあったり…個人的にきっちりした人はきっちりとドキュメント化してたりしますが、そうでない人の方が多いかも。
デプロイメントフリーズの違い
皆さんは何と呼んでいるか知りませんが、デプロイメントフリーズという考え方があります。何かのリリースをするときに、新しい機能追加を一定期間やめる行為です。なぜならソフトウェアに変更を入れると障害が起こる可能性があるからです。だから、「No fly」と言って重要なイベントがある場合は、新しいデプロイをしないこともあります。
新しい機能を開発している時は、大きなリリースの前には、このデプロイメントフリーズをすることが日本でもアメリカでもありました。しかし、結構このノリが違うことに気が付きました。
日本では計画してかなり前から開発を終えてテストしてデプロイメントフリーズをして実際変更しません。（燃えてるプロジェクトではない場合）そして、実際がっつりフリーズするので、本番も問題が起こることは本当に少ないイメージです。（繰り返しますが燃えてない場合）
フリーズ？
ところが、こちらでは、フリーズはしませんが、P0 と呼ばれるこれが動作してないとリリース出来ない致命的なもの以外は優先順位を落として、P0 issue もしくは P1 のみ対応する感じになります。たまにびっくりしますが、こういう状態でもがっつりコードを変えたりする人もいます。だから、たまに結構直前になっても、問題が起こることがあって、個人的には「なんでデプロイメントフリーズせえへんねやろ？変更したとしても超安全なのものにとどめたらええのに」と思うこともありました。
カオスの裏側
そんな時に頭によぎったことは、「じゃあなんてアメリカの方がソフトウェアが強いの？」ということです。アメリカの開発の方がどう考えてもカオスで、整理整頓されていません。
そんな観察をしていてふと思ったのは「もしかして、カオスの方がエンジニアが強くないといけなくない？」という事でした。
日本にいるときは整理されていて、「自分が居なくなっても誰でもわかるように」という事が実際できるかどうかは別としてお題目としてあります。
ところが、こちらはそんなことはあまり考えてない雰囲気です。ユーザーには手厚いドキュメントが用意されていますが、開発者はいろいろ開発中なので、しっかりしたドキュメントなんてありません。自分が全く変えていない個所が急遽トラブルになって動かないこともざらです。
だから、自分で仕様を明確化して、自分の知らないコードを読んだり、エキスパートに聞いたり、半分ハックみたいなことをして物事を理解して開発をしたりします。
カオスがエンジニアを底上げする
自分がいかに慎重にやってようと、他の人が書いた部分ががっつりこけることもあります。そんな時も原因を分析して Root Cause を見つけて、その Fix を実装する必要があります。アメリカにいると誰がいつ Vacation にいくともわかりませんので、キーマンが一定期間いないこともしょっちゅうです。それでも何とかしないといけません。しかも短い時間で。障害は待ってくれません。そういう自分が出来るかわからないことにチャレンジすることで、次の技術力の扉が開く感じがします。
つまり、このカオスな状況をハンドルするためには、エンジニアとして強くなるのが一番楽な方法かもしれません。
そして、実際のところ、このやり方はめっちゃくちゃに見えるかもしれないですが、結局開発のスピードは速いですし、変化への対応も強力に感じます。やっぱりソフトウェア開発の生産性の肝はチームの「各個人のスキル」をいかに高めるかなのだと思います。
日本に居てた時の作戦
ちなみにこれは私が日本にいるときも同じで、当時はマネージャとかコンサルでしたが、自分が絶対に成功させたいプロジェクトがあったら、イケてるプログラマを探すことに全力を費やしていました。「そんなの無理」とよく言われていましたしみんなしなかったのですが、日本でも探す努力をすれば沢山見つけることが可能です。
そういう人を集めて楽しい仕事を作って、楽しく開発をしてもらうと、失敗する確率が物凄く低くなるので、私は常にそういう戦略でした。ちなみに新人が来るときもありましたが、誰でも出来る方向じゃなくて、彼を技術イケメンにする方向性で技術レベルを下げませんでした。そしたら、周りの技術イケメンから吸収して普通の新人よりめっちゃ早く成長してくれました。（ちなみに技術イケメンは私の用語で、性別は関係ありません）
失敗はあるもととして、チームで難しいことに挑戦する
だれでもできる方向に舵を切るのではなく、チームのメンバーの実力を上げて自律的に動けるようにするのがやっぱり生産性にはとても効いていそうです。
あとは、こういうカオスでチャレンジングで、失敗しても誰もなんにも言わずに、みんなで解決しようとするチームのムードは「失敗するか成功するかわからないものに挑戦」することを簡単にしていると思います。
実際だれかがバグを作ったとして、その人が責められているのを見たことがありません。そして、「誰もが出来る」ようにするではなく、「みんなを信じて実力上げる」方向にあるから、その後も継続的にチームとしての実力が上がっていっているように感じます。
自分の「保守性」に気づく
そんな姿勢があるので、誰も「絶対出来る」「安全」な方に舵を切らないので、こんなカオスなアメリカの現場が面白いものを沢山生み出しているのかもしれません。
今回は自分が経験したことと、頭の中で考えていたことをノートにまとめてみました。この過程で私自身も考え方が保守的だったなと気づきました。もっとチャレンジングなことに挑戦してもっといいエンジニアになるぞ！
私の本ですが、ITの本としてはぶっちぎりの８万部既に売れているようです。ビジネス書ですので、エンジニアではない人も楽しんでもらえるように編集していますので、もしよかったらどうぞ！