この本がどのようにして生まれたか

この本がどのようにして生まれたか

Published Invalid Date

新たなチームメイト向けの単純な「README」として始まったものが、チームの摩擦の真の原因——価値の定義の不一致、暗黙の期待、そして文化が構築されたり毒されたりするしばしば無言の方法——についての本になりました。

この本は、readmeとして始まりました。

私は学校を卒業したばかりのエンジニアと働くことになっていた。彼は聡明で有能だったが、プロのソフトウェアチームでの経験が一度もなかった。それで、彼が知る必要があると思ったことを書き始めた。彼への親切心からではなく、あまりにも新人すぎる人を面倒に見るのを嫌がったからだ。そして、どんどん追加していき、やめられなかった。


ちょうどその頃、新しいエンジニアマネジメントの仕事を始めて数週間が経ったころ、チームの2人のエンジニアの間に対立が起こるのを目撃した。一ヶ月の間、それがエスカレートするのを見守った。進捗確認ミーティングも効果がなく、摩擦はどんどんひどくなっていった。

懲戒処分について考え始めた。

でも、何かがうまく噛み合っていなかった。どちらのエンジニアも有能だった。両方とも価値を生み出したいと思っていた。それなのに、なぜ彼らは争っていたのか?必要な時間よりも長くかかったが、ついに私はそれに気づいた:彼らは、価値が何を意味するかについて、互換性のない定義で動いていた。一人は仕事をプロダクトチームのように扱っていた:証拠を用い、正しく行い、曖昧な要件に抵抗する。もう一人はデリバリーチームのように考えていた:決定されたことを実行し、期限に間に合わせ、スコープを再考しない。理論的にはどちらも間違っていなかったが、実践的には一方が間違っていた。しかし、誰もその違いを明らかにしていなかったため、彼らは認識を合わせることができなかった。

それで、強制をやめて質問することにしました。「品質を保とうとして反対しているんですか?」わかった。「品質の理想と、今やるべき現実の間の線引きはどこでしょう?」「これをやりつつ、会社が優先する目標も達成するにはどうすればいい?」彼女は変わった。でも、私が変えたわけじゃない。一緒に考えて解決したんだ。


この仕事の前には、MBTAで8年間を過ごし、そのほとんどをエンジニアリングディレクターとして務めました。私の任期の終わり頃には、10のチームに40人のエンジニアがいました。私は部門を約20人から100人以上に成長させるのを助け、その使命は、単に機能をリリースするだけではなく、人々がシステムを実際にどう体験するかを変えることでした。

すべてがバラ色だったわけではない。いくつかの傑出したパフォーマーと少数の詐欺師がいた。インスピレーションを与えるリーダーと多くの魅力のないリーダーもいた。しかし、その数年間で、私は少数の人々とパートナーを組んだ:ポール・スワーツ、シオバン・カニングハム、クリスティン・テイラー、マット・シャンレー、グレジディ・ジュラ、ジョシュ・メルッチ。一緒に、私たちはこの仕事のやり方を理解した。チームをより良い成果へ導く方法。たった一つの問題行動がグループ全体を腐敗させる方法。チームが実際に革新的になるために必要な資質は何か、単に見た目が革新的なものと比較して。インパクトのあるチームを構築する方法と、成果を生まないチームを解散する方法。

それは段階的に起こりました。それは長年にわたるものでした。それは私のキャリアのハイライトでした。しかし、私たちはそれ(チームの軌道修正、解決主義への対処、不適切な行動への対峙)に忙しくて、自分たちが築いたものを一歩引いて見ることがありませんでした。仕事の全体像を振り返る時間がありませんでした。

この本はその振り返りとなりました。私にとって、それはその時期の一種のケアリングです。一部の人々がまだ葛藤の中にいると知っていても。


MBTAでは、人々が移行期を共に過ごしてくれました。私たちは共に成長しました。新入社員は、意味のあるポリシーと健全なエンジニアリング文化を持つ成熟した組織に加わりました: 創造的摩擦、助け合い、好奇心、そして真のインパクト志向です。しかし、私が去り、新しいチームを率い始めたとき、私たちが築いた基盤なしに、始めたときと同じ多くの問題を見つけました。何をしようとしているのかについての共通理解さえありませんでした。

だから、この本は私の新しいチームに伝える手段でもあるんです:これが現実です。一緒に成果主義文化を築き、意味のある仕事をし、一生懸命働くけど無理はせず、人間関係を壊さないようにしましょう。しかし、そのほとんどは成長していくものです。一度きりではなく。継続的に。

私が繰り返し学んでは忘れているのは、変革は一度で終わるものではないということです。一度学んだからといって、ずっと持っていられるわけではありません。学んでは、プレッシャーで忘れ、本番の時には再び選び直さなければならないのです。

私は部屋で一番賢い人になりたかったのに、自分がどれだけ視野が狭くなっていたかに気づいていませんでした。私はスプリントを共通の目標を達成する手段ではなく、個人的な競争のように扱っていました。私はいくつかの不快な会話を避け、その結果、キャリアが停滞しました。この本のすべての失敗は私が犯したものです。私があなたに求めているすべての変革は、私自身が行わなければならなかったものです。時には複数回です。


これは私が初めて出版した本ですが、実際に書いたのは四冊目です。執筆を通して多くのことを学びました。現実の制約の中で、この本は今日の私ができる最善のものを表していると思います。ソフトウェア製品と同様に、スコープ削減を行い、自分が望むものと他者が実際に必要とするものを区別し、最後までやり遂げなければなりませんでした。また、ソフトウェア製品と同じく、いくつかのバグがあるでしょう。

最も難しかったのは、エッセイの山から背骨のあるものへと移行し、文壇で言う「統治理念」を見つけることでした。結局、私が繰り返し戻っていた考えは単純でした:この仕事には自己変革が必要だということです。だからこそ、この本はまさにそれについて書かれているのです。

もし始めたばかりなら、この本はあなたがどんな道を歩むことになるかを教えてくれます。新しいチームを理解しようとしているなら、周りで起こっていることを表現する言葉を提供してくれます。そして、これを何年もやってきて、なぜ行き詰まっているか分からないなら、知らずに繰り返していたパターンを示してくれるかもしれません。

私はすべてを理解したからこれを書いているのではありません。まだ探求している途中です。書くことで思考が明確になります。もしこれがあなたにも役立つなら、この本はその使命を果たしたことになります。

エンジニアリング・フィールドガイド © 2026現代の開発者のためのソフトウェアエンジニアリングの原則、ベストプラクティス、ツールに関する総合ガイド。