LabHub

ブログ

結局、人がやる仕事 — ソフトウェアチームで人を尊重するということ

2026-06-16 · 44 分で読めます · #respect#teamwork#engineering-culture#communication#collaboration#people

한국어English日本語

はじめに — バグの本当の原因

障害の振り返りの場で最もよく挙がる表面的な原因は「特定のコードのバグ」です。しかし振り返りを深く掘っていくと、本当の原因はコードではなく人々の間の何かである場合が驚くほど多いのです。

私が経験した一つの事例をお話しします。決済システムで二重請求のバグが起きました。コード自体は二行で直せました。ところが振り返ってみると、一か月前にある開発者がすでにその危険を見つけ、コードレビューで言及していたのです。レビューコメントにはこう書かれていました。「ここで再試行が起きると二重請求になるかもしれませんが?」。そのコメントへの返答はたった一行でした。「今は時間がないので後で見ます」。そして誰も後で見ませんでした。

バグの本当の原因はコードではなく、そのコメントが真剣に扱われなかったという事実でした。意見を出した人は無視されたと感じ、その後レビューでだんだん口を閉ざしました。これは技術問題ではなく、人とコミュニケーションの問題です。

ソフトウェアはコンピューターが実行しますが、人が作ります。人が集まって決定し、議論し、ときに争いながら作ります。だから「人を尊重する」という言葉は温かいスローガンではなく、良いソフトウェアを作る実質的な条件です。この文章では、その尊重を抽象的な説教ではなく具体的な行動として解きほぐしたいと思います。

技術問題に見えるものの本質

ソフトウェアチームで起きる衝突は、表面的には技術論争の衣をまとっています。「RESTかGraphQLか」「モノリスかマイクロサービスか」「この変数名が正しいかあの変数名が正しいか」。しかしその下を覗くと、しばしば次のような非技術的な問題が横たわっています。

表面(技術に見える)本質(人・コミュニケーションの問題)
終わらないアーキテクチャ論争誰の意見がより尊重されるかの力比べ
コードレビューが険悪になる批判と人格を区別できない
同じミスが繰り返されるミスを正直に言える安全感の欠如
情報が共有されない信頼と協力の欠如
会議が長く結論がない意思決定権限の曖昧さ

もちろん純粋に技術的な論争もあります。すべての衝突を人の問題に還元するのもまた危険です。肝心なのは、技術論争が異常に激化したり繰り返されたりするとき、その下に人の問題が横たわっていないか疑ってみることです。技術問題はたいていデータと実験で解けますが、人の問題はそうは解けません。

尊重の具体的な行動

「お互い尊重しましょう」という言葉は誰もが同意し、何も変えません。尊重は名詞ではなく動詞であるべきです。毎日の小さな行動として現れねばなりません。

傾聴 — 話を遮らず最後まで聞く

最も基本ですが最も守られないものです。会議で誰かが話している途中に割り込まない、同意しなくても最後まで聞いて「ちゃんと理解できたか確認させてください」と問い返す。これだけでも雰囲気が変わります。

[傾聴しない会話]
A: 私の考えではキャッシュを導入すれば—
B: いやそれはダメです。キャッシュ無効化がどれだけ大変か。
A: (言葉を失う)

[傾聴する会話]
A: 私の考えではキャッシュを導入すれば応答速度が改善しそうです。
B: 良い方向ですね。一つ心配なのはキャッシュ無効化ですが、
   その部分はどう解こうとお考えですか?
A: ああ、それはTTLを短めにしながら—

二つの会話の技術的内容は同じです。違うのは一方が相手を人として扱った点だけです。

クレジット — 功績を正確に帰す

誰かのアイデアで問題が解けたなら、会議で、ドキュメントで、発表でその人の名前を明示的に言うこと。「先週OOさんが提案した方法で解決しました」という一言は、その人にとって大きな承認になります。逆に、他人の功績をこっそり自分のものにすることほど信頼を速く崩すものはありません。

公正 — 一貫した基準で接する

同じミスを誰には寛大に、誰には厳しく接するなら、それは不公正です。好きな人のPRはざっと通し、嫌いな人のPRには難癖をつけるなら、人はすぐ気づきます。公正さは基準の一貫性から生まれます。

時間の尊重 — 相手の集中をむやみに壊さない

「ちょっといいですか」と他人のディープワークをしょっちゅう壊すのも尊重の欠如です。急がない質問は非同期で残し、会議は必要な人だけ、短く。同僚の時間は同僚の最も貴重な資源です。

コードレビューと議論での態度

コードレビューは尊重が最もよく試される場です。コードは人が時間をかけて作った成果物であり、それを批判することは本質的に敏感にならざるを得ません。

コードを批判して人を批判しない

[人を攻撃するレビュー]
「なぜこんな書き方を?基礎が足りない気がしますが。」
「このコードはどうしても理解できません。」

[コードに集中するレビュー]
「この部分でN+1クエリが発生しそうです。一度に取得してはどうでしょう?」
「この流れがうまく追えないので、コメントをもう少し付けていただけますか?」

肝心の原則は「主語をコードにする」ことです。「あなたが間違っている」ではなく「このコードがこういう状況で問題になり得る」と言うことです。

質問の形を借りる

命令より質問のほうが柔らかいです。「こう変えてください」より「ここをこう変えてはどうでしょう?」が相手に考える余地を与えます。ただし、答えの決まった偽の質問(「本当にこれが最善だと思いますか?」)はかえって攻撃的なので避けるべきです。

議論で勝とうとせず、正しい結論に到達しようとする

技術論争の目的は誰が賢いかを証明することではなく、より良い決定を下すことです。「私が間違っていました、その方法のほうが良いです」と言える人が実は最も強い人です。意見の不一致は健全ですが、それが終わったあとは決定に従い(disagree and commit)、人に対するわだかまりを残さないことです。

多様性と包摂 — 異なる視点がより良い結果を生む

多様性を倫理的当為としてのみ語ると空虚になりがちです。より実用的な視点があります。同質的なチームは同じ死角を共有します。全員が同じ背景、同じ経験、同じ思考様式を持つと、全員が同じものを見落とします。

異なる背景の人々は異なる質問を立てます。誰かはアクセシビリティを思い浮かべ、誰かは別の言語圏のユーザーを思い浮かべ、誰かはセキュリティの脅威を思い浮かべます。この多様な質問が集まって、より堅牢なソフトウェアを作ります。

包摂(inclusion)は多様性より一歩先へ進みます。多様な人を集めることを超えて、彼らが実際に声を出せるようにすることです。会議でいつも同じ二、三人だけが話すなら、多様性はあっても包摂はないのです。

包摂を作る小さな実践
- 会議で静かな人に意見を直接尋ねる
  「OOさんはこの部分どう思いますか?」
- 非同期チャネル(ドキュメント、チャット)も併せて運用し
  口で割り込みにくい人も意見を出せるようにする
- 新人や少数派の意見を先に聞き、シニアの意見を後で出す
  (先に権威ある意見が出ると他の意見が埋もれる)

アンチパターン — 天才神話の罠

ソフトウェア業界には「孤独な天才」神話がしぶとく残っています。一人の非凡な開発者がすべてを作り出すという幻想です。この神話は二つの面で有害です。

第一に、事実ではありません。私たちが知るほとんどすべての偉大なソフトウェアはチームが作りました。Linuxでさえ数千人の貢献者が共に作ったものであり、リーナス・トーバルズ本人も誰よりその点を強調します。

第二に、有害です。「天才」と祭り上げられた人は、しばしば無礼を免罪されます。「あの人はもともと気難しいが実力があるから」という言葉がチーム全体の心理的安全を崩します。一人の優れた個人が生む価値より、その人が周りの十人を萎縮させて失わせる価値のほうが大きいことがあります。

Googleが自社のチームを分析したアリストテレス・プロジェクト(Project Aristotle)の結論も同じ方向を指します。最高のチームを作る最も重要な要因は、個々の構成員の天才性ではなく、チームの心理的安全感でした。誰もがバカげた質問をし、ミスを認められる雰囲気のことです。

ほかのアンチパターンも挙げておきます。

事例 — 無礼な天才 vs 優しい助力者

二人のシニア開発者を比べてみます。どちらも実力は抜群でした。

Sは典型的な「無礼な天才」でした。コードは見事でしたがレビューは厳しく、会議で他人の話をよく遮りました。ジュニアたちはSに質問するのを恐れ、知らないことを知らないと言えませんでした。その結果、同じミスが静かに繰り返されました。

Dは違いました。コードはSほどではありませんでしたが、ジュニアの拙い質問に真剣に答え、自分のミスを先に公開しました。「これ、去年まったく同じく間違えました」と。時間が経つと、Dの周りのジュニアが速く成長し、チーム全体の生産性が上がりました。

一年後にチームの産出物を比べたとき、Dの属するチームのほうが多くを、より安定して作り出しました。個人Sのコード一行はより優れていたかもしれませんが、人Dが作ったチームのほうが強かったのです。これが「結局、人がやる仕事」という言葉の意味です。

三つの現場事例

抽象的な原則は、具体的な物語の中でこそ生き生きと動きます。私が間近で見たり伝え聞いたりした三つの事例を通して、尊重が——あるいはその欠如が——どうチームの運命を分けたかを辿ってみます。

事例1 — クレジットを奪われ去ったシニア

あるリモートチームにJというシニアエンジニアがいました。Jは分散システムの厄介なデータ整合性の問題に何日も取り組んで解き、その解法をチームチャンネルに長く丁寧にまとめて共有しました。問題はその後でした。チームのリードがその解法を役員報告の場でまるで自分が設計したかのように発表し、Jの名前は一度も出ませんでした。

リモートのため、その発表の場にJはいませんでした。あとから議事録で知ったJは、最初は何も言いませんでした。しかし同じことが二、三度繰り返されると、Jは静かに貢献を減らし始めました。難しい問題を解いてももはや公に共有せず、結局半年後に会社を去りました。退職面談でJが残した言葉は短いものでした。「自分のやったことが自分のものとして残らない場所では、働く理由を見つけられません。」

リードはJが去った本当の理由を最後まで理解しませんでした。表面的には「より良い条件の転職」でしたから。しかしチームが失ったのは一人の人ではなく、その人が解いていた最も難しい問題を解く能力そのものでした。クレジットを正確に帰すことは、礼儀の問題ではなく人材保持の問題です。

事例2 — 険悪になったPRスレッド、そして鎮静化

もう一つの事例は、あるオープンソースへの貢献の過程で起きました。ある貢献者が大きなリファクタリングのPRを上げ、メンテナは「この変更は我々の設計思想に合わない」という短いコメントで閉じようとしました。貢献者はかっとなり、スレッドは急速に険悪になりました。「ならば最初からガイドラインに書いておくべきでしょう。」「あなたはコードベースをちゃんと読んでいない。」両者とも人へ向かい始めました。

このスレッドを救ったのは第三者でした。別のメンテナが割って入り、こう書きました。「お二人とも同じものを望んでいるようです——よりきれいなコードベースを。ただ、その方法についての前提が違うだけです。まず、我々が合意した設計原則をどこにも文書化していなかった点は我々の落ち度です。そこから整理して、このPRは小さな単位に分けて見直してはどうでしょう?」

この一つのコメントが雰囲気を完全に変えました。それは(1)双方の共通の目標を明示し、(2)責任の一部をメンテナ側に引き取り、(3)次の行動を具体的に提案しました。結局その貢献者はPRを三つに分けて上げ直し、そのうち二つがマージされ、のちに正式なメンテナになりました。衝突を人格の争いから問題解決へ戻すには、誰か一人が「我々は同じ側だ」という事実を改めて思い出させるだけで十分なことが多いのです。

事例3 — 非難する振り返り vs 非難なき振り返り

同じ障害を二つのチームがどう違って振り返ったかを比べてみます。両チームともデプロイ後のデータベースマイグレーションのミスで30分サービスが停止しました。

Aチームの振り返りは「誰がやったか」から始まりました。マイグレーションを実行したジュニアが名指しされ、会議の間ずっとその人は顔を上げられませんでした。結論は「次からもっと気をつけよう」でした。そのジュニアはその後デプロイを極度に恐れるようになり、ほかの人たちも危険な作業を互いに押し付け合い始めました。一か月後、似たミスが別の人の手でまた起きました。

Bチームの振り返りは「どうしてこんなことが可能だったか」から始まりました。マイグレーションを実行した人を責める代わりに、問いはシステムへ向かいました。「なぜ危険なマイグレーションが自動検証なしに本番まで行けたのか?」「なぜロールバックに30分もかかったのか?」結論は人ではなくガードレールでした——マイグレーションの事前検証の自動化、ワンクリックロールバック、段階的デプロイ。そのジュニアはむしろ検証ツールを作る役を任されました。似たミスはその後二度と起きませんでした。

同じ事故、正反対の結果。違いは振り返りが人へ向かったかシステムへ向かったか、一つだけでした。

非難する振り返り vs 非難なき振り返り

二つの振り返り方式の違いを表に整理すると、次のようになります。

項目非難する振り返り非難なき振り返り
最初の問い誰がやったかどうして可能だったか
焦点個人のミスシステムの穴
雰囲気防御と弁解好奇心と学習
成果物もっと気をつけるという誓い具体的なガードレールとアクション
情報開示ミスを隠すようになるミスを早く出すようになる
長期効果同じミスが繰り返される同じミスが防がれる
心理的安全低下上昇

非難なき振り返り(blameless postmortem)の核心の前提は単純です。人は与えられた状況で合理的に行動したと前提し、ならばなぜその行動が合理的に見えたのかを問うのです。この前提が人々を防御モードから学習モードへ移します。Etsyが共有した「Blameless PostMortems and a Just Culture」は、この手法の古典的な出発点です。

SBIフィードバック・フレームワーク

尊重しつつも正直なフィードバックは、その場の勢いでは出てきません。構造が必要です。最も実用的な道具の一つがSBIフレームワークです。Situation(状況)、Behavior(行動)、Impact(影響)の三つを順に述べることです。

SBIの力は、「あなたは無礼だ」のような人格評価を、「この状況でこの行動がこういう影響を与えた」という観察に変えるところにあります。聞く側が防御する必要が減ります。

[SBI適用例]
状況(S): 昨日の午後の設計レビューで、
行動(B): 私がキャッシュ案を説明し終える前に
         「それはダメだ」と二度遮りました。
影響(I): そのため無効化戦略まで説明する機会がなく、
         自分の意見がうまく伝わらなかったと感じました。
依頼:    次のレビューでは私が説明し終えてから
         反論をいただければ、もっと深く議論できそうです。

最後の「依頼」はSBIの正式な構成要素ではありませんが、フィードバックを批判ではなく協働の提案として締めくくるのに役立ちます。

対話例 — 敵対的 vs 尊重する1on1フィードバック

同じ状況、同じ問題をめぐる二つの1on1の対話を比べてみます。あるメンバーが最近締め切りを二度逃しました。

[敵対的な1on1]
リード: 最近どうしたんですか?もう二度も締め切りを
        逃したじゃないですか。こんな調子だとチームの
        迷惑です。
メンバー: すみません…ちょっと忙しくて。
リード: みんな忙しいですよ。言い訳せずにちゃんとやって。
メンバー: …はい。
(メンバーは本当の理由を最後まで言わない。
 次の締め切りも危うい。)

[尊重する1on1]
リード: 最近二度締め切りが押したので、何があったか
        一緒に見たいんです。責めるためじゃなくて、
        詰まっているところがあれば解きたくて。
メンバー: 実は…決済モジュールの依存で何度も詰まって。
          あちらのAPIがよく変わるので作り直しが続いて。
リード: ああ、それは一人で抱える問題じゃないですね。
        あのチームとの調整は私も一緒に入ります。
        それと、こういうブロッカーは早めに上げてくれると
        ずっと速く解けますよ。
メンバー: はい、そうします。実は言い出しにくくて。
リード: 詰まっていることを伝えるのが、仕事ができる
        ということですよ。
(本当の原因が表に出て、構造的な解決につながる。)

二つの対話の事実関係は同じです。メンバーが締め切りを二度逃したということ。しかし敵対的な対話は本当の原因を隠させ、尊重する対話はそれを表に出して解決へつなげました。正直さと無礼さの違いは「問題を直視するか」ではなく、「相手を敵に置くか味方に置くか」にあります。

反対の視点 — 心理的安全が誤用されるとき

ここまでの話が一方に偏らないために、バランスのための反対の視点も押さえねばなりません。尊重と心理的安全は強力な道具ですが、誤って使えば正反対の結果を生みます。

心理的安全 ≠ 責任の免除

最もよくある誤解は「心理的安全 = 誰も指摘されない状態」というものです。これは間違いです。エイミー・エドモンドソン本人が強調するように、心理的安全は高い基準と対になるべきです。安全感だけ高く基準が低いと、チームは「快適な無気力(comfort zone)」に沈み、基準だけ高く安全感が低いと「不安(anxiety zone)」に陥ります。両方が高いときにのみ、「学習と高成果(learning zone)」が生まれます。

「ミスをしても大丈夫」は「ミスの責任を取らなくても大丈夫」ではありません。非難なき振り返りも「誰も責任を取らない振り返り」ではなく、「個人を責める代わりにシステムとプロセスが責任を取る振り返り」です。同じ人が同じミスを学習なく繰り返しているのに、毎回何も言わず流すなら、それは心理的安全ではなく放置です。

有害な前向きさ(toxic positivity)の危険

もう一つの罠は、「前向きにだけ話そう」という文化が正直な問題提起を封じてしまうことです。すべての会議が「いいですね」「素晴らしい」で埋まり、誰かがリスクを指摘すると「なぜそんなに後ろ向きなのか」という視線が返るなら、そのチームは表面的には和やかでも、実際には重要なシグナルを失います。冒頭の決済バグの事例を思い出してください。リスクを指摘したコメントが埋もれたのは、無礼さのためだけでなく、不都合な真実を真剣に扱わない雰囲気のためでもありました。

本当の尊重は「聞こえの良いことだけを言う」ことではなく、「不都合でも必要なことを、相手を尊重する仕方で言う」ことです。キム・スコットの表現を借りれば、個人的に気にかけながら(care personally)直接的に挑む(challenge directly)、その両方です。どちらか一方だけなら、無礼な攻撃か破壊的な共感のどちらかになります。

よくある質問

Q. 正直さと無礼さの違いは何ですか?

対象が違います。正直さは問題へ向かい、無礼さは人へ向かいます。「この設計はこの負荷で壊れそうです」は正直さです。「こんな設計をするとは実力が疑わしい」は無礼さです。もう一つの基準は意図です。相手がより良くなることを願う正直さと、相手を貶めて自分を高めようとする無礼さを、聞く人は本能的に区別します。

Q. disagree and commitは結局、沈黙の強要ではありませんか?

順序が肝心です。disagree and commitは「十分にdisagreeしたあとにcommitせよ」という意味であり、「ただ口を閉じて従え」ではありません。反対意見を出す機会が十分に与えられ、その意見が真剣に検討されたうえで決定が下されたなら、その決定を実行段階で揺らさないことです。もしdisagreeする機会すらなくcommitだけ求められるなら、それはこの原則の誤用です。

Q. リモート環境ではどう尊重を示しますか?

リモートでは非言語のシグナルが消えるため、尊重をより明示的に表現する必要があります。いくつかの具体的な実践があります。テキストでクレジットを明確に残す(チャンネルに「これはOOさんのアイデアでした」と書く)、非同期メッセージに素早くリアクション絵文字でも付けて「読んだし無視していない」というシグナルを送る、ビデオ会議で静かな人を意図的に指名する、時間帯が違う同僚に未明の返答を強要しない。事例1のJが去ったのも、リモートゆえクレジットの盗用がより見えにくく起きたからです。

Q. 無礼だが実力が高い人はどう扱うべきですか?

まず「実力」の定義を広げる必要があります。周りの人を萎縮させてチーム全体の産出を下げる人は、個人の貢献がどれほど優れていても、正味(net)の貢献がマイナスになり得ます。扱う方法は、明確な期待値を行動の言葉で伝えることです(前のSBI参照)。「あなたは無礼だ」ではなく、「レビューで人身攻撃的な表現を使うと人が質問をやめる、それがチームの学習を止める」のように。変化の余地を与えつつ、変わらないなら、その人の実力がチームに残す損害を正直に計算せねばなりません。

Q. 新人なので意見を出すのが怖いです。どう始めればよいですか?

質問の形を借りるのが最も安全な出発点です。「これは間違っています」の代わりに「この部分を私が理解しきれていないかもしれませんが、こうするとこういう場合はどうなりますか?」と問えば、間違っても学ぶ姿勢になり、当たっていれば問題を指摘したことになります。また非同期チャネルを活用してください。会議で口で割り込みにくいなら、ドキュメントのコメントやチャットで意見を残すほうが負担が少ないです。

Q. うちのチームにはすでに不信が積もっています。どこから始めますか?

一度の大きな宣言より、小さな行動の繰り返しが信頼を回復させます。リーダーなら、自分のミスを先に公開することから始めてください。「今回の判断は私の誤りでした」という一言が、ほかの人に「ここではミスを認めても安全だ」というシグナルになります。そして小さな約束を守ることを繰り返してください。信頼は大げさなイベントではなく、守られた小さな約束の積み重ねで築かれます。

オンボーディング最初の30日 尊重チェックリスト

新しく加わった人をどう迎えるかは、そのチームの尊重の文化を何より鮮明に映し出します。最初の30日のためのチェックリストです。

[1日目]
- [ ] 合流初日に歓迎メッセージをチームチャンネルに公に残す
- [ ] 開発環境のセットアップ文書が最新かを事前に確認しておく
- [ ] 「分からないことはいつでも聞いてよい」と明示的に伝える
- [ ] ランチや軽い1on1で、人として先に挨拶する

[1週目]
- [ ] メンターまたはバディを一人指定する
- [ ] 小さく安全な最初の課題(易しいPR一件)を一緒に決める
- [ ] 最初のPRには特に温かく具体的なレビューを残す
- [ ] 「バカげた質問はない」ことを実際の反応で証明する

[2週目]
- [ ] チームの意思決定の仕方と権限の構造を説明する
- [ ] 過去の主要な決定とその文脈(なぜこうなったか)を共有する
- [ ] 会議で一度は新人に直接意見を尋ねる

[30日目]
- [ ] 1on1で「これまでどうだったか」正直なフィードバックを双方向で交わす
- [ ] 新人の第一印象から出た「なぜこうするのか」という質問を真剣に聞く
      (外からの目は、我々が見えない死角を照らす)
- [ ] 小さな貢献でも公に認め、名前を挙げる

新人が最初の月に投げかける「なぜこうするのですか?」という素朴な質問は、実は最も価値ある資産です。それは、我々が慣れすぎてもはや疑わなくなったものを照らし直すからです。その質問を「もともとそうだ」で止めた瞬間、チームは外からの目を一つ失います。

実践チェックリスト

おわりに

ソフトウェアの品質は、結局それを作った人々の関係の品質を映します。互いを尊重しないチームが作ったコードには、その不信が微妙に刻まれます。共有されなかった情報、扱われなかった警告、口を閉ざした人々の沈黙として。

人を尊重するということは大げさなことではありません。最後まで聞き、功績を正確に帰し、コードを批判して人を批判せず、知らないことを知らないと言えるようにすること。この小さな行動が積み重なって良いチームを作り、良いチームが良いソフトウェアを作ります。

覚えておいてください。私たちが作るのはコードですが、私たちが共に働くのは人です。そして結局、ソフトウェアは人がやる仕事です。

参考資料

原文を読む: https://www.youngju.dev/blog/culture/2026-06-16-respect-people-software-is-human.ja

コメント

まだコメントはありません。

ログインするとコメントできます