14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

問題を自分で解決する」から「チームで問題を解決できるようにする」へ——クリティカルシンキングで再考するエンジニアチームマネジメント

Last updated at Posted at 2025-12-12

TRIAL&RetailAI Advent Calendar 2025 の13日目の記事です。

昨日は@kyojinnaapyon さんの「log.debug() だけでは見えなかった世界を OpenTelemetry が見せてくれた話」という記事でした。

この記事は OpenTelemetry を使った観測(オブザーバビリティ)の理解を深め、log.debug() だけでは見えなかったシステム内部の挙動を可視化する価値を丁寧に伝えていて、実務的視点と初心者目線の両方をうまく両立している良記事です。

皆様もぜひご一読ください!

はじめに

ジュディス・A・ボス著『Think: Critical Thinking and Logic Skills for Everyday Life』で紹介される有名な心理学実験 ミルグラムの服従実験 では、多くの人が権威者の指示に盲目的に従い、自らの判断を放棄してしまうという衝撃的な結果が示されました。これは、単なる昔の実験室の話ではありません。「〇〇さんが言ったから」「仕様書に書いてあるから」——私たちの日常業務にも、権威への服従は形を変えて潜んでいます。こうした思考停止は、個人の責任感を薄れさせ、理不尽な状況を受け入れさせるだけでなく、“主体性”という本来持つべき力を奪ってしまいます。

クリティカルシンキング(批判的思考)は、この思考停止から脱却し、個人とチームが主体性を発揮するための強力な武器です。それは単に物事を否定的に見ることではなく、前提を疑い、証拠に基づき、論理的に結論を導くための思考プロセスそのものを指します。

本記事では、個人のスキルセットとして語られがちなクリティカルシンキングを、どのように「チームの文化」に昇華させ、「指示待ち組織」から「規律を持ち、自ら問題を解決できる自律的組織」へと変革していけるのか、その道筋を考察します。

一、なぜエンジニアチームはクリティカルシンキングを重視すべきか

現代のソフトウェア開発環境において、クリティカルシンキングはもはや「あれば望ましいスキル」ではなく、「不可欠な生存戦略」とすら言えます。

  1. 複雑なシステムと変化への対応
    マイクロサービス、クラウドネイティブ、分散システム——現代のシステムは、一人のエンジニアが全体像を完全に把握することが難しくなっています。仕様は絶えず変更され、昨日正しかった前提が今日には覆ることも珍しくありません。このような不確実性の高い環境で「ただ作る」だけでは、間違った方向に全力疾走してしまうリスクを孕みます。
    チーム全体が「この前提は妥当か?」「このアーキテクチャは将来のスケールに耐えられるか?」と問いを立て、仮説を検証し、データに基づいて軌道修正する能力こそが、プロジェクトの成否を分けます。

  2. 継続的な学習とイノベーションの促進
    クリティカルシンキングは「問題発見 → 分解 → 再構築」というサイクルをチームのDNAとして根付かせます。このサイクルを持つチームは、失敗を学習の機会と捉え、技術的負債にも計画的に向き合います。

一方、この文化が欠如したチームは、過去の成功体験に縛られ、慣性に支配されます。技術導入が遅れ、同様のバグが再発し、根本原因の解決が進まないまま時間だけが過ぎていくのです。イノベーションとは現状を批判的に見つめ、より良い方法を探求するところから生まれます。

二、チームの思考を妨げる「見えざる壁」

では、なぜ多くのチームでクリティカルシンキングが機能しないのでしょうか。その背景には、人間の心理的な壁が存在します。

妨害要因 チームでの典型的な行動 もたらされる悲劇的な結末
回避と否認 技術負債や過去の失敗事例に見て見ぬふりをする。定例会では成功事例だけが共有される。 技術負債が雪だるま式に膨れ上がり、大規模な障害や手戻りを引き起こす。
感情論と衆人環視 「〇〇さんが言うなら」とデータを見ずに賛成する。反対意見を言うと場の空気が悪くなるため沈黙する。 個人の好みや声の大きさで技術選定が歪む。コードレビューやテストが形骸化する。
絶対主義と挑戦への恐れ 「うちは昔からこのやり方だ」「言っても無駄だ」という空気が蔓延する。 若手や新しいメンバーが改善案を出すことを諦め、組織全体の成長が停滞する。
面子と気まずさの文化 全体会議では誰も質問しないが、SlackのDMや飲み会では不満が噴出する。 重要なリスクの発見が遅れる。問題の根本原因を探る「なぜなぜ分析」が機能せず。
単一情報源と権威へ依存 特定のテックリードしか触れない「秘伝のタレ」化したコンポーネントが存在する。 属人化が進み、その人がいないと何も進まない。知識が共有されず。

これらの妨害要因は、「自分が間違っていると証明されたくない」という人間の本能的防御機制から生まれます。その結果、他者の意見が遮断され、協力が阻害されます。特に「シフトレフト」の思想とは真逆で、問題の発見が遅れるほど修正コストは指数的に増大します。

三、クリティカルシンキングを育むチーム環境の構築

思考停止に陥ったチームを変えるには、個人への意識改革だけでは足りません。リーダーは、クリティカルシンキングが自然と発揮される「環境」を設計する必要があります。

  1. 心理的安全性の醸成:「無攻撃の挑戦」を奨励する
    すべての土台となるのが心理的安全性です。リーダーが率先して自身の判断ミスを認め、「私の考えはこうだが、皆はどう思う?」「もっと良い方法はないだろうか?」と問いかける姿勢が重要です。「誰が言ったか」ではなく「何を言ったか」に焦点を当て、どんな意見も、たとえそれが未熟であっても、まずは受け止める文化を創りましょう。根拠のない批判や人格攻撃は許さず、しかし、意見やコード、設計に対する建設的な「挑戦」は奨励する。「無攻撃の挑戦(Challenging without attacking)」が当たり前の状態を目指します。

  2. 情報の透明性とコンテキスト共有
    なぜこの機能が必要なのか、ビジネス上のゴールは何か、どのような顧客課題を解決しようとしているのか。こうした「Why」の部分をチーム全員で共有することが、主体性を引き出す鍵です。コンテキストが理解できて初めて、メンバーは単なる「作業者」から、ゴール達成のための「当事者」へと変わります。そして、「その仕様は本当にゴール達成に最適か?」という本質的な問いが生まれるのです。

  3. 議論のフレームワーク導入
    ただ「自由に議論しろ」と言っても、議論は深まりません。思考を補助するフレームワークを導入しましょう。
    * 「その意見の根拠となるデータや事実は何ですか?」
    * 「そのアプローチのメリットと、考えられるリスク(デメリット)は何ですか?」
    * 「私たちが暗黙的に置いている前提は何でしょうか?」
    * 「他の選択肢は検討しましたか?なぜこの選択肢がベストだと考えますか?」
    こうした問いを、設計レビューや定例会議の標準アジェンダに組み込むことで、議論はより構造的かつ論理的になります。

  4. 「斧を研ぐ」時間を意図的に確保する
    リンカーンの「木を切るのに8時間与えられたら、斧を研ぐのに6時間使う」という言葉は、エンジニアリングの世界にも通じます。目の前のタスクをこなす(木を切る)ことだけに追われていては、生産性(斧の切れ味)は落ちる一方です。
    新しい技術の調査、リファクタリング、学習のための時間をスプリント計画に意図的に組み込みましょう。現状のやり方への挑戦を奨励し、より良い「斧」を探求する文化を育むことが、チームを単なる作業マシンではなく、自己進化する自律的組織へと変貌させます。優劣がすぐにつけられない技術選択に際しては、小規模なPoC(概念実証)やスパイクを設けて「両方試してみる」という実験的なアプローチも有効です。

四、文化変革を測定し、改善し続ける

文化変革は目に見えにくいため、測定が重要です。

プロセス指標(先行指標)
* コードレビューでの指摘・質問数: 単なるtypo修正だけでなく、設計やロジックに関する本質的な議論がどれだけ生まれているか。
* 意思決定会議での代替案提示率: 主要な技術決定において、複数の選択肢が比較検討されているか。
* 実験・PoCの実施数と失敗からの学習数: 挑戦的な試みが推奨され、失敗がナレッジとして共有されているか。

結果指標(遅行指標) ※文化変革が最終的なビジネス価値に繋がっているか
* プロダクトの欠陥率(バグ密度)の低下: 問題が早期に発見・修正されている証拠。
* 技術負債の返済サイクル: チームが計画的に負債と向き合えているか。
* メンバーからの改善・イノベーション提案数: メンバーが主体的に課題発見に取り組んでいる証拠。

五、おわりに

クリティカルシンキングは、チーム内に不和をもたらす「粗探し」ではありません。それは、不確実性に満ちた航海において、チームが進むべき最も確かな針路を見つけ出すための「羅針盤」です。

エンジニアリングマネージャーの真の役割は、すべての答えを知っていることではなく、チームが自ら答えを見つけ出せるような、鋭い「問い」と、安心して思考できる「環境」を提供することにあります。

「質疑・検証・反復」をチームの文化として根付かせること。それこそが、変化の激しい現代において、チームが継続的に価値を創造し続けるための、唯一にして最強の戦略なのです。

※ 本稿の日本語表現には AI サポートを用いています。

さいごに

明日は@taquangku さんの『「モバイルアプリにおけるJWT認証の実装について』という記事です。
ぜひお楽しみに!!

RetailAIとTRIALではエンジニアを募集しています。
興味がある方はご連絡ください!

14
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?