オフライン の bananaplaza

オフラインが映画、ドラマ、本、仕事とかのこと綴ります。

「 WBS 」 一覧

WBSは初心者でも作れる?

高杉です。自分は、まだプログラミングを勉強して2年しか経っていませんが、仕事で設計業務もしています。 そんな自分にとっては、ものすごく勉強になった本でした。 開発初心者にとって最高の本だと思う。 本の最後には、付録でWBSのテンプレートの表がありますが、そのテンプレートをExcelに写して一項目ずつ勉強していきました。 専門用語は少し出てくるけど調べればわかる範囲ですし初心者にとっては有難い本でした。 なんで新米プログラマーの自分が設計やっているかっていうと、PM,SEがみんな辞めたからです。 なので、ちょっと頑張るかと一念発起して本を読みまして、 プログラムがわからない営業社員と新米プログラマーがプロジェクト進めるなら、 以下の開発手法で進めるのはどうかと、まとめて提案してみることにしました。 その内容を載せてみようと思います。 目次 開発手法の目的①ヒアリング②見積り③受注④開発⑤テスト⑥納品まとめ 1.開発手法の目的 結論から言いますと、この開発手法の目標は「見積もる前に大枠の設計を確定させること」です。 今までは、お客様との認識のズレが出た時点で予定が達成できないことが確定していました。 なぜなら、認識のズレが出ることを見込んだ手順になっていないからです。 認識のズレは必ず発生します。 最初からそれを見込んだ手順でプロジェクトを進める必要があります。 そこで今後、開発を予定通り進めるために 「お客様との認識のズレが起きないこと」を目的に考えてみましたが、 どうしても「見積もる前」に設計を確定させなければならないと思いました。 しかし、今までの経験から、開発を進めていく途中、 追加でご要望が出ることは多くあるとわかっていると思います。 なので、この開発手法の目標を「見積もる前に大枠の設計を確定させること」としました。 大枠だけでもお客様とすり合わせて設計の確定印を頂きます。 ただあくまで現状の案なのでさらに良くなる方法があれば、再検討していきたいと思っています。 それでは、詳しく説明していきます。 2.①ヒアリング(お客様の業務情報の資料化する) この手順では、以下の情報を集め、確定させます。 システムの目的(成果物)の確認最低限必要な機能の確認ステークホルダーの確認納品期日の確 「1.システムの目的(成果物)の確認」の「目的」は、複数出る場合があると思いますが、 その場合は優先順位を決めてください。 「2.最低限必要な機能の確認」の「機能」は、5W1Hで詳しくまとめてください。 複数出る場合は優先順位を決めてください。 「3.ステークホルダーの確認」では、お客様の中から最低でも、 決済者を1人、システム導入責任者を1人決めて、 その他にシステム運用者、利用者と、各役職、各部署の名前を確認してください。 運用者、利用者が多くなる場合は、名前は必要ありません。 「4.納品期日の確認」では、最低でも月までは確定させてください。 3.②見積り(仮見積を行う) この手順では、以下の資料を作成し、お客様に提示します。 機能一覧・仮見積書仮画面レイアウト図 「1.機能一覧・仮見積書」は、1枚にまとめておくといいかもしれません。 ただし、お客様には金額を提示する必要はなく、 あくまで社内用に見積もります。機能一覧は、提示させて頂き、 ①ヒアリングでお聞きした目的から発展した機能なども追加提案します。 その後、受注になれば、詳細を付け加えていきます。 「2.仮画面レイアウト図」は、A3用紙に画面と用紙が1対1になるようにまとめます。 テンプレートがあるので統一して提示してください。 また、③受注の際にも使用するのでデータを保存しておいてください。 レイアウト作成ソフ「XD」を使用して画面の画像を作成し、 パワーポイントのテンプレートに貼り付けて作成すると良いと思います。 4.③受注(仮見積を確定見積として修正し印鑑を頂く) この手順では、以下の資料を作成します。 また以下の資料以外に確定しておきたい情報もまとめて提示してください。 業務フロー図機能一覧・追加予定機能一覧画面遷移図・レイアウト図データベースER図・テーブル仕様書確定見積書 「1.確定見積書」を作成する前に、 ②見積りで作成した資料(機能一覧・仮見積書)を利用して、 受注予定を気にしつつ、お客様が納得するまですり合わせます。 そして、納得して頂いたところで確定見積書を作成し印鑑を頂いてください。 この確定見積書を基に詳細設計が行われます。 この時点からご要望を締め切るので、将来的なご要望なども 全てヒアリングしておいてください。 そしてお客様にはご要望を締め切ることを必ず伝えてください。 5.④開発(開発メンバーが設計の再確認、開発スケジュールの再調整、開発を行う) この手順では、まず受注者が開発メンバーに設計内容の情報共有を行います。 開発メンバーは、その設計を基に開発スケジュールを機能ごとに詳細まで調整します。 ③受注で作成した確定見積書か機能一覧を利用してください。 開発スケジュール表 「1.開発スケジュール表」は、資料の形式を問いません。 この時点でスケジュールが大きくズレる場合は、早めに受注者に報告してください。 開発のスケジュールの内容には、新たな言語やツールなどの教育・トレーニング期間なども入れてください。 開発開始後、スケジュールにズレが出そうな場合も早めに受注者に報告してください。 受注者は、調整を行って必要な場合はお客様に現状を報告してください。 お客様にも早めの報告をお願いします。 6.⑤テスト(テストメンバーが設計の再確認、テストスケジュールの再調整、テストを行う) この手順では、テストメンバーがRedmineでバグなどを報告します。 新たな資料の作成が必要であれば、この時点で作成すると良いと思います。 特に必要な資料はありません。ただし、テスト計画を社内で確定し 掲示板などにメモしておいてください。テスト計画について以下にまとめます。 どこまで担保しているか実行環境注意事項(将来的に発生する可能性がある不具合など 「1.どこまで担保しているか」については、 「機能不備がない・フリーズしない」ことは最低限としてください。テストシナリオを作成するといいと思います 「2.実行環境」は、いつ、どのパソコン、OS、Officeなどのソフトのバージョンでテストしたかのメモを取ってください。 「3.注意事項(将来的に発生する可能性がある不具合など)」については、 リスク内容と優先順位も一緒に一覧にしておいてください。 7.⑥納品(納品スケジュールを立てて、納品する) この手順では、お客様と改めて納品スケジュールの調整をしてください。 既存システムなど業務を止めて頂く場合も考えてすり合わせてください。 8.まとめ 他に必要な資料や良い案があれば、改良していこうと思っています。 bananaplazaまでご意見お願いします。 自分で考えて本に書いていた難しそうなことは勝手に端折ったので、 インターフェース?とか検討しないといけない部分が多いと思いますが 今自分が理解しているのはここまで。もっと頑張らないと! つづく。

ブログ内容

高杉、沖田、斎藤で運営しています。