エンジニアが無駄なと思う作業をするときの心得
どこの立ち位置でと言うのがキモになるかもしれませんが、プロマネやコンサルの立場に関わらず、いちエンジニアとまるっと括った上でお話をすると、
「（これ今やるのがいいのか、必要とする数日前にやらないともう1回更新することになるから無駄だろう）」
なんて思うことがままある。今のお仕事の役割は良くある。
でも、絶対に「無駄ですからやめましょう」とかは言わない。
何故いわないか。手戻りしたらやり直しで追加の費用を貰える契約ではない。手間を掛けたら掛けた分、リソースが目減りするから依頼元から見れば損失である。エンジニアの専門家としては行う期日をスライドさせるべきだ、と言うのが正しいのかもしれない。
正しいことを言うのが専門家ではない。正しいと思うこと自体がエンジニア目線である。専門家として助言を求められているなら、例えば、どのタイミングでやるのが最適かを尋ねられているなら必要とする数日前が合理的であればそう答えればいい。
なぜ無駄と言わないか。
別に無駄ではないと思っていない訳ではない。無駄である。1回で終わる作業であれば。
ここである。
業務を委託する元が作業の結果を見てみないといいとも悪い（作り変えて欲しい）とも判断がつかないことがある。例えば、レビューのメトリクスを集計してある期間を特性ごとに分類して原因を分析して欲しいと依頼されたとする。依頼された日から、必要とする期日の数日前に作業をすれば十分間に合うオーダーがあったとする。
依頼元は必要な期日より前、必要とする期日までの中間日に見たいと言う。どうしてかを考えてから無駄だと言っても遅くはないし、多くのケースでは口は閉じておいた方が良い。
どうして委託元は、中間日に見たいと言うか、その事情、段取りを聞き出すことが先決である。
多くのケースでは、委託元が依頼した作業の内容を見極められていない、と言う理由があるからである。必要とする期日まで時間を使い切ってしまった上で、得られた結果が期待する結果にならなかった場合、分析方法を変えるとか追加でメトリクスを収集するとか対処する時間を確保できず、結果的にはその委託元は立場がなくなることを恐れているからである。
委託元の立場はどうでも良い（ビジネスになっているなら良くない）が、結果により将来が左右されるのであればそれは回避したいところである。
ここでもエンジニアは期待する結果を得られようが、得られまいがそれは委託元の先のビジネスであってエンジニアの立場では関係がないと短絡的な反応をするケースがあとをたたないが、ここで切ってはいけない。ビジネスとして。
ちょっと勘違いをされるとあとがおかしくなるので補足しておくと、無駄な作業でも言われたことをホイホイやる何も考えもせず仕事をやっておけばいいとは思っていない。
ここで押さえておきたいことは、その作業＝中間的な作業をすることに価値があるかどうかを受け止めよう、と言うことだ。
長くなったのでおさらいをすると、委託元は分析結果を見なければそのあとのアクションを変えざるを得なくなる場合、期待する結果となるか期待する結果とならないかをリカバリできるだろうタイミングで判断したいと言う段取りと心情は理解できるものだ。
これは何かに類似しているパターンではないだろうか。
そう、アジャイル開発でのスプリントを短くして早く結果を手に入れ、ビジネスにフィードバックするのと同じである。
アジャイル開発は、短いスパンで結果を判定し、ビジネスの方向性をピボットするかどうかを判断すると言う考え方は情報施策の企画やフィージビリティスタディで使えるのである。
エンジニアの目線でだけで見ると同じ作業を2回することになり無駄に見えるかもしれないが、委託元のポジションで考えると価値がある中間作業に変わるのである。
ではエンジニアはどうしたら良いか。
基本はやりましょう、と言えばいい。つまり、yes,butと始めればいい。スケジュールが詰まっているなら中間作業をすると他の作業を後ろ倒しするスケジュールの調整はその場でコメントをすること。
もし、実作業をするのが依頼を受けた本人ではなく、別のメンバの場合、1回目の作業をする際に、手順の確立をさせておくことと2回あるよと申し送りしておくこと。
最初から2回やると言っておけば、単なる２ショットと受け止められる。先が見えないところで追加をされる方がよっぽど嫌な気持ちになるものだから。
