家づくりで理解するシステム開発

スポンサーリンク

一般的に家づくりとシステム開発は似ていると言われています。
SIer企業に勤めている私が、家づくりでの体験を考慮し纏めてみました。
以下に該当する方にお役に立てると思います。是非ご覧下さい。

・システム開発工程を分かりやすく表現したい方
・要件定義に携わる方
・SIerへの就職・転職を考えられている方

・家づくりの工程を理解したい方

スポンサーリンク

家づくりの工程とシステム開発工程のマッピング

家づくりもシステム開発も、納期が長くコストも高額なため、出来上がってからニーズとかけ離れていたとなっては元も子もありませんし、そもそもが人間のニーズを落とし込むことは困難なものです。

そのため、工程を用意し、ニーズを具体的に要件として定義、その要件に基づき、利用者視点での設計(間取りや見栄え等)やものづくりに至れるまでの詳細な設計に落としていく必要があります。

更に、作って終わりではなく、要件・設計通りとなっているかの厳しいテストを実施することや、アフターサポートも欠かせません。

以下、「家づくり」の工程と「システム開発」の工程のマッピングとなります。

家づくりの工程システム開発の工程
【企画】
施主のニーズを聞き、大まかな住宅の外観や空間構成、資金を決める。
【企画】
経営や業務の方針を踏まえて、システムの全体像を考える。
要件定義
住宅の用途や家族構成、部屋数、レイアウト、外装、内装、設備、予算などを定義する。
要件定義
現状の作業工程やシステムについて調査し、問題点、課題を分析します。その解決策と、システム要求を定義する。
基本設計
要件を元に、3次元CGを作りながら、外観、間取り、平面図、材質、収納、設備、照明、コンセント位置、見積りなどを図面におこす。
外部設計
システムにおける機能の構造と、個々の機能の使いやすさについてデータを利用するユーザーの立場から検討する。
【実施設計】
基本設計を元に、強度、施工、配線、配管などの作業工程に関わる部分を設計する。
【内部設計】
外部設計をもとに、ソフトウェア内部での処理について設計する。
施工・工事管理
基本設計と実施設計を元に、基礎、柱立て、内装、配線、設計監理などを行う。
製造
内部設計書に基づき、そのシステムに最適な言語でプログラムを作成する。
【検査】
完成に近づいた段階で、申請や建築確認を行う。
【テスト(単体、結合、総合、運用)】
作成したプログラムが正常に作動するかを確認します。複数のテストによりバグを発見、修正し、完全な状態に仕上げる。
【引渡し・アフターサービス】
引き渡し後においても、問題が発生すればすぐに補修などを行うと共に、増改築などの経年変化にも対応する。
【納品・保守・運用】
ユーザーのシステム環境で正常に稼働することが確認されたのち、実際の利用者に画面の操作方法や運用引継ぎを実施し納品する。必要に応じて、納品後の保守・運用を行う。

上記の中でも、利用者に取って特に重要で醍醐味のある工程は、要件定義と基本設計/外部設計施工/製造ではないでしょうか(青太文字緑太文字箇所)。その中でも一番難しい要件定義について、以下の通り纏めてみました。

①そもそも家やシステムを買って何が変わるのか

家づくりもシステム開発の工程が類似していることは、上記マッピングの通りとなりますが、一番重要な要件定義工程のプロセスも類似しています。
IPAで参考になる資料があったため、それをベースに噛み砕いてみます。

初期要求(ニーズ)を明確にする

家づくりは、人生で一度あるかないかの大きな買い物、理想の家を作りたいと思う方は多いと思います。
私も勿論そうでした。

そうすると、対面型のキッチン、ウォークインクローゼット、天井高、床暖房、テラスが欲しいといった話から、エリアは港区、文京区、世田谷区に住みたい等、まるで夢を語っている様な良い気分になってきます。

この「〜が欲しい、〜がしたい」というニーズを明確にすることが初めの一歩となります。
システム開発の場合、経営・業務部門・システム部門の既に存在する要求(ニーズ)を収集することと同一となります。

要求(ニーズ)抽出を行う

夢の様なニーズから真のニーズを導いていきます。
「【初期要求(ニーズ)を明確にする】」では、どんな家が欲しいかに偏っていましたが、その家がなぜ必要なのかの観点、つまりどんな生活を送りたいかに落とし込むことが大切です。

例で言えば、通勤が楽になる、スーパーが近い、治安が良い、子育てに優しい等です。私の場合は、スーパーが近い、子育て環境が充足、治安が良いといった具合にアウトプットしていきました。

システム開発の場合、どんなシステムが欲しいかではなく、どんな業務に変えるかを検討することが重要です。システムはあくまで手段、業務のやり方を変えるだけで業績を伸ばすことができる可能性はもちろんあります。

現行業務やシステムを把握し(As-Is)、To-Beの変化を明確にする

日々の生活に沿い、職場までの通勤時間、スーパーまでの距離・営業時間等を洗い出し(As-Is)、希望エリアに住んだ場合(To-Be)の変化・違いを明確にしていきます。

通勤時間は長くなっても、生活する上での住環境にメリットが大きいといった結論が出ると良いと思います。

システム開発の場合、業務内容、As-Is、To-Be、GAP、GAPへの対応、効果といったマトリクスに纏めることが多いと思います。業務FIT&GAPといった方が理解が早いかもしれません。

②要求を多方面から引き出す

ステークホルダーを洗い出す

ステークホルダーとは利害関係者を意味します。
夫婦2人で家づくりを検討しているのであれば、2人の両親や兄弟・姉妹、友人を考慮する必要があるかと思います。
また、将来のお子さんも立派なステークホルダーになります。

システム開発の場合は、業務担当者全員とすると限界がありますので、要求を抽出する方、意思決定・合意形成する方を選出すると良いと思います。

ステークホルダ要求(ニーズ)を明確にする

両親や兄弟・姉妹の要求(ニーズ)を収集し、夫婦2人のものとは異なるものを抽出していきます。

例えば、ご高齢なご両親の場合は、バリアフリーの設置や腰に優しい客間だったり、将来のお子さん向けには、整備された公園が欲しい等が挙げられます。

くまなく要求(ニーズ)を拾い上げていきます。
声の大きい方に流されず、俯瞰的な視野を持って実施していきましょう。システム開発の場合も全く同様ですね。

非機能要求など、その他の要求を明確にする

これは何かというと、犯罪、災害、ゴミの分別、緑化等を指します。例えば、空き巣被害が多い地域だったり、川の氾濫で浸水してしまう地域であるか・無いかを事前に理解しておく必要があります。

機能面(家そのもの)以外にも着目することを忘れない様にしましょう。

システム開発の場合は、非機能要求グレードやお客様IT標準資産に沿い満足しているかをチェック、満足出来ていない場合はどの様な対処・対策を実施するかを纏めて行きましょう。

③要求(ニーズ)の妥当性を評価する

「①そもそも家やシステムを買って何が変わるのか」、及び「②要求を多方面から引き出す」で出した要求(ニーズ)が妥当であるかを評価するフェーズに移っていきます。

夫婦2人の夢の様なニーズにステークホルダーのニーズも入ってきたことにより、真意分かり難くなってきているものを評価していきます。

何のために、何をよくしたいのか

天井を高くしたいというニーズに対し、なぜ高くしたいのかを自問自答します。それは「リビングの開放感」であり、そのリビングでの開放感は「くつろげる空間」が欲しいからといった様に目的化がなされていきます。

更に、くつろげた空間があると何が良くなるのかというと、家族や友人との「コミュニケーション」が豊かになっていきます。

つまり、家族や友人が自然とコミュニケーションを取れる・過ごせるリビングが欲しいという真意を導くことができました。

これを、要求を目的展開するといいます。
目的と手段を明確に分離するイメージです。

上記はシステム開発にも勿論同様の考えはありますが、どちらかといえば、空・雨・傘に代表される様なビジネスフレームワークに近しいと思います。

目的から手段を検討する

コミュニケーションを豊かにしたいという目的に対する解決手段を検討します。

例えば、リビングの近くに和室を作って子供との遊び場にする等が挙げられ、天井を高くすることが解決手段ではなくなっていきます。

一番インジェクションの効く手段を導いていきましょう。

要求(ニーズ)を絞り込む

目的から手段を検討することによって、小さな要求を排除することができる様になります。
つまり、要求が絞り込まれ、コミュニケーションを豊かにするために、天井は高くなくて良い、大それた音響設備は要らないと言った様な事です。

システム開発の場合も同様です。
要求は膨らむものであり、その要求を投資対効果と照らし合わせて経営や業務に必要ないものを切り落としていくことが重要です。
今回を逃すと対応が数年先になるだろうからという思いで何でもかんでも要求を入れてしまうと、確実にプロジェクトはデスマーチ化し失敗します。
要求は膨らむものであり、成功のために絞り込むという意識が大変重要です。

④要件として定義する

「③要求(ニーズ)の妥当性を評価する」にて絞られた要求(ニーズ)を、要件として定義します。
要求と要件は違うものではありませんが、要件は要求が具体化、もしくは分解、なくなったりと要求の状態が変わったものです。

 ・要求:分析するもの、具体化するもの
 ・要件:第三者にも分かるように定義、提示できる状態

要件として定義するために、制約条件・前提条件、優先度付けを実施していきましょう。

制約条件や前提条件を考慮した現実案を検討する

制約条件とは、予算や納期等、どうしても変更できない条件です。

前提条件は、リスクを伴うが、遵守することでリスクを低減することができる条件です。
混同しがちですが、まずは制約条件を明確にし、次に前提条件を決定する段取りで進めていきましょう。

家づくりの場合、要求(ニーズ)に対し予算も納期も厳しい場合は、注文住宅ではなく、建売住宅や建築条件付き住宅を選択していきます。

建売住宅は個別仕様は盛り込めないため、譲れない個別仕様が必要な場合は、建築条件付き住宅がオススメだと思います。

システム開発の場合は、

 ・注文住宅→オールスクラッチ
 ・建売住宅→パッケージ、SaaSサービス
 ・建築条件付き住宅→パッケージ、SaaSサービス+個別カスタマイズ

というイメージでよろしいと思います。

要求の優先順位付けを行う

制約条件である、予算・納期という縛りがある中、優先順位の低いものを削ぎ落としていく段階です。

例えば、システムキッチンや収納棚を標準仕様に変える、ウォークインクローゼットを止める等です。

既に予算・納期が問題ない様であれば、リスクが顕在化した時に備え、優先順位をつけておくことで、いざとなった時にスコープ外にするといった前提条件をつける様にしましょう。

システム開発の場合も、膨らむ要求を抑える、優先順位をつけるということを意識する様にしていきましょう。

要件として定義する

要求はニーズ、要件は仕様と解釈します。

今まで明確化された要求(ニーズ)を第三者がわかる要件(仕様)として纏めていきます。例えば、部屋数、窓の数、窓の大きさ、照明の数、浴室仕様等々を指します。

システム開発の場合は、あやふやな要求を整理し、価値を見極め、制約や前提条件を考慮し、最適解(業務としての解、システムとしての解)を見つけ出し、その上でステークホルダとの合意形成を行っていきます。アウトプットとして、要件定義書等を作成し完了です。

まとめ

私自身、家づくりでは悶々と要求(ニーズ)を決められず大変苦労しましたが、ハウスメーカーの営業・設計士さんにアドバイスを頂いたり、展示場を見に行ったりとなるべく要求(ニーズ)を標準仕様に落とすことを行い、着工合意に至りました(一部予算のストレッチ・納期変更もありましが)。

その時思ったのは、システム開発に類似しているなということですが、家づくりよりもシステム開発の方が何倍も難しいと思います。

なぜならば無形であり、目に見えるものが殆ど製造工程に至らないと出来上がってこないからです。

今後のシステム開発で意識的に改善していきたいのは、要件定義、もしくは外部設計の前半の段階で、なるべく画面ユーザビリティや幹の機能のプロトタイプを開発して提示していく方法をプロセスに組み込んでいきましょう!

【SIerにご興味ありましたら、無料のプログラミングスクールへの参加は如何でしょうか】

【引用・参考文献】
システム開発の仕事とは
家づくりで理解する要求明確化の勘どころ~システム構築を成功させる要件定義のポイント~
 

スポンサーリンク
仕事のこと
hikoblog