Tweet
- 田中 紳詞
- 株式会社Exciter 代表取締役／主席コンサルタント
- 東京都
- 経営コンサルタント／ＩＴコンサルタント
-
03-6280-3255
トイレで学ぶ、システム開発の難しさ その２ 要件定義～設計
-
システムの開発は、殆どの場合、いきなり開発に着手することはしません。
大まかなコンセプトを決め必要な機能を洗い出す要件定義、それを元に要件を満たすために必要な機能詳細（仕様と呼びます）を詳細化する設計、その後ようやく実際の開発に取り掛かります。
近年では色々な開発の進め方がありますが、この流れを小分けにしたり繰り返したりと、基本的にはこの形が王道であると解釈して差し支えありません。
重要なことは、必ず要件定義→設計→開発という順番で行われ、並びが入れ替わることはないということ、開発は設計の結果を元に行われ、設計は要件定義の結果を元に行われるということで、前のステップでの実施内容が次のステップの元ネタの殆どであるということです。
つまり、開発を実施している際に要件の変更が入った場合、全てではないにせよ今現在の開発内容は意味を持たなくなり、変更された要件を元に設計からやりなおし、再度開発に取り掛かる必要があります。
システムの開発においては、こういった手戻りは必ずあるものですが、その回数や影響を最小限に留める努力は不可欠です。
また、後の工程に及ぼす影響が大きいことから、実際の開発も重要ですが、それよりも更に設計、設計よりも更に要件定義が重要であると言えます。
前置きが長くなりましたが、前回と同じく「トイレに行っておしっこをする」というシステムの開発を例に、実際の要件定義・設計・開発というステップごとに触れていきたいと思います。
※トイレが題材のため、表現により気分を害される方もいらっしゃるかもしれませんが、ご容赦ください。
要件定義
さて、要件定義とは、システムの大まかなコンセプトを決め必要な機能を洗い出すことが目的です。
これは、要は「何がしたいか」を決めると言い替えることもでき、システム屋さんだけで決められるものではありませんので、お客さんへのインタビューや質疑応答で進めます。
ここで重要なことは、ここで決める要件定義とは、お客さんにとっては普段自分がやっていることに過ぎず、いつもやっている当たり前のことについて取り決めるということです。
いつも自分がやっていることなら、問題なくできるでしょ？と思う人もいるかもしれませんが、違います。
「いつもやっていること」であるからこそ、当たり前過ぎるからこそ誰かに説明する時も、「○○の後に××をやって、最後に△△するだけ」的な簡単なコメントになってしまうのです。
本当は、「○○の後に□□をしなければならない」、「××の後に、特定の取引先や商品を扱う場合は別途書類を作成しなければならない」、「△△は四半期に一度は特別な処理をしなければならない」などが潜んでいたというのはよくある話ですが、このトイレの例でいえば、「おしっこがしたくなったら、トイレに行って、おしっこ用の便器に行って、排尿する」という説明のみがなされるという塩梅です。
ここでは、この要件定義のまま進めることとします。
この時点での顧客側の問題は、「自らの要件を正確かつ漏れなく言葉に出来ていないこと」、「システムが現時点では具体的な形になっていないためイメージがつかないという点もあるが、ある意味、真剣になっていない」ことです。
対し、システム屋さん側の問題は、客の言うことを鵜呑みにしていること（言葉を選ばずに言えば、疑うべきです）、「必要な情報を話してもらう」という好ましくないスタンスで取り組んでおり、「情報を引き出す」という姿勢がないことです。
設計
さて、ここでは上記で定めた「おしっこがしたくなったら、トイレに行って、おしっこ用の便器に行って、排尿する」という要件を満たすために必要な機能詳細（仕様と呼びます）を詳細化する作業に入ります。
この文章を、小分けにしてみます。
１．おしっこがしたくなったら
２．トイレに行って
３．おしっこ用の便器に行って
４．排尿する
順番に触れていきますが、１の「おしっこがしたくなったら」について、これをシステム化する場合に何をもって、「おしっこがしたい」とするかが重要なポイントです。
例えば、この機能を組み込むロボットの中に「おしっこ行きたい度」という数値が予め組み込まれているならそれを採用するのがよいでしょう。でも無かったらどうしましょうか？
のシステムの開発は、あくまでトイレで排尿するシステムですので、「ロボットにおしっこ行きたい度センサーを組み込む」という開発まで考慮していません。
顧客は、「でも必要ならやってよ」と言うでしょうが、「じゃあ追加で出しますので見積お願いします」だなんてお客さんは大抵いません。全てが据え置きであることが殆どです。そのため、新たな開発のために割く人員も、作業期間も、予算もないのです。
かといってシステム屋さん側がサービスもできません。どうすればよいでしょうか？
調べてみると、このロボットはどうやら2時間半の間、おしっこを我慢することができるようです。
じゃあ定期的にトイレに行くという取り決めでどうでしょうか、と提案してみたところ、お客さんからokがもらえました。
回数はできるだけ少ない方がよいので、ギリギリいっぱい二時間半ごとに行くように設計しました。
次に、２の「トイレに行って」です。
これについて、ロボットには記憶機能があるため、一度行った場所であれば現地点から行くことができます。では、例えば駅や出先ならどうでしょうか？
つまり、「トイレを探す」という機能が必要だということです。
要件定義にはなかったことですが、「目視でトイレマークを探す」「人に聞く」という程度であれば簡単なので、ここはサービスで対応して頂きました。
「地図を探してから探す」という機能の要望もありましたが、「そちらは別料金です」というと、「じゃあ結構です」となりました。
３の「おしっこ用の便器に行って」ですが、ロボットが「おしっこ用の便器である」と判断する条件はなんでしょうか？
個室じゃないところ、という判断基準はイケていません。手洗い場や掃除用のシンクも含まれてしまいます。
TOTOとかINAXとか書かれている、という判断基準もイケていません。その他のメーカーの立つ瀬がない。
じゃあ、現在販売されている便器の写真をロボットに組み込んで判断しては？それもイケていません。便器の写真を格納するデータベースが新たに必要となりますし、新商品が販売されるたびに写真の登録が必要になってしまいます。
紆余曲折の結果、組み込んだロボットが見た映像について、「おしっこ 便器」でGoogle画像検索で探し、近ければそれだと判断する仕様にすることにしました。
最後に、４の「排尿する」です。
これも要件定義には明確に含まれていないのですが、「排尿する前にズボンとパンツを下げる」という機能が必要です。
これは、スーツもジーンズも基本的には同じ構造をしているため同じ機能でよく、ロボットがブリーフ派でもトランクス派でも「パンツを下げる」という行為は変わらないため簡単で、開発対象に含めることにしました。
ただし、フンドシや女性の使う矯正下着のようなものには対応しません。これは、お客さんもokしてくれました。
長くなりましたので、今回はこの辺りで。
このコラムの執筆専門家
- 田中 紳詞
- （東京都 / 経営コンサルタント／ＩＴコンサルタント）
- 株式会社Exciter 代表取締役／主席コンサルタント
業務システムからモバイルまで、ＩＴ業界の無差別格闘家
専門はSAPなどの業務システムとコンサルティングですが、それに限らず企業にとって必要なITとその活用を考え、幅広い分野の経験を積んできたと自負しております。ITには多くの分野がありますが、一面ではなくトータルで勘案したプロの仕事をお届けします。
「IT全般」のコラム
トイレで学ぶ、システム開発の難しさ その４ まとめ（2013/07/30 22:07）
トイレで学ぶ、システム開発の難しさ その３ 開発～納品と検収（2013/07/18 11:07）
トイレで学ぶ、システム開発の難しさ その１ Overview（2013/07/11 16:07）
このコラムに関連するサービス
- 料金
- 39,000円
自助努力のみでは「民間療法」 にならざるを得ない面があり、またその中で「迷信」に囚われてしまう例も多くみられます。
これについて、多くの事例、企業様、業種に関わらせて頂いたプロフェッショナルによるアドバイスやプレゼンテーションなどの様々な形によりサポートさせて頂きます。
また、情報システム部やシステム担当者様がいない会社様向けには、社内作業を一部代行させて頂くケースもご用意しております。
このコラムに類似したコラム
トイレで学ぶ、システム開発の難しさ その３ 開発～納品と検収 田中 紳詞 - 経営コンサルタント／ＩＴコンサルタント（2013/07/18 11:31）
トイレで学ぶ、システム開発の難しさ その１ Overview 田中 紳詞 - 経営コンサルタント／ＩＴコンサルタント（2013/07/11 16:41）
ちょっとしたこと。 井上 敦雄 - ITコンサルタント（2013/11/25 11:40）
「幸せから生まれる幸せ」 井上 敦雄 - ITコンサルタント（2013/10/11 11:00）
仕事マインドとビジネスマインド。 井上 敦雄 - ITコンサルタント（2013/09/27 09:53）
