WBS（Work Breakdown Structure）というプロジェクト管理手法があります。
システム開発や、大規模なソフトウェア開発においては、これを作らなければ開発全体のスケジュールを立てることができない程、重要な作業です。
しかし、ソフトウェア開発の現場でWBSの使い方を正しく教えてくれる人が居ません。
なぜなら、WBSでスケジュールのプランニングをする人は、ごく一部の人間だからです。
現在の職場で、若手のエンジニアにWBSの使い方を何故知らないのかと聞いたとき、
「だって、おそわってないもん」と言われたのは衝撃的でした。
一人でソフトウェアを開発している人、システムの一部のモジュールの担当者、日程を気にせずにソフトウェア開発をしている人には、まったく不要なのがWBSです。
WBSとは（基本的なところ）
基本的な話は、いまさらなので、他の方に任せましょう。
料理を例えとして、WBSの目的とメリットを大変わかりやすく説明されています。
WBSを利用することで、100人分のカツサンドを作るために、必要な作業を洗い出して、時系列に並べることで、複数の人数で分担することで時間を短縮したり、全体でどれだけの時間が必要となるかなどが見えるようになるツールです。
実際にどんな作業が必要となるのかを洗い出すためには、当ブログでも何度か登場しているマインドマップというツールを利用するのがオススメとのことです。
いくつかのページで、同じようにマインドマップで作業を洗い出しましょうと紹介されていました。最近はそんな考え方なのか？
システム開発、大規模ソフトウェア開発におけるWBS
ソフトウェア開発の現場で、作業の洗い出しのために、マインドマップをしていてはいけません。そんな曖昧な、思いつきで作業洗い出しするのは危険です。
ソフトウェア開発では、いつまでに、何を作らなければいけないかが先に決まってしまうケースが良くあります。
例えば、6ヶ月後に５００ページの機能仕様に従って動作するソフトウェアを作らなければいけない。
１ページずつ順番に一人でつくっていたら、いつ終わるかわかりません。
そのため、複数人での開発が必要となります。
WBSのタスクを洗い出すのは、マインドマップでは無くて、以下の手順になります。
機能仕様を整理
例えば、画面仕様なのか、画面と関係無い仕様なのか、音を出す機能なのか、モーターを制御するのか、通信を制御するのか等、大枠の機能分類を作って整理していく必要があります。
日本料理で例えるなら、ご飯に関する要求か、煮物に関する要求なのか、お吸い物に関する要求、器に関しての要求、添え物に関する要求なのかなどなどを整理するみたいなことですね。
こうすると、その後作業が分担しやすいのがイメージ湧きますか？
ここでは詳細な要求事項を理解する必要がなくて、ざっくり分担できるレベルに整理できればOKです。詳細な要求の分析は担当毎に任せましょう。
しかし、この場合でも各料理毎の統一できていなくて、各板前毎に味付けや盛り付けの見た目が独特な個性がでていると寂しいですね。
共通で守るべき要求事項なども、このタイミングでハッキリさせておきましょう。
各機能仕様の実現方法を整理（作業の細分化、役割と関連性の明確化）
各要求事項をどのように実現するのかの大枠を決める必要があります。
それぞれ異なるハードウェア毎に、制御するソフトウェアが違う場合があります。
既にあるソフトウェアを利用できる場合もあります。既にあるソフトウェアを利用するけれど、そのままでは問題ある場合もあります。
また、そのハードウェアを制御するソフトウェアを利用するソフトウェアが誰とだれか、画面に情報を渡すソフトウェアは誰かなど、作りやすい単位で分割します。
このレベルでシステム設計時に詳細に決めておかないと、各部品として、何を作らなけれいけないかがわかりません。各担当が勝手に作ってしまってから、くっつけても無理です。
こうやって、要求仕様毎に必要な部品、やらなければいけないこと、作らなければいけないソフトウェア開発の作業をWBSのタスクとして、洗い出します。
魚を切る人、肉を切る人、野菜を切る人、焼く人、ごはんを炊く人などを分ける作業と同じです。
それでも手が廻らなければ、野菜の皮を剥く人、切る人、すり下ろしする人をわけましょう。
煮出しでも、つけあわせでも人参をつかうなら、別々に人参を用意するのでは無くて、共通で人参準備しましょう。
他にも複数のソフトウェアの担当者で同じようなものを作ろうとしていないか、無駄をみつけておきましょう。
作業を時系列に並べる
料理にも順番があるように、ソフトウェア開発もWBSのタスク毎に順番を整理するのが大事です。
野菜は火の通りが悪いものから、先に鍋に入れるため、全ての材料となる野菜が切り終わるまで待つのではなくて、必要な野菜を切り終えたら、鍋に放り込みましょう。
鍋に放り込まれても問題ないように、そのタイミングにあわせて鍋に水を入れて火をかけておきましょう。
最後の日程から考えていったときに、どのタイミングで何が終わっていなければならないかが見えてきます。
本当にそのタイミングで終わっていなければいけないのか？作業をさらに分割することで日程に余裕ができあがる場合もあります。
もしくは、そのタイミングに前の工程を間に合わせるためには、何か工夫しなければいけません。
作業を分割して、さらに人を増やすのも一つの手段ですし、人は増やさずに優先度の高い作業と低い作業に分割して、優先度の高い作業を先に片付けるという手段もあります。
WBSの完成
作るべき日程までの間に、ソフトウェア開発担当としてやれる手段を全部詰め込んで、やりきったところが、開発スケジュールと開発工数予測の完成です。
- 作業の分割
- モジュールの最適な役割配置
- 無駄な工数の排除 ＝共通部品の利用、作成
- 作業優先順位の整理、分割
とにかく細分化です。作るべきソフトウェアが決まっても、さらに細分化してくと、となりのソフトウェア担当が作っているものと同じものが見えてきたりもするのです。
ソフトウェアを作るため、テストするためには、別のソフトウェアが必要なケースも往々にあり、依存関係を明確にしておかないと、スケジュールが組めません。
ソフトウェア開発におけるスケジュールは、このように分割、細分化、構成見直しがどこまでもできてしまうので、料理やハードウェア開発等よりも難易度が高いのです。
ソフトウェアの開発日程は、ソフトウェア開発担当者にしか無理です。
WBSは誰が作るのか
ソフトウェアを知らないプロジェクトマネージャや営業に日程が引けるはずが無いということを、もっとソフトウェア開発をしているエンジニアは自覚するべき。
WBSを作れないソフトウェア担当者は、そもそも設計ができていないのと同じだと思います。
おわりに
頑張れ、若手エンジニア。
こんなことを職場で誰にも教えたことが、確かに無いです。^^;
書いていて思い出したのですが、昔バイトしてたレストランのチーフは凄かったです。次から次へと注文される料理の出す時間にあわせて、的確に全員に指示をだしていました。本当に頭の良い人だと感心しました。ソフトウェアの計画ができる人と料理が効率良くできる人は同じセンスが必要だと思います。
私の家庭は、何か一つのことを始めると、他に何も並列でできないお馬鹿さんな料理人なので、料理はバラバラ出てきます。困ったものです。
ごはんとおかずが揃ってから、お味噌汁を作り始める光景も良くみます。
絶対、こんな人はソフト開発も無理だなと常々思っています。
