[応用編] アクアリウムエンジニアリング(1/3) 要件定義から設計局面 [再利用]

ということで、昨日の”[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用] | oshiire*BLOGoshiire*BLOG“の続きです。

1.はじめに

最近はじめた趣味として「アクアリウム」、まぁただ魚を飼育して、水槽を見て和んでいるだけですが、これを始めました。

最初は行き当たりばったりで、突然ドジョウを飼わなければならない事態に対して、早急に対応が必要だったために見よう見まねで水槽をさっさと立ち上げました =>(参考) “[ドジョウが] 水槽が到着して、アクアリウムを始めるよ [やってきた」 | oshiire*BLOGoshiire*BLOG”

もともと魚が大好きだったこともあり、これをきっかけにたくさんの水槽を買い並べる結果となりました。ただ「好きだから」という理由だけで、このようにたくさんの水槽を並べるにあたっては、闇雲にはじめて進めてもダメで、ちゃんとデザインする必要がありました。そのために、ウォーターフォール型アプローチでフェーズを区切って、実現へのアプローチを取ってみたわけです。

個人的に、この手法を「アクアリムエンジニアリング」と名付けていますが、この方法は、ほかのイベントにも勿論適用できますので、皆様の理解の参考としてご覧ください。
また、この手法自体は、もっと具体的に整理してまとめたいと考えていますので、ここではサンプルとなるようにざっくりとした全体感でご説明します。
あくまでも、ウォーターフォール型アプローチを採用して、実際に日常のイベントに適用したサンプルと理解ください。

さて、ここでは「要件定義(RD)」「基本(外部)設計(ED)」「詳細(内部)設計(ID)」「構築(開発)(CD)」「テスト(UT/IT/ST/UAT)」のフェーズ毎に、V字モデルと連携してご説明します。細かいことはそのうち説明しますが、V字モデルについては「”Vモデル – Wikipedia“」などをご覧ください。

2.要件定義

まず要件定義ですね。各フェーズではこうしなきゃいけない!! ということよりも、各フェーズにはちゃんと目的とゴールを作って、フェージングする、と言うことを意識して実行してください。
要件定義だからと言って、要件を整理するだけにすると、設計にはいった途端、実現できない要件があったりして、手戻りが発生します。具体的な設計はせずとも、構成のアウトラインができて、実現可能性のある状態へ持っていくことが望ましいです。

さて、今回の要件定義局面の目的とゴールは次のようにします。

目的: 現状の運用上の課題を明確にし、改善策となる要求事項を整理すること
ゴール: 要求事項を、要件と制約に分類して整理し、水槽の配置と、必要な器具類を明確にして概算を求める

当時の状況を説明します。１つの水槽に大きなドジョウと小さい熱帯魚がせめぎ合って生活しているために、熱帯魚のストレスもたかく、小さい海老などは補食の可能性がありました。
また、ドジョウのサイズと比較して水槽が小さく、飛び出ることが多く一匹はそれで☆になりました。

要求事項としては、大ざっぱに言うと熱帯魚とドジョウを分離すること。コリドラスと小さな熱帯魚を群泳させたいことでした。

2-1. 要件と制約

これらを分類して整理します。まず、要求の分類には何が必要かというと、「要件」と「制約」に分解します。

要件: 実現したい要求事項。今回で言うと、熱帯魚とドジョウの水槽を分離すること、熱帯魚を群泳させることが要件です
制約: 変更不可避な前提事項。例えば、予算、期間、場所などです。今回、水槽を追加するにあたって家を変えるわけにはいきませんから、今の家の中で実現できなければいけません。
また、お金もたくさんあるわけではありません。今回は2万円を予算の制約としてあげました。他に制約条件として、「水槽を平らに設置するための水槽台」は制約事項として定義していました。どのような台でも良いのですが、水槽を水平に配置することは、水槽の運用上必要不可欠です

2-2.機能要件と非機能要件

次に、要件を更に分解します。機能要件と非機能要件です。

機能要件: 実現したい機能です。今回の水槽で、私が実現したかったのは、ドジョウを飼育することと、熱帯魚を飼育すること、という生体を飼育して観賞することが機能的な要件です
非機能要件: 対して、非機能要件とは、機能要件を運用するために必要な要件です。
水槽に水を入れて魚を入れて、はいおしまい。という訳にはいきません。その水槽の「品質」を管理できなければいけませんし、継続運用「可用性」や「運用管理性」、品質を担保するための「信頼性」などもあります。
たとえば、水槽の水質を維持するためのろ過が必要ですし、そのために水草も準備したりします。水草は、卵の孵化も考慮したものにするなど機能を補助する要件になります。

2-3.要件定義のポイント

このように分類して網羅性を担保しながら整理しながら、必要な要件と制約をまとめます。機能要件は「実現したい」を要件に書き起こしていくだけなので、網羅性をどのように担保するかは難しいのですが、非機能要件は”非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開：IPA 独立行政法人情報処理推進機構“のようにリファレンスが公開されている様なものもありますので、こういったものを参考にして網羅性を担保することが重要です。

ここまでできあがった後に、各要件で反発する様な要件はないか、整合性や制約におさまらない様な要件がないか、実現するための課題やリスクを明確にしていきます。
たとえば、アロワナとメダカを一緒に飼いたい! という要件は反発します。同じ水槽に入れたらメダカは食われますし、そもそも我が家の容積上、アロワナを飼育できる様な巨大水槽は配置できません。制約にも反します。
このように、各要件を十分に精査して、課題と想定されるリスクをつむぎながら、この段階で解決できる様なものであればそれらを一つずつ潰していきます。このケースでいけば、「アロワナを飼うのをやめる」。が正解です。

結果、どのような水槽を準備するか、どこに配置するか、何が必要か、というものがあらかた見えてきます。それらの構成をラフにして、一覧にした課題とリスクを精査して、実現可能性を判断します。
本当に、この要件と制約で実現可能なのだろうかと、しっかり考えてください。

ここまで書いて良く分かると思いますが、実現する能力のあるエンジニアでなければ、要件定義局面は遂行できない、と言うことです。実のところ、この要件定義がその後の設計をうまくできるかどうかの重要なポイントとなるわけです。プロジェクトの重要なキーと言って良いでしょう。ですから、要件定義のフェーズには、十分に時間と力を注ぐことをオススメしています。

実際の仕事では時間はなかなか取れませんが、家でやる個人的プロジェクトでは、しっかりと時間を作ってくださいね。ただ、本気度を高めすぎると、やる気がなくなって頓挫しますので注意が必要です。あきたら、先に進みながらでもいいかと思います。どうせ、個人でやるレベルですから。(おい

3.外部(基本)設計

外部(基本)設計では、要件を受けて、実際に必要な構成を確定します。必要なものを全て洗い出し、どのようにくみ上げるか。全体像を設計します。

目的: 要件を実現するために必要な器具、生体、それから維持・運用するために必要な餌、道具を全て明確にして決定すること
ゴール: サービスインまでに必要な機材、サービスイン後に必要な機材を全て一覧化して、機材と作業を明確にして精緻な金額を算出すること

3-1.追跡可能性

この先の検討で重要なことは「追跡可能性(Traceability)」です。トレーサビリティって言うと、聞いたことがあるかも知れません。
物流などでは、どこで生産されて、どこの仲介を経由して、市場に出るまでを追跡できることをトレーサビリティと呼んでいます。では、このようなプロジェクトで必要な追跡できなければならないものはなんでしょう。

それは、要件からの紐付けです。

要件を出しておきながら、設計や構築で異なるものを作ってしまう傾向のある業界ですが(れいのあの写真(右)を思い浮かべたまえ)、それはトレーサビリティがなってないことが一つの原因です。一つ一つの要件は、実現される機能と密接に紐付けられなければなりません。そして、紐付かない機能は不要です。「あったらいい」というものは要件になければ、基本的に不要です。余計なことはしません。ただ、その機能が外せない、見過ごせないような場合には、もう一度要件定義をやりましょう。その機能の要否を含めて判断が必要です。本当は、要件定義中に想定しておくことが望ましいわけです。そのために、スキルの高いメンバーを最初から入れるわけですから。
まぁ、素人の場合はいかんせん、不勉強なこともあって「こんなこともできるのかー」なんてことはわんさか出てきます。特に、個人的なプロジェクトやイベントなんて、分からないことが後からわんさか出てきます。ですから、他の方の実践した経験を参考にしたり、事前の調査に時間をかけることで、このような手戻りは、軽減できます。

さて、では、どのように基本設計と要件を紐付けるか、です。整理された要件を、一つ一つ、実現可能な機能へマッピングしていきます。
今回の要件では、ドジョウと熱帯魚の飼育ですから、ドジョウと熱帯魚は実現する機能として必要不可欠です。そして、非機能要件で定義されている、水槽・ろ過装置・ライト・エアーポンプ・底砂・石・岩・水槽台などを具体的に、どこで購入してどのように配置するか配置図を作成します。各水槽でのろ過装置やライトの電源の結線図、ろ過装置やエアーポンプのチューブの配線図なども準備すると良いでしょう。
このように図示(モデリング)して表現することで、具体性も増しますし、イメージがわきやすくなります。ぜひ、図を描いて可視化したものを残すことをオススメします。

3-2.説明責任とアーキテクチャ上の決定

カンタンに「必要なものを選定して図示しましょう」といいましたが、ここで一つ、重要なものがあります。

それは「なぜ、その生体・水草・器具を選択したか」です。要件として「マドジョウの♂♀一匹ずつ。サイズは5-7cm」とまで出ていれば、要件どおりにしたら良いのですが、そこまで決めないことがほとんどでしょう。また、非機能要件では「60cm以上の水槽とする」くらいのはずです。実際に選定をする場合、水槽一つをとってみてもたくさんの種類があります。予算や形、色、サイズによって趣味思考も変わってきます。
そこで、「なぜ、それを採択したか」を必ず検討して、その結果を記録しておきましょう。あとになって「なんでこんなに使いにくい水槽使ってるんだっけ。なんで外部フィルターなんだっけ、どうして底面じゃないんだ」とかになったとき、その理由を残しておくことで、どのような意図があって、その器具を選択したかが明確になります。後々になって、要件が変わってきて、この理由から外れてくる可能性もありますが、その場合は「要求事項の変更にともなる、器具の変更」が分かりますから、変更理由も明確です。

これは、アーキテクトとしての重要なポイントです。「なぜ、私はそれを選択したか」。これこそが、アーキテクトに求められる重要なスキルであり、要素です。この決定理由を明確にできないことほど恥ずかしいことはありません。「なんでこんな設計なの?」に対して「フィーリングで( ´ー｀)y-~~」「いや、みんながそうしてるから」と言う人とは関わらないが吉です。まぁ、フィーリングで、これが良いなーってときでも、それにした建前の理由は付けます。ちゃんとした人なら。

このように設計理由を明確にして、公言することを「説明責任(Accountability)」といいます。

3-3.基本設計の最終確認

さて、一つ一つの要件に対して、必要な機能を洗い出して、図示して説明責任を果たしたら、このフェーズもあと少しです。
すでに、必要な器具は洗い出されていて、購入場所と想定金額もでてきているはずです。全てを足しあわせましょう。それが予算内に収まっていれば成功です( ´ー｀)y-~~

また、必要な生体と器具を、どのタイミングで購入し、いつ作業を実施するか、概ねあたりをつけてスケジュールを作成します。
要件定義内でもフェーズ毎のスケジュールを作成しますが、それを一つブレークダウンします。このようなウォーターフォール型、トップダウン型のアプローチでは全体を決めて、それを詳細化していく、という流れを間違えずに従ってください。それ自体にトレーサビリティが発生しますので、分かりやすいのではないでしょうか。

4.内部(詳細)設計

内部設計では、外部設計で決定した個々のパーツに対して、具体的な設計・パラメータの決定を実施します。

目的: 外部設計で決定した生体、器具自体の内部を詳細まで検討して決定し、作業に漏れが発生しないようにする
ゴール: 各生体・器具の内容物を全て決定し、具体的な購入・入手プロセスの確認と、詳細のスケジュールを決定すること

4-1.構成要素を洗い出す

ここでは、各生体・器具がもつ構成要素を丹念に調査します。実際のブツがあれば、それを調べるのはたやすいのですが、ここで購入に踏み切ってしまうと「あ、この器具じゃダメだったんだ」と買い直したり、そもそも生体など、どこで飼育するんだということになりますね。
ですから、アクアショップや、ネットで取扱説明書などをひっくり返して、各器具がどのように構成されているか、内容物として何を決定しなければならないかを洗い出します。

そうは言っても、水槽で購入する各器具の内部構成などは、ほとんどないようなものですから、必要となるのは「ろ過装置」内の「ろ過材」の選定や、想定器具には実は含まれていないチューブやホースなども配線図から不足がないか確認しましょう。
なお、ここでも「トレーサビリティ」を想定して、ちゃんと要件から紐付けされて、そのデザインが成されているかを考慮しなければなりません。今回、ろ過装置にはエーハイムEF500外部フィルターを準備しています。では、そのろ材はというと、今回はあく抜きの必要な木が入っていたりする関係から、当初はブラックホールを入れておき、1-2ヶ月経過後からは生体ろ過用のろ材を増やすとして、ろ材を準備しています。
ろ材の構成自体は基本に忠実にしています。構成については成功事例を元にリファレンスする事把握ではありません。既に実績のある構成なので。その参考となる構成と、今回準備している内容に大きな乖離がある場合には役には立たないことは覚えておきましょう。

4-2.スケジュールを決定しよう

ここまでやってくると、作業の具体的な内容と、作業量(時間)も想定できるところに来ていることでしょう。
それでは、「購入日」「作業日」を決めて、実際にスケジュールへ割り当てていきます。作業の前に物品がないといけませんから、購入→作業の順番になります。
ただ、生体については、水槽ができあがって、水が立ち上がってからでなければ追加しませんから、どの程度、水を作る時間を想定するかによって、生体の購入時期も変動します。

この時点で、すでに立ち上がった水槽がありましたから、その飼育水をベースに新しい水槽を準備することを考えていましたから、水を作る期間は1週間程度で想定をおきました。

さぁ、後は実際に水槽を立ち上げるところになります

だんだん文章量が少なくなってきたのは、手を抜いているわけではなくて、要件定義と外部設計がしっかりできていれば、後発は考慮点が少ないからです。ITだと、製品毎に数百、数千のパラメータがあるので、考えることはたくさんありますし、その分スケジュールも長くひかないといけませんけどね。

この後、「構築」「テスト」とありますが、V字モデルとあわせて、構築・テストを考慮するとなると文章量がハンパなくなるので、今日はここまで(おい