なぜWBSをExcelで書くのでしょうか？

Question

こんにちは。
なぜWBSをExcelで書くのか。
代替案はあるのでしょうか?

わたしが思うに、WBSはプロジェクトのなかの仕事を管理可能な単位に細分化して、理解したり共有したり、文字通り管理するために使うものであって、表形式であるかどうかと、Excelであるかどうかは、ごく二次的な要素であると思います。
ほとんどそれは管理者である人間が使えるソフトがExcelしかないという単純な理由で選ばれているように思っています。
あるいは以前からExcelであるという理由だけで。

WBSは、Work Breakdown Structure:作業分解構成図ということなので、それにExcelを使わなければならないなどという理由はないためです。

WBSをExcelで表現する場合、しばしば共有の問題が起きます。
どこのフォルダに最新版が置いてあるのかわからないとか、というような。
あるいはしばしばExcelの超巨大な表になっていて、A3に出力しても2ミリくらいの文字になってしまうとか、1920×1080ピクセルくらいの解像度で見ているだけでは一覧性がないとかで、全体を把握できないとか。

ディスプレイを前にミーティングしていて、相手が操作しているとひんぱんにスクロールするので目が回ってしまうとか(わりと酔いやすい)。

そんなわけで、巨大で最新版がわかりにくくコントロール不能で全体像を把握できないので、自分が求めてWBSを見ることはほとんどないのです。

自分が行う場合によく使うのは、階層化できるToDoです。
最近使ってよかったなぁと思うのはOffice365のTaskとか。
Todo.lyとか。
チケット方式のなんだったかな。Backlogだったか。
ChatWorkのチェックリストとか。なのです。

それらとExcelの表とのあいだに、どうしようもない距離感を感じているのですけど、そういうのってなんともならないものでしょうか?
こういうのがよかったとか、これにしたらうまくいったとか、というのがあれば、教えてください。
情報交換したいです。

よろしくお願いします。

Answer 1

Excelで作るのが甚だ効率が悪いのは確かにその通りだと思います。ですが日本のIT企業の多くにとって、開発業務が自社内で完結していることは希でしょう。そうなると他社（自社では開発などを行わない発注元も含む）との情報共有の必要が生じます。そのときに、ほぼどちらの会社でも閲覧編集出来るファイル形式となるとExcelかWord辺りが浮上してくることになります。

Excelで作ると便利という積極的理由ではなく、他社とのデータ交換のためにはExcelで作るのが無難という消極的理由以外はないと思いますよ。

最近はWEBサービスとして提供されているプロジェクト管理ツールも増えていますので、機密保持契約などに抵触しない場合には、それらのツールの利用も増えてくと思いますよ。

Comments

[cancat]

ありがとうございます。やはり消極的な理由なんですよね～。ちなみにわたしはExcelの初期にはかなり驚いたことがあって、とてもよいソフトだと感じていました。オートフィルとかはすごく好き。Wordよりは2歩くらい未来的だと感じてました。ダメだな～と思い始めたのは、シートがわかれるようになったときです。シートによって縦スクロールと横タブとで、2次元的にファイルを把握しなければならなくなり、直観性を失ったと思いました。あとは使い方でダメにしたと感じたのは、Excel方眼紙がメジャーになったときです。セルという入れ物を根本的にダメにしてしまったので、もう別物になってしまったなと。シートとExcel方眼紙が、Excelをダメにしてしまったと思います。いまでは、すくなくとも縦にスクロールするので1次元的で把握しやすいWordのほうがコンセプトを失ってないので一貫性があると思います。とはいえ、どちらも旧態依然というのはたしかで、なんというか、新しさというのはないですね。手になじむ感もないというのが残念なところです。
Webサービスいろいろメジャーになっていくといいですよね～。

Answer 2

代替案はあるのでしょうか?

MSプロジェクト使っていたことがあります。

それほど悪いツールではないのですが、どうしてもやり方が判らないとか、使いずらい点が出てきます。
プロジェクト管理はなかなか影響が大きい仕事なので、仕事上の見過ごしをしないかビクビクして使いました。

結果、メリットがデメリットを上回れなかった印象です。恐らくこの点は他のツールも同様ではないでしょうか？

大規模に導入してもっと関係者が多いプロジェクトに適用させたらデータのまとめ上げなどで上手く使えたかもしれません。

その点、Excelであればスゴク手間がかかったとしてもできる事は判っているのです。予想可能なことはプロジェクト管理においてすごく大事なことです。

また、データの二次利用を考えるとExcelで管理していた方が良いというのもあると思います。

---

ただ、問題の本質はWBSにあると思います。WBSでプロジェクトを管理すること自体が複雑かつ煩雑なので、ツールが複雑になってしまう気がします。(もともと、土木や建築で使われていたツールだと思うのですが、作業の追加とその影響の分析がしずらい。)

クリティカルパスを管理する点ではWBSは便利だと思います。しかし単に進捗管理がしたいなら、予定と実績の積み上げなので、WBSではなくて挙げられているようなチケット管理タスク管理のツールの方が良いと思います。（そしてタスク管理であれば、Excelでも問題なく運用できるとおもいます。）

そういう意味でどうしてWBSを使おうとしているかが問題なのではないかと思います。
（勘だけど、システム開発を工場作業や建設作業と同じだと思い込もうしているのが問題な気がする。）

Comments

[cancat]

ご回答ありがとうございます。
おっしゃるとおり、予測可能であるというのは大事だなと思います。

これまたおっしゃるとおりで、プロジェクト管理は影響力が大きいので、見落としや見過ごしをしないようにしないとならないのです。わたしの場合、Excelではそもそも気乗りしない(見ずらいとか反応速度が悪いとかしばしばいろいろな理由で最新版でないとか)で、見落とし見過ごしなどを起こしがちであったり、しばしばプロジェクトをうまく管理者がタスクに分割できていなくて、そのためWBSで管理がうまくいっていないと感じることがあります。
これがわたしの考える問題の本質ですね。
管理者はExcelで表にしたから管理できていると思っているけれど、その分割したタスクが、充分にタスクになっていない。
なので、わたしはそれをきちんとしたタスクに分割しないとプロジェクト管理をしている意味がないと感じるのだけれど、かといってWBSをもしわたしが編集して書き足してもその書き足したファイルを管理者が使ってくれるとは限らない(しばしば管理者は自分のローカルにあるWBSファイルを使い、それを一方的に共有フォルダにアップロードするので、わたしが書き足しても上書きされて意味がない。
管理者はWBSに書けば管理できていると思っているのだけれど、そのタスクが必要充分な粒度でタスク化できていない限り、タスクの意味をなしていない、ということ。これが問題の本質なのだなとあらためて思いました。
たとえば製造という過程で、じっさいにプログラミングするときに、できること・既知のことをプログラムするだけならば、とても能率的で、時間を読めます。
でも現実的にはそんなことはまれで、すこしでも調査やテストが必要になる未知のことをプログラムする場合、時間がどれだけかかるかは基本的に「やってみなければわからない」のだと思います。
ある程度類推できることはあるとしても、それがどれだけ適当かはわからない。
未知のこと、考えることは予想がつかないのだと思います。
予想がつかないことを、時間を区切ってWBSに書いて予定を書けたと勘違いして「できた」とか「できない」とか「達成率がどう」とかいってもほとんど机上の空論なのであって、そういうリアルな問題を、かなりリアルタイムにWBSに反映しないとプロジェクトの進行の実情を反映できないんじゃないかという気がします。
もちろん、調査して予定通りの時間でできないといっても、1時間が3時間くらいならある程度誤差の範疇だとは思いますけれど。というのは、3時間の予定が10分でできちゃうことだってあるから。でも、8時間(1日)が24時間(3日)となるとだいぶ違ってくる。1日の予定が5日間かかるなんてこともよくあるわけです。よくあっちゃまずいのかもしれないけど。
だいぶ違うときには当然相談するわけだけど、そういうボトムアップで柔軟な環境って、なかなかないよな～、という気がしてます。
結局そうなると、未知の調査はあきらめて、しばしばできることしかしないプログラミングになりがちで、そういう書き方だと限界の積み重ねが増えて、あるときに決定的に全部書き換えないとダメみたいなことになり、それがプロジェクトの終了のあとに来ればいいけど、そうでないとやばいな～、みたいな印象。
経験を積み重ねてできることを増やしたり、コミュニケーションを密にするのは当然だけど、そのためのツールがExcelのWBSなのは貧弱すぎるなぁと、あらためて思いました。

[iwamoto_takaaki]

結構なサイズのプロジェクトをやってらっしゃるようですね。

WBSのツールを使うと、バージョンの問題などには一定の効果がみられると思います。ただ、ドキュメント管理は重要なプロセスだと思います。定期的な更新と取りまとめがないとどんな対策も意味をなさないと思いますし、そのようなドキュメントを書くならメンバーに声かけて回った方が生産的だとおもいます。

あと、進捗管理では投入と進捗の計測が大事で、例えば１０００時間の投入に対して進捗が８００時間だったとすると”論理的には”２５％の作業の不足が考えられます。結構ざっくりした見方ですが、統計的に扱うことができるの意味はあると思います。これに対して、見積もりが甘いのか、技術力が低いのか、設計が甘いのか、特定の箇所で問題が起こっているのかなど個別の問題の影響がどの程度なのかを分析をして対策をうつのがマネジメントだと思います。

このような点は、マネージメント視点でしか見えてこないだろうなと思います。

ここまでは、WBSでなくてタスク管理ツールで十分扱えます。使ったことがありませんが、バーンダウンチャートは追加されたタスクの量に関しても管理ができるので分析がしやすいように思います。特にイナズマ線はタスクがどんどん追加されるプロジェクトにおいては何の意味もありません。全体会議前に、リスケして「オンスケです（ハート）」とのたまうリーダーをどれだけ見たことか・・・

WBSこれにクリティカルパスを計測することで、クリティカルパス上にある不確定要素を徹底的に洗い出すことができます。クリティカルパス上の問題点に集中的にリソースを投入するのです。そして、これが大事なことですが、「WBSはクリティカルパス以外の遅れは人員増やせばいいでしょ。」といえることが前提になっています。この点が、土木や建築を前提にしていると思われる部分です。

ただ、プロジェクトリーダーが優秀な技術者たちの風よけになって、メンバーをプロジェクトに集中させるという仕事をしているのも忘れてはいけないとおもいます。プロジェクトにまったく意味のない資料でも、会議室では武器になっているのかもしれません。

[cancat]

コメントありがとうございます。
最近、立て続けにすこし大きなプロジェクトにかかわっています。
このところ6つのプロジェクトのうち、ExcelでWBSしていたのは4か所。チケット方式が2か所です。チケット方式をとるプロジェクトは、運営もとてもスマートで、MVVMやMVCで設計したり極力コードを書かないとかテスト駆動開発するとかなど、徹底した運営管理をしていました。
その他の4か所は、どちらかといえば旧態依然としていて、べったりとしたコードを書くケースが多かったです。もちろんテストは人海戦術で手作業。残業も多くて、みんな死んだ魚みたいな、ときおり徹夜ハイみたいなことになっています。
環境や考え方が古いからExcelを使っているようにも思えました。因果関係ではないとしても、相関関係はありそうな印象。
「Excelでないと達成率がわからない」などと、ほとんど寝言みたいなことをいわれたこともあって、途方にくれます。そういう相手になにかいうのって、むずかしいなと思います。
総当たりの仕様書とか、総当たりのテストとか、みたいな原始的な現場も多く、総当たりすると条件の掛け算で増えたりするじゃないですか。今日なんかも、8×8×8×8×8とかで条件が増えるような仕様書を書いたりして、だれが読むのかとか思いますけど、ま、それがいいっていうんならそれがいいんでしょうね。とほほです。
よいプロジェクトリーダーとか、よいプロジェクト運営とか、夢みたいなことはあまり見ないようにしているのですが、とはいえすこしでもマシなようにはしたいですね。掛け算の仕様書にコミットしていると、自分だけのソフトをていねいに作りたいななんて思っちゃいます。自分で作るソフトは、タスク管理という加工したいというリストは作るけど、WBSなんてのとは無縁ですし。気の向くまま作れますし。

Answer 3

Excelで作成するのは「ほとんどのメンバーがインストール済み」で「とりあえず共有・編集」するのが楽だからという理由しか思いつきませんww 他のツールがメンバー内でスタンダードになっていればそれでいいと思います。

そもそもWBSを作成する目的が、進捗管理のガントチャートのためなのか、チケット駆動のためなのか、いずれにせよWBS作ってメンバーで確認ってだけで終わることはないはずです。

マネジャーとしてガントチャートを含めて進捗管理するならMS Projectで慣れている人ならそれを使うでしょうし(昔からMS ProjectのWBSは使いにくいけど…)、リーダーやメンバーとしてチケット駆動でのチケット細分化の叩き台にするためにとりあえず作成・共有するならExcelでなくても問題ないでしょう。

WBSはあくまでも管理する上での「中間生産物」と言えるので、WBSを作成した先での利用形態に合わせて便利なツールをメンバーで共有して使うのがベストだと思います。WBS作成途上のレビュー段階でもない限り、巨大なExcel画面のWBSシートをみんなでグルグル見るというのはナンセンスかとww

Comments

[cancat]

コメントありがとうございます。皆様のご意見伺うのはとても楽しいです。Excelの理由はみんなが持っているから、結局それに尽きるのかな、という感じがしました。
おっしゃるとおりでわたしもWBSは中間生成物で手段であって、目的ではないので、そこに注力する気持ちが、とんと理解できない、という思いがあります。とくにWBSでのタスクの分割が、現実の進行と大幅に乖離していたり、そもそもそこに書いてあるスケジュールがぜんぜん箸にも棒にもかからないようなときには、よけいに。
中間生成物であるにもかかわらず、それに固執したりするプロジェクトマネージャーに対しては、なんというか、心理的に距離感が生まれてしまいますね。おなじ空間にいるはずなのに、違う世界に生きている気がしてしまいます。それではたぶんうまくいくはずがなくて、なるほど日本のソフトウェア開発の3割だか6割だかが失敗しているのは、ほんとうだなぁ、などと思うこともしばしば。
巨大なExcelのWBSシートを、画面で見えないくらい縮小したり、くるくるスクロールしたりして酔っちゃうよ～、みたいな光景、けっこう見かけます。朝会とかいってね。いったいあれはなんなんでしょうね。ほんとによくわからないです。

Answer 4

人員数を揃える開発等は誰がくるかわからないので、ひとまずエクセルならば実用性を担保した上で誰でもどこもで使えるだろうという少し後ろ向きな理由もあるかと思います。
エクセルはデータの全体的な管理には難がありますが、レイアウトや提出物としては優れているので、区切りのある開発はそれで済ましてしまう傾向もあるかと思います。
RedmineやJIRA等のITSツールには、WBS用のプラグインがあるようなので試してみると使えるかもしれません。
Redmine WBS plugin
WBSガントチャート for JIRA

Comments

[cancat]

ありがとうございます。
Redmineには(未体験ですが名前は知ってる)WBSプラグインあるんですね。
JIRA(未知)にもあるとのこと。そういうのいいですよね～。
そういうのがスタンダードになっていくといいな～と思ってます。

[aro10]

あとは、Markdown等が好きならばテキストベースでPlantUMLやmermaid.jsで書いて配布はPDFで取り扱う方法もありますが、周囲とツールが離れると思わぬ負担を負うかもしれないので難しいところです。
[PlantUML Gantt Diagram](http://plantuml.com/gantt-diagram)
[mermaidjs](https://mermaidjs.github.io/gantt.html)
WordやExcelの良さとしては、旧バージョン等の20年以上前のシステムの設計書があっても開いて書き足せていけるので、フォーマットの互換性はMicrosoftの努力により優れているかと思います。
その分Webサービスだと、サービス終了によって出力物が別移行用のCSV等になってしまうかもしれないのでリスクがあります。
最近のMicrosoftのOffice系のクラウドサービスだともしかしたら使いやすい何かがあるかもしれません。

[cancat]

そうですね。おっしゃるとおりで、周囲と足並みをそろえるのがとてもたいへんなのだな～と感じてます。
WBS@Excelの読みにくさが、WBSを見ることを敬遠しがちにして、結果として進捗管理の「波」に乗れないでいるな～、などと思います。
これはちょっとよくないので、といってExcel開くのもな～、重いしセル探すのめんどうだし画面小さいし。
慣れるしかないのかとか、ちょっと苦戦中なのです。

Answer 5

それら(excel以外のWBS管理ツール)とExcelの表(excelで管理するWBS)とのあいだに、
どうしようもない距離感を感じているのですけど、そういうのってなんともならないものでしょうか?

その距離感は双方にあって、それらを乗り越えるツールが出てきてメジャーにならない限り、
多分、なんともならないと思います。

一番の要因は、そのツールを利用するのに必要な学習・環境構築などのコストです。
何の制限も掛けられないのであれば、コストに低いものに流れるのは、自明の理です。

メジャーになるということは、必要な学習・環境構築コストは殆ど掛からない、若しくは考慮する必要がありません。

入口がツールである以上、そこで管理すべきスコープに対して十分な機能を持っているかは、見落とされがちです。

過去に進捗管理をexcelで行っていたという歴史がある以上、肯定される部分があり、個々の利用者にそれを上回るメリットを提供するツールが出現するまでは難しいのではと思います。

こういうのがよかったとか、これにしたらうまくいったとか、というのがあれば、教えてください。

希望されているだろう具体的なものは出せませんが、redmineで上手くいかず、excelでやってみようとした際に見つけたツールを紹介しておきます。
開発マイルストーン
習熟や維持にはそれなりにコストは掛かりますが、整形などの手間は省くことができるので、客先に詳細なWBSで報告が必要でこの程度での管理で十分な場合などに、使ったりしています。

excel以外ではBacklogが良さげだと感じます。

あくまでツールですから、どのように利用・継続・推進していくかはまた別で、視点が変われば利用するツールも変わります。

距離感持つより、臨機応変にそのステージでの改善を考えてみては如何でしょうか。

Comments

[cancat]

ご回答ありがとうございます。
おっしゃるとおりで、その距離感は、みんなにあるんだなとあらためて意を強くしました。そして、それを乗り越えるメジャーなツールがないんだなというのも、だからなんともなっていないんだな、とあらためて。

ほんとに、WBSはツールにすぎないと思っていて、いろいろ知識を蓄えておいて、臨機応変に選びたいですね。情報感謝です。