捨てる技術IT編

開発現場は、トラブルと隣り合わせ。急な要件変更を迫られることも少なくないのでは。今回は、期間やコストへの影響を最小限に抑えて開発を進めるには、なにを優先し、それによってなにを「捨てる」べきなのかを考えていきます。

アジャイル開発における要件変更

アジャイルプロセスのeXtreme Programmingでは「変化を享受せよ」として要件の変更はいつでも受け入れましょう、としています。ただ、開発がある程度進んだ段階で要件の変更を受け入れることは、期間やコストに影響が出てしまう場合がほとんどです。メンバーが超過勤務したり、メンバー増員などでなんとか対応すると、開発側のビジネスとしては問題が残ります。期間を延長、費用も追加というプロジェクトもあるでしょうが、発注側としては予算超過しサービスインも遅れてしまいます。それに期間を延長してもらったとしても、開発側の要員計画には影響が出てしまいます。

つまり要件変更の対応を誤ると、発注側も受注側(開発側)もWin-Winの反対の現象がおきてしまうということです。

捨てる技術IT編とは

追加される要件が非常に効果的であるならば対応したほうがよいのは言うまでもありません。「発注時に提示されていない要件だから受け入れる必要はない」というのはウォーターフォール型開発の考えです。システム開発は本来はお客様が想定しているビジネスの成功を実現するために行うもので、契約に従うためのものではないからです。とはいえ思い付くまま要件変更を受け入れることは当然無理です。

何かを変えるなら何かを諦める必要があるのですが、要件の削減はたいていのプロジェクトでは認めてもらえません。しかし、もし効果的な要件の削減を提案し実現できれば変化に対応できるはずです。

今回は、本当に必要な要件のみ実現し、必須ではない要件は後回しにしたり捨ててしまったりする工夫のことを指しています。では、具体的な例を挙げながら説明していきましょう。

要件変更の具体例

たとえば以下の様なショッピングサイトの構築を請け負ったとしましょう。

• ユーザー認証できること
• 商品一覧には該当カテゴリに商品が一つもない場合は、適切なメッセージを表示すること
• 在庫表示で在庫が規定以下の場合は、在庫僅か表示を出すこと
• ユーザーの属性ごとに提示される金額を変更できること
• キャンペーン対象の商品の金額を適切に表示できること
• 商品一覧が多い場合はページャ機能で実現すること
• 商品一覧は4秒以内にすべての商品を表示すること
• 商品をクリックすると商品詳細が表示されること
• 商品のキーワード検索ができること

実際の要件としては少々不完全ですがあくまで例としてお考え下さい。それでも多くの要件がありますね。この中で捨てることができる要件はどれでしょうか。答えられる人はいないはずです。これらの要件だけではお客様の目的や求めている効果がわからないため、答えられるはずがないのです。としても一般的なオンラインショッピングならほとんどの要件は実現必須なように見えます。そのため、追加の対応が必要となるとなにも要件を削ることもできず、対応内容が増える一方となってしまうわけです。たとえば、開発中に以下のような要件が追加されたらどうなるでしょう。

• 商品のキーワード検索ではある程度の曖昧な検索をサポートしてほしい。たとえば、「チェキ」という商品に対し、「チエキ」、「ちぇき」、「ちえき」でもヒットさせたい。

どうしてもこのような検索を実現しなければいけない、これは要件なのだから開発側が無償対応してくれ、となってしまうかもしれません。そのようなときにすでに決定している要件を削減できればこの対応が可能になりそうです。お客様はなにも開発側の利益を下げたいと思っているわけではありません。ビジネスの成功を求めているだけです。もしも数ある要件のうち一部を捨てることによりこの要件が実現されるのならそちらの方が良い、と考えていただける可能性は十分にあるのです。

捨てる候補の見つけ方

では先ほど挙げた要件の一覧をもう一度確認してみましょう。

たとえば「商品が一つもない場合は適切なメッセージを表示すること」、という部分ですが、商品が一つもないカテゴリは存在しなかったらどうでしょう。機能としてはあったほうが良いですが、状況によっては不要かもしれないのです。将来そのような商品があるかもしれないから対応してほしい、と言われたらしめたものです。「では将来に対応しましょう」で解決ですね。もちろんいつ来るかわからない将来なのだから明日来るかもしれないので対応したほうが良いのは事実です。しかしメッセージがでなくても致命的ではありませんしそのようなデータは事前にわかるかもしれません。それならばその時に対応できるかもしれません。

ほかにも、商品一覧にページャ機能が必要とあります(ページャ機能とは前ページ、次ページなどのサポート機能と解釈して下さい)。しかし、サービスイン時点では極端に多くの商品一覧が表示されるほど商品が無い、という場合もあります。それならばいったん捨ててしまっても誰も困らないはずです。

在庫の表示などもそうです。在庫と連動しなくても運用でカバーできるケースも多いはずです。(実際に在庫連携は難易度が高く、1日前の情報連携で良しとしてしまったり、売れ筋商品を常に在庫僅少と表示するケースもあります)

そうです、前記の要件すべてが捨てる候補です。あげられた要件すべてを実現しない、というのは難しいでしょうが幾つかの要件の変更や一部の機能制限ならば全てが候補になります。

また捨てると言っても永久に捨てるわけでは当然ありません。いったん捨てた要件も「次の機会に載せましょう」という進め方も当然提案していけばよいでしょう。本当は捨てるのではなく延期や再検討というべきです。が、要件を捨ててしまうぐらいの勇気がなければ要件削減や延期はできません。そのぐらい強い意志が開発側にもお客様側にも必要なため「捨てる」という表現をとっている、という訳です。

捨てる技術を磨こう

要件変更をおそれ、要件変更に対応せずに済むことを優先すべきではありません。要件変更は積極的にうけいれますがその場合何かを捨てる必要がある、ということをお客様に説明しお互いに納得して進めていきましょう、ということです。最終的な判断はお客様です。しかし、開発側が「こういう捨て方がある」を毎回適切に提示することで、「それならばいったん先送りでも良いかな」と思っていただけるように説得すること、それが「捨てる技術」です。

要件漏れなのか要件追加なのかを議論し、追加費用の調整をしていくというやり方もあります。しかし、その前に「何かを捨てる」ことができれば費用調整などはしなくて済むかもしれないのです。なにより費用の調整などには時間がかかります。その間、開発のスピードが落ちてしまうとしたら、それも想定外の負担となってしまいます。

何をどうやって捨てるか、捨てても影響がどの程度でどういう運用をすればカバーできるか、など常に考え続けることで捨てる技術は磨かれていきます。ただし、お客様やサービスによって何を捨てられるかは千差万別であり、コレという解答はありません。常に「何を捨てることができるか」を考え続け、必要に応じて提案し続けることで捨てる技術を養っていく必要があるのです。

次回は、パラレルプログラミング、という開発手法をお届けしたいと思います。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。