デスマーチ認定調査報告書
(念のためおことわり)以下文章は事実関係を基に加筆・演出を加え再構成したフィクションです。よって記述内容に関して筆者は記述内容に関して一切の責任を負いません。あくまで「読み物」としてお楽しみください。まぁいつものことなんですけどね。つーか雑文書きがどうゆう人種なのか、今更言わずともわかってるよな?
先日より依頼された上記調査の件、以下結果となったことを報告する。尚、正式な調査結果に関しては詳細データも含めた上で後日改めて報告する。
なお、本レポートの存在に関しては理由の如何を問わず、第三者に渡らないよう、細心の注意を払うこと。本レポートを漏洩した結果、いかなる災難が貴方を襲おうとも、当方は関知しない。
以下、調査レポートを添付する。
依頼No.02197に関する調査結果(概要)
1.目的
某社(以下A社と表記)で現在新規開発中のプロジェクトは既に破綻状態に追い込まれているのか、それとも修復の見込みを持っているのかを見極める。プロジェクトに関わるマイナス要因を洗い出し、最終的に本プロジェクトがデスマーチと化しているか否かの判定を行なうことを本レポートの目的とする。
2.調査期間
2002/09/01〜2003/01/31(予定)
3.調査方法
本レポートの作成者(以下調査人と表記)が自らプロジェクトメンバーとして調査対象プロジェクトに潜入。実際にプロジェクト内での業務に当たる一方で文書調査(盗み見)、ヒアリング(盗み聞き、井戸端会議)を実施。現状と問題点を洗い出した。
4.前提条件
4−1.プロジェクト概要
本プロジェクトはA社向け基幹業務として新規開発されるもので、実開発はB社が元受を行い、それを更に下請けとしてC社が部分請負を行なっている。
プロジェクトの構成はいわゆる3層物(ホスト−サーバ−クライアント)と解釈していれば問題は無い(実際にはサーバ及びクライアントの構成は標準とは離れているのだが、技術的依存度が高いためここでは割愛)。
使用するメイン言語はホストがCOBOL、サーバ−クライアントがJava。その他にも複数の基幹インフラ向けソフトやサポート用各言語も使用する。
プロジェクトの規模があまりにも巨大なため、プロジェクトは「グループ」単位に分割され、プロジェクト参加者は事実上グループの中で各業務に従事する形を取っている。グループ数は現状把握している時点で12とのこと(増減している可能性あり)。この他に共通技術を提供するグループ、DBを一括管理するグループ、進捗管理を行なうグループなどが別途存在している。要は「それだけ規模が大きい」ということを把握して頂きたい。
4−2.グループメンバー概要
以下は調査人が直接関わったグループに限定して現状を述べる。
本グループに参加しているメンバーは以下の通り。
- M1(マネージャー:プロジェクト総括責任者)
所属会社:B社- P1〜4(プロジェクトマネージャー:各作業従事者のとりまとめ、ユーザ向け折衝)
所属会社:B社、C社- B01〜B22(ホスト側担当SEまたはPG)
所属会社:B社、C社- C01〜C13(サーバ/クライアント側担当SEまたはPG、調査人もここに所属)
所属会社:C社合計40人によって構成されている。今回はホスト側の方が規模が大きいということ、開発言語がCOBOLであることから、メンバーの平均年齢は約35才程度と、若干高めになっていることから、COBOL経験者を片っ端からかき集めたのではと推測できる。
4−3.進捗状況
調査人がプロジェクトに参加した時点で既に当初予定から推測2ヶ月−3ヶ月の遅れが生じている。現在懸命に遅れを取り戻そうとしているが、残念ながらその効果は上がっていないばかりか、破綻の度合いを更に強めているというのが実情である。
以上の点を踏まえた上で、現在プロジェクトにどんな弊害が存在しているかを明らかにしていく。
5.確認できた現象
本項は非常に多岐に渡るため、本レポートでは基本的に記述は発生している現象、それにともなう影響の2点に留め、さらに対象も深刻なものに絞る。
5−1.腐乱するドキュメント
本プロジェクト(全グループ共通)では、各種展開資料をすべて「EXCEL」「PowerPoint」、そして「紙」にて管理されている。正確に言うなら「管理していると思い込んでいる」。
参加時点での総ファイル数は既に1000を越え(総ページ数は既に把握不可能)、それらが整理とは名ばかりのフォルダに散りばめられているのが実情。かろうじてバックアップ体制はあるものの、履歴管理もないし一覧把握等はもはや夢のまた夢。しかも個人名でディレクトリを管理している個所もあり、「ブロック名¥山田¥外部仕様書¥○○機能」「ブロック名¥鈴木¥外部仕様書¥××機能」といったディレクトリ構成までもが存在するという、まさに腐乱と呼ぶにふさわしい有様。
こんな状態では、もはやユーザ/ベンダを問わず、全ドキュメントの概要を把握できる人間が一人もいないであろうということは容易に推測できる。
5−2.遅延する情報伝達
このようなドキュメントの散乱が、いくつもの影響を及ぼしている。
まず作業者が何かを知りたいと思ったとき、作業者は「ここにあるであろう」と推測できる場所から手当たり次第にEXCELファイルを開く/閉じるを繰り返す。この時点で既に相当時間のロスが生じる。またそれでも見つからなければ知ってる人に聞くしかない。その分聞かれる側にもロスが生じる。これが数十人規模で頻繁に起こり得るので必然的に把握している側の負担は想像以上に厳しいものになってしまう(他人にかまっているために自分の作業ができない)。
これらの面倒を見てやっと見つかったドキュメントはすぐさま印刷され、各個人によってストックされる。次に見たい時にまたディレクトリ探すことが億劫になってしまうことからの自衛手段なのであるが。これが該当ドキュメントが変更された場合などに、思い違い等の致命的ミスを引き起こしてしまう。ミスということがわかるならまだ救われた方で、間違ったものを正しいものと思い込んで実装してしまう危険性がかなりの確率で存在する。
5−3.紙至上主義、EXCEL至上主義
柔軟かつ正確な情報検索の為には
- ドキュメントの管理方法を見直す(文書管理/履歴管理ソフトの導入)
- ドキュメントフォーマットの変更(EXCELの破棄、HTML等の画面閲覧に適したフォーマットの採用)
が必要不可欠との判断から、フォーマットを変更できないかと打診を試みたことがある。しかし回答は、
- 納品の規約の中に「ドキュメントはEXCELで作成されていること」が明記されている
- 既に膨大な量のドキュメントを作成済であり、いまさら変換する労力は割けない
- ユーザはユーザでEXCEL文書を再利用したい。他のフォーマットでは余分な手間が生じる
- 紙として印刷できればドキュメントとしては成立しているので、今のやり方を代えることに意義があるとは思えない
- このやり方に慣れてしまった
これらの理由でことごとく却下されてしまったという経緯がある。完璧な却下で、議論の余地すら与えられなかった。結局このやり方がずるずると引きずられ紙・EXCEL以外を排除してしまうことになってしまったのは遺憾の極みである。このことが5−1.及び5−2.に対しても更なる悪影響を与えてしまった事実は否定できない。
5−4.変更できない運営方針
ヒアリング(盗み聞き)を行なった限りでは、「一度決めてしまったものは変えられない」という諦めに似た空気が既に蔓延しているようだ。状況を打開するはずの各個人のモチベーションが、既にマイナスにまで突入している有様を如実に表している。
技術的要因等で変更をユーザ(A社担当)に申し出る。ユーザは「一度決めたことじゃないか、これでやってもらわなきゃ困る」と突っぱねる。担当者はベソをかきながら七転八倒する。この繰り返しが「どうせ言ってもムダ」という感情を芽生えさせている。
無論ユーザから見ればすべてを却下しているという訳ではない。実際、提案・協議の結果取り消されたケースも存在している。が、心理的には1の失敗によって5の成功も帳消しになってしまうようなダメージを提案側が受けてしまう、というところにそもそもの問題がある。
本来ならば対等であるはずのユーザ/ベンダ間の力の均衡が崩れ落ちている。これではユーザの要求に対してベンダが技術的に可能/妥当か判定するという、システム開発に不可欠なジャッジが機能するとは到底思えない。
5−5.「もったいない」の貧乏根性
前出5−4.に関連してもうひとつ。一度取り決めたことを覆すことに恐れを感じてしまう理由のひとつとして、どうも「せっかく手に入れたものを手放すなんて」という心理が働いているような空気がある。
要は「せっかくこの機能入れたのに外すなんて」「せっかくこのスピードで出てくれるって言ってくれたのに」という心理だ。気持ちはわかるが、一度ここにこだわりを持ってしまうことで、実現可否の判断でさえもが意味をなさない状態に追い込まれている。
ドキュメントに関しても同様のことが言える。「せっかくこれだけ作ったのに」。たとえそれがゴミの山であっても、作ったということに意義が見出される。そのため「作ったけど見られないドキュメント」が蓄積されていってしまう。
5−6.作業環境
ここで作業者個々にかかる負担の方にも目を向けてみる。
まず指摘しておかなければならないのが通勤時間の長さ。作業場所が名古屋市から電車で約1時間半かかる場所に存在しているため、自宅→名古屋→作業場所までのトータルで2時間半〜3時間かけて通勤している作業者が無視できない割合を占める。独身の者は会社から近い範囲(通勤1時間圏内)に引っ越す等の対策も可能だが、家庭持ちはそうはいかない。ずるずると長距離通勤を強いることになってしまう。
また実作業環境そのものに関しても決していいとはいえない。人数が多い関係で一人あたりに割り当てられるスペースは通常縦1m×横1m(場所があるだけでも感謝して欲しいというのがユーザの弁明)。周囲の雑音も酷く、空気の循環も悪いため悪性の風邪が一年を通じて流行っている。お世辞にも快適な環境とは呼べない。実際、調査人はとある機会に「ここはブタ箱か?」と吐き捨てていたことを併記しておく。
先月(11月)に喫煙室にて聞き込み(雑談)を実施したところ、こうゆう環境を理由に「次回の契約を更新するつもりはない」と断言した開発担当者が既に3人に上った。潜在的なプロジェクト離脱候補者はもっと増えているであろう。
作業に適さない環境はプロジェクトにも確実に悪影響を及ぼしている。
5−7.個人が得られる情報量の限界
物理的にも精神的にも隔離された状況の中では、各作業者が積極的に新しい・正しい情報を得ようという気が失せていく、というのが特徴としてあるようだ。
たとえば書籍ひとつをとってみても、生活圏内に本屋そのものが無いため、技術書のひとつすら手に取れないというのが実情である。その上現在ではWebをはじめとするインターネット上の文書すら見ることができない(12月にA社により閲覧が禁じられ、Proxyが切断された)。
確かに短期的に見れば「今持ってる知識」だけで作り上げることも不可能では無いだろう。だが、長期的視点で見た場合、こうゆう情報からすら隔離された環境は、作業者の「知識停滞」を引き起こしかねない。
5−8.変化に弱い作業形態
ここらでこの章を締めるため、焦点をプロジェクトの本質として抱えている問題点に移したい。
現在プロジェクトでは総計40名が、ほぼフル稼働の状態で各種資料の作成や問題点の解消にあたっている。が、実質的にこのプロジェクトとしての生産価値はほぼ「何も産み出していない、時間をドブに捨てているだけ」と断言できる状態にある。
というのも、何か問題が出てきた場合、その度に何度も何度も後戻りを繰り返しているだけなのだ。その上、本来のスケジュールは遅らせることができない為、結果として欠陥にフタをするような、あやふやな作業が続いていく。
某メンバーがため息交じりにこう嘆いていた。
「なんで直すとわかりきってるゴミを作らなきゃならないんだ?」
この愚痴に対して対案が打てない限り、プロジェクトが好転する可能性は万に一つもない。
5−9.従来手法の限界
本プロジェクトは基本的に「ウォーターフォール型」の開発手法が取られている。要件を決め、外部仕様書を作り、プログラム仕様書に落とし込んだ上でコーディング・・・という、どこででも行われているはずの普遍的な形。
が、完全にこのやり方は破綻してしまった、というのが実際のところ。正確に言うなら「ウォーターフォール型にすらなってない」とでも言うべきだろう。したがってこの例だけを基にウォーターフォールを批判することはできない。
各作業者は既にプログラム仕様書を書き終え、場合によってはコーディングに移行しようとする者さえいる。が、実態は今をもって「要件定義すら固まったとは言い難い」というのが現状だ。ユーザの心変わりひとつで、また新たな炎が開発者を焼き尽くす。もはや現在の各作業者には、炎に耐えうる体力も、精神力も残っていないだろう。
要件定義がもし変わってしまえば、もちろん仕様書は修正しなければならない。内部設計書の詳細ドキュメントに至ってはゴミの山となりかねない。そんな危ない橋を渡ろうとして、案の定橋の下に転落してしまった・・・というのが愚直な感想ではないだろうか。
5−10.その他
本来であれば、他にも指摘しておきたい要因はそれこそ「掃いて捨てる」程存在している。それこそ、このプロジェクトの顛末だけで文庫本1冊の分量を書き切れる自信さえある。が、ここでは「直感的に判断できた」以上の項目に留めておきたい。
なお、本レポートにおいては以下文献が参考になったので、リストアップしておく。
- 「ピープルウェア 第2版」トム・デマルコ/ティモシー・リスター著 松原友夫/山浦恒央訳 日経BP社
- 「動かないコンピュータ〜情報システムに見る失敗の研究」日経コンピュータ編 日経BP社
- 「ソフトウェア職人気質」ピート・マクブリーン著 村上雅章訳 ピアソン・エデュケーション
- 「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」ケントベック著 長瀬嘉秀/飯塚麻理香/永田渉訳 ピアソン・エデュケーション
6.結論
簡潔に表現できる。
「本プロジェクトをデスマーチであると認定する。」
しかも残念ながら、更に過酷な結論を述べなければならない。
「現段階において、本プロジェクトをデスマーチから救済する手段は無い。」
誠に残念だが、こう述べざるを得ない。
7.将来予測
本プロジェクトは現在も当初予定厳守を目標として進行している。そのためには多少の人員/予算増加も厭わない姿勢を維持することになるだろう。実際に来年1月以降、更なる増員の噂も聞いている。
が、おそらくこれらの対策はすべて空振りに終わるであろう。
もし仮に「納期を現状から更に半年以上延期し、かつ、開発人員を半分以下に縮小した上でプロジェクトを一から再構築する」ということができれば、まだ可能性はあるかもしれないが・・・。
事態がここまで深刻化している以上、この場にこのまま留まることは身の危険を意味する。よって本レポートを持って調査活動を打ち切り、プロジェクト脱出作戦に移行する。脱出作戦成功後、潜伏に入ると同時に更なる詳しい調査結果をお伝えしたい。
脱出する自信はあるが、余談は許さない。どうか無事を祈っていて欲しい。
そして最後に。私が去りし後も残らざるを得ない、短い間ではあったが苦楽を共にしたプロジェクトの同士達の無事を、心からお祈りしたい。
病気で倒れて再起不能になりませんように。
こころが壊れませんように。
自殺しませんように。どうぞ、神の御加護があらんことを。