新人のころから言われてきていて、30目前になってもまだ上手く仕事ができないことがあるので、見つめなおすためのポエム。全ての仕事に当てはまるわけではないので、ご注意ください。
この記事は要約すると「ホウレンソウをしっかりしよう」です。
当たり前の話ですが、納品が必要な仕事では納品物を作成する必要があります。
エンジニアだとコードを納品することが多いのではないでしょうか。（私はインフラエンジニアや保守運用等々のエンジニアの経験が無いので、何を納品するかわかっていません。）
それで、コードを納品した後に言われるんです。
「で、設計書は？」
似たような経験はありませんか？当人としては仕事を完了したと思ったのに、後から認識していなかった条件が提示された経験はどなたもあると思います。
これを回避するためには、作業の初期に作業者が作業の終了条件を依頼者と認識合わせをしておく必要があります。
登場人物（アクター）
- 作業者
- 作業する人。
- 依頼者
- 作業を依頼した人。作業の完了を受け入れる人。
終了条件の整理
仕事内容にもよりますが、私の場合は次を意識していると相手との会話がスムーズになることが多いです。
- 納品物の整理
- フォーマット確認
- 内容確認
- 実装対象の機能リスト
- 事前条件や実行条件、事後条件等々
- 業務フローに沿ったテスト一覧
- どの粒度のテストまで行うか
作業の終了条件の認識合わせで大事なのは、内容がすべて満たせている場合は必ず相手に作業終了を受け入れて貰うことです。
作成物の品質が悪い場合は受け入れることはできません。しかし、依頼者の条件提示が不足することは無くなります。もし、条件提示の不足が起こった場合は、認識合わせの場で言わなかった依頼者が悪いのです。
だからといって、依頼者を責める必要はありません。依頼者も人間なので確認漏れはよくありますし、作業が終了するころには、状況が変わっていることはよくある話です。
その場合は、今の作業は完了にしつつ、追加作業という形で管理しましょう。または、スケジュールの期日を伸ばしてもいいです。
作業者と依頼者のお互いが納得するようにコミュニケーションをとると、ストレスが大きく減ります。
これは経験則ですが、できるだけ責任は偉い人に取ってもらえるように立ち回るとうまくいくことが多いです。今回の場合は、依頼者ですね。
相手が悪いのか、自分が悪いのかで納得感が違うためです。
本来であれば、作業者が悪いのは依頼者の管理能力不足でしょうが、そういう目線で守ってくれることは経験上ありませんでした。で、スケジュールの期日が伸びずに残業でカバーする毎日…。
相手に納得してもらうコミュニケーション術は大事です。
作業の完了度は作業の理解度
作業が完了する頃には、その作業に対して最も理解しているのは作業者です。逆に言うと、作業を完了させるためには、作業を理解する必要があります。
では、作業を完了させるまでの中間の理解はどうなっているでしょうか。
毎日コツコツと理解できるでしょうか。
実際にはコツコツと理解することはできません。だいたい、作業終盤に急に理解したり、レビューで理解できることが多いのではないでしょうか。
後で理解するのと、先に理解しておくのでは、当然先に理解する方がいいです。早期に作業の終了条件を定義するのは、理解を前倒しにするためです。
いかに早く理解するか。いかに早く失敗するか、というのは大事です。
個人的に10年近く仕事をしてきた経験から、知らなくてもいいことは想像よりも少ないです。
例えば返金機能を実装するとしましょう。その場合、返金機能だけを理解すればいいものではありません。返金するためには売上を事前にしなければなりませんし、売上の前に入荷等の機能もあるかもしれません。返金したら次は返品等もあるでしょうし、返金した分は売上に反映しないといけないでしょう。
そのような業務フロー、事前条件を理解しないまま作成することは可能ですが、手戻りが発生する確率は非常に高くなります。
なお、理解度を深めるために「とりあえずやる」は危険信号です。できるだけ本番に近い状態にして早く失敗することは大事ですが、行き当たりばったりになりかねないです。
結局、「要はバランス」ということになりかねないですが、少なくともそのシステムが請け負う主要な業務フローは理解しておくといいでしょう。
備考
この記事では終了条件という表現をしていましたが、アジャイルだとDoneの条件(Definition of done, DoD)、受入条件(Acceptance Criteria, AC)と表現しています。
Doneの条件と受入条件は表現していることが異なります。
- Doneの条件
- 全ての作業でやるべきこと
- 資料の作成する
- テストする
- 等々
- 全ての作業でやるべきこと
- 受入条件
- それぞれの作業でやるべきこと
- 業務フローに沿った「入荷」して「売上」して「返金」できることを確認する
- 等々の具体的な内容
- それぞれの作業でやるべきこと
Doneの条件は開発者が品質を担保し、受入条件はプロダクトオーナーが機能を担保します。
責務が分かれているので、言葉の定義が分かれていますが、結局のところやることは変わらないので、豆知識として覚えてください。
なお、競技プログラミングでもACと言いますが、競技プログラミングのACはAccepted（受け入れました）らしいので、ちょっと意味は異なります。
終わりに
「段取り八分・仕事二分」とも言われています。
段取りが多すぎて仕事をする時間が取れない…ということもありますが、手戻りが発生すると大変です。最悪、スケジュールが遅れてることの説明、その説明の準備…と無駄な仕事が増えることも多々あります。
私はコミュニケーションをすると非常に体力を持っていかれるので苦手なタイプですが、そのデメリットを上回るほどのメリットを感じてきました。
ぜひ、仕事がうまくいかないという場合は、終わりから逆算するようにし、相手との納得感を持ちながらコミュニケーションをしてみましょう。
この記事がお役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。
