トイレで学ぶ、システム開発の難しさ　その１　Overview

システムとは、前もって定義し組み上げた通りの動作しかできません。いわゆる「空気を読む」ことは全くできませんし、臨機応変な動きを期待するなら、そのパターンは予め組み込まなければならず、また、組み込んだパターン以外はどのような動作をするかわかりません。

ただし、保証された動作は永遠に、確実に、動作します。

人間のように自分の頭で考え都度その場にマッチした振る舞いができない代わりに、人間のようにうっかりミスをしたり工程に抜け漏れが起きることが無いため、今や定型処理や自動化には欠かせない存在です。

今回は、そんなシステムの開発（作り上げること）について触れたいと思います。

なお、タイトルの通りトイレを題材にしていますので若干汚い話もありますが、ご容赦ください。
勿論、男の子である私は女子トイレ事情には詳しくないため、男子トイレが舞台となります。

まずは目的を決め、前提条件を洗い出す

今回作るシステムは、科学の力で排尿機能を備えた最新ロボットに組み込む、「トイレに行って、おしっこをする」というシステムです。
つまり、目的は「トイレに行けること、おしっこができるようになること」です。

組み込むロボットは、はた目には成人男性と同じで30歳くらいの見た目で、リモコン等で操作するタイプではなく、予め組み込んだ動作に従って動くタイプです。
成人男性と同じような仕草をしますし、服も下着も良く見かけるようなものを身に着けており、ぱっと見ではロボットとはわかりません。また、尿意の感じ方や尿が体に溜まるスピード、我慢の限界を超えると漏らしてしまうことなども、全く一緒だとお考えください。

また、トイレ自体については、いきなり全てのトイレ対応型というのは難しいので、最近では極々一般的な、おしっこ用便器が3つ、洋式の個室が3つ（おしり洗浄機能付き）でトイレットペーパーは予備を入れてホルダー2つ、手洗い場は3つ（蛇口でなくセンサーで水が出る）、ハンドソープは下から押し上げると出てくるタイプ、洗った手を空気で乾燥させるジェットタオルが1つとしましょう。

一般的には、このくらいの段階か或いは下記のステップの段階でと見積を出し、発注を頂き契約が成立します。

これより前に、本当にざっくりとしたところで人月（技術者ひとりが1か月間に160hに働く単位）どのくらいか算出して契約し、要件定義と呼ばれるこのブロックに入るパターンもありますが、今回は、この要件定義ブロックを実施し、ある程度の情報が収集できてから見積もりを行い契約するパターンとします。

目的と前提条件から、粗い仕様に落とし込む

上記の目的と前提条件より、より具体的に落とし込みます。

はた目には人間と一緒→背が3mを超えているわけでも200kgの巨漢でもなく、170cm 65kgくらいの標準体型
　→便器と合った体系をしているため、アジャストする動きは不要
服や下着も一般的なもの→排尿の前にはチャックを下してパンツを下げる動きが必要。
　→フンドシや江頭スタイル等ではないので、それらに合った動きは組み込まない
尿意の感じ方も人間と一緒で、漏らすこともある→限界を超える前に排尿しなければならないことも考慮する
　→「尿意」は都度変わるので、固定ロジックではなく変数。また、尿意レベルがどのしきい値（基準）を超えたらトイレに行こうとするかの取り決めが必要
対応するトイレについては、全てに対応する形ではなく、一般的なスタイル向けとする→おしっこ用便器と、一般的な個室型
　→ちょっと変わった風なトイレには未対応
その他、トイレ自体の設備→手洗い場は3つ、ハンドソープ、ジェットタオル。
　→これらを使うことができるプログラムも組み込まなければならない

こういったことを、どんどん具体化します。
お客様に検討ポイントを「これでよいのか」と都度確認を行いますが、ここで重要なのは「取り入れるもの」と「切り捨てるもの」をある程度大きなレベルではっきりさせることです。

細々とした要項は客もIT屋も具体化させなければ中々見えてこないという面はあり、それも具体化させる過程で条件がどんどん変わるため、この時点であまりに細微な議論は不要です。
あくまで、インパクトのある決定事項について、「取り入れる」「取り入れない」を分けることが肝要です。

要件の切り落としと、受注金額や利益との兼ね合いを考える

具体化すればするほど、客は「契約書や見積書に条項はないが、この機能はあって当たり前」だの「新しい機能を付けて欲しい。当初見積もりで稟議を通しちゃっているので、タダでお願いします」だの言ってきます。
これについて、ある程度はお金を出す側の論理としてやむを得ないという面はあります。サービス業ですし。

それに、自分がお金を出す側になった時、「契約を取るまではイイコトばかり言って、契約した後になったらアレはできないコレは追加料金って、何なんだおまえらは！！！」と思うものです。例えそれが契約書に無い条項であっても。

また、人間関係はやはり大事なもので、顧客の要望の全てを却下しているとプロジェクトは円滑に進みませんし、よくある開発側のチョンボでトラブルになった際も良好な関係が構築できていたなら小言で済むものが、険悪な状態だと契約の解除や最悪は訴訟などの話に発展しかねません。プロジェクトの後の関係だってあります。

とはいえ、このブロックは一般的に設計フェーズと呼ばれますが、大抵の場合はお客様とざっくりとした合意は形成されており（しなければなりません）、頂くお金や開発の期間は既に決まっています。

開発側としてある程度はサービスするものの、決まったお金と期間の範疇で赤字にならず納期の遅延もないようご奉仕しなければならないため、この時点では色々な部分を切り落とすこと、それを客先に納得してもらうことが大事な大事なプロセスとなります。

例えば、今回の例では、

はた目には人間と一緒→標準の成人男性を160-190cm 60-100kgと定義し、範囲外のロボットサイズには対応しない
服や下着も一般的なもの→排尿の前にはチャックを下してパンツを下げる動きが必要だが、それ以外（ズボンとパンツ以外）の格好は動作未対応とする
対応するトイレについては、全てに対応する形ではなく、一般的なスタイル向けとする→おしっこ用便器と一般的な個室型を対象とし、ちょっと変わった風なトイレには未対応
おしっこをするプログラムなので、ウォシュレットの使用は考慮しない

などなど、どんどん要望をカットし、仕様を制限していきます。

理由は、冒頭の通り、システムは予め組み込んだことしかできません。「どんなパターンが来ても大丈夫」なんてシステムは組めないのです。

想定するパターンを増やせば増やすほど、「予め組み込むもの」が多く大きくなり、手が入れば入るほどテストに費やす時間は多く必要となり、不具合の発生件数や発生率も多く高くなります。
くどいですが、この時点で開発に投入できる時間もお金も決まっているにも関わらず、です。

だからこそ、
・「何となく欲しいだけ」「あったほうがいいんじゃないか」で言っている顧客要件の切り落としと説得
（この例でいえば、「身長3mのロボットでも対応できるべきだ」等の要件。そんなデカい人は、そもそもトイレに入れない）
・当初見積で確保した金額をベースにしてしか人員の調達はできないし、これ以上詰め込むと納期にも間に合わないという現実を理解して頂く
・切り落とした後のアフターフォロー（誰だって、自分の要望が取り入れられなかったら良い気分にはならない）
といったものが重要になってきます。

長くなりましたので、今回はこの辺りで。