アプリケーション開発における工程管理の重要性
この世の中はモノを作る機会に溢れています。
家を建てる、車を製造する、料理を作る、システムを開発する・・・。
モノの種類は違えど、それぞれに共通していることがあります。
それは、モノを作っていく過程には必ず段階や順序があるということ。このことは、”工程”という言葉で定義されます。
今回のブログでは、「アプリケーション開発」における”工程管理”の重要性について考察し、いくつかの例を挙げて、良質アプリを生み出すために必要な工程管理の秘訣をご紹介していきます。
アプリ開発において、何を”工程”として捉えるか？
このタイトルだけだと漠然としていますが、モノ作りをするとき、実はこれが結構重要です。
例えばカレーライスを作るシーンを想像してください。人によって作る方法や順序は様々かとは思いますが、一般的には以下のような流れになるかと思います。
- ご飯を炊く
- 肉、野菜を切る
- 肉、野菜を炒める
- 肉、野菜を煮込む
- ルーを入れて煮込む
- お皿に盛りつける
カレーライスを製造するプロセスの中でこれら6つの作業を”工程”と仮定します。
しかし、
「ちょっと待った。肉と野菜を炒める工程は、肉・野菜と別にした方が良くない？」
「野菜を切るにしたって、玉ねぎ、にんじん、じゃがいもとあるんだから、当然それ毎に工程は分けた方が良いでしょ」
上記のように、どれを”工程”として定義するか、正解はありません。
もし、カレーライスの味が不味かった時、それはどこに原因があったのでしょう？
工程を細分化していれば、その原因は分析しやすくなるかもしれません。
ここまで、カレーライスを例に挙げてきましたが、今回のテーマであるアプリケーション開発においてはどのような工程があるでしょう？
一般的には以下のような工程が挙げられると思います。
- 要件定義
- 設計
- デザイン
- 製造
- テスト
- リリース
- (顧客)受入テスト
アプリケーション開発を1つのプロジェクトとして捉えたとき、プロジェクト全体の管理はもちろん行うと思います。
そのプロジェクトを”工程”という単位に分け、その”工程”ごとに進捗やコスト、品質を管理する。これが「工程管理」です。
よって、何を”工程”とし、どの粒度で管理するかがまず重要なのです。
例えば、規模の大きなアプリケーション開発になれば、設計、デザイン、製造、といった作業はある程度の機能別に工程を分けた方が良い場合もあります。
それぞれを担当するチームが分かれているのであれば、並行して作業を行う事もあるので、尚更管理しやすくなります。
- A機能-製造
- B機能-製造
- C機能-製造
せっかく、カレーライスを最初に例として挙げたので、カレーライスで”工程”を細分化して定義すると、以下のような感じです。
- 玉ねぎを切る
- にんじんを切る
- じゃがいもを切る
これら野菜を切る作業も場合によっては、複数人で並行して実施する事もありますよね。
弊社のプロジェクト管理ツール「SI Object Browser PM（以下OBPM）」では、アプリケーション開発としてプロジェクトを立ち上げた際、まずは工程を定義するところから始めます。
※プロジェクト登録時は”ドメイン”と呼ばれるテンプレートから初期値の”工程”が展開され、プロジェクトの途中で追加・変更する事も可能です。
上記画面の赤枠で囲っているのが”工程”として定義した部分です。
工程の下にはさらに細分化した”タスク”と呼ばれる作業をぶら下げる事もできます。
OBPMではプロジェクトの単位ではもちろん、ここで定義した”工程”の単位で、進捗、コスト、品質を詳細に管理していく事が可能です。
アプリケーション開発の工程管理で伝えたいこと
再びカレーライスの話に戻りますが、”玉ねぎを切る”という工程を定義しておけば、
「玉ねぎを切る人が別の作業をしており、玉ねぎを切る作業が遅れている。これが終わらないと炒める作業に入れないから、他の野菜を切り終わった人に玉ねぎを切ってもらおうか」
といったような、作業遅れの検知や、遅れへの対処がしやすくなる等のメリットがあります。
ここで伝えたいことは、ただ闇雲に作業を細分化し”工程”を定義するべきだ、という事ではなく、どのレベルで作業を管理していくかを明確に決め、プロジェクトを遂行していく必要があるということです。
管理する範囲やレベルが明確になれば、実態の把握が「早く・正確」になり、より健全なプロジェクト管理を行う事ができると考えます。
アプリ開発における、工程別の進捗率を標準化せよ
管理する工程が定義できたら、いざプロジェクトを遂行していきます。
工程管理の要素は前章でも述べたように、進捗、コスト、品質などが対象として挙がりますが、ここでは進捗管理にスポットを当ててお話をします。
このブログの筆者である私が、実際に経験した話です。
私は当時、とある大規模アプリケーション開発のうち、1つの機能の設計～製造～テストのチームリーダーを任されており、4人のメンバーをコントロールする立場でした。
進捗管理は式の入ったExcelツールを用いて、細分化したタスク毎に日々メンバーに％で進捗率を入力してもらう事を徹底、また、週次でメンバー全員を集め、進捗会議を実施していました。
私「では、今週の進捗報告をお願いします」
メンバーA「概ねスケジュール通りに作業を進められています、順調です」
メンバーB「一昨日、風邪で休んでしまったため、ちょうど1日分ぐらい遅れています」
メンバーC「来週までに予定している担当作業のうち、10分の8が完了しました。前倒しで進められています」
メンバーD「担当作業は昨日までで全て完了しています」
私「承知しました。進捗管理Excelでも確かにそうなって・・・ん、これで見ると、C君の作業が2日遅れって表示されていて、一番遅れているように見えるけど？笑」
各自の報告コメントだけ聞くと、Bさん以外の作業は順調で、特に対策が必要とは思えません。では、なぜCさんは遅れている疑惑があるのか、、もしや、嘘の報告をあげているのでしょうか？
その後、Cさんから話を聞き、その原因が分かりました。
このチームの作業は、作業完了時に私が最終チェック(レビュー)を行っていましたが、Cさんは作業の進みが早く、私のチェックが追い付かず、それが滞留している状態でした。Cさんは、その未チェックの状態を進捗率50%と入力しており、それが原因でExcelのツールが進捗遅れとして検知していました。
このような事象は決してCさんが悪い訳ではありません。
当然、どの段階まで完了したら何％という感覚は人それぞれであり、進捗率の表現の仕方は自由です。
しかし、「正しく・早く」進捗を管理するといった目的のためには、進捗率のルール化が必須ではないでしょうか。
特にプロジェクト内の立場が上になればなるほど、その目的の重要性は上がってくるように思えます。
各メンバーは、上記の【ガントチャート】画面より進捗率を入力しますが、その際に既に用意されているマスタから進捗率を選ぶことが可能です。
この機能により、担当者間で発生する％に対しての定義ギャップを埋め、正しい進捗率を集計することができます（進捗率の標準化）。
細分化したタスクに対して進捗率を入力していったとしても、前章で定義した”工程”のレベルでOBPMが自動的に進捗率を計算してくれます。
また、この進捗率のマスタは”工程”ごとに設定を持つ事が可能です。
- 基本設計工程の進捗率設定
- 詳細設計工程の進捗率設定
- 製造工程の進捗率設定
前述のように、必ずしもレビューという行為が発生しない工程もあり、実際のプロジェクトにおいては、工程により進捗率の考え方は様々になるかと思います。
“工程”という単位を意識して進捗率の定義をすることが大切です。
工程別の進捗報告により、アプリ開発のプロジェクト管理をさらに細かく
工程毎の進捗管理という観点でもうひとつ、OBPMの機能を紹介させて頂きます。
【進捗報告登録】という機能で、通常、プロジェクトリーダーが上長に対して、プロジェクトの進捗報告を行う事を想定した機能です。
上記が【進捗報告登録】の画面です。
赤枠で囲った工程項目で”全工程”を選択し、プロジェクト全体の進捗報告を登録可能ですが、予め定義しておいた”工程”を選択し、工程毎の進捗報告を登録する事もできます。
例えば、「詳細設計」工程を選択すると、OBPMにて入力されたガントチャート、障害情報、課題情報などのデータから、現在の「詳細設計」工程における集計値を、【進捗報告登録】画面の右側に表示します（「詳細設計」工程に限定されます）。
もし、工程毎に責任者が分かれているのであれば、各工程の責任者は自分の工程を選択し、画面右側に表示される定量的数値と、現在の状況を分析し、画面左側に定性的な報告を記載する。そういったご利用イメージが、工程別の進捗報告になります。
もちろん、上長は各工程の進捗報告の確認が必要です（確認をする機能もOBPMには備わっています）。
ただ単に工程ごとに報告をしたから終わりではなく、上長の確認までの一連のサイクルを回すことで初めて、しっかりと工程管理をしている、と言い切れるのではないでしょうか。
正しい工程管理が良質アプリを生み出す
以上が、「アプリケーション開発」における”工程管理”のポイントでした。
このブログの序盤にも書いた通り、まずは管理したい範囲を明確化し、そのプロジェクトにおける“工程”の定義をきっちりとすることが、プロジェクトの成功、つまり良質アプリを生み出す事につながってくるのでは、と考えています。
また、プロジェクトとしてやるべきこと、管理する範囲を明確にし、工程ごとの管理が完璧にできていたとしても、必ずそれらを束ねた上のレベル(今回でいうとプロジェクト)における、集計や管理を怠ってはいけません。
作業細分化、分割管理を徹底するがあまり、プロジェクト全体の本来の目的を見失わないよう注意してアプリケーション開発を進めていきましょう。
プロジェクト力強化につながるポイントをまとめた資料もご用意していますので、こちらもぜひご活用ください。
