Word/Excel無間地獄


★もっぺん言う。Word/Excelはクソ。

 え?枕がいきなり刺激的だ?構うもんか何度でも言ってやらぁ。あんなもん糞以外の何者でもねぇや。何が「ドキュメントはWord/Excelで。それ以外は却下」だぁ?ふざけんな!脳にウジ湧いてるんかてめぇらは!おめーみたいな輩が一人や二人消え失せたところで社会経済にはプラスにしかならないんだからとっとと日本海溝の藻屑と消えろやボケナスがぁぁぁあああ!!

 いきなりケンカ腰かよ>俺。

 まぁこのWord/Excel話に関しては、以前からもずーっと事ある度に指摘し続けているのですが、一向に収まる気配がないばかりか、かえって増幅しちまってる感がどうにも否めませんので改めてネタにしよう。そんな趣旨なのでございますが。

 ていうか現時点、プロジェクトの大小や分野を問わず、既にWord/Excelの類は既に蔓延完了している、と言い切ってしまってもいい位じゃないでしょうか。Microsoftの野望ここに完成ってな感じで。

 事実上、Word/Excelが社内/社外文章の標準形式になってる企業なんて80%や90%、下手すりゃそれ以上にまで浸透してるんじゃないですかね?極端な話Word/Excel取り上げられたら業務が止まる。そんな所も少なくないのではないかと。

 ですので好き嫌いに関わらず「選択の余地なんか無い。周りがこればっかりだから使うしか無い」と渋々使い続けてるユーザもいるのではないかと思います。

 で、その逆に「好き好んで」Word/Excelを多様してる人ってのも、以前に比べたら随分増えてると思います。バージョン上がるにつれ機能も洗練されて使いやすくなりましたしね。今Excel2000を使ってる人にExcel95に戻れと言われてもおそらく強硬な反対に遭うでしょう。要はそれだけ「なんだかんだで使いやすい」と思ってる人も実はかなり多いのではないかと。

 でもな。ちょっと待ってくれ。私が今からしたいのは機能の使いやすい/使いにくいの話ではないんです。

 つー訳でまずはじめに、主張いっこ入れてみます。こんな感じ。

 

 

 「Word/Excelが原因で・・・・・

 

 

     ・・・・・プロジェクトが破綻することがある」

 

 へぇ〜。へぇ〜。へぇ〜。へぇ〜。へぇ〜。5へぇ。トリビアかよ>俺。

 でも、言っておきますけど私大真面目ですから。私の言うことが電波なのかそうでないのかは、以下読んで判断してくんろ。その上で電波呼ばわりなら仕方無しですが。弱気だな>俺。

★通常のドキュメント、プロジェクトのドキュメント

 世間一般では当たり前に使われているExcel/Wordが、なぜプロジェクトに関しては破綻要因になりえるのか。そのためにはまずこの2者における「ドキュメントの性質」の違いに目を向ける必要が出てきます。

 まずは通常(プロジェクト以外)でのドキュメントの流れを考えてみます。

「おーい山田君。明日会議で配布する資料もう出来た?」
「あ、はいできてます課長。メールしておきますんでチェックお願いします」
「お、ありがと。どれどれ・・・・。おーい山田君。3ページ目だけここ 間違ってるから直しておいて。それ終わったらもう部数印刷して構わないから。」
「あ、わかりました直しておきますー」

 こういったシチュエーションでドキュメントが作成される場合。まぁ別に配布資料じゃなくても、月次報告書でも経費清算書でも始末書でも辞表でもなんでもいいんですけど。いや最後のは良くないだろ俺。

 基本的に、業務とそれに伴うドキュメントの流れはこうなります。

一般的なドキュメントの流れ

 サイズでかくてごめん(笑)。

 基本的にドキュメントは展開者に配布され、会議が終了した時点で、基本的に作成された資料はそのライフサイクルを終えます。ここポイント。

 もちろん資料自体は会議後も保存はされますがあくまで保存されるだけです。その後の成果は議事録なり正式のレポートなりで姿形を変えて「別の成果物」へとクラスチェンジしていきます。元の資料はバインダーに挟まれ余生を過ごしていく訳で。 こういった流れを日々繰り返し、数多の資料を作る訳ですが、基本的なライフサイクルというのは一定しています。

 で、こういった用途に関してはWord/Excelは向いてます。多彩な表現力しかり、手抜きできるテンプレートしかり。印刷物(紙)の融和性しかり。

 ところが、これがソフトウェア開発のプロジェクトとなると話が全然違ってくる訳です。先程の図にちょっと書き加えてみましょうか。

プロジェクトにおけるドキュメントの流れ

 どうゆうことか。特に仕様書等の場合、一回作って一回読まれてハイ終わり。なんてこたぁまず100%ありえません。書いて読まれて、間違い直して再配布して、また別の人に見せて修正して・・・の繰り返し。少なくともプロジェクトが進行している限り、作成されたドキュメントは死なないんです。

 で、断言しておきます。こうゆう性質を持つドキュメントを、Word/Excelで扱うことが命取りになるパターンは多々存在します。これ、脅しでもなんでもありません。実際に私の周りでも起こった「無間地獄」です。

★具体的Excel/Wordデメリット

 という訳で、現時点で私が把握している、Excel/Wordを使うことによって起こりえるデメリット。ちょっと羅列してみたいと思います。

○紙?ファイル?マスターは?

 今更言うまでもなく、Word/Excelで作成されたドキュメントは単一、もしくは数個の「ファイル」によって保存されます。このファイルを基に印刷するもよし、メールするもよし、共有フォルダに置くもよし・・・と機敏に対応することができます。

 が。時にはこの機敏性が悲劇を生むことになります。以下の図をご参照。

分割の悲劇の図

 とあるドキュメントが展開され、共有フォルダ内に保存されました。「重要だから必ず見るように!」とお達しが入ります。マネージャーのAさんは展開の際にそれを印刷し、自分のバインダーにそれを挟んでおきました。一方、開発者のBさんとCさんはそれぞれ自分のマシンにファイルをコピーし参照しています。このファイルは顧客のDさんにも知らせる必要があったためAさんがDさんにメールしました。Dさんも同じようにそれを印刷しバインダーに挟みました。

 さて問題です。このドキュメントが修正されました。再配布する際に、彼らはどれだけの手間を必要とするでしょーか?

「え?そんなもんAさんが自分の印刷物差し替えてDさんに再メール、Dさんもそれ印刷して差し替えて、BさんとCさんは自分のファイルと差し替えるだけでしょ?」

 と思った方。正解です。ですがその後に、

「で?それが何か?」

 と思った方。不正解です。とっとと荷物まとめて田舎帰ってください。これが重大な欠陥となりえることに気付かないようじゃかなりヤバいです。

 このケースの問題点が共有ファイルのマスターはもちろんのこと、各人のコピーしたファイル、印刷物、それぞれがマスター=自分にとって正しいもの、となってしまうことにあることは言うまでもありません。

 極端な話、一回の変更が起こるたびに、共有ファイル=A印刷物=Bファイル=Cファイル=D印刷物、とこれらすべてをイコールで結ぶ作業が必要になってきます。それを誰が保証するか?各人で気をつけるしかないじゃないですかと。

 え?それ位のこと造作もないと?ホントにそうですか?更新頻度が1日2回とかになっても?ファイルの数が100になったら?人数が100人になったら?

 共有ファイル≠A印刷物≠Bファイル≠Cファイル≠D印刷物となるのは、意外とたやすいことなんですよ?

○どこが変更されたの?

 現在のプロジェクトの中で、頻繁に更新され、かつ複数人で共有されるドキュメント、というのを想像してみてください。ある人にはDBテーブル定義書というかもしれませんし、ある人には単体テスト仕様書かもしれません。プログラム指示書かもしれませんし障害レポートかもしれません。

 まぁ何であれ上で挙げた「プロジェクトある限りドキュメントは死なない」の原則がある以上、あるとあらゆる種類のドキュメントがプロジェクトを追い囲む、という状況は必然的に起こりえる訳で。

 ましてやテーブルのカラム名いっこ変えただけで、動くもんが動かなくなるなんてのも当たり前のように存在するのがこの世界。「いつ、何が変わったか」を押さえることが、非常に重要視される、はずです。プロジェクト管理手法かじった人であればまず聞いたことがあるであろう大原則でしょう。

 ですが、どうも実際の作業となるとこの部分が抜け落ちてしまうようでして。結果どこかしこで惨事が発生しています。

 大抵のプロジェクトでは、WordにせよExcelにせよ、大抵「変更履歴」なる個所が設けられ、いつ誰がどこを書き換えたかを記述するように、それこそ口を酸っぱくして何回も念押しされます。

 実はこの「変更履歴」をつけなければならないこと自体がWord/Excelの最大の弱点のひとつ、といっても過言ではありません。

 ご存知の通りWordもExcelも(というよりプレーンテキスト以外すべて)バイナリファイルです。したがってUNIXのdiffのようにコマンド一発で違いがわかる、なんて機能は基本的には用意されていません(*1)。

 したがって「変更履歴」に何を書いてくれたか示してくれないと、後から見てどこが変わったのかなんて判断ができないと。ですので変更者が逐一そこを書き換えなきゃいけないんですけど。この「手で書き加える」ってのが思いっきり罠なんです。

 だって手作業ですよ。ミスするに決まってるに決まってるじゃないですか。

 変更履歴自体には、

 このいずれの間違いも許されません。さもないとそれを見た他者が間違ってる記述を「合ってる」と思って頭の中にインプットしてしまうからです。繰り返し言います。カラム名が変わるだけで、バイト数が変わるだけで(いずれもドキュメント的には数文字の変更)、システムが全く動かなくなるのが当たり前なのがこの世界ですよ?いいんですか?こんな大事な作業を「手作業」なんかに任せてしまって。

(*1)で、実はこれを回避することもできます。VisualSourceSafeがその例。VSSはWordもExcelも解析してくれて、本当に違うところだけをdiff表示してくれます。これに何度救われたことか(笑)。しかし実際、私が練り歩いたプロジェクトの中で一部の開発者以外の人間がVSSを使った例にはお目にかかったことがありません。理由は「操作覚えられないから」「めんどくさいから」。上からVSS使用禁止令(ライセンス持ってるにも関わらず)が出たこともありますね。当然そのプロジェクトは潰れました。

★更にデメリット絨毯爆撃

 さて。さらに畳み掛けてみましょうか。

○結局どこにあるんだよ

 これに関しては以前本館の方でも書いたんですがここでも改めて。

 ファイルベースの管理をしようとした場合、どうしても「ファイル名による管理」及び「ディレクトリによる管理」という呪縛からは逃れることができません。

 したがって、ドキュメントルート(大抵はファイルサーバの共有フォルダ)には、

  • 外部仕様書
    • ホスト
    • 機能A
    • 機能B
    • 機能C
    • ・・・
    • サーバ
    • 機能A
    • 機能B
    • 機能C
    • ・・・
    • クライアント
    • 機能A
    • 機能B
    • 機能C
    • ・・・
  • 内部仕様書
    • ホスト
    • 機能A
    • 機能B
    • 機能C
    • ・・・
    • サーバ
    • 機能A
    • 機能B
    • 機能C
    • ・・・
    • クライアント
    • 機能A
    • 機能B
    • 機能C
    • ・・・
  • DB仕様書
  • 本DB
    • 生成規約
    • テーブル構成
    • 容量見積もり
  • 連帯DB
    • 生成規約
    • テーブル構成
    • 容量見積もり
  • 調査
    • 以下略
  • 進捗
    • 以下略
  • 以下略(延々と続く)

 途中までリアルに書こうとしたんですけどめんどくさいんで途中まで。場合によってはこれらのフォルダの下に更に「山田」「Suzuki」「20030801」「Backup_2」「新しいフォルダ」等がわなわなとゾンビの如くうごめいている状態になるのは目に見えています。

 それに加えてファイル名が加わりますから。こんな感じで。

 テーブル定義書101_○○マスタ.xls
 テーブル定義書102_○○マスタ.xls
 テーブル定義書103_○○マスタ.xls
 テーブル定義書104_○○マスタ.xls
 テーブル定義書105_○○マスタ.xls
 テーブル定義書111_○○管理.xls
 テーブル定義書112_○○管理.xls
 (以下延々とID単位に続く)

 俺の見たいファイルはどのディレクトリのどのファイルにあるんじゃボケー!やってられっかふざけんながっしゃーん!!あいなる訳で。

 さらには。プロジェクトの規模が大きくなればなるほど、こうゆうファイルの類はそりゃあもうネズミ講の如く加速的に増加します。大規模モノともなれば総ファイル数1000、2000は当たり前ですから。こうなっちゃうともはやOfficeについてくる検索ウィザードでさえ、何の役にも立ちません。検索に時間がかかりすぎるんです。

 しかし、深刻なのはそれだけではないです。大量のファイルをExcel/Wordで作ってしまったがために起こる悲劇はこっからが本格化します。

 皆さん胸に手を当てて考えてみてください。過去にこんなことやってませんか?

 キレイに見せるため、印刷するために誰でもやってるテクニックです。当然私もやってました。

 でもね。これをやられると、検索側としてはもうどうしようもなくなっちゃうんです。だってヒットさせるべき文字列が無いんですもん。手も足も出ません。

 こうなると結局は記憶を頼りに1枚1枚ファイル開いて目視捜索する以外、何も手がかりなんかありゃしないんですな。唯一の手がかりはファイル名とディレクトリ名のみ。それすらも所詮は人間のつけたもの。合ってるかどうかなんて、神に祈るしかありませぬ。

 こうやってできあがっていくのが、いわゆるアンチパターンの「文書化地獄」(*2)であることは言うまでも無い訳で・・・。本当にそんな状態で「管理している」「管理できている」と言えるのでしょうか?

(*2)「アンチパターン―ソフトウェア危篤患者の救出」より。実はこの本、それなりにまとまってるんですけど残念ながら万人にはお勧めできませぬ。訳がボロボロなんで。個人的にはなんでパターン名を日本語にわざわざ訳したのかなぁと。そのためにパターン名と一般形容詞が文中でごちゃごちゃになっちゃってるんですよね。読み抜くには日本語を読み解くパズル能力が必要です。もしくはいっそ原書読んだ方がいいかもしれません。私にその根性は無いが。

○成果とは別の満足感

 既に普段の倍以上の文章書いてるんですが、皆さんまだ耐えられてるでせうか。もうちょっとです頑張ってください。何を。

 で、この項に関しては直接的な害、という観点とはちょいと離れます。それでも切り離すという訳ではいきませんのでちょっと触れさせてくださいな。

 確かにWord/Excelは高性能です。いろんな表現できます。それは認めます。

 でもね。高性能なばかりに「必要以上に時間をかけてしまう」ということが起こりえませんか?テキストだけなら20分で終わるものを、あーだこーだと体裁いじくって1時間、とかよくやってませんか?

 そのドキュメントはなぜ作る必要があるんでしょう?作ったものをどうやって活用していくのでしょう?そんな最終目標も、WordやExcelとにらめっこしてる間に頭ン中から吹き飛んでしまうんですね。いわゆる目的と手段の逆転。

 これは理屈じゃなく感情なんですけど。やっぱりワープロやスプレッドシートの類って、「人を仕事している気にさせてしまう」みたく魔性的な性質があるような気がしています。実はその今作ってる書類は作ったところで誰も見ない、誰も参考にしないかもしれない。でも作ってる本人は一心不乱に入力と修正繰り返すことで妙な満足感に浸ってしまうというからくりは今でも健在のような気がするんです。実作業の進展とはまったく関係の無い充実感と疲労。これはプロジェクトにとって、はたしてプラスなんでしょうかね?

 間違いなくマイナスだと思うんですが。

 XPのプログラミング導入編の中に、こんな一節があります。

「結局のところ、何を記録しておくかはあなた自信が判断するよりほかにない。しかし、お願いだから、プロジェクトが火を噴いているのを横目に、のうのうとスプレッドシートを相手にしているようなマネジャにはならないでほしい。成功は人にある。人と仕事をしよう。」

 先生〜!右見ても左見ても、スプレッドシートの前で地蔵になってる人ばっかりです!誰も人のことなんか見ちゃいません!

★さてやっとまとめじゃ。

 あー長かった。書いてる方が疲れてます(笑)。

 という訳で、現時点思いつくだけのことをあーだこーだと連ねてみました。他にもあるかもしれませんけどまぁいいや。

 で、ここで終わらせてしまうと単なる原理主義者の遠吠えに終わってしまうので(違うとでもいうのか>俺)、最後にまとめ的に書いてみますが。最後の気力振り絞って。

 さて。ここで考えて頂きたいのですが、今までにえんやこらと4つ例示してみましたが。ひとつひとつならともかく、これらが同時進行で発生した場合の恐怖を貴方は感じることができますか?どこかしこでも当たり前のように発生してますけど。まっとうな方、もしくは過去に痛い目見た方はウンウンウンと頷いてくれるはずなんですが。

 現実問題言います。このデメリット自体、感覚で理解できない輩の方が、まだまだ多いです。経験上では、上のデメリット説明してWord/Excel使わないように説得しても、ヒステリックに断固拒否するであろう人が10人中8名は占めます。そしてこの8名の中にPL、顧客、その上のマネージャー等、要職につく人々はほぼ100%を占めてます。

 この人達にとってはまさに「すべてが釘に見えてる」んですよね。Excel/Wordが唯一使いこなせる金槌で、ドキュメントはすべて釘。唯一使いこなせるWord/Excelを取り上げるなんてもっての他、だから絶対にWord/Excel使え、と強制してくる馬鹿は一人や二人ではありません。

 この人たちをねじ伏せるのは並大抵のことではありませんよ。下手に力持ってますから。逆らえばクビが飛ぶのは下っ端側です。つーか俺も飛んだけどなぁわはははは。あかんやん。

 となれば策は1つしかなくて。Excel/Word以外の「金槌」を与えてやって、徐々に釘と見えるもの叩きまくりの状態から脱却させてやる。これしかないと思ってます。

 その道具が何になるのかは人それぞれ。通常のHTMLドキュメントかもしれませんし、Wikiかもしれません。ストーリーカード、付箋紙、ホワイトボード。他にも選択肢は山のようにあります。どれを選ぶのは貴方(というかプロジェクト)のセンス次第。

 ただ。そのどれを選ぶにせよ、一番最初に書いた「ドキュメントが持つライフサイクル」というのは常に頭の上に置いといて損はないと思うんです。

 こういった各要素も最終的にはサイクルの長短によって決まっていくところが大きいと思いますし。数多あるドキュメントの種類の中から「これはこっちに移せばよりラクそう」というものをピックアップして移行・・・というのを繰り返していくと。

 地味ですけどね。結局はこれ以外の解決策は存在しないような気がしています。現時点で既にウン百ウン千ものドキュメント抱えてる人にとっては気の遠くなるよな話ですし。

 でもね。結局はどこかしら手をつけないことには、永久にそれは目の前からは消えてなくならないってことなんですよ。部屋の片付けといっしょ。カオスと化した部屋を見たくないのであれば、マメに整理していくしかない。整理するためにはExcel/Wordだけでは用が足らないこともある。そうゆうことなんじゃないっすかね結局?

 つー訳で。いい加減金槌ブン回すのやめましょう。わてらはソフト作るためにこの仕事やってるんですから。

 以上、かつてドキュメントに押し潰された男より忠告でした。

 もうあんなのはゴメンだ。


新着順INDEX 分類別INDEX
Top