Hatena::ブログ(Diary)

EC-CUBEのカスタマイズならクロスキューブ!サイト制作メモ このページをアンテナに追加 RSSフィード Twitter

2018-08-16

システム開発のフローと粒度

非エンジニアに知って欲しい要件定義 | システム開発の基本

システム開発のフローと粒度

またまたご無沙汰しております。だいぶ前回の更新から時間が経ってしまいました。

最近、弊社ではEC-CUBEのカスタマイズやconcrete5を使ったWeb制作以外に、ITコンサル技術顧問などのお仕事も増えてきました。
そういった仕事でよく遭遇する悲しいケースが、発注側の発注スキルの低いケースです。
これは社内で開発部隊を持っているケースでも一緒で、経営陣や部長クラスの人のシステム開発プロジェクト管理に関する知見が無いことからコミュニケーションが上手くいかない事態が起きてしまいます。

経営陣が学べば良い」と言えばごもっともなんですが、あいにく経営陣のメインのお仕事経営であり、システム開発ではありません。他にもやらなければいけない事がたくさんあるのです。
ただ、現代社会においてシステム開発はどの会社でも避けては通れない重要経営課題になっています。

この機会に一人でも多くの発注者の方に、最低限抑えておけばOKという勘所を知って欲しいと思います。

なぜ知らないといけないのか?

f:id:xross-cube:20180816135644p:image:w640

知らないと余計なお金が膨大にかかる」この一言に尽きます。

何故かと言うと、安全のために外注であればバッファを多めに取ったり、間違った発注不要ゴミが出来上がってしまったりするからです。そもそも完成せずに途中で放棄されるケースも少なくありません。
そこから発生する時間的、機会的ロスは想像したくもありません。

そしてそういう会社ではエンジニアや開発会社が定着せず、関係者にとって残念な状況になってしまいます。

システム開発の基本をわかってるだけで大きく違う

ただ、そう悲観的になることもありません。基本的な事さえ押さえておけば、そういった最悪のケースは簡単回避できます。むしろ経営者とか、技術的な知見が無い人が専門的な技術知識を備える必要性はありません。
クラウドやらAIやら目先の細いIT用語に惑わされる事なく、正しい日本語で伝えれば良いだけです。

f:id:xross-cube:20180816135831p:image:w640

では、何をどういう風に伝えれば良いのでしょうか?
まずは伝統的なシステム開発の流れを理解しましょう。

要件定義

要件定義とは、そのプロジェクトで「何が満たされなければならないか」を決める作業です。

要は決めの問題ですね」の「決め」の部分です。
なので、設計以降のフェーズでこの言葉が出てきたら要注意です。

発注者が最も多くの時間を割かなければいけないのもこのフェーズです。ここで正しく自分たちの要求を伝えないと失敗します。詳しくはも少し下の方で解説します。

設計

要件定義に基づいて、エンジニア設計をします。

これは、一種翻訳作業です。と言うか、システム開発とは自然言語からコードへの翻訳作業と言っても過言ではありません。

このフェーズでは、要件定義に基づいて実際にプログラマコードを書ける粒度までその内容を落とし込みます。
このフェーズ発注者が行わないといけないのは、ちゃん定義された要件が満たされているか確認です。

理解できるまで「どう満たすのか?」をちゃんと聞きましょう。「なんか良くわかんないけど、相手プロだし多分大丈夫だろ」という意識では失敗する可能性が上がります。
コミュニケーションスキルの高い、腕の良いエンジニアは、この時の説明もとても上手です。わかりやすい説明だったら「当たり」の人です。

実装

設計に基づいてプログラマコードを書いたり、エンジニアサーバネットワークの設定をします。

ここまでくると、発注者がやらないといけない事はそう多くはありません。定期的に進捗の確認をしましょう。この時重要なのが、口頭や資料だけの説明確認しない事です。必ずコード成果物現物確認しましょう。
何が書いてあるかわからなくても大丈夫です。「どのタイミングで」「どういったものが提出されたか?」の記録を残しておくだけでも充分です。どうしても心配だったら、セカンドオピニオンみたいに別の開発会社かにレビューをお願いしましょう。

もし、遅延が発生しても感情的になってはいけません。感情的になっても、さらに遅れるケースがほとんどです。

  • どの程度の遅れなのか?
  • 追加の費用必要なのか?
  • 事業に与えるインパクトがどの程度なのか?

確認し、対策を取りましょう。
ここで無理に当初の納期に間に合わせようとすると大炎上するケースがほとんどです。

この場合選択肢はそう多くありません。だいたい、

くらいです。ただ、リソースの追加は上手くいかない事が多いので注意が必要です。

検証

さあ、実装されたものを確認しましょう。

この検証フェーズでは、実装されたものをテストします。開発側では自動テストを書いている事が多いので、この段階で細かいエラーとかは出ないはずです。

ここで発注者が行わないといけないのは、ちゃん要件定義されたものが設計にそって実装されているか確認です。
不具合が出たら修正してもらいましょう。

このフェーズでよくモメるのが、発注者が「バグ」だと言い、開発側が「仕様」だと言うケースです。
このケースは要件定義設計が失敗している、網羅されていなかったケースがほとんどです。要件定義書設計書で明確に記載されていなかったら、開発会社を責めても無駄時間がかかるだけなので、大人しく交渉しましょう。だいたい発注者も開発側双方に問題があったケースがほとんどです。

この段階で、「あ、やっぱココちょっとこう変えて」と言うのは、原則的にできません。文言1文字であろうと1色変えるだけであろうと無料ですぐにはできないと思ってください。

とは言え、出来上がったものを見てみないと気づかない所もあると思います。もし、検証段階で変更をしたい場合はあらかじめ発注段階でその旨を伝えて、そういった場合費用対応相談しておきましょう。

以上が伝統的なシステム開発の流れです。よくウォーターフォール式とか言われるのがこれです。

メリットは、あらかじめ開発内容と費用がわかるという事で、デメリットは途中の変更が難しい、などです。なので、業界の流れが早く対応スピードを求められるシステムにはあまり向いていません。とは言えアジャイル開発とかはさらに難しいので、まずは小さいプロジェクトで慣れる事をおすすめします。

要件定義とは?

お待たせしました。ここから大事な勘所のお話です。

上記の流れを読んで頂いてわかったと思いますが、最初要件定義がものすごく重要です。
ここで間違えると、後のフェーズが全部間違ったものを基に進んで行くので確実に失敗します。
なので、自信が無かったら小さなフェーズに分けましょう。まずはプロトタイプを作るところから始めた方が、結果的に出費を抑えられたりします。

要件定義とは上記の通り、「何が満たされなければならないか」を決める作業です。
ここで重要なのが、どのレイヤーで、どれくらいの粒度で決めるか?となります。

レイヤー粒度に気をつける

システム開発のフローと粒度

要件にはレイヤーごとに

と分かれます。下に行くほど粒度は細かくなり、より具体的な内容になります。

ここで注意しないといけないのが、「その要件はどのレイヤー要件」という事です。
ビジネス要件策定している時に、「AWS必須だよね」とか言い出すのは間違いです。
逆にシステム要件を定める時に、「幅広いユーザ層にリーチできること」とか言い出すのも間違いです。

経営層の人間は「ビジネス要件」だけを決めれば大丈夫です。もし、会社の規模が小さく、もっと下のレイヤーまで経営層が決めなくてはならない時でも業務要件までを決めれば充分です。
システム要件以下はエンジニア相談しながら策定していきましょう。

逆に、「レスポンシブ対応必須!」などの細かい機能要件から入ってしまうと失敗するケースが多いです。自社の事業計画マーケティングプランにそって、求められるビジネス要件策定をきちんとしましょう。

ビジネス要件とは、言い換えるとその事業の優先的に解決しなければ課題です。
業務要件ビジネス要件を満たすために必要業務を決める事です。その業務要件に従い、どの部分をシステム解決するか?がシステム要件となります。
そして最後システム要件を満たすためにはどういった機能必要か?というところで機能要件を定める流れになります。

こういった要件レイヤー意識せずにいきなりシステム要件機能要件を出して発注すると、道に迷って失敗するケースが多いです。
当然ですよね、最終的にどこに行くのかを気にしないで自転車で行くか電車で行くか悩んでいる様な物です。

逆に、きちんと決めていれば、各フェーズで正しく振り返る事ができ、現在地目的地の確認が正しくできます。迷う可能性は低くなります。

要件(must)と要望(better)の区別

要件定義でやりがちなミスが、要件要望混同です。

見分け方は簡単です。
上位レイヤー要件を満たすのに必要なのが要件で、そうじゃないのが要望です。

例えば、ECサイトの会員登録の際のシステム要件が「買い物に必要情報登録できること」だとします。この場合入力項目に「性別」を入れること要望であり、機能要件ではありません。
なぜなら性別はなくてもお買い物はできるからです。

この時のシステム要件が「買い物に必要情報及び顧客のセグメントを判断できる情報登録できること」だった場合性別入力項目に入れる事は要件になります。
無論、性別入力項目があった方が軽微とは言え、開発費用は高くなります。また、会員登録障壁も上がるので、ビジネス要件業務要件確認して判断する事が必要になります。

CTO必要性

こういった要件定義を進めて行くと、下のレイヤーになる程に技術的な知見が必要になってきます。
自分判断できない時は遠慮なく専門家に任せましょう。
そういった役割の人がCTOだったり、技術顧問だったりします。

信用でき、幅広い高度な知識を持ち、自社のビジネス理解した上で経営考慮した判断すること、これがCTO大事お仕事です。もし、社内に居なければ外部の人を技術顧問とするのも良いかもしれません。

どちらにせよ、現代ではどの会社でも必須人間になってきています。

まとめ

いかがでしょうか?
要件定義重要さと、非エンジニアの人がどこまで何をすれば良いのかをわかってもらえたでしょうか?

ここさえ押さえておけば、そうそうシステム開発は失敗しません。今後なにかしらのシステム開発の予定がある方は、ぜひ試してみてください。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/xross-cube/20180816/p1