非エンジニアに知って欲しい要件定義 | システム開発の基本
またまたご無沙汰しております。だいぶ前回の更新から時間が経ってしまいました。
最近、弊社ではEC-CUBEのカスタマイズやconcrete5を使ったWeb制作以外に、ITコンサルや技術顧問などのお仕事も増えてきました。
そういった仕事でよく遭遇する悲しいケースが、発注側の発注スキルの低いケースです。
これは社内で開発部隊を持っているケースでも一緒で、経営陣や部長クラスの人のシステム開発やプロジェクト管理に関する知見が無いことからコミュニケーションが上手くいかない事態が起きてしまいます。
「経営陣が学べば良い」と言えばごもっともなんですが、あいにく経営陣のメインのお仕事は経営であり、システム開発ではありません。他にもやらなければいけない事がたくさんあるのです。
ただ、現代社会においてシステム開発はどの会社でも避けては通れない重要な経営課題になっています。
この機会に一人でも多くの発注者の方に、最低限抑えておけばOK！という勘所を知って欲しいと思います。
なぜ知らないといけないのか？
「知らないと余計なお金が膨大にかかる」この一言に尽きます。
何故かと言うと、安全のために外注であればバッファを多めに取ったり、間違った発注で不要なゴミが出来上がってしまったりするからです。そもそも完成せずに途中で放棄されるケースも少なくありません。
そこから発生する時間的、機会的ロスは想像したくもありません。
そしてそういう会社ではエンジニアや開発会社が定着せず、関係者にとって残念な状況になってしまいます。
システム開発の基本をわかってるだけで大きく違う
ただ、そう悲観的になることもありません。基本的な事さえ押さえておけば、そういった最悪のケースは簡単に回避できます。
むしろ経営者とか、技術的な知見が無い人が専門的な技術的知識を備える必要性はありません。
クラウドやらAIやら目先の細いIT用語に惑わされる事なく、正しい日本語で伝えれば良いだけです。
では、何をどういう風に伝えれば良いのでしょうか？
まずは伝統的なシステム開発の流れを理解しましょう。
要件定義
要件定義とは、そのプロジェクトで「何が満たされなければならないか？」を決める作業です。
「要は決めの問題ですね」の「決め」の部分です。
なので、設計以降のフェーズでこの言葉が出てきたら要注意です。
発注者が最も多くの時間を割かなければいけないのもこのフェーズです。ここで正しく自分たちの要求を伝えないと失敗します。詳しくはも少し下の方で解説します。
設計
要件定義に基づいて、エンジニアが設計をします。
これは、一種の翻訳作業です。と言うか、システム開発とは自然言語からコードへの翻訳作業と言っても過言ではありません。
このフェーズでは、要件定義に基づいて実際にプログラマがコードを書ける粒度までその内容を落とし込みます。
このフェーズで発注者が行わないといけないのは、ちゃんと定義された要件が満たされているか？の確認です。
理解できるまで「どう満たすのか？」をちゃんと聞きましょう。「なんか良くわかんないけど、相手もプロだし多分大丈夫だろ」という意識では失敗する可能性が上がります。
コミュニケーションスキルの高い、腕の良いエンジニアは、この時の説明もとても上手です。わかりやすい説明だったら「当たり」の人です。
実装
設計に基づいてプログラマがコードを書いたり、エンジニアがサーバやネットワークの設定をします。
ここまでくると、発注者がやらないといけない事はそう多くはありません。定期的に進捗の確認をしましょう。この時重要なのが、口頭や資料だけの説明で確認しない事です。必ずコードや成果物の現物を確認しましょう。
何が書いてあるかわからなくても大丈夫です。
「どのタイミングで」「どういったものが提出されたか？」の記録を残しておくだけでも充分です。どうしても心配だったら、セカンドオピニオンみたいに別の開発会社とかにレビューをお願いしましょう。
もし、遅延が発生しても感情的になってはいけません。感情的になっても、さらに遅れるケースがほとんどです。
- どの程度の遅れなのか？
- 追加の費用が必要なのか？
- 事業に与えるインパクトがどの程度なのか？
を確認し、対策を取りましょう。
ここで無理に当初の納期に間に合わせようとすると大炎上するケースがほとんどです。
この場合の選択肢はそう多くありません。だいたい、
- リリース日を延ばす
- リリース内容を減らす
- リソース（開発人員）を増やす
くらいです。ただ、リソースの追加は上手くいかない事が多いので注意が必要です。
検証
さあ、実装されたものを確認しましょう。
この検証フェーズでは、実装されたものをテストします。開発側では自動テストを書いている事が多いので、この段階で細かいエラーとかは出ないはずです。
ここで発注者が行わないといけないのは、ちゃんと要件定義されたものが設計にそって実装されているか？の確認です。
不具合が出たら修正してもらいましょう。
このフェーズでよくモメるのが、発注者が「バグ」だと言い、開発側が「仕様」だと言うケースです。
このケースは要件定義と設計が失敗している、網羅されていなかったケースがほとんどです。要件定義書や設計書で明確に記載されていなかったら、開発会社を責めても無駄に時間がかかるだけなので、大人しく交渉しましょう。だいたい発注者も開発側双方に問題があったケースがほとんどです。
この段階で、「あ、やっぱココちょっとこう変えて」と言うのは、原則的にできません。文言1文字であろうと1色変えるだけであろうと無料ですぐにはできないと思ってください。
とは言え、出来上がったものを見てみないと気づかない所もあると思います。もし、検証段階で変更をしたい場合はあらかじめ発注段階でその旨を伝えて、そういった場合の費用や対応を相談しておきましょう。
以上が伝統的なシステム開発の流れです。よくウォーターフォール式とか言われるのがこれです。
メリットは、あらかじめ開発内容と費用がわかるという事で、デメリットは途中の変更が難しい、などです。なので、業界の流れが早く対応スピードを求められるシステムにはあまり向いていません。とは言えアジャイル開発とかはさらに難しいので、まずは小さいプロジェクトで慣れる事をおすすめします。
要件定義とは？
お待たせしました。ここからが大事な勘所のお話です。
上記の流れを読んで頂いてわかったと思いますが、最初の要件定義がものすごく重要です。
ここで間違えると、後のフェーズが全部間違ったものを基に進んで行くので確実に失敗します。
なので、自信が無かったら小さなフェーズに分けましょう。
まずはプロトタイプを作るところから始めた方が、結果的に出費を抑えられたりします。
要件定義とは上記の通り、「何が満たされなければならないか？」を決める作業です。
ここで重要なのが、どのレイヤーで、どれくらいの粒度で決めるか？となります。
レイヤーと粒度に気をつける
要件にはレイヤーごとに
- ビジネス要件
- 業務要件
- システム要件
- 機能要件
と分かれます。下に行くほど粒度は細かくなり、より具体的な内容になります。
ここで注意しないといけないのが、「その要件はどのレイヤーの要件？」という事です。
ビジネス要件を策定している時に、「AWSは必須だよね」とか言い出すのは間違いです。
逆にシステム要件を定める時に、「幅広いユーザ層にリーチできること」とか言い出すのも間違いです。
経営層の人間は「ビジネス要件」だけを決めれば大丈夫です。もし、会社の規模が小さく、もっと下のレイヤーまで経営層が決めなくてはならない時でも業務要件までを決めれば充分です。
システム要件以下はエンジニアと相談しながら策定していきましょう。
逆に、「レスポンシブ対応は必須！」などの細かい機能要件から入ってしまうと失敗するケースが多いです。自社の事業計画やマーケティングプランにそって、求められるビジネス要件の策定をきちんとしましょう。
ビジネス要件とは、言い換えるとその事業の優先的に解決しなければ課題です。
業務要件はビジネス要件を満たすために必要な業務を決める事です。その業務要件に従い、どの部分をシステムで解決するか？がシステム要件となります。
そして最後にシステム要件を満たすためにはどういった機能が必要か？というところで機能要件を定める流れになります。
こういった要件のレイヤーを意識せずにいきなりシステム要件や機能要件を出して発注すると、道に迷って失敗するケースが多いです。
当然ですよね、最終的にどこに行くのかを気にしないで自転車で行くか電車で行くか悩んでいる様な物です。
逆に、きちんと決めていれば、各フェーズで正しく振り返る事ができ、現在地と目的地の確認が正しくできます。迷う可能性は低くなります。
要件（must）と要望（better）の区別
要件定義でやりがちなミスが、要件と要望の混同です。
見分け方は簡単です。
上位レイヤーの要件を満たすのに必要なのが要件で、そうじゃないのが要望です。
例えば、ECサイトの会員登録の際のシステム要件が「買い物に必要な情報を登録できること」だとします。この場合、入力項目に「性別」を入れることは要望であり、機能要件ではありません。
なぜなら性別はなくてもお買い物はできるからです。
この時のシステム要件が「買い物に必要な情報及び顧客のセグメントを判断できる情報が登録できること」だった場合は性別を入力項目に入れる事は要件になります。
無論、性別の入力項目があった方が軽微とは言え、開発費用は高くなります。また、会員登録障壁も上がるので、ビジネス要件や業務要件を確認して判断する事が必要になります。
CTOの必要性
こういった要件定義を進めて行くと、下のレイヤーになる程に技術的な知見が必要になってきます。
自分が判断できない時は遠慮なく専門家に任せましょう。
そういった役割の人がCTOだったり、技術顧問だったりします。
信用でき、幅広い高度な知識を持ち、自社のビジネスを理解した上で経営を考慮した判断すること、これがCTOの大事なお仕事です。もし、社内に居なければ外部の人を技術顧問とするのも良いかもしれません。
どちらにせよ、現代ではどの会社でも必須の人間になってきています。
