最低品質保証スタイル :-)
たいていの現場がそうであるように、今私が作業しているプロジェクトも進捗が遅れている。遅れの原因はいろいろあるが、その中の一つに、「よいものを作りたい。」という気持ちがあったと思う。
「よいものを作ろうとして何が悪いのか？」と思われる方も多いだろう。実は自分も「よいものを作ろう」という姿勢は大事だと思っているが、その適用方法に問題は無いだろうか、ということなのだ。
「何を当たり前のことを言っているんだ。理想どおりに作れるはずが無いじゃないか。状況にあわせて最適なやり方をするのは常識でしょ。」とも言われるだろう。確かにそのとおり。しかし、じゃ、なぜシステム開発は遅れるのでしょうか。状況にあわせた最適解を適用できなかった開発者たちのミスなのでしょうか。それで片付けてしまうにはあまりに、開発が遅れるプロジェクトが多すぎるとは思いませんか。
結局、理想と現実にあわせた最適な解を状況に応じ採用し、システム開発を計画通りに進めるということが非常に困難である、ということになると思う。現実に、計画通りもしくは前倒しでリリースまで持っていけたプロジェクトは自分の場合、1回だけだ。ただ自分の周りの人に聞くと、計画通りに進んだことなど、1度もない、という人がほとんどである。こんな開発の仕方を進めていてよいのだろうか。
もう少し原因を探ってみる。
たとえば、6ヶ月の開発期間を予定したプロジェクトがある。そのプロジェクトの最初の3ヶ月は要求から設計で、後の3ヶ月が実装とテストとしよう。その場合、たいてい最初の3ヶ月は実装で困らないように、必要な項目は抑えられているか、などを考え設計を進めていくだろう。特に、以下のようなことを抑えて設計をしていくことが重要だとよく言われている。
- 変化に対応できるか。
- 運用に問題はでないか。
- 一度運用したら、システム停止は気軽には行えない場合が多い。また状況に応じ、システムのチューニング等ができる構造になっているか。
- 障害に対応できているか。
- 障害時に状況を分析しやすく、対応がしやすいシステムか。復旧時の問題はないか。
ただ動くだけではだめである。特にシステムは一度動かしてから運用され、それが継続的にビジネス価値を生み出す必要があるので、一度限りリリースしただけではだめなのである。こういうことをきちんと考えなければならない、というのが常識だと思う。
で、そのために、設計時にも実装時にもこのような考慮の元、複雑で難しいシステムを作り上げていく必要があるのだ。ある意味当たり前でもある。
しかし、そこが理想が高くないか、ということなのである。こういう内容を実装しなければいけないから、あらかじめそのことを考慮し設計をするから、設計も遅れるし、実装も遅れる。何か問題が発生してもこのような変更や運用を考慮しながら、問題に対処するため、修正も大変だったりする。もちろん、うまく切り分けができていればよいのだが、一人の優秀な人だけで開発するわけでもないので、なかなか難しいのだ。
- 「リーダ、ここのクラス設計ですが、これでいいですか？」
- 「これだと、追加要件が来た場合に、対応できないでしょ。要求事項を抽象化して、すべて同じように扱えるように対応してくれる？」
- 「わかりました。」
- 「リーダ、このシーケンスでよいでしょうか。」
- 「これだと、この部分で障害が起きたら、どうなるの？めったにおきないはずだけど、考慮は必要だよね。」
- 「わかりました。」
こんな感じで、開発当初から理想が高いシステム作りをしていっているんじゃないだろうか。そうして実装、テストになったときには工数が足りず、場当たり的な対応がはいり、結局理想はどこかへ行ってしまったりもする。それならはじめから無くても同じかもしれない。
もちろん、理想を高く、よいシステムを作ろうとすることは重要だが、システム開発が終わったときに本当に質の高い満足のいくシステムであればよいので、その間の作り方、進め方は別にどうでもよいはずだ。
だからイテレーティブ開発をすれば、少しずつ、理想に近づけることができるはず。それでもよい。しかし、いくらイテレーティブで開発しても結局同じように苦しんでいるプロジェクトが多いように思う。イテレーティブ開発はコツが必要なので、従来のウォーターフォールしか経験していない人たちにはなかなかその有効なやり方がわからないようで、これも失敗を生むケースが多いように思う。(実は私も失敗している。）
で、どうするかというと、ウォーターフォールが好きならそれでもよい。しかし、リリース日を半分の期間で迎える計画を立てるのだ。「工数を半分にするなんて、できるわけ無いじゃないか。」と思うかもしれないが、先の理想をすべて削ってしまい、動くだけのモデルにしたら案外簡単にできるんじゃないだろうか。半分でなく、1/3でもよいかもしれない。
そして残りの半分(もしくは2/3)の期間はひたすらリファクタリングを行うのだ。理想からかけ離れ、運用も考慮されず、変更にも弱かったシステムを少しずつリファクタリングにより機能を変えず構造だけを変えていくのだ。日次ビルドと組み合わせれば、リスク無く、できる限りのところまで品質をアップし続けることができる。
このやり方のメリットは、以下のような項目があげられるだろう。
- 動くシステムは期日には必ずできあがる。(必ずはちょっと言い過ぎかもしれないが、従来よりはリスクが少ないはずだ。なにしろ、半分の期間で完成品が出来上がっているのだから。)
- イテレーティブのように細かく計画を立てず、できる限りのリファクタリングをその都度選ぶことができる。(もちろん、優先度付けは必要。)
- イテレーティブでは顧客が毎回確認をする。そのため、改善も期待できるが、あくまで一部のリリースしかできていないはず。このスタイルなら、期間の半分で本物すべてを目にすることができる。
- 改善要求もリファクタリング期間で優先度をつけ対応が可能。イテレーティブの場合でも完了までの期間的余裕は無いので、仕様変更がくるとインパクトが大きいが、このスタイルなら、すでに最低限が出来上がっているので、余裕をもって仕様変更対応が可能。
- 開発者は余裕をもって、システムを改善していくことができる。(残業、休日出勤が当たり前のプロジェクトにはならない。)
- 期間の半分以上は、改善を行うため、システムが進化していくため、開発者の喜びも大きい。(できるかどうかわからないシステムを目をつりあげながら、必死に開発している人と比べてみてほしい。)
性悪説のひとには、「メンバに余裕なんてあたえると、ロクなことにならない。」と思う人もいるだろうが、それはどうだろうか。だんだんとシステムが機能アップしていく様を体験していれば、だんだんシステム作りが楽しくなり、新たな提案も生まれやすくなるのではないだろうか。
このやり方の注意点は以下のような点だ。
- 開発期間の半分は動くソフトのみを目指し、理想を低く抑える。
- 対応しなければいけない項目、したほうがよい項目の対応は開発終了後になるので、忘れないように項目管理しておく。(優先度付けも重要)
たとえば、重複コードは避けるべきだ、という意見が大半だろうが、この開発スタイル(最低品質保証スタイルと呼ぼう）では、重複コードは許容しなければいけないのだ。コピペOK。動けばよい。なのだ。もちろん、それが最終納品時に残っていてはいけないが、そこが後半のリファクタリング期間で一つ一つつぶされていくのだ。
いくら理想を高く持っていても、開発後半は混沌としてきて、どんどん品質が落ちていくのが現実だ。それなら最初からわざと品質を落としてもよいから、一刻も早く動くシステムをつくりあげ、残りの期間で可能な限りリファクタリング繰り返し、よりよいシステムにバージョンアップしていくほうがよほど有効だ。
この開発スタイルなら、厳然たるウォーターフォール開発であってもおそらく、チーム内部で合意して進めることができるだろう。要求仕様がそんなに早い時期で決まらない、というのなら、それもリファクタリング項目に入れてしまえばよいのだ。
