負の連鎖を断ち切るために
「負の連鎖」を断ち切るためには、“ターニングポイント”が必要と述べました。私にも“ターニングポイント”があり、そのおかげで改善への第一歩を踏み出すことができました。
会社も期待できない、現場も期待できない、でも改善したい･･･。その答えが｢独善｣でした。
第1回で紹介した「独善のパターン」を、あらためて以下に示します。
- 改善したい事を明確化する
- 情報を収集する
- 実践項目を選択する
- 導入前に試してみる
- 試した結果を評価する
- うまくできた → 導入する
- うまくできなかった → 改善策を考える／導入を見送る
このパターンに従い、まずは自分が生み出している負の要因を洗い出してみました。
自分が生み出す負の要因
- スケジュールの管理不足
開発作業に加え、調査や解析などの様々な割り込み作業をこなさなければならず、自分の進捗管理がほとんどできていない状況がありました。進捗管理が不十分なため、計画をたてた作業が行えず、いつも進捗が遅れている焦燥感に駆られ、ついつい残業してしまう場面がありました。 - 依頼内容の管理不足
時々刻々と発生する様々な依頼作業を上手く管理できておらず、作業の見落としが発生し、事前調整することもできなくなり、ぎりぎりになって作業を実行する場面がありました。もっと早く実行していれば残業しなくて済んだのに、時間がなくなって、締め切り前日の夜まで忘れていたことも何度かありました。
また、作業終了日を確認せず、「完了希望日未定」と考え後回しにしていると、ある日突然「締め切りは明日です」と告げられ、残業対応が発生するといったこともありました。 - 見積もり精度が低い
とにかく見積もりは苦手でした。何度やっても上手くいかず、非常に悩みました。見積もりを作るためだけに会社に２泊したこともありました。
上記３点の負の要因に対し、簡単かつ費用の掛からない改善策を考えてみました。ちょうど仕事が閑散期に入ったこともあり、実際に改善へのプロセスを実現することができました。
自分を独善する
改善へのプロセスを検討する際、社内のメンバー、ネット、書籍などから得た様々な知識を総動員し、最適な方法を選び、試してみました。
特に、下記２冊の本は非常に参考になりました。
- 『管理者になったとき困らない 実践的ソフトウェア開発工程管理』
著者：竹山 寛（技術評論社） - 『図解入門 よくわかる最新XPエクストリームプログラミングの基本と仕組み』
著者：樋口 博昭、長瀬 嘉秀（秀和システム）
以下に、実際に試してみた内容と、その感想を記述します。
朝イチで本日の実施内容を決める
スケジュールの管理不足
朝、一番初めに昨日実施したこと、今日実施すること、残り作業を確認します。これらの３項目を確認することで、日々のスケジュール管理と当日の目標が明確になり、その日自分がどれだけ作業を消化しなければならないのか判断可能になります。さらに、朝一番で作業の確認を行うことで、自分がどれだけ頑張ればよいか明確になります。
それまでスケジュール管理は週１回確認する程度で、朝出社しても無計画のまま作業を進めていました。毎朝作業実績（昨日の実績、本日の消化予定、残作業）を確認するようになり、進捗状況を容易に把握できるようになりました。また、毎日チェックするため、１週間まとめて集計するよりも、短時間で集計することが可能となりました。
忘れないよう、メモを取る
依頼内容の管理不足
オーソドックスではありますが、意識して手帳に作業内容をメモするようにしました。まずは手帳を買いました。何でも良かったのですが、バインダー式の８００円程度の手帳を購入しました。何らかの作業を依頼された場合、即座に手帳に記入日／作業内容／完了希望日を書きます。特に作業依頼者から「完了希望日」が告げられなかった際、必ず「完了希望日」を聞き出すよう心がけました。作業完了時、手帳からその依頼作業を削除します。すべての作業か完了したページは、破り捨ててしまいます。こうすることで、自分がやるべき作業しか書かれていない手帳が完成します。
手帳に記入＋毎朝の実施内容確認を繰り返すことで、作業漏れは激減しました。依頼された作業そのものが消える訳ではありませんが、事前にどれだけ作業が残っており、いつまでに消化しなければならないか明確になっていると、その日にやるべき作業なのかどうか確実な判断を下すことが可能になります。また、割り込み作業を依頼された際、他のどの作業に影響がでるか、判断することが可能になります。本当にオーソドックスな手法ではありますが、「朝イチで本日の実施内容を決める」と組み合わせることで、より強力なツールとなります。
予実差集計
見積もり精度が低い
実施した各案件の見積もり時間と実際にかかった時間の集計結果を比較（＝予実差の比較）し、次回案件実施時にその数値を参考に見積もり工数を算出します。
ソフトウェアの開発工数は、実際に開発してみないと分からない場合が多いと言われています。開発中、機能漏れや実装漏れ、或いは考慮漏れなどといった不測の事態が発生すると、見積もり工数をオーバーしてしまう場合があります。これらの不測の事態を予測し、見積もりにある程度のリスクを上乗せしなければ利益を確保することが難しくなります。しかし、リスクを厚くすると顧客から「高い」と指摘され、受注そのものができなくなる可能性があります。リスクを厚くするか、それとも薄くするか、非常に難しい問題であります。また、経験年数の浅いメンバーの場合、開発の経験が少ないため、その作業にどの程度時間がかかるのか見積もることは非常に難しいと考えます。見積もりは、過去の実績から作業工数を予測するのが常套手段ですが、実施するためには、見積もり工数と実績工数の差異を比較し、ずれ幅がどの程度であったかを把握しておく必要があります。ずれ幅さえ押さえておけば、リスクが妥当かどうか判断することが可能になります。そこで、日々の作業実績を記入可能な様、独自のExcelフォームを作成し、作業実績を収集することにしました。そして、作業完了時、予定と実績のずれ幅を確認することで、少しずつ見積もり精度を向上させることができました。
終わりに
今回は、自分を中心に据え、改善へのきっかけから私が実践してきた内容を紹介致しました。次回は、視点をすこし高くして、チームに対する改善への取り組みについて紹介したいと思います。
現在、組込みZineに連載中の記事「社内シナプスを活性化しよう」（著者：前川直也氏）は、「独善のススメ」と対照的な内容となっております。社内でコミュニティを立ち上げて、改善への道を進んで行くといった、非常に興味深い内容となっております。２つの記事を読み比べて頂くと、新たな発見があるかもしれません。改善や社内コミュニティなどに興味をお持ちの方、ぜひご一読下さい。
