PDCAを回すために「書く側」と「読む側」が意識したいこと
エンジニアの仕事には、コーディングだけでなく、設計、技術調査、レビュー、テスト、ミーティング、他部署との調整、障害対応など、実にいろいろな仕事があります。
そんな日々の仕事を振り返るために、週次の「振り返り」や「週報」を取り入れているチームも多いのではないでしょうか。
ただ、この週次振り返り。
「今週やったこと」を書くだけになっていませんか？
あるいは、読む側も「予定通り終わったか」「たくさん仕事をしたか」だけで評価していないでしょうか。
週次振り返りは、単なる作業報告ではありません。
せっかくなら、PDCAを回しながら、本人の成長や仕事の改善にもつながる場にしたいところです。
エンジニアの週次振り返りについて、「書く側」と「読む・評価する側」それぞれが意識したいポイントを、自分なりに整理してみました。
そもそも、週次振り返りは何のため？
週次振り返りで確認したいのは、以下のことです。
-
今週、何を目指していたのか
-
実際に何をしたのか
-
結果はどうだったのか
-
なぜそうなったのか
-
次はどうするのか
つまり、
「何をしたか」→「どうだったか」→「なぜそうなったか」→「次にどうするか」
までつながって、初めてPDCAとして意味を持ちます。
「今週は○○をやりました」で終わってしまうと、これは作業ログです。
もちろん作業ログも記録としては大切なのですが、振り返りとして考えるなら、もう一歩踏み込んでみたいところです。
書く側が意識したいこと
PLAN：何をする予定だったのか
まずは「今週何をするつもりだったのか」。
ここでは、単純にタスクを書くよりも、そのタスクによって何を実現したかったのかまで書けると、その後の振り返りがしやすくなります。
例えば「APIの設計を進める」だけでは、「どこまでやれば終わりなのか」が少し曖昧です。
それよりも「○○機能のAPI設計を完了させ、来週から実装に着手できる状態にする」と書いておけば、「そこまで到達できたか？」を後から確認できます。
ポイントは、作業内容ではなく「達成したい状態」を意識すること。
「○○をする」ではなく、「○○ができる状態にする」と考えると、PLANがぐっと具体的になるのではないでしょうか。
DO：実際に何をしたのか
ここは比較的書きやすいところです。
ただし、「何をしたか」だけではなく、その中でどんな判断や工夫をしたのかも残しておきたいところ。
例えば「○○機能の設計を行った」よりも「○○機能のAPI設計とDB設計を実施。既存機能を調査したところ、認証方式が異なることが分かったため、新たな方式で設計した」
と書いたほうが、仕事の中身が伝わります。
エンジニアの仕事は、手を動かした時間だけではありません。
「調べた」「考えた」「比較した」「相談した」「判断した」という部分にも、かなり大きな仕事があります。それらを明確にすることが、自分のできたこと・工夫したことを読み手に伝えられるのではないでしょうか。
CHECK：ここが一番大事
週次振り返りで、一番価値があるのはここかもしれません。
「予定通り終わった」「終わらなかった」だけで終わらず、なぜそうなったのか？を考えてみます。
例えば、予定より遅れた場合「設計が終わらなかった」だけでは、次につながりません。
そこからぐっと踏み込んで「当初は既存仕様を流用できると考えていたが、実際には○○の制約があり、新規に設計する必要があった。その調査に想定以上の時間を要した」とすると、「遅れた」という結果だけでなく、その原因が見えてきます。
さらに「次回は類似機能の仕様確認を設計開始時に行い、見積もりに反映する」までつながれば、次のACTIONになります。
これで、ちゃんとPDCAが回り始めます。
「うまくいかなかったこと」だけが振り返りではない
振り返りというと、どうしても「反省点」を探してしまいがちです。でも、うまくいったことも立派な振り返りの材料です。
例えば「今回はレビュー前に設計上の懸念点を整理しておいたことで、レビュー時間を短縮できた」
のであれば、「なぜうまくいったのか？」を考えてみましょう。
すると「事前に懸念点を整理することで、レビューを効率化できた」という気づきが得られます。ならば次回以降も「レビュー前に懸念点を整理する」という行動を継続すればいい。
失敗を繰り返さないことだけでなく、成功した行動をCheckで評価し、Actionとして再現することもPDCAで大事なことです。
ACTION：「次は頑張る」から一歩進む
振り返りの最後にありがちな言葉。
「引き続き頑張ります」
……気持ちは分かります。
でも、これでは次の行動が変わりません。
例えば「引き続き設計を進める」ではなく「設計着手時に既存の類似機能を確認し、流用可能な部分を先に整理する」なら、次回の行動が具体的になります。
「コミュニケーションを意識する」よりも、「MTG中に認識が曖昧な点をその場で確認し、終了後に決定事項を整理して共有する」のほうが、実際に行動できます。
ACTIONでは、「次に、自分の行動がどう変わるのか・変えるべきなのか」を、より実務に近い行動を考えて、書いていきたいものですね。
ふわっとした感想や概念だけでは、行動に移しにくいです。
コーディング以外の仕事も、ちゃんと成果
エンジニアの仕事というと、どうしても「コードを書いた量」に目が行きがちです。
でも実際には、
-
要件整理
-
設計
-
技術調査
-
コードレビュー
-
テスト
-
障害調査
-
ドキュメント作成
-
ミーティング
-
他部署との調整
-
メンバーへの支援
-
リリース対応
なども、すべて仕事です。
例えば「○○MTGに参加した」だけでは、どんな成果があったのか分かりません。
一方「○○について関係者間で認識が異なっていたため、仕様を整理して合意形成を行った」なら、そのミーティングによって何が進んだのかが見えてきます。
「MTGに何時間使ったか」だけではなく、その時間によって何が前に進んだのかを振り返ってみると、仕事の価値が見えやすくなります。
「忙しかった」と「成果があった」は別の話
週報でよくあるのが「今週はMTGが多かった。 問い合わせ対応が多かった。 急な依頼が入った」という記述。
もちろん、これも重要な情報です。ただ、「忙しかった」という事実と「成果があった」ということは、少し別の話です。
例えば「問い合わせ対応に予定より時間を使った」で終わるのではなく「問い合わせの多くが○○に集中していたため、FAQを整備した。今後、同様の問い合わせを減らせる可能性がある」となれば、単なる突発対応が改善活動につながっています。
目の前の仕事をこなすだけで終わらず、そこから改善につなげられたか。これも週次振り返りで見たいポイントです。
読む側・評価する側が見るべきポイント
ここまでは「書く側」の話でした。
では、その振り返りを読む側は、何を見ればいいのでしょうか。
単純に「予定通り終わったか」だけを見るのではなく、次のようなポイントを意識すると、より適切な評価につながります。
① 目的を理解しているか
言われた作業をこなしただけなのか。それとも、「なぜ、この仕事をするのか」まで理解しているのか。
これは成果物だけでは分かりにくい部分です。だからこそ、振り返りに書かれた「考え方」に注目しておきたいところです。
② 状況を客観的に把握できているか
予定と実績に差があったとき、
-
自分の見積もり
-
技術的な問題
-
要件変更
-
他チームとの依存
-
突発対応
など、原因を切り分けて考えられているか。
「遅れた」という結果だけでなく、なぜ遅れたのかを、本人が把握できているかを見ることが大切ではないでしょうか。
③ 原因分析ができているか
例えば、遅延という事象に対して「時間が足りなかった」だけではなく、「不明点を調査せずに見積もりを出してしまったため、追加調査に時間がかかった」など、細かい部分まで分析できているか。
そして「次回は見積もり前に不明点を洗い出す」と次に繋げる意識を持てているか。
ここまでできていれば、今回の失敗そのものよりも、そこから学習できていることをプラス点として評価できます。いわゆる褒めポイントですね！
④結果だけで評価しない
例えば「今週予定していた実装が完了しなかった」
これだけを見ると、マイナス評価に見えるかもしれません。
でも、その理由が「実装前の調査で既存設計の問題を発見し、後工程での大きな手戻りを防いだ」のであれば、むしろ価値の高い仕事だった可能性があります。
反対に「予定通り実装完了しました」でも、レビューで大量の修正が発生していたら、単純に「予定通りだから良かった」とは言えません。
だからこそ「予定通り終わったか」ではなく「どんな価値を生み出したか」を見ることが重要だと考えています。
⑤フィードバックは「良かったです」で終わらせない
振り返りを読んだ後「良かったです。 引き続き頑張ってください」だけで終わってしまうと、せっかくのPDCAがここで止まってしまいます。
あくまで個人的な主観ではありますが、フィードバックは、事実 → 評価 → 次への期待という流れを意識すると書きやすくなる気がします。
-
何が良かったのか
-
なぜ良かったのか
-
次に何を期待しているのか
などを記載すると、相手の理解解像度がアップすると思います。
改善を求める場合も「もっと計画的にやりましょう」だけでは、本人には何を変えればいいのか分かりません。
例えば、
今週は当初想定していなかった調査に時間がかかり、予定との差が発生しています。今回の調査自体は必要なものでしたが、次回は設計開始前に不明点を洗い出すことで、見積もりに反映できると良さそうです。
とすれば、「何が問題だったのか」と「どう改善するのか」が明確になります。
⑥評価する側も「書かれていないこと」を想像しすぎない
ここも意外と重要かな、と最近思い始めました。
例えば「○○の設計を完了」としか書かれていないのに、「きっと難しい設計だったんだろう」
と評価者が勝手に補完するのは危険です。
逆に、MTGが5件あったと書いてあるから、「MTGばかりで開発作業をしていない」と判断するのもよくありません。
今週はMTGが多かったようですが、その中で担当した役割や、決定事項への貢献があれば教えてください。
こうした質問を通して、相手の行動を深堀りしていくことも必要ではないでしょうか。
書く側・読む側、それぞれのポイント
最後に、ポイントをまとめてみます。
|
観点
|
書く側
|
読む・評価する側
|
|---|---|---|
|
PLAN
|
目的・達成状態を明確にする
|
目的を理解して計画しているか
|
|
DO
|
作業だけでなく判断・工夫を書く
|
どんな貢献をしたか
|
|
CHECK
|
結果と原因を分けて考える
|
状況を客観視できているか
|
|
ACTION
|
次に変える行動を具体化する
|
改善が実行可能な内容か
|
|
成果
|
コード以外の仕事も含める
|
作業量ではなく価値を見る
|
|
問題
|
問題と原因を整理する
|
責任追及ではなく改善を見る
|
|
成長
|
学び・気づきを書く
|
成長や再現性を見る
|
|
課題
|
必要な支援も書く
|
必要な支援を提供する
|
|
フィードバック
|
指摘を次の行動につなげる
|
事実＋評価＋期待を伝える
|
「評価されるための作文」にしない
週次振り返りで一番避けたいのは、これかもしれません。
「悪く見られないための作文」になってしまうこと。
そうなると「問題ありませんでした。 順調に進みました。 引き続き頑張ります」という、無難だけれど、何も分からない振り返りになってしまいます。
むしろ「ここは見積もりを外した。 この判断はうまくいった。 このMTGによって問題を解決できた。 ここは自分だけでは判断できなかった。 次はこう変えてみる」という現実的な記録のほうが、本人にとっても、評価する側にとっても役に立ちます。
なにより評価する側も、「失敗を見つける人」ではなく、「振り返りから次の一手を一緒に考える人」でありたいものです。
エンジニアの仕事は、コードを書いた量だけでは測れません。
成果物、判断、問題発見、改善、周囲への影響。そうしたものまで含めて振り返ることができれば、週次振り返りは単なる「週報」ではなく、仕事そのものを少しずつ良くしていくためのツールになるはずです。
