プロジェクトの成果物はちゃんと読んで理解しようぜって話
こんにちは！
オアシステクノロジーズの古本です。
今日はプロジェクトの成果物について話そうと思います。
まずはこちらを見てみましょう
せっかくMermaidで書いたのに文字数オーバーだったので画像にしてます。拡大してください。。
ほんとはもっともっといろんな成果物がありますが、ウォーターフォールの場合はざっくり要点まとめるとこんな感じかな…と思います。
意見があればコメントください。
もっと詳しく知りたい！って方はIPAの標準成果物を見てもらったり「システム開発 成果物一覧」って調べるといろんな記事が出てくると思います。
今日話したいこと
- 成果物は前後関係が存在するから、あなたの作業に前工程の成果物が影響しないわけがない。
- 前工程の成果物を理解しないで開発した場合に発生するしがちな問題。
- 全ては「要件」を実現するためにどうするのかを示している。
今日話さないこと
- 各成果物にどういう内容が書かれるべきとか、成果物のサンプルを提示するわけじゃないです。
- V字モデルの話もしません。
ここから本題
1. 成果物は前後関係が存在するから、あなたの作業に前工程の成果物が影響しないわけがない。
冒頭の図を見てもらえればわかりますが、各成果物には前後関係があります。
- 要件定義フェーズで作成された成果物をもとに基本設計フェーズの成果物がつくられ
- 基本設計フェーズの成果物をもとに詳細設計フェーズの成果物がつくられる
- 詳細設計フェーズの成果物をもとに製造する
- 製造フェーズの成果物に対してテストする
みたいな
ここで重要なのは
各機能の設計書は対象機能固有の情報しか記述されていない
ってことなんですね
ここで皆さんに１つ質問します。
あなたはプロジェクトの開発メンバーです。
今日新たに１つの画面製造のタスクが割り当てられました。
何(どの成果物)をインプットにして製造に着手しますか？
結構「画面設計書」と「画面プログラム設計書」「ビジネスロジックプログラム設計書」みたいな、最低限な成果物しか見てない方多いんですよね。
あなたはどうですか？
この状態で実装しちゃうと、いろんな問題が発生します。
2.前工程の成果物を理解しないで開発した場合に発生するしがちな問題。
確かに各機能の設計書を見ていれば、動くものはできるでしょう。
もしあなたがこんなことを感じたことがあるなら注意が必要です。
ちゃんと機能として正常に動いてんじゃん。何がまずいの？
てか、何がわるいのか設計書に書いてねーからわかんねーし。
こういうときに発生しがちな問題として、以下のようなものがありますね。
ここに示したものはあくまで一例です。
他にもプロジェクトの根幹を揺るがすような問題が発生することもあるでしょう。
要件定義書や方式設計書などの「前工程の成果物」をちゃんと理解していないからこういう問題が発生するんですね。
では、それぞれどのようなアプローチをすれば問題を事前に防げたでしょうか。
DBのインデックスが適切に利用されないSQLになっていて、オンラインレスポンスがタイムアウトした。
業務処理量定義書・業務フロー・性能要件実現方式を読み、どの程度の負荷が発生するのか・どうやって負荷を少なくするのかを理解するべきであった。
ストレージを不適切に利用していて、他の機能が対象ファイルを読み込みできなかった。
アプリケーション処理方式・インフラ構成設計書を読み、ストレージの利用ポリシーやアクセス権を理解すべきであった。
なぜか一部の画面だけエラーメッセージの表示位置が違ってユーザビリティの低下を招いた。
アプリケーション処理方式を読み、メッセージの表示ポリシーを理解すべきであった。
秘匿性の高い暗号化対象の項目が、平文でログに出力されていて情報漏洩が発生した。
セキュリティ要件定義書・セキュリティ実現方式設計書を読み、暗号化対象の項目と、暗号化・復号方法を理解すべきであった。
単体テストの観点が網羅されておらず、バグが頻出した。
テスト方式設計書を読み、テストフェーズごとの観点を理解すべきであった。
適切にログを出力していないためバグの原因が特定できない。
アプリケーション処理方式・運用保守性実現方式設計書を読み、ログの出力ポリシーを理解すべきであった。
ブランチの運用を間違えて１週間かかった作業がやり直しになった。
開発方式設計書を読み、ブランチ運用ルールを理解すべきであった。
いかがでしょうか。
特定の機能の開発においても、要件定義書や方式設計書がどれほど影響してくるのか理解してもらえたなら嬉しいです。
3.全ては「要件」を実現するためにどうするのかを示している。
成果物っていうのは納品物だから作らなきゃいけないんじゃなく、必要だから存在しているんです。
なぜ必要なのかというと、プロジェクトの目的を達成するためです。
1つの文書に全ての情報がまとめられればいいんですが、システム開発プロジェクトは大規模になりがちです。そのため細かくカテゴライズして独立した文書として成果物を作成します。
しかし全ての成果物は別の成果物と関連性をもちながら「要件を満たすためにどうするのか」ということを記述しているのです。
あなたの仕事は機能を開発すること、プログラミングすることではなく、プロジェクトの目的を達成し、お客様の要望を満たすことで売上向上や業務効率化にコミットすることだということは弊社メンバーには常々伝えています。
そのためのごくごく小さい局所的なタスクとして機能開発を行っているに過ぎません。
プロジェクトを成功に導くためにはお客様の要望やプロジェクトの要件、そしてそれをどう実現するのかを正しく理解する必要があります。
プロジェクトの成果物はちゃんと読んで理解しようぜ
特に要件定義書と方式設計書は確実に理解した状態で日々のタスクに取り組みましょう。
Discussion