日々の「小さな判断」を構造化したらわかったこと

趣味でやっているDTM。
音色ひとつ決めるだけでも無限に時間を掛けられるし、自分で決めないと終わりはありません。

つまり、１曲の中に無数の判断が介在しています。

ここでは日々の業務の中にある「小さな判断」を整理し、私の判断軸を言語化してみたいと思います。

エピソード１：停滞している案件の進行整理

とある孫請け案件の話。
納期近くになってからお客様より仕様変更のオーダーがあったと、元請けより五月雨に連絡がありました。

時間がかかっても良いから、いいものにしたいとお客様より要望がありました。
なので、ここはこうする予定でしたがお客様が方針を検討中です。
あとここも・・・​

いいものにしたい、という気持ちは同じですが現実的な制約は当然あります。

お客様とのコミュニケーションは元請けのみ、自分達はお客様に直接意図を伺う立場にない。
さらに私たちは次の案件も控えており、予算が出てもリソースは埋まっている。
次案件への影響も懸念される。
自分たちとしては当初の仕様、納期で納めたいし、元請けとしてもいつまでも付き合ってはいられない。

いいもの、といってもどこまでやるのか、終わりも見えていないと判断もできない。

コミュニケーションが間で絶たれる構造により三者間それぞれの前提と意向が噛み合っていない状況です。

私はどう判断したか？

このまま仕様変更の議論が続けば、次案件への影響が避けられない状況でした。
特に元請けが情報の中継をするだけの状況と未定のゴールが大きなボトルネックと判断し、本来のスコープ外でも、進行整理を買って出る選択をしました。

• 仕様を変える場合にお客様側で増えるタスクをリストアップ
• 仕様変更の場合の概算費用とスケジュールを提示

特にタスクについては元請けがそのままお客様に説明できるように資料化し、元請けに提供しました。

これらの判断材料を用意し、「当初の仕様、スケジュールを一旦ゴールとしませんか？」という着地にしやすい状況を作りました。

なぜそう判断したのか？

進んで手綱を掴みに行かないと振り回されるだけ。
本来は役割でなくても将来的な混乱を未然に防げる方が、結果的に三者それぞれにトータルでのコストを抑えられると判断したためです。

どうなったか？

結果的に仕様変更を見送る決断をされ、なんとかプロジェクトの軌道修正を図り無事に納期通りに納めることができました。

関係者間の前提や制約を構造として整理し、意思決定しやすい状態を設計することで
プロジェクト全体のリスクを最小化することに繋がったと考えています。

エピソード２：常駐先でのアドバイス

常駐先の若手エンジニアとの話。

とある案件でお客様から頂いた宿題を任せており、明日はその回答をプレゼンするという段階で、資料のレビューを行いました。

ぎっちりとスライドの隅までテキストが埋め尽くされており、流石にこれは・・・というアウトプットでした。

私はどう判断したか？

常駐先では指導を任されていたわけではありませんし、任せたタスクではあるものの
「差し出がましいかもしれないけど ”私ならこうする” という案を作ってもいい？」
と確認した上で「あくまでも一つの案」として資料を作りました。

• テキスト中心から図示に変更
• ぱっと見で比較できるようにA案とB案を連続するスライドに並べて「こっちの方が運用上も分かりやすい」ということを把握しやすくする

なぜそう判断したのか？

任せたタスクを奪いたいわけではないし、立場を踏まえると関係悪化のリスクも考えられます。それでも目的が「お客様が納得する方向を示す事」であるなら、差し出がましいと承知の上で一歩踏み込みました。

どうなったか？

私の案をそのまま採用させて欲しいとのことで、そのまま資料を託してプレゼンも無事に乗り切ることができました。

それ以来、資料のレビュー依頼が増えましたし、私の作った資料がフォーマットとして採用されるなど役割以上の貢献に繋がりました。

私の判断軸

構造化されてこなかった日々の「小さな判断」を言語化してみると、以下のキーワードに集約されます。

• 相手
• 関係性
• 目的

判断とは自分の中で完結するものではなく、相手の合意があって初めて成立します。
そして相手と私、それぞれの立場や役割の違いは判断の違いに繋がります。

以上を大前提として目的と関係性を判断の起点として、「立場的にここまで」とするか、敢えて踏み込むかを判断する、という傾向があるとわかりました。

今回の例では結果的には関係性を維持しながら目的も果たせており、
一定の再現性を持って意思決定を行っていると捉えられます。