はじめに
プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。
10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。
- 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。
- レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。
そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。
つまり、__各自の仕事の進め方の良し悪しを見える化__が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結果をメンバー全員で共有しました。
その結果、各自が自分の仕事の進め方のよくない点を認識し、各自が自分で自分の行動を改善してくれるようになりました。
その時に活用したチェックシートと運用方法を紹介します。
チェック項目
7項目あります。実際に大きな手戻りとなった事例をもとに項目を作成したため、MECE(重複なく漏れなく)に分類されていない点はご了承ください。
以下に具体的なチェック項目を紹介します。
目的の意識を評価する項目
1. 自分のタスクの目的が何であり、その成果がどのように活用されるか理解して進めている。
- 起きる問題の例
- タスクを進めているうちに、いつのまにか本来の目的を忘れてしまい、目的を達成できない成果を作ってしまった。
- テスト仕様書を作成する際に、該当のテストケースでどんな不具合を除去すべきか考えずに作成したため、目的の不具合が除去できないテストケースになってしまった。
2.タスクを依頼するときに、タスク内容と共に、何のためか目的を説明している。
- 起きる問題の例
- 同上
効率の意識を評価する項目
3.自分の作業範囲のみを考えるのでなく、自分が関わるプロダクト全体を効率よく進めようと考えている。
- 起きる問題の例
- 分担して同時に複数人でテスト実施する際に、ある参照ドキュメントの不備が原因で、テスト実施につまずき無駄な時間がかかる問題があった。その問題は、テスト実施者全員が遭遇する可能性が高いため、情報を共有すべきであった。しかし、その情報はテスト実施者間で共有されず、全員同じ問題で無駄な時間を費やしてしまった。
4.時間がかかり手戻りリスクがあるタスクは、独断で進めず、事前に識者と進め方を相談している。
- 起きる問題の例
- 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。
5.完了条件を明確にした上でタスクを進めている。
- 起きる問題の例
- タスクの完了条件を明確にしていないため、「やるべきこと」と「やった方がいいこと」の区別ができず、「やった方がいいこと」をし続けて、完了時期が大幅に延びてしまった。
品質の意識を評価する項目
6.発生した問題に対して、類似問題がないか横展開調査を実施している。
- 起きる問題の例
- レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。
判断全般を評価する項目
7.なんとなく意思決定するのでなく、ロジカルに判断して意思決定している。
- 起きる問題の例
- 設計時に、クラスの分割方針、クラスやメソッドの命名、処理順序などをなんとなく決めてしまい、レビュー時になぜそれが妥当なのか説明できず、手戻りが発生した。
運用方法
当時の私のプロジェクトでは、毎月メンバー全員が自己評価し、その結果は1つの帳票で確認できるようにしました。チームリーダーも当然実施します。
評価結果の判断基準は、以下の通りです。
○：概ねできている（感覚的に90%以上できている）
△：意識はしているが時々できていない（感覚的に60%以上できている）
×：あまりできていない(感覚的に60%未満）
－：そのような機会がない
以下は記入例です。
皆に見られる帳票なので、できていないのに○にする人はなく、みんなちょっと厳しめに自己評価していました。
ポイントは、毎月、結果に対して、リーダーがフィードバックをすることです。「今月はA君とB君が目的意識の評価項目が上がりましたね！」とか、そういうフィードバックが重要です（この手の活動は、フィードバックをしないと形骸化します）。
実施効果
「自分の問題点を認識」→「自分の行動を改善すると帳票に反映」というサイクルにより、自分で行動を改善する傾向が現れ始めました。最初は×だらけだった項目が、少しずつ△や○に変わっていき、各自の仕事の進め方が段々改善されていきました。数ヶ月で×がかなり減りました。
×の項目が少なくなったら辞め時だと思います(あまり長くやってもマンネリ化するため)。
当時から10年近く経過した今、このやり方を改めて見ると、評価が生々しすぎて、人によっては合わない場合もあると思いました。ただ、当時は若手同士でわりと楽しくやっていたと思います(素直なメンバーばかりで救われました)。
帳票ダウンロード
以下にExcel形式での帳票を格納しましたので、もしよろしければ、ご利用ください。
仕事の進め方チェックシート
ただし、上記チェック項目は「当時の私のプロジェクト」でよく起きた問題です。
そのため、利用する際は、チェック項目を「そのプロジェクトでよく起きている問題」に入れ替えることをお勧めします。
まとめ
仕事の進め方も、見える化すると改善されます。
最近は、もっと楽しく仕事の進め方を改善できる以下の施策を実施しています。
特に__モブプログラミング__は、暗黙知や考え方の共有も含めて楽しく成長できるので、とてもお薦めです。
私は上記手法を用いて こちらのツール を作ったりしています。
Twitterでも開発に役立つ情報を発信しています → @kojimadev