「毎日仕事が忙しくてさぁ」が口癖になっている皆さん。この忙しさを何とかしようと、スケジュール管理や作業工数を見直してみても解決しないケースがあります。それは複数の課題が混在しているからです。具体例をあげてみましょう。
●締め切りを伸ばしたことで関係者への調整コストが増えた
●決定権をもつ担当者が不明確で最終チェック時間の見積もりがなかった
●納品後の修正対応にルールがなくすべてのフィードバックに対応せざるを得なかった
どんなに念をいれて決めた予定も、人が関わっている以上は遅れやミスが発生してしまうもの。しかし想定外のハプニングにすべて対応していては非効率に時間を消耗することになります。
そこで実践したいのがエンジニアがプロジェクト改善に活用している「KPT（Keep, Ploblem, Try）」の思考フレームワークです。つねに課題を明確に示してゴールへの最短ルートを探しだすエンジニアの方法論を使って、Web編集・ライターである私が1日の作業を振り返ってみました。
KPTのフォーマットに課題を当てはめてみた
KPTとはKeep、Problem、Tryの3つに考えを分類して課題を振り返るためのフォーマットです。このフォーマットをベースにホワイトボードや紙に書き出します。
●Keep：今やっていて今後も継続したいこと
●Problem：問題・リスクだと感じていること
●Try：改善策やチャレンジしたいこと
今回の事例は、フリーランスのWeb編集・ライターとして関わるオウンドメディアで、記事納品後のチェック体制にルールがなく、クライアントや編集者などすべてのフィードバックに対応せざるを得ない状況となってしまった、という課題を解決するための振り返りをやってみました。
●Keep：納品完了後には関係者全員が必ず目を通す
●Problem：修正が必要とされるものすべてに対応している（なかには重複もある）
●Try：納品後の修正可能期間を定めてみてはどうか？
実際に試してみると問題点ばかり頭に浮かんできてしまいますが、適切な振り返りを行うために1つの課題にのみ焦点を当てることにしました。私がつねに忙しさに翻弄されている問題の本質は、どうやら誰の責任範囲なのかが曖昧で無法地帯と化している「納品後」にあるようです。
Tryするためのルールをつくってみた
そこで次は納品完了後の記事に抜け漏れのないチェック体制を保ちつつ、ルールを定めるにはどうすればよいかを考えます。実際にあげてみたルールです。
●納品後のチェックは会議形式でおこなう
●チェック会議は関係者が参加し1時間と定める
●参加できない人は議事録でキャッチアップする
●その後2営業日をテスト期間とし修正の対応をする
●最終確定日を決めて以降の修正対応は禁止にする
ルールを守ろうと意識して行動するのは意外にも負担がかかります。しかし定例化してしまえば関係者間での調整が不要になり、スケジュールにも余裕がでて記事の品質上のリスク要因を削減することができるかもしれません。
またKPTで振り返りをするときに気をつけるべきなのは、Problemにあたる問題点が抽象的になってしまうことです。例えば「ミスが多い」だとあまりにもざっくりしていてTryが浮かばなくなってしまいます。
ミスのなかでも誤字脱字が多いなどある程度の傾向を特定すれば、どの段階でミスを防げるのかの具体策をTryに挙げることができます。
忙しさに振り回されないためにエンジニア的思考法を利用する
フリーランスのWeb編集・ライターである私がエンジニアの問題解決手法であるKPTを取り入れてみた結果、「忙しい」状態をつくっている要素分析を習得することができました。プロセスの改善、ひいては品質の向上は、こうしたトライ＆エラーを着実に積み重ねていく体制づくりにあります。
今回は、こうした思考フレームワークを使いこなし、目標達成に余念のないエンジニアの優位性も伺い知ることができました。私のようにエンジニアじゃない人にも教えたい、エンジニアだけが知っている思考法や仕事術は、まだまだありそうです。
（執筆：小田直美）
