1.1 ソフトウェアエンジニアリングの価値観

概要と動機

ソフトウェアエンジニアリングの価値観とは、人々が一緒にソフトウェアを作る方法を形づくる、共有された信念、規範、日々の行動です。壁のポスターや社員ハンドブックの文言のことではありません。午前3時にインシデントで誰かが起こされたとき、若手エンジニアが主席エンジニアに異を唱えたとき、締め切りが品質とぶつかったときに、実際に起こることです。価値観は、あらゆる技術的判断の下にある、目に見えないシステムです。

小さなチームでは、価値観は自然に広がります。人々は近くに座り、規範を吸収し、自ら修正します。より大きなチームでは、この自然な伝播は働きません。価値観を明示し、書き出し、リーダーが体現し、仕組みを通じて強化しなければなりません。それを怠れば、文化は互いに相容れない数十のミクロ文化に分裂し、あらゆる協働に静かに税を課します。

より大きなチームにとって、賭け金は構造的です。弱い価値観は、離職、遅い意思決定、抱え込まれた知識、根本原因が完全には直されない繰り返しのインシデントとして現れます。強い価値観は、速く、安全で、信頼できる変更として現れます。エンジニアは問題を早く表に出し、失敗から学び、オーナーシップを取ります。この二つの状態の差は、どの技術選択の差よりも大きいことがよくあります。

大企業と政府機関は、大規模に、精査のもとで、長い時間軸で仕事をするため、これを痛切に感じます。今日作られたシステムは10年以上動き続け、元の作者に会ったことのない人々が担当するかもしれません。こうした環境では、意図を時間と人の入れ替わりを越えて運ぶのは文化です。

規制の厳しい企業にはもう一つの圧力があります。信頼の代わりにプロセスを置きたくなる誘惑です。説明責任が重く、ミスが目立つとき、反射的に統制、承認、非難を積み上げたくなります。理解はできますが、裏目に出ます。最も信頼性が高く、安全で、コンプライアンスの取れた組織は、たいてい最も懲罰的な組織ではなく、最も学習文化の強い組織です。価値観とコンプライアンスは対立物ではなく、味方です。

主要原則

心理的安全性が土台です。それがなければ、他のすべての実践が劣化します。
失敗はデータです。非難なき学習は、インシデントを永続的な改善に変えます。
オーナーシップとは、成果物だけでなく成果への説明責任を意味します。「作った者が運用する」。
書くことは考えることです。決定を書き残す文化は、その判断力をスケールさせます。
ヒーロー任せより持続可能なペースです。バーンアウトは個人の失敗ではなく、システムの失敗です。
多様性、公平性、インクルージョンは、意思決定の質を高めるエンジニアリング上の強みです。
価値観はトップダウンで体現され、ボトムアップで強化されます。リーダーの行動は言葉より重みがあります。

推奨事項

心理的安全性を意図的に築く

心理的安全性とは、屈辱や罰を恐れることなく、発言し、質問し、ミスを認め、決定に異議を唱えられるという共有された信念です。大規模な研究で、チームの有効性を最も強く予測する唯一の要因とされています。意図して築いてください。リーダー自身が自分のミスを声に出して認めます(「私が犯したミスと、そこから学んだことはこうです」)。悪い知らせには罰ではなく好奇心で応じます。会議で異論を公然と歓迎します。誰が最初に話すかを持ち回りにし、上位者の声が議論を固定しないようにします。そして「わかりません」「助けが必要です」と言うことを普通のことにします。

非難なき学習を実践する

何かが壊れたとき、それを引き起こした人ではなく、失敗を許した条件を見ます。非難なきポストモーテムを採用します。何が起きたか、タイムライン、寄与要因、そして担当者と期限のある具体的なアクションアイテムを書面に残すものです。全員が、その時点で知っていたことを踏まえて合理的に行動したという前提から始めます。「誰がやらかしたのか」ではなく、「何がこれを間違えやすくしていたのか」と問います。そしてアクションアイテムを完了まで追跡します。フォローアップを決して閉じないポストモーテム文化は、ただの芝居です。

明確なオーナーシップモデルを確立する

「作った者が運用する」は、サービスを書いたチームに、オンコールを含めてそれを運用する責任を負わせます。これは設計判断と運用上の痛みのフィードバックループを引き締め、品質を高めます。これに、すべてのシステムについて、誰が所有し、どう連絡し、依存関係は何で、ランブックはどこかを記録するサービスカタログを組み合わせます。オーナーシップは明示的で、重複がないようにします。曖昧なオーナーシップは、システムが腐り、インシデントが長引く原因です。チームが自力ではどうしても運用できないシステムには、説明責任を分散させるのではなく、プラットフォームの支援を与えます。

書く文化を育てる

書くことは思考を鋭くし、タイムゾーンと年月を越えて運ばれる成果物を生みます。重要な変更にはデザインドキュメントと意思決定記録を日常のものにします。問題、検討した選択肢、提案するアプローチ、トレードオフを述べた短い文書を、作る前に回覧してコメントを募ります。これにより、対立が安く済むうちに早く表に出て、なぜそう決めたかの永続的な記録が残ります。テンプレートは軽く保ち、期待は決定の重さに見合うものにします。そして、優れた文章を公の場で称えます。

持続可能なペースを守る

少数の人が持続不可能な努力で繰り返し組織を救うヒーロー文化は、弱さの症状であって美徳ではありません。人を燃え尽きさせ、知識を危険なほど集中させ、直すべき根本の問題を隠します。ですからオンコールの負荷を測り、管理します。一人が絶えず呼び出されているなら、それは設計で取り除くべき欠陥として扱います。休暇を当たり前にし、集中できる時間を守り、成果は一週間ではなく四半期で判断します。

DEIをエンジニアリング上の強みとして扱う

多様なチームはより良い判断をします。より多くの視点を比べ、集団思考や盲点に陥ることが少なく、それはアクセシビリティ、セキュリティ、幅広い人々へのサービス提供にとって非常に重要です。包摂を日々のエンジニアリングに組み込みます。アクセスしやすいドキュメント、コードとインターフェースでの包摂的な言葉遣い、静かな声が貢献できる会議の進め方、そして華やかな仕事と地味な接着剤の仕事の公平な分配です。

トレードオフ: 長所と短所

アプローチ	長所	短所
非難なきポストモーテム	真の根本原因を明らかにする。信頼を築く。システム的な修正を促す	部外者には「説明責任がない」ように見えうる。アクションを閉じる規律が必要
「作った者が運用する」	品質のフィードバックループが引き締まる。オーナーシップが明確	オンコールの負担。燃え尽きを避けるには強力なプラットフォーム支援が必要
ドキュメント先行 / RFC文化	決定が永続する。人の入れ替わりに強い。非同期に向く	些細な変更には遅い。過剰に適用すると官僚主義の恐れ
持続可能なペース	定着、信頼性、長期的なベロシティ	追い込み期には遅く感じる。リーダーが線を守る必要がある

中心的な緊張は、短期的なスピードと長期的な健全性の間にあります。ヒーロー任せと非難は、一時の見かけの統制を買いますが、その後に士気と信頼性がゆっくり崩れます。非難なき学習、オーナーシップ、持続可能なペースは、どの一週間をとっても遅く感じられますが、四半期、年と積み重なると、はるかに高いベロシティへと複利で効いてきます。リーダーは、長期的な能力を守るために、短期的な不快を引き受ける覚悟が必要です。

チームで議論すべき問い

「非難なき」が、監査人、経営幹部、市民に「説明責任がない」と読まれないようにするには、どうしますか。 規制された企業や、監督下にある政府機関では、誰も名指ししないポストモーテムは、エンジニアリングの外にいる人々には隠蔽に見えることがあります。相反する考慮は現実のものです。非難なきことでしか得られない正直さが必要であり、同時に、意思決定者が失敗が対処されると信じられることも必要です。インシデントの再発率やポストモーテムのアクションアイテムの完了率のような具体的な証拠を議論に持ち込んでください。確実にフォローアップを閉じる仕組みは、犠牲の羊がいなくても目に見えて説明責任を果たしているからです。非難の文化が一緒くたにしてしまう二つの問いを分けてください。何がこれを間違えやすくしていたのか、そして誰かが真に怠慢または悪意で行動したのか。説明責任は条件を直しアクションを閉じることにある、というのが答えなら、その仕組みを公開し、部外者が求めている説明責任を見られるようにしてください。
現実的には運用できないオンコールのシステムを抱えているのはどのチームで、そのギャップのコストは誰が払っていますか。 「作った者が運用する」はフィードバックループを引き締めますが、それはチームが作ったものを運用するためのプラットフォーム支援を持っていることを前提とします。大企業や政府の規模では、レガシーシステム、ベンダーのブラックボックス、小さなチームでは到底自力で所有できない横断的インフラを引き継ぐチームがあります。トレードオフは、説明責任の分散(悪い)と、応答できないポケベルを持たせてチームを失敗させること(これも悪い)の間にあります。ページングのデータを持ち込んでください。特定の一人や一つのチームが絶えず呼び出されているなら、それは名誉の印ではなく、設計で取り除くべき欠陥として扱います。答えは、プラットフォームチーム、段階的ロールアウト、最新のランブックのどこに投資すべきかを教えてくれるはずです。そうすればオーナーシップは明確なまま、運用の負担は人道的に保たれます。
実際に昇進で評価している行動は、公表している価値観と一致していますか。 価値観は、リーダーがポスターが非難するものを評価した瞬間にシニシズムへと朽ちます。そして大規模では、この乖離は離職と静かな知識の抱え込みが明らかにするまで見えないままです。直近の昇進サイクルをよく見てください。消火とヒーロー的な働きに報いましたか、それとも火災の予防と、大きなチームを健全に保つ接着剤の仕事に報いましたか。大企業や政府機関は、硬直した等級制度と長い在職期間のせいで、ずれたインセンティブが誰にも正されないまま何年も続きうるため、リスクが重なります。実際の証拠を持ち込んでください。誰が昇進したか、誰が公に称賛されたか、その人たちが実際に何をしたか。ヒーロー的な働きが報われるなら、組織は自ら危機を製造し、その解決を祝うよう訓練されているのであり、直すべきは壁の飾りではなくインセンティブです。
チームごとの心理的安全性が高いのか低いのかを、組織図から想定するのではなく、どうやって実際に知りますか。 安全性は他のあらゆる実践の土台であり、同時に最も自分をごまかしやすいものです。最も安全性が低いチームほど、それを教えてくれにくいからです。規模が大きいと、千人の平均が、重要なばらつきを隠します。一人のマネージャーが、全体としては健全な組織の中で、恐れに基づくチームを静かに率いることがありえます。相反する考慮は、率直さと快適さです。本当の問題を明らかにする質問ほど、人々が正直に答えにくく、シグナルを集めること自体が安全でないと感じられることもあります。雰囲気ではなく具体的な証拠を持ち込んでください。検証済みの安全性指標によるチームレベルの結果、ミスを書面で認める頻度、インシデントになる前に表に出たヒヤリハット報告、退職面談のテーマなどです。大企業や政府機関では、データはチームレベルに留め、低スコアのチームを罰するために決して使わないよう求めてください。安全性スコアが棒になった瞬間、それは安全性ではなく、測定への恐れを測り始めるからです。
オンコールとヒーロー的な働きの実際の負荷はどれくらいで、あなたは火災を防ぐ人と火災と戦う人のどちらに報いていますか。 持続可能なペースは、良い意図がデリバリーの圧力のもとで静かに崩れる場所であり、大きな組織は、疲れ切った少数の人の見えない残業で何年も回り続け、それに気づかないことがあります。緊張は率直です。ヒーロー的な働きは、その瞬間には実際にあなたを救います。しかしそれに頼ると、知識が集中し、システム的な欠陥が隠れ、最も献身的なエンジニアが燃え尽きます。運用データを議論に持ち込んでください。一人当たりの週あたりのページ数、時間外のデプロイ、チーム内のオンコール負荷の分布、そのうちどれだけが月々同じ数人に集中しているか。直近の昇進サイクルが誰に報いたかも見てください。硬直した等級のはしごと長い在職期間を持つ大企業や政府機関では、消火に報いる文化が十年も誰にも異議を唱えられずに続きうるので、答えは、ポケベルを設計でどこまで減らせるか、火災予防をいかに目に見える昇進対象の行為にするかを教えてくれるはずです。
過去二年間の重要な決定のうち、理由の記録が書面にないものはどれで、作者がいなくなったときにそれはどんなコストになりますか。 書く文化は、意図を人の入れ替わりを越えて運びます。その不在は、誰かが、もう誰も理解していないシステムを変える必要が生じる瞬間まで見えません。相反する引力はスピードです。デザインドキュメントや意思決定記録を書くことはその場では摩擦に感じられ、過剰に適用すると、些細な変更を遅くする官僚主義に変質します。調整のための証拠を持ち込んでください。重要な変更のうちデザインドキュメントや意思決定記録があるものの割合、既存のアーキテクチャの背後にある理由を実際に見つけて引用できる頻度、文書化されていないサービスで新しいエンジニアが戦力になるまでの時間。システムが作った人々の在職期間より長く続き、監査や情報公開の精査を受けうる大企業や政府機関にとって、書面の記録は組織的記憶であり、相当の注意を払った証拠でもあります。したがって答えは、決定の重さが書くことを正当化するところに線を引き、それより低くしないことであるはずです。

セクター別の視点

スタートアップ。 価値観はまだ自然に広がるので、重いプロセスは持ち込まず、最も重要な一つか二つの行動に名前を付けてください。たいていは、ミスについての非難なき正直さと、悪い知らせを早く表に出す習慣です。創業者は自分の誤りを声に出して認めることで基調を作ります。小さなチームでは、Slackでの一度の鋭い反応が、問題を何か月も隠すことを全員に教えうるからです。限られたランウェイは、安全性を省く理由ではなく守る理由です。バグを隠すチームは、五分のふりかえりよりはるかに高くつきます。

小規模事業者。 エンジニアリング文化の専門家がおらず予算も厳しいので、購入や人員確保が必要なツールではなく、軽い儀式に頼ってください。共有のインシデントチャンネル、一枚の意思決定ログ、「何がこれを間違えやすくしていたのか」という習慣は、費用がかからず、価値の大半を運びます。実践についても自作か購入かの線引きを意識してください。保守できない独自システムを作るのではなく、既製のポストモーテムのテンプレートと簡単なオンコール当番表を採用します。

大企業。 規模が大きくなると、仕事は画一ではなく一貫性になります。非難なき学習、重複のない明確なオーナーシップ、書く文化が、ツール、期待、サービスカタログに支えられた組織全体の規範になります。ガバナンスと監査は統制へと押しますが、強い学習文化こそ最も信頼性が高くコンプライアンスにも適う選択肢だと主張し、インシデント再発とアクション完了のメトリクスで示してください。チーム間のばらつきに注意してください。平均は、静かに人材と知識を漏らす、恐れに基づく一角を隠します。

政府。 調達規則、透明性の義務、公的な説明責任が、特に非難をめぐって価値観の表現のされ方を形づくります。誰も名指ししないポストモーテムは、外部の監督者には隠蔽と読まれうるので、仕組みを公開してください。説明責任は条件を直しアクションを閉じることにあると示し、市民や監査人にも見えるようにします。システムは政権より長く続き、人の入れ替わりは年単位で測られるため、書面の意思決定記録を、組織的記憶であり、情報公開の精査のもとでの相当の注意の証拠として扱ってください。

事例

スタートアップ。 6人のスタートアップは信頼と廊下での会話で回っているので、誰もチームの価値観を書き出していません。創業エンジニアの一人が悪いマイグレーションをプッシュし、CTOがSlackでその人に厳しく当たると、場が静まり、その後の二つのバグは、表に出されず静かに隠されます。チームは、一つの軽い習慣を採用して立て直します。インシデントのたびに、テンプレートなしで、五分間の非難なき「何がこれを間違えやすくしていたのか」の対話を行うのです。この小さな儀式が、大きな組織なら必要になるプロセスの重さなしに、自然発生的な文化を健全に保ちます。

大企業。 大手金融サービス企業で、日常的な設定変更がサービス間に連鎖して大規模な障害が起きました。非難の文化なら、変更をプッシュしたエンジニアが叱責され、それで終わっていたでしょう。代わりに、非難なきポストモーテムで、デプロイツールが危険な変更を安全な変更と同一に見せていたこと、段階的ロールアウトがなかったこと、ランブックが古かったことが明らかになりました。同社は段階的ロールアウトと設定の検証に投資し、同様の変更は今では安全に失敗します。人ではなくシステムを見ることを選んだことが、永続的なエンジニアリングの改善を生みました。

政府。 ある政府のデジタルサービス機関は、「作った者が運用する」を、厳格なドキュメント先行のRFC(意見募集)プロセスと併せて採用しました。システムは政権交代と、年単位で測られる人の入れ替わりを生き延びなければならないため、重要な決定はすべて、文脈とトレードオフを説明するデザインドキュメントに記録されます。新しいエンジニアも、新たに入る契約者も、十年前のアーキテクチャの背後にある理由を、逆解析するのではなく読むことができます。その書面の組織的記憶があるからこそ、同機関は高い入れ替わりと厳しい説明責任の要件のもとでも、公共サービスを信頼できるものに保てます。

ビジネスケース: 動機、ROI、TCO

文化への投資収益は現実のものですが間接的であり、そのため慢性的に資金が不足しています。システムの生涯を通じて、支配的なコストはそれを作ることではありません。保守、インシデント対応、手戻り、そして熟練した人材を失い再び採用するコストです。強い学習文化は、これらすべてを改善します。非難なきポストモーテムは繰り返しのインシデントを減らします。明確なオーナーシップは平均復旧時間を短縮します。書く文化は、オンボーディングのコストと、それまでの理由を知らないまま下される決定のコストを下げます。

離職だけを取っても、中堅エンジニアの代替には、採用、立ち上がり、去っていく組織的知識を数えると、年収の半分から2倍程度のコストがかかるのが一般的です。より健全な文化が、1000人規模の組織で惜しまれる離職をわずか数ポイント減らすだけでも、その節約は、ポストモーテムの実施やドキュメントの執筆というささやかなコストをはるかに上回ります。導入のコストは、おもにリーダーの注意と少しのプロセスのオーバーヘッドです。導入しないコストは、継続的に、目に見えない形で支払われます。遅いデリバリー、繰り返すインシデント、静かな人材流出です。

経営層にこれを訴えるには、文化を、経営陣がすでに追っている指標に結びつけてください。デリバリーのリードタイム、変更失敗率、平均復旧時間、インシデント再発、惜しまれる離職です。心理的安全性をソフトな恩恵としてではなく、他のあらゆるエンジニアリング投資を実らせる仕組みとして位置づけてください。安全でないチームは、それらの投資が直そうとしている問題をまさに隠すからです。

アンチパターンと落とし穴

非難と恥をかかせるインシデントレビュー: 問題を地下に潜らせ、人々は報告をやめます。
ヒーロー崇拝: 火災予防より消火に報いることは、火災を永続させます。
リーダーが破る「価値観」: 行動に反する表明された価値観は、シニシズムを生みます。
支援のないオーナーシップ: チームが現実的に運用できないシステムにオンコールを割り当てること。
信頼の代用品としてのプロセス: 本物の安全性を築く代わりに承認を積み上げること。
ドキュメントの芝居: 誰も読まない、あるいは決定に影響しない文書を書くこと。
チェックボックスとしてのインクルージョン: 多様性のために採用しながら、同じ人々の声を意思決定から締め出すこと。

成熟度モデル

レベル1、開始: 価値観は偶発的で、個人の人柄に依存します。インシデントは非難を意味し、知識は少数の頭の中にあり、ヒーロー的な働きで物事が進みます。チームが何を信じ、圧力のもとでどう振る舞うかを、誰も書き出していません。
レベル2、発展: 一部のチームが非難なきポストモーテムを始め、時々デザインドキュメントを書き、オーナーシップを語りますが、実践は一貫せず、適用にむらがあり、まだリーダーに強化されていません。健全なチームに当たるかどうかは、おおむね運次第です。
レベル3、標準化: 非難なき学習、重複のない明確なオーナーシップ、書く文化が、テンプレート、サービスカタログ、定義されたオンコールへの期待とともに、文書化された組織全体の規範になっています。リーダーが価値観を体現し、良いマネージャーがたまたまいる場所だけでなく、あらゆる場所で同じ行動が期待されます。
レベル4、管理: 文化はベースラインと比べて測定され、データで制御されます。チームレベルの心理的安全性スコア、インシデント再発、ポストモーテムのアクションアイテムの完了率、オンコール負荷の分布、平均復旧時間、惜しまれる離職を追跡し、チームがずれたら数字に基づいて対処します。消火を促すインセンティブは証拠に基づいて廃止し、今では見えるようになった火災予防に報います。
レベル5、オーケストレーション: 文化は継続的に改善され、組織全体の計画、採用、昇進と統合されています。安全性は高く、学習は速く、実践は証拠と文脈の変化に応じて適応します。組織はオンコール負荷を再配分し、意思決定記録を更新し、危機に迫られるのを待たずに、規範を意図的に進化させます。

議論のためのアイデア

私たちの組織のどこで、人々は「わかりません」「反対です」と言うのに安全だと感じていませんか。それはなぜですか。
私たちのインシデントレビューは、システムを変えていますか。それとも、過失を割り当てて先に進むだけですか。
設計で取り除くべきヒーロー的な働きに、私たちは報いていませんか。
過去二年間の重要な決定のうち、理由の書面記録がないものはどれですか。
接着剤の仕事とオンコール負荷は、チーム内でどれほど均等に分配されていますか。
私たちが表明する価値観は、ここで実際に人を昇進させるものと一致していますか。

要点

価値観は、あらゆる技術的判断の背後にある目に見えないオペレーティングシステムです。規模が大きくなれば、価値観は明示されなければなりません。
心理的安全性は土台です。それがなければ、他の実践は衰えます。
非難なき学習は、失敗を永続的なシステム的改善に変えます。
明確なオーナーシップ(「作った者が運用する」)は、品質のフィードバックループを引き締めます。
書く文化は、タイムゾーンと人の入れ替わりを越えて判断力をスケールさせます。
持続可能なペースとインクルージョンは、コストではなく、長期的なベロシティの乗数です。

参考文献とさらなる読み物

Amy C. Edmondson, “The Fearless Organisation” and “Teaming”
Google re:Work / Project Aristotle research on team effectiveness
Sidney Dekker, “The Field Guide to Understanding ‘Human Error’”
John Allspaw, “Blameless PostMortems and a Just Culture” (Etsy Code as Craft)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate: The Science of Lean Software and DevOps”
Gene Kim et al., “The Phoenix Project” and “The DevOps Handbook”
Camille Fournier, “The Manager’s Path”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Tom DeMarco and Timothy Lister, “Peopleware: Productive Projects and Teams”