目の前の作業は真面目にやっている。期日も守っている。それなのに、案件の終わり際になって「これ、全部作り直しでは」という状況になる。しんどいのは、サボった結果ではないところです。
先日、私が見ている案件でそれが起きかけました。指摘が間に合ったので実際の手戻りにはなりませんでしたが、あと少し遅ければ確実に余計な作業が積まれていたと思います。
何が足りなかったのかというと、能力でも真面目さでもなく、最初に納品物の形を見ておくという一手間だけでした。
技術力とは別のところで仕事が詰まる話は、このブログでいくつか書いています。この記事はそのうち「どこを見ているか」に関するもので、最後に他のパターンもまとめています。
目次
- 運用保守の案件で起きかけたこと
- 器を先に合わせていれば、途中の記録がそのまま成果物になる
- 進捗が順調でも、基準がズレていれば意味がない
- 最初に確認するのは、手順ではなく最後に出すもの
- それでも、意識の問題は残る
- 技術力の外側で詰まるパターンは、他にもある
1. 運用保守の案件で起きかけたこと
運用保守の案件では、定期的に報告を出す義務がついてくることがよくあります。決められた周期で、決められた相手に、決められた内容を出す仕事です。
その定例報告は、毎回きちんと出ていました。期日も内容も問題ありません。ただ、使っていたのは定例報告のために用意されたフォーマットで、案件の最後に納品するものとは何の関係もない形でした。
最終的な納品物の形式を、一度も確認していなかったからです。
このまま最後まで行くと、積み上がった報告を全部開いて、納品物の形に詰め替える作業が発生します。中身は足りているのに、器が違うというだけで。
2. 器を先に合わせていれば、途中の記録がそのまま成果物になる
最初に納品物の形式を確認して、それに合わせて定例報告を書いていたらどうなっていたか。
最後にやることは、集めて出すだけになります。詰め替えも整理もいりません。毎回の報告が、そのまま最終成果物の一部として積み上がっていくからです。
同じ材料で、同じ結論なのに、かかる手間だけが違う。しかも減らせるのは、たいてい案件の終盤という一番余裕のない時期の手間です。
詰め替え作業には、価値が増える瞬間がありません。書き直しても内容は良くならないし、読む人にとって新しい情報も生まれない。純粋に、時間だけが減ります。避けられるなら避けたい種類の作業です。
3. 進捗が順調でも、基準がズレていれば意味がない
やっかいなのは、途中では誰も困らないことです。
一回目の報告を作るときにズレが決まって、以降は真面目にやるほど、ズレたものが正確に積み上がっていきます。本人の中では順調です。決めた通りに、期日通りに進んでいるので、嘘をついているわけでもありません。
だから進捗確認では引っかかりません。「予定通りです」という報告は事実で、その予定が最後の形とつながっていないだけです。表に出るのは、いよいよ納品物を作る段になってからになります。
ズレが表面化するのは終盤ですが、発生したのは着手した最初の一回目です。終盤に見つかった問題を終盤の頑張りで取り返そうとすると、たいてい人と時間が余計にかかります。
4. 最初に確認するのは、手順ではなく最後に出すもの
何かを引き継いだとき、まず知りたくなるのは手順です。どの作業を、いつ、どうやるのか。それは当然として、その前に見ておくものがあります。
最後に何を、どんな形で出すのか。
この案件で私が聞いたのも、その二つでした。最終成果物は確認したか。普段の報告がその形式に沿っていれば、最終成果物は自然とできあがるのではないか。
見るべきものは、前任者が納品した実物、契約や仕様書で決められている様式、あるいは発注元が使っているテンプレートあたりです。手元になければ、着手時点で聞いてしまうのが早いと思います。案件の最初に「最終的な納品物の形式を確認したい」と言って、嫌な顔をされることはまずありません。むしろ終盤に聞く方が気まずいです。
形が分かったら、途中の記録をその形に寄せておく。完全に一致させる必要はなく、項目の並びや粒度が近いだけでも、最後の詰め替えはかなり軽くなります。
プロジェクト全体で認識のズレをどう防ぐかという一般的な整理は認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に書いていますが、個人の作業レベルでは、まず最後に出すものを一度見る、それだけで防げることが多いと感じています。
5. それでも、意識の問題は残る
ここまで書いておいて何ですが、これをチェックリストにすれば解決するかというと、たぶんしません。
「着手前に納品物の形式を確認する」という項目を作っても、目の前の作業しか見えていない状態だと、その項目自体が目の前の作業として消化されます。確認したという事実だけが残って、確認した内容が途中の作業に反映されない。それでは何も変わりません。
私自身、以前は同じでした。言われた範囲を、言われた通りに、期日までに出す。それで仕事をしているつもりだったので、最終的な成果物の形を先に見ていた記憶はありません。全体を見ろと言われても、全体が見えていないから目の前を握りしめているのであって、順番が逆なのだと思います。
なので、これは能力の問題というより、視線をどこに置くかという癖の問題だと考えています。癖なので、一度言われて直るものでもありません。ただ、案件の最初に一度だけ「最後に何を出すんだっけ」と思い出す。それを何回か繰り返しているうちに、順番が入れ替わる瞬間がある気はしています。
同じ出来事を指摘した側から書いたものが定例報告は毎回きちんと出ていたのに、納品物を一度も見ていなかったです。上司の側からどう見えていたのかは、そちらに書きました。
6. 技術力の外側で詰まるパターンは、他にもある
ここまで書いてきたのは、視線をどこに置くかという話でした。コードが書けないから詰まったのではなく、見ている範囲が狭いまま全力で走っていたから、最後にやり直しになりかけた。技術力とは別の軸の問題です。
同じように、技術力があるのに仕事が進まなくなるパターンは他にもあります。心当たりのあるものから読んでもらうのが早いと思うので、それぞれどんな話なのかを書いておきます。
自分では筋道立てて説明しているのに、上司や同僚から何度も聞き返される。そういう状態が続いて自分の性格を疑い始めているなら、それって自分がコミュ障？意図が伝わらないエンジニアが陥る落とし穴が近いはずです。多くの場合は性格ではなく、伝える順番が整理できていないだけだという話を書いています。
難しい問題にぶつかったとき、途中で「まあいいか」と流してしまう自覚があるなら、思考する体力 〜優秀なITエンジニアに必須の“考え抜く力”〜の方です。知識の量ではなく、一つの問題を投げ出さずに考え続ける持久力の話をしています。もう少し広く、知的労働そのものに求められるのは賢さなのかという角度から書いたものが知的労働の本質は“賢さ”ではなく“考え抜く力”です。
新しい技術を試したい気持ちが先に立って、要件から離れた実装をしてしまう。それに気づいているならその技術力、ただの自己満足じゃない？が該当します。技術は目的ではなく手段だという、当たり前だが現場では簡単に見失う話です。
そもそも技術以前に日本語や論理の組み立てで詰まっているのではないか、と感じている場合はソフトウェアエンジニアに最も必要なものは結局〇〇？から読んでみてください。部下のドキュメントやメールを見ていて感じたことをまとめています。
どれも、勉強すれば身につくという種類のものではありません。ただ、自分がどのパターンで詰まっているのかが分かるだけでも、次に何を意識すればいいかは少し絞れると思います。