はじめに

転職して2日目。演習課題として売上管理システム作成のプロジェクトを丸投げされたので、基本的なプロジェクトの進み方を勉強しました。本記事では備忘録としてプロジェクトの流れを書き記しておきます。

プロジェクトのつくりかた

学生時代から見切り発車＋自己満足なプログラムしか組んでこなかったので、実際の業務も「なんか書類作りは適当にやって、組みながらシステム考えていくかなー」程度にしか考えていませんでした。甘かった。プロジェクトは計画が8割ということを思い知りました。

私が今回作成したプロジェクトは、以下の流れで動いています。

1. 要件定義　・・・なにを作るか決める
2. 設計　　　・・・どうやって作るか決める
3. 実装　　　・・・実物を作り始める
4. テスト　　・・・正しく動くかチェックする

実際には納品等があるらしいですが今回は演習課題なので割愛します。

それぞれの仕事

1. 要件定義

システムを作る前提条件として「何をするシステムなのか」を考えなければなりません。それを規定するのがこの要件定義です。

要件定義で最も重要なのは、できなければならないこと、できなくてよいことを明確化することです。たんに「売上管理システム」と言われると、「明細書を作るまでがシステム？」「いやいや、確定申告まで自分でできるのがシステムだ」と、どれぐらいできなければならないか不明瞭になる。このまま実装を始めてしまうと、開発者が何万人いても足りない膨大なシステムの話になってしまう。

そこで、「伝票の詳細は出せるようにしてね」「でも在庫の自動補充とかはしなくていいよ」というように、どこまでシステムで実現させるかを入念に練る。これが要件定義。要件定義があるおかげで、何を作って何を作らないかを明確化することができる。

実際に見よう見まねで作った要件定義書を貼りたいけど著作権云々で保留

2. 設計

何作るか決めたら、どのように作るかを決める。また書類作成だけど仕方ないね。
まずはWBSと呼ばれる進捗管理の様式を作る。個人的な解釈をするととりあえずやらなきゃいけないことを書けるだけ書いておこうシステムと考えています。

というわけで、やらなきゃいけないことを片っ端から書いていきます。実装はもちろん、「データの表し方を考える」「この辺で大丈夫かお客さんに見てもらう」「そもそもこの書類どもを作っている期間」……などなど。書けるものを書いて、分類して統合して、作業の順番に並べる。これがWBS。

それができたらいよいよシステム…………の設計書を作ります。

(1) 外部設計書

外側から見た設計書…………ということで、システム全体をどのように構成するか？を記述する設計書。入力がこれで出力がこれで、必要な機能がこれで…………などなどを記入していきます。これがあれば、システムを実現するのにどんな機能が必要か？が理解できるわけです。

(2) 内部設計書

内側を考える設計書……………ということで、機能をどのようにして作っていくか？を記述する設計書。外部設計で出てきたシステムをひとつずつ切り出して、入出力データがこれで見た目がこれで、そもそもシステムの考え方はこれで…………などなどをを記入していきます。これがあれば、どのような機能を作ればシステムができるか？が理解できるわけです。

3.実装

お待たせしました、いよいよコーディング。得られた設計書をもとにつらつらとプログラムを組んでいきましょう。
これを始める前に必要なのがコーディング規約。大勢で組むときに、変数の使い方やタブ幅が違うと発狂したくなります。私はなります。ここが曖昧だと後々に深い確執が出来るに決まってます。
プロジェクトが始まるたび社内に敵を作るわけにもいかないので、「こういうエラー処理をしましょう」「こういう微妙な場合はこうやって判断しましょう」とお約束します。コーディング規約が調停者になってくれます。

ここまで書いて、実装はあんまり書くことがないことに気付いた。やっぱり実装2割。

4. テスト

作ったプログラムは各自デバッグしてるはずですが、いざデータを食べた瞬間に落ちるなんてことがたまによくあります。商品として送り出したあとにそんなことがあると洒落にならないので、開発中に美味しいものとマズイものを食べさせて、プログラムをいぢめる工程が必要になります。これがテストです。

テストに先立ってテスト方針書と、各テストでのテスト設計書を作成します。テスト方針書は「こういうテストをします、これこれしたらクリアです」という方針を定義。テスト設計書は「あんなデータでいぢめます、こんな操作でいぢめます」という実際のデータやクリア条件を書いておきます。これに則ってテスト開始。

最初は機能の中身だけを辿る単体テスト。詳細は気が向いたら書きますが、コードとにらめっこしながら変数の動きまで考えます。

次に結合テスト。各々が持ち寄った単体テスト済みの機能をくっつけてバグを探します。ここで落ちるとすごく恥ずかしいから頑張って備えてます。

最後にシステム全体としてプログラムを使うシステムテスト。お客様になりきって、正常に動かしたり無理やり動かしたりして変な挙動にならないかチェックしていきます。

新人よ、これがプロジェクトだ

こうして見ると炎上する要因というのは至る所にあると感じます。

「要件定義から漏れてた機能を後出しされた」
「設計ミスで入力データが次々消えていく」
「コーディング規約を守らない奴のコードが死ぬほど読みにくい」
「テスト失敗」
「テスト失敗」
「テスト大失敗」
「そもそも設計おかしい」
「そもそも要件に無いことを指示されてる」

こんな事が容易に想像できてしまうし、容易に想像できる先輩と上司が数名いる。こわい。
しかし、これらの要因はよく吟味したドキュメント作成で回避できるものも多い。初心忘れるべからず、常によいドキュメント作りをしてプロジェクトを進めることを意識したい。

おわりに

最後までご覧頂きありがとうございました。ご指摘等ございましたらコメントにてご教授いただきますようお願いいたします。