優れたスケジュールを目指して
さて、こうしてスケジュール管理がある程度上手く運ぶようになったところで安心しては困ります。「今日の要請」には応えられても、そのままでは「明日の要請」には応じられなくなるからです。
市場の要請はいつでも
コスト → 製品価格
開発期間 → 製品投入時期
品質 → 製品品質
の3つの要素の形で我々に要求を突き付けてくるのです。
そのほか、開発のテーマも変わるでしょう。企業もいつまでも同じものを作っている訳ではありません。また、1年も経てば使用する言語や開発手法や開発環境も変わるでしょう。電子メールが導入されれば、開発組織のマネージメントそのものが大きく変わらざるをえません。そのことは、新たな市場の要請として、我々の前に姿を現わすのです。
したがって、ある程度段取り良く事が運べるようになっても、定期的に「負荷」をかけて、新たな「知恵の川」に水(=工夫)を流す必要があります。今まで通用していた前提を否定することで、別の方法を考え出すのです。
則ち「ストレッチ」です。ストレッチは主に、
・開発期間からのストレッチ
・品質面からのストレッチ
が考えられます。
たとえば、これまでは実質15日間確保できていた「設計作業」を12日程度に縮めたり、コストを2割縮めてかかったりするのです。もちろん、単に旗を上げるだけでは意味がありません。それを実現する方法を考える必要があるのです。こうして、今まで延ばしていなかった「頭の筋肉」を伸ばすのです。
このとき、ただ“ガンバリ”だけで対応されては困ります。“ガンバリ”は必要ですが、それでカバー出来る範囲やレベルは知れていますし、すぐに限界が来てしまいます。第一、去年より年を取っているのですから、同じような“ガンバリ”は通用しません。
継続的に「開発期間の短縮」を実現するには、スケジュールそのものにも「工夫」が必要であり、そこに設定される「作業」の中身に工夫が必要です。今までと同じやり方では、同じ結果しか得られないことは明らかです。
ある作業工程の期間を短縮するためには、
1)その中で行なわれている必要のない作業を捨てる
2)短縮しようとする作業の前工程の成果物を見直す
ことです。
ドキュメントなども、前工程の作業の仕方や、その結果の成果物の構成の工夫などによって、後の工程の工数が変わってきます。作業はもともと繋がっているのですから、工夫の余地は沢山あります。
「開発期間の短縮」にはもう一つの領域があります。それは「チーム」による作業分担の見直しです。誰かが先行して、メンバーのみんなが使えるテスト環境を整備することで、大勢の人の作業時間が短縮されます。テスト環境を用意している間、その人の作業の一部を他のメンバーが負担することで、全体の開発期間は大きく短縮されることが期待できます。
一方、品質に関してもストレッチをかける必要があります。つまり、品質を意識させるような目標を掲げて、それを達成するためにどのような作業工程を組み立てるか、それぞれの作業工程の中で、どのような作業をするべきか、どのような成果物を生み出せばいいのか、等々工夫を重ねることを求めるのです。
たとえば、
・バグの件数の削減
・パフォーマンスの向上
・プログラムサイズの削減
・「クリーンルーム」の導入
等の「目標」とその達成度を測るために「目標数値」を一緒に掲げます。これまでの取組みで、これらの品質に関連して事前に計測されていれば、「クリーンルーム」以外は目標数値を設定するのにそれほど難しいわけではありません。逆にこの数値が設定されなければ、実際に品質の向上は望めないでしょう。
品質向上のストレッチは、作業機間のストレッチと違って、必ずしも、目標から直接的(直感的)に作業工程が連想されるとは限りません。逆に云えば、作業の段取りを調整するだけでは実現しないということです。つまりこのストレッチは“思い付き”で出来るものではなく、周到に計画されなければなりません。
明らかなことは、品質を向上させるためには、『プロセスを変え、プロセスへの投入物を変えないかぎり、結果は変わらない』ということであり、いままでやってきた「やり方」を変えることが求められるのです。
目指すは「リワークゼロ、滞り作業ゼロ、無意味作業ゼロ」です。
この目標に対して、果たしてどれだけの事が考え付くか、それが問われているのです。力仕事ではなく、知恵仕事としての工夫が求められているのです。
近い将来にやってくる「高齢化」社会を考えたとき、長く第一線で働けることは、とても重要なことです。そのとき、力仕事でしかこの仕事をこなせないようでは、選択肢を無くしてしまうでしょう。今から取り組めば間に合います。