仕事をしていると、「これは大事だ」と気づく瞬間がある。
マニュアルには書いてない。研修では教わらない。でも知っているかどうかで、プロジェクトの結果が変わる。そういう「小さくて大事なこと」を集めてみた。
議事録は「事実」より「決定」を書く
会議の後に議事録を書くとき、「何が話された か」を書くのではなく「何が決まったか」を書く。
長い議事録を後で読み返すと、何が決まったのかわからないことがある。「〇〇については、Aという意見とBという意見が出た」という記録は、翌週見ても意味がない。「〇〇はAで進める、理由は□□」という記録が、プロジェクトを動かす。
決定事項・担当者・期限——この3点がわかればいい。
「確認します」は最強の返し
クライアントから突然の質問や要望が来たとき、その場で「できます」とも「できません」とも言わない。
「確認してご連絡します」と言う。
この一言で、その場の判断ミスを防げる。即答するためのプレッシャーに負けて「できます」と言ってしまい、後でエンジニアに「それは3週間かかります」と言われるのが最悪のパターンだ。
「確認します」は逃げではなく、正確な情報を届けるための誠実な返答だ。
メンバーの「なんか変」に敏感になる
チームのメンバーがいつもより口数が少ない、返信が遅い、ミスが増えている——そういうサインを見逃さない。
プロジェクトの問題は、たいてい人の問題から来る。タスクが詰まっているのか、体調が悪いのか、何か気になることがあるのか。早めに気づいて声をかけることで、大きな問題になる前に対処できる。
「気にしすぎ」と言われるくらいでちょうどいい。
クライアントを「教育」するという感覚
「クライアントの言う通りに動く」がディレクターの仕事だと思っていると、いつか限界が来る。
クライアントはシステム開発の専門家ではない。「これができるはず」「こうすればいい」という思い込みを持っていることがある。その思い込みをそのまま受け入れると、作ったものが本来の目的を果たさない。
「それはこういう理由で難しいです」「代わりにこういう方法があります」と提案できる関係を、丁寧に作っていく。それがプロとしての仕事だ。
「完璧なドキュメント」より「使われるドキュメント」
仕様書は美しく書く必要はない。必要なことが書いてあれば十分だ。
むしろ「完璧な仕様書を作ること」に時間をかけすぎると、その間に状況が変わって書き直しになる。80%の完成度で共有して、フィードバックをもらいながら更新する方が、最終的に精度が高くなる。
ドキュメントは「作るもの」ではなく「使うもの」だ。
余裕のないときこそ、立ち止まる
プロジェクトが炎上しそうなとき、人は「とにかく前に進もう」と焦る。
でも焦って判断した決断は、だいたい後で後悔する。5分でいいから、今の状況を整理する。何が起きているのか、何が一番重要な問題なのか、何から手をつけるべきか——それを書き出すだけで、頭が整理される。
パニックのときに冷静でいられるかどうかが、ディレクターの実力差になる。
