見出し画像
Photo by syuka_sakura

設計・開発に思いを伝える、要件定義書の重要性

UMEZO

詳細設計書は要る？というblogを書きましたが、今度は要件定義書についてです。

いろいろな案件を見ていますが、企画書や要件定義書、要件仕様書等が不明確で、何を目的としているのか、どんな目標があるのかがわからないものをよく目にします。企画書・要件定義書、どちらでも良いのですが、書くべきものはちゃんと書いた方が良いです。


よくあるケース

IT部門作成する要件定義書でよく見る「目的」は下記のようなものがあります。

  • システムの老朽化に伴いリニューアルをする

  • 運用の負荷を軽減するためにリニューアルをする

  • 全体的な性能を向上させるためにリニューアルをする

残念なことですが、これらは目的でも目標でもなく、リニューアルするという「方策」です...

さらに、

  • 極力コスト削減に努めること

  • 可能な限り現行のソースコードを利用すること

とか書かれていますよね... 何のためにリニューアルを計画しているんでしょうか？？コストを無尽蔵に掛ける必要はないですが、現行のソースコードを再利用するのなら、今までと変わらないものができますよ？

せっかくお金をかけてシステムを構築するのに、どのような業務になるのかを描いていないものも多いです。ここをきちんと書いておかないと、

  • 依頼元の思いが実装されず、とりあえず動けばイイだけのアプリができる

  • 芯のないコンニャクみたいなアプリとなり、障害時の問題特定に多くの時間が掛かる

  • 過去のソースコードに囚われて新しいことにチャレンジできない、今までと何ら変わらないアプリができる

といったことが起きます。

そして、要件定義書なのに実装レベルの細かいことが書かれている、今までの経緯による例外処理が山のように書かれているも、実際に今それが使われているかどうかの言及がない等、インテグレータが道に迷うような、「定義書なのか仕様書なのか」もわからないような代物があったりします

要件定義書や企画書など、タイトルは何でも良いのですが、アジャイルだから無くても良いというものではありません。むしろ、詳細設計書を書かないのであれば、要件定義書は重要なものになります。

要件定義書に書くべき内容

課題や要望に対する対策として3つの軸で目標を立てると良いと思います。例えばアプリケーションの再構築などにおいては、こんな感じです。

業務としての目標

  • 案件状況を把握しやすいシステム

    • 何の対応で時間がかかっているかがわかるようにし、作業時間の短縮へ手が打てるようにする

  • 既存ナレッジを利用した自動対応化

    • 人材リソースの恒久的な減少に対応をするべく、状況に応じた機器の調整を推論を用いて自動的に行い、品質の向上と生産能力の向上を目指す

  • 報告業務の省力化

    • 伝えるべき内容の密度を高め、重要な報告は正しく、そうでないものは簡略化できるようにし、報告書作成の省力化で社員の負荷の軽減を目指す

ITとしての目標

  • 応答速度の向上

    • 案件が増えるに従いDB検索に時間が掛かるようになっている。要求される応答速度を満たせるよう、DBのテーブル構成やアプリを再構成し応答速度の向上を目指す

  • アプリケーション構成の単純化

    • 追加開発で多くの時間を要している現行のモノリス構造のアプリケーションを、役割に応じた単位に切り分け、開発効率の向上を目指す

  • 耐障害性の向上

    • 再稼働までの自動化や連携の非同期化を含め、障害発生時のワークフローを再考しダウンタイムの最小化を目指す

プロジェクトとしての目標

  • 品質の向上

    • 設計の確からしさはモックを作って確認し、課題を初期段階で解決させ、全体の品質を向上させる

  • 工期の短縮

    • 品質を向上させることにより、無駄な実装やテストなどを排除、工期の短縮を目指す

  • より多い要望の取り入れ

    • 使いやすいシステムにするべく、業務部門と密に連絡を取り合い、本当に必要なものが何かを追求し、より良い方策の提案と要望の取り入れを行う

業務とITについては書かれていることは多いですが、プロジェクトとしての目標がITとして書かれているケースが殆どです。関連はしているものの、プロジェクトマネージャの観点と設計・実装の観点は違うので、分けて書くことでよりわかりやすくなると思います。

まとめ

業務として、ITとして、そしてプロジェクトとしての3つの観点を入れることで、それぞれの立場の思いを尊重しつつ、最適な方策は何であるかが、全員同じ視点で考えられるようになると思います。
詳細な要件については、ある程度言葉で表現しておくべきです。このような「骨太の目標」は、その後に作るであろう「設計書」の冒頭にも転記しておくべきで、いつ誰が見ても目指すものが何であるかわかるようにしておきましょう。

技術者は詳細なコードやデータに目移りし、プロジェクトマネージャは各工数や責任範囲等、細かい議論になりがちです。苦労の多いプロジェクトは木を見て森を見ずなものが多い気がします。プロジェクトの初期段階でしっかりとした目的や目標を立て、しっかり共有することのは重要なことなのです。

思いを伝える要件定義書を書いたうえでルール駆動開発を行うと、とてつもない効果が出てきます。

是非ご検討ください！

いいなと思ったら応援しよう！