Chat GPTと壁打ちしながらリーダーとしてやったことをまとめていると、思ったよりいい感じのアウトプットになりそうだったので、備忘録も兼ねて記事にしてみます。
はじめに
とある官公庁向けの開発プロジェクトで、リーダーを担当しました。
本案件では、外部システムと連携し、
標準仕様に基づく検査結果データを扱う機能の開発を行いました。
東京・地方の2拠点体制。
通常であれば4ヶ月規模と想定される開発を、約1ヶ月で実施。
4名体制（うち2名は新卒メンバー）での挑戦でした。
最初に決め“きれなかった”こと ― 完璧より完遂
本来であれば、最初に明確にすべきだったのは、
「今回の制約の中で、何を最優先にするのか」
という判断基準でした。
通常4ヶ月規模の開発を1ヶ月で行う以上、
すべてを理想通りに仕上げることは現実的ではありません。
それでも私はどこかで、
設計の美しさや将来拡張性も両立できるのではないか、
と考えてしまっていました。
振り返れば必要だったのは、
完璧を目指さないと宣言することではなく、
成立を最優先にする、と腹をくくること
だったのだと思います。
チーム構成が教えてくれたこと
今回のチームは4名体制で、そのうち2名は新卒メンバーでした。
経験の浅さそのものが問題だったわけではありません。
難しかったのは、
- なぜこの仕様にするのか
- なぜ今は止めないのか
- なぜこのリスクを受け入れるのか
といった「判断の背景」まで言語化しなければ、
認識が揃わないという点でした。
自分の中では暗黙だった基準を、
説明可能な形にする。
その過程で、自分自身の判断基準も磨かれていきました。
標準規格があっても、認識は揃わない
外部サービスの標準規格があることで、
ある程度の前提は共有できると考えていました。
しかし実際には、
- 必須項目の解釈差
- 任意項目の扱い
- 想定外データへの対応
- バージョン差異
など、細かな部分で認識のズレが発生しました。
標準規格は共通言語ではあっても、
共通理解を保証するものではありません。
リーダーとして必要だったのは、
解釈を揃える場をつくること
でした。
一番プレッシャーを感じた瞬間 ― 意思決定
最も重かったのは、
リスクが見えている中で、
それでも「進める」と判断した瞬間でした。
完璧な情報は揃っていない。
すべての懸念が解消されたわけでもない。
それでも納期は迫っている。
止めるのか。
影響を限定して進めるのか。
どのリスクを受け入れるのか。
最終的に決めるのは自分でした。
また、意思決定は、設計の方向性だけではありませんでした。
短納期の中で常に求められたのは、
- どのタスクを優先するのか
- どこまでを今回のスコープに含めるのか
- どの品質ラインを守るのか
という現実的な判断でした。
すべてをやろうとすれば破綻する。
しかし削りすぎれば信頼を失う。
特に難しかったのは、「やること」よりも
何をやらないと決めるか
でした。
今回扱った検査機能は、標準仕様として43項目におよぶ検体検査結果を扱う必要がありました。
各項目ごとにデータ形式や値の扱いが異なり、解釈のすり合わせや検証にも一定の工数を要します。
1ヶ月という期間の中で、43項目すべてに対して設計・実装・テストを完遂するのは現実的ではありませんでした。
その中で、外注検査機能のうち
検査のオーダー機能は今回のスコープから外す判断をしました。
短納期の中で全機能を成立させようとすると、設計も検証も中途半端になるリスクがあったためです。
一方で、
外部システムからの検査結果取得・保存機能は優先して実装しました。
理由は明確でした。
今回の業務フローにおいて最も重要だったのは、
「結果を正しく取得し、保存できること」
だったからです。
オーダー機能は将来的に拡張可能ですが、結果取得部分が不安定であれば、システム全体の信頼性が損なわれます。
完璧に作ることよりも、
業務上の中核を確実に成立させること
を優先しました。
結果として、主要機能は納期内に安定稼働させることができました。
自分の力量への不安
あのときの迷いの正体は、
自分の力量で、この判断を引き受けられるのか
という不安でした。
もし自分の判断が誤っていたら、
チームの努力も、プロジェクトの信頼も失われるかもしれない。
「このスコープで本当に成立するのか」
「削った判断は後で問題にならないか」
頭の中で何度も反芻していました。
しかし気づいたのは、
自信があるから決められるのではなく、
不安や迷いを抱えたままでも、
その責任を引き受ける覚悟を持つことがリーダーなのだ
ということでした。
自信がある状態を待っていたら、
きっと何も決められなかったと思います。
リーダーとは何か
今回の経験を通じて、「リーダーとは何か」を明確に言葉にできたわけではありません。
正直に言えば、今も分かっているとは言い切れません。
ただ一つ言えるのは、
43項目という仕様や短納期といった制約の中で、
迷いながらも判断を止めなかったこと。
そして、その判断の理由をチームに説明し続けたこと。
それだけは、リーダーとしてやるべきことだったのだと思います。
迷いがなくなったわけではありません。
むしろ今後も迷い続けるのだと思います。
それでも、その都度立ち止まり、
判断を引き受けるしかない。
今回のプロジェクトは、その覚悟を持つきっかけになりました。
明日から意識したいこと
今回の経験を通じて、次から意識したいのは次の3つです。
- 方針は最初に言語化する
- 判断の理由まで共有する
- 不安は消すのではなく、分解する
どれも特別なスキルではありません。
しかし、意識し続けることがリーダーとしての差になるのだと思います。
おわりに
完璧なリーダー像にはまだ遠いと感じています。
それでも、
迷いながらも判断を引き受けたあの1ヶ月は、
自分にとって確かな転機でした。
次に同じ局面が来たとき、
今回よりも少しだけ強く、
少しだけ静かに決断できる存在でありたい。
そしていつか、
「あの人のように意思決定できるリーダーになりたい」
と思ってもらえるような振る舞いができればと思っています。
