がんばれ。私の本。この本を必要としている人のところへ届いてくれ。
【火事場プロジェクトの法則の最新記事】
2006年09月25日
Amazonランキング更新
Amazonランキングをちょっとだけ記録更新。現在、3711位。
がんばれ。私の本。この本を必要としている人のところへ届いてくれ。
がんばれ。私の本。この本を必要としている人のところへ届いてくれ。
2006年09月23日
「火事場プロジェクトの法則」その後
読者のみなさんからの感想が、ちらほら載りはじめました。みなさん、ご購入いただき、ありがとうございます。
まずは、ふじはらさんの日記「それでも明日はやってくる。」から
http://www.mars.dti.ne.jp/~hirok/diary/
はい、三年かけて、やっと形になりました。出版された後こうして振り返ってみると、題材が根深いだけあって、長かったというよりもむしろこのくらいかかっても仕方がない「必要な三年」だったと思えます。
そして「デスマの人は本を読む暇がない」に関しては、本に書いたとおりなのですが、それでも、デスマの中の人は読めなくても、中の人の家族とか、友達とか、隣の部署とか、周りの人が読めれば、間接的に中の人に私のメッセージが届くのではないかと。
本当ならば直接届くほうが効果的ではあると思うものの、状況がこれでは、周りの人に期待するしかないですね。どうか、デスマの中の人をご存知の方はこの本の存在を彼らに教えてあげください。この本が彼らにとって蜘蛛の糸になれれば幸いです。
「mymy-mycompany分室」から
http://mycom.jugem.jp/?day=20060923
「管理ごっこに付き合っている暇は無い」という意見に賛同します。それは、バードビュー的に無駄ですし、価値創造＝社会に対する貢献に直結していないし、そのままでは会社も個人も幸せに繋がらないと思うからです。
ただ、開発者も管理者も一蓮托生であることから、このことは早めに共感しておきたい点です。
また「理論と実践」の間にも「理想と現実」の間にも隙間があって、その隙間を反復し、高速に回すことが価値に繋がるというアジャイルの精神でもあるわけです。どちらかだけの努力は報われない努力になると言えます。報われる努力にするためにも価値観の共有は早いほうが良いと思います。
「capsctrldays」から
http://capsctrl.que.jp/kdmsnr/diary/20060917.html#p02
お金の話は、私も悩んでいる箇所です。
お金に関しては「売り切り」で考えるよりも「継続的な関係を築く」がキーワードになると思います。
まず、「売り切り」で言えることは「このシステムが出来上がると、顧客はどのくらい嬉しいのかを把握すること」が大切だと思うのです。顧客の立場から言えば「システムが出来ると１０００万の利益につながる」と確信がもてるのならば「７００万でも８００万でも出す」となるはずです。この顧客の利益がどのくらいになるのかを考えずに開発者のコストの話を押し付けては話が進まないでしょうし、デスマーチに突入するとも思うのです。ただ、きっちりと金額を見える化できるようなケースは少ないわけで、そうなると「試行錯誤するしかない」＝「継続的な関係を築く」でしょう。試行錯誤をするには、やはり反復開発をあてはめるのが適切だと思います。そして、コストは１イテレーションでいくらとなり、そのイテレーションの中でなにをするか、なにを入れるかは顧客との話し合いで決めるという流れが、現状ではベストであると思います。
＠IT > 情報マネジメント > NewsFlash > ブックガイド
「■今週のオススメ」から
http://www.atmarkit.co.jp/im/news/books/index.html
ここの紹介文がかなりよかったので、引用しちゃいます。（ご紹介、ありがとうございます＞ライターさま）
貴重なご意見や、ご感想をありがとうございます。
今後の活動にフィードバックさせていただきます。
まずは、ふじはらさんの日記「それでも明日はやってくる。」から
http://www.mars.dti.ne.jp/~hirok/diary/
TIPSに関してはさすが編集に３年かかってるだけあって、新旧織り交ぜてコンパクトにまとめきったなぁ、と評価します。本来ならばなぜこうゆうTIPSが存在するか、そのバックボーンも理解して欲しいのが本音だけど、このような本を読んでいくうちに「デスマーチにはこうすればよかったのか」「もっと早く読んでいれば」と何度も思った。しかし、デスマーチの現場に入ってしまうと、本を読んでいるひまはない。本はおろか、普通の生活はできなくなるためだ。(p.219)
この指摘の通りで、とてもじゃないけどそんな時間は捻出できないと（なにせ仕事以前に生活が破綻してる）。そんな戦火の下でこれらのTIPSが「蜘蛛の糸」的存在になってくれれば、本書の存在意義は充分に果たせるのではないでしょうかね。今日日戦場ではネットからも隔離されるのが当たり前の話ですし、これが本という形で読めるということに意義があるのでは。
はい、三年かけて、やっと形になりました。出版された後こうして振り返ってみると、題材が根深いだけあって、長かったというよりもむしろこのくらいかかっても仕方がない「必要な三年」だったと思えます。
そして「デスマの人は本を読む暇がない」に関しては、本に書いたとおりなのですが、それでも、デスマの中の人は読めなくても、中の人の家族とか、友達とか、隣の部署とか、周りの人が読めれば、間接的に中の人に私のメッセージが届くのではないかと。
本当ならば直接届くほうが効果的ではあると思うものの、状況がこれでは、周りの人に期待するしかないですね。どうか、デスマの中の人をご存知の方はこの本の存在を彼らに教えてあげください。この本が彼らにとって蜘蛛の糸になれれば幸いです。
「mymy-mycompany分室」から
http://mycom.jugem.jp/?day=20060923
そうそう、「それ以外は管理者ごっこ」を久々に思い出して、結局のところ現場で働いている開発者としては、管理者の管理者たるべき権威＝ごっこ、に関わっている暇はなく（むしろ迷惑）なわけで、そのごっこに付き合うコスト（時間／労力）は、いわば何らかの組織内でのゲーム（昇進競争とか）に関わる話であって、開発者が何かを生産すること、ドラッカー的に言えば「成果をあげること」には関与しないわけですが、それは、開発者の戦略としては、一種の手持ちのカードとして用意しておくほうが、ごっこに振り回されずに済む（先手を打つことができる）かなぁ、と思ったりします。
何を言っているのか、不明に見えますが、、、火事場プロが、素直に感じられるのは、前半の当たり前に思えるような「型」と後半の思うようには行かない「現実」＝混沌とがあって、これは、混沌（カオス）がある境界部分で型（反復）を持つことと対比して、境界においてどちらに倒れるかという思索＝変化への態度が、悪循環から脱出する術になるのかなぁ、と。ますます、わからないかも...。
たぶん、苦労は報われるように努力すべき、なんです。きっちりとした成果に繋げて自分に報いようという姿勢が大切です。
「管理ごっこに付き合っている暇は無い」という意見に賛同します。それは、バードビュー的に無駄ですし、価値創造＝社会に対する貢献に直結していないし、そのままでは会社も個人も幸せに繋がらないと思うからです。
ただ、開発者も管理者も一蓮托生であることから、このことは早めに共感しておきたい点です。
また「理論と実践」の間にも「理想と現実」の間にも隙間があって、その隙間を反復し、高速に回すことが価値に繋がるというアジャイルの精神でもあるわけです。どちらかだけの努力は報われない努力になると言えます。報われる努力にするためにも価値観の共有は早いほうが良いと思います。
「capsctrldays」から
http://capsctrl.que.jp/kdmsnr/diary/20060917.html#p02
金額の算出と交渉タイミングは合わせて考えたい（どーすればいい？）。
お金の話は、私も悩んでいる箇所です。
お金に関しては「売り切り」で考えるよりも「継続的な関係を築く」がキーワードになると思います。
まず、「売り切り」で言えることは「このシステムが出来上がると、顧客はどのくらい嬉しいのかを把握すること」が大切だと思うのです。顧客の立場から言えば「システムが出来ると１０００万の利益につながる」と確信がもてるのならば「７００万でも８００万でも出す」となるはずです。この顧客の利益がどのくらいになるのかを考えずに開発者のコストの話を押し付けては話が進まないでしょうし、デスマーチに突入するとも思うのです。ただ、きっちりと金額を見える化できるようなケースは少ないわけで、そうなると「試行錯誤するしかない」＝「継続的な関係を築く」でしょう。試行錯誤をするには、やはり反復開発をあてはめるのが適切だと思います。そして、コストは１イテレーションでいくらとなり、そのイテレーションの中でなにをするか、なにを入れるかは顧客との話し合いで決めるという流れが、現状ではベストであると思います。
＠IT > 情報マネジメント > NewsFlash > ブックガイド
「■今週のオススメ」から
http://www.atmarkit.co.jp/im/news/books/index.html
ここの紹介文がかなりよかったので、引用しちゃいます。（ご紹介、ありがとうございます＞ライターさま）
IT業界の現場では、残業、徹夜は当たり前という風潮がある。デスマーチと呼ばれる死ぬほど過酷な労働環境が、IT業界に限らず、一般企業のIT部門でも発症してきている。SEを14年経験した筆者が、その悩みや苦しみから解放されるための法則をまとめる。
火事場のプロジェクトでは、本質的なことが欠けていて、それらは「バードビュー」「コミュニケーション」「エモーション」「フィードバック」に分類される。前半は、それぞれについて、個人はどうか、会社はどうかをチェックし、体質を改善するための解決案を提示している。
後半は、デスマーチが起こる背景やそこから逃れる方法を紹介する。人海戦術によるコスト増大やコミュニケーションの難しさ、効率の悪化に気付かずにいるのがデスマーチの一因となるが、顧客との話し合いの強化やルールを変えることによりその状態から抜け出すことができる。また、仕事に対する考え方を変えることが、自分や周りの価値を高めることにつながると説く。
巻末の付録として、全体最適や人の能力を引き出すために役立つビジネス書をまとめる。いまの状況を打破したいSE向け。（ライター・生井俊）
貴重なご意見や、ご感想をありがとうございます。
今後の活動にフィードバックさせていただきます。
2006年09月20日
「火事場プロジェクトの法則」目次
はじめに
■■■本書の構成・使い方 ――
デスマーチ・チェックリスト
■■■第1部 火事場プロジェクトの○と×
■■B：バードビュー 全体指向／継続指向
■B1
【個人】顧客が本当に必要としているモノ（「ありがとう」と言ってもらえるモノ）がわかる
【組織】顧客が必要としているモノを探り出す仕組みがある
×：顧客の要望が曖昧
×：顧客の要求が大きすぎる
×：顧客からの仕様変更が多い
×：良い物は無条件に売れると信じている
○：複数のレベルの解決策を提案する
○：顧客にとっての良い物を考える
○：だれがどのような「ハッピー」を感じるのか考える
■B2
【個人】自分の「強み」をきちんと理解している
【組織】チームの「強み」をきちんと理解している
×：なんでもできる
×：最新の知識が強みだと思っている
○：自分／チームにできることを書き出してみる
○：地図を持つ／Must-Will-Canの図を描く
■B3
【個人】わかりやすさを優先している
【組織】ルールを減らす努力をしている
×：自分が理解できればいいと思っている
×：無駄なルールがある
○：わかりやすいコードを書く
○：無意味なルールをなくす
■B4
【個人】目の前にある作業に没頭せず、まわりの状況も把握している
【組織】部分的な効率よりも全体的な効率を優先している
×：全力疾走している
×：歯車になる
×：隣の人が何をしているのかよくわからない
○：最も弱い部分を効率化する
○：常に、より良い方法を探し続ける
○：すべての作業工程を理解する
○：クリティカルパスを知る
○：大切なことから実行する
コラム ウォーターフォールはすべての作業がクリティカルパス
■B5
【個人】作業項目ではなく、要件単位に仕事を分割している
【組織】人数とスキルから納期やコストを計算している
×：人材が足りないと思っている
×：人海戦術
×：人月計算で人数をわりだしている
○：並列に分割する
○：「人数×期間＝規模」で計算する
コラム：どんぶり勘定／人月計算
■B6
【個人】仕事だけを優先しない
【組織】コストとパフォーマンスの両立を目指している
×：仕事が一番大切だと思っている
×：コストを避ける
○：コストとパフォーマンスが両立する点を探す
■■C：コミュニケーション 共有指向
■C1
【個人】「こんにちは」「ありがとう」などの基本的なあいさつがきちんとできている
【組織】ルールで縛らずに、個人の誠実さやモラルを尊重している
×：あいさつと仕事は無関係だと思っている
○：きちんとあいさつする
○：気持ちを込める
■C2
【個人】いつでも相談できる相手がいる
【組織】気軽に話せる場がある
×：会議を開くまでの段取りが長い
×：雑談はムダだと考えている
○：雑談を活用する
○：喫茶室や喫煙室を有効に使う
○：スタンドアップミーティングをする
■C3
【個人】上司にいつでも気軽に話ができる
【組織】部下の意見を大切にしている
×：上意下達の一方通行
×：まちがったやり方を押し付ける
×：上司を敵だと思っている
○：話を聞く
〇：信用を大切にする
○：頼られる存在になる／頼れる人を探す
■C4
【個人】顧客の声を直接聞いている
【組織】開発だけでなく、いろいろな仕事を経験させている
×：言った！言わない！の水掛け論が多い
×：歩み寄ろうとしない
○：相手の要求を積極的に聞き出す
〇：自ら顧客にアポをとる
○：顧客の現場に足を運ぶ
〇：飲みに（食事に）行く
コラム 情報が正しく伝わらない／ノイズが多い
■C5
【個人】担当を超えて、アイディアを発信したり、練り上げることができる
【組織】チーム間、部門間で情報（意見やアイディア）がとおりやすい
×：部門間での勝ち負けを重視する
○：人の交流を加速する
■C6
【個人】メールばかりに頼らず、直接対話も大切にしている
【組織】情報を共有するための仕組みがある
×：黙々と、淡々と仕事をする
○：直接会って話し合う
○：ホワイトボードを使う
○：手書きで描く
○：大きな紙に描いて壁に張る
■■E：エモーション 人間指向
■E1
【個人】チームや組織のビジョンに共感できる（近くに目標となるようなあこがれの人物がいる）
【組織】ビジョンに対するチームの位置を把握できる
×：チームがバラバラ／どの方向に進んでいるのかわからない
○：ビジョンを共有する
○：マイルストーンを置く
■E2
【個人】やりがい、達成感、充実感（まわりからの期待や信頼）がある
【組織】地位や金銭以外の報酬（対価）に力を入れている
×：報酬のみを増やす
○：金銭以外の報酬に力を入れる
○：ほめる／認める
■E3
【個人】顧客の役に立っていると感じている
【組織】顧客の感情が全員に届くようになっている
×：何を作っているのかわからない／何のために仕事しているかわからない
○：作業に意味を持つ／意味や意義を「見える化」する
○：笑顔、感謝、喜びに触れる
■E4
【個人】上司や仲間の言葉に納得できる
【組織】「命令」より「共感」を優先している
×：人を物のように扱う
×：根性論
○：感情を大切にする
■E5
【個人】仕事量は適切だと感じている
【組織】チーム全員の疲弊度を把握する仕組みがある
×：いつもいそがしい／家に帰れない
×：残業が美徳になっている
×：割り込みが多い／兼業が多い
○：1つのプロジェクトに集中させる
○：ゆとりをとる／バッファをとる
○：感情を表してみる
■E6
【個人】仕事に誇りを持てている
【組織】人に誇れるチームである
×：不誠実／後ろめたさを感じる
○：誠実さを大切にする
○：やるべきことをきちんとやる
■■F：フィードバック 適応指向
■F1
【個人】顧客の声を改善に活かしている
【組織】顧客の声がスムーズに流れている（対応が早い）
×：顧客を敵だと思っている
×：クレームを受け付けない
○：プロトタイプを出す
○：アンケートをとる
○：反復開発をする（アジャイル開発を意識する）
コラム 永遠のベータ版と考える
■F2
【個人】失敗をすばやく正確に報告することができる
【組織】失敗を受け入れている
×：失敗を隠す／問題を隠す
×：失敗を恐れる／失敗を避ける
○：失敗を共有する
○：失敗を怒らない
■F3
【個人】問題を話せる人（解決できる人）がすぐ近くにいる
【組織】問題や失敗を大きくしないうちに見つけだし、すばやく修正し、検証できる
×：表面を取り繕う
○：根本原因を探る／なぜを5回繰り返す
○：全員の距離を近くする
○：顧客を巻き込む
■F4
【個人】新しい技術ややり方に積極的に挑戦している
【組織】変化やリスクを受け入れる仕組みがある（リスクに過剰に反応しない）
×：変化を避ける
○：フィードバックしながらリスクを最小限にする
○：ゆとりを持つ／安全域を持つ
○：単体テストをする／自動テストをする
○：デイリービルド／常に動くコードを維持する
■F5
【個人】現場の経験や勘を大切にしている
【組織】理論ばかりではなく実践や実験を重視している
×：現実を見ない／現状を知らない（特に上司が）
×：数字しか見ない／理論にこだわる／技術にこだわる
×：現場に権限がない／やらせない
○：やってみる／体感する
○：数字よりも意味や価値を見る
○：検証済み／実践済みの知識を重視する
○：権限を委譲する／委譲してもらう
■F6
【個人】積極的に知識や知恵を共有している
【組織】1つの作業を2人以上が理解している（作業のバックアップやフォローする体制ができている）
×：仕事を休めない／休むと全体の作業が止まる
○：レビューをする
○：ペアプログラミングをする
■■■第2部 デスマーチを斬る
■■1章 デスマーチはなぜ生まれるのか
一生、飢えない
■1-1 おかしいことを疑問に思わない
モノづくりが好き
人と関わらなくても仕事が終わる
ルールの意味がわからない
無駄なルール
作業の意味がわからない
だれも読まないドキュメント
顧客は何もわからない
テスト＝ハンコをもらう仕事
やり方を変えようとしない
コラム 家を建てる話
■1-2 こまったときの根性論、話の通じない上司
残業するのがあたりまえ
残業代 ＞ 基本給
常に全力疾走（スパート）
パニック状態でまわりが見えない
根性論による過度なプレッシャー
まわりの人が次々に辞めていく
過度なプレッシャーによる悪循環
いそがしいことより上司がストレス
コラム 問題上司には2つのタイプがいる
■1-3 技術力がすべて
変わるパラダイム・変わらない考え方
ひたすら技術を磨く
技術は見ても顧客は見ない
■1-4 見える数字が見えない問題を増やす
要求があいまい
人海戦術の罠
人が増えるコストを考慮しない
人がいても効率は上がらない
人数が10倍＝コミュニケーションの負荷は100倍
規模ではなく複雑度の問題が大きい
威張る上司
お金があってもデスマーチは防げない
■■2章 どうすればデスマーチを防げるのか
■2-1 現場に行けば楽になる
顧客と話してすべてを決める
顧客と自分でルールを決める
顧客と対立しない
顧客から本当の希望を引き出す
入力と出力は比例する
コラム コミュニケーションを隔てる3つの壁
■2-2 ルールを変えれば逃げられる
規模が大きすぎて全体を把握できない
仕様書を鵜呑みにしない
自分が動けばルールは変わる
意味あるルールに変えていく
シンプルにすればうまくいく
対立してはダメ
コラム 無意味な検収
■2-3 問題は根本から断ち切る
プロジェクトの途中で人を増やす
最悪の条件とルール
臭い物には蓋をする、ことなかれ主義
できることからやっていく
分割リリースでしのぎ切る
コラム 問題を増やす業界構造
■■3章 会社を辞める、そして見えてきたもの
■3-1 デスマーチから逃げるためには
スキルがあっても逃げられない
自分で仕事を取りに行く
仕事＝社会に価値を生み出すこと
働くだけでは価値にならない
雇われていると見えないもの
視点の変化はパラダイムの変化
自分1人じゃどうにもならない
スーパー火消しなどいない
■3-2 サラリーマン生活からの脱出
会社に気持ちを踏みにじられる
辞める不安と手にする自由
自分でお金を管理する
人のつながりで仕事をもらう
■3-3 技術だけでは見えないもの
お金の本質とは
「人」についての本を読む
技術書の限界？
技術書からビジネス書へ
求めなければ手に入らない
■3-4 人との出会いが価値を生む
従業員から投資家へ
価値に対して投資する
価値とは何か
自分の価値観と他人の価値観は違う
「人」を見ないと利益は出ない
価値を生むのは開発者ではない
顧客は価値を語れない
プロジェクトの価値とは
■■4章 1人の力を最大限に活かすには
■4-1 チーム（組織）はやはり必要
1人の限界
なぜ組織は価値を発揮できないのか
ムダを増やす合理主義
モチベーションを下げる管理者
臭いものに蓋をする成果主義
意味ない効率化につながる分業化／専門化
現場を萎縮させる変化への恐れ
■4-2 どうすれば人の力が発揮されるのか
人がすべての中心
人は意味を求めて動く
「意味」「つながり」「誠実さ」がモチベーションを高める
管理するのは「チームが進む意味」
■4-3 組織のために個人は何をすべきか
対立から共存へ
「自分だけ『ハッピー』」にはなれない
give and given
BCEF
ハンマーは捨てるな、磨き続けろ
お互いが価値を高め合うために
幸運は、努力し続けた人にのみ渡される
あとがき
2006年09月16日
「デスマーチ・チェックリスト」公開
「火事場プロジェクトの法則」の巻頭に載っている「デスマーチ・チェックリスト」をPDFにしました。
check-list.pdf
「火事場プロジェクトの法則」を読んだことの無い方でも（すでに購入された方でも）どなたでもチェックできます。ぜひ、チェックしてみてください↑。
（↓サンプル画像）
今のところ、配布に制限を設けるつもりはありませんので、印刷して周りの人に配っていただいてかまいません。
また、各自の診断結果（「B:1,C:2,E:0,F2」など）とご意見もお待ちしています。コメント欄までお願いします。
check-list.pdf
「火事場プロジェクトの法則」を読んだことの無い方でも（すでに購入された方でも）どなたでもチェックできます。ぜひ、チェックしてみてください↑。
（↓サンプル画像）
今のところ、配布に制限を設けるつもりはありませんので、印刷して周りの人に配っていただいてかまいません。
また、各自の診断結果（「B:1,C:2,E:0,F2」など）とご意見もお待ちしています。コメント欄までお願いします。
2006年08月29日
「[システム開発] 火事場プロジェクトの法則―どうすればデスマーチをなくせるか？」サポートページ
やまざきが個人的にサポートしているページ。末永く売れますように…
デスマーチの記録に見る運命の分かれ道
開発の現場 Vol.002 に寄稿した原稿を公開します。
処方箋⑩
デスマーチの記録に見る運命の分かれ道
体験記にみるプロジェクトの闇プログラマはなにを学ぶべきか
デスマーチの記録に見る運命の分かれ道
処方箋⑩
デスマーチの記録に見る運命の分かれ道
体験記にみるプロジェクトの闇プログラマはなにを学ぶべきか
デスマーチの記録に見る運命の分かれ道
| 山崎敏 YAMAZAKI Satoshi |
| ●体験記にみるプロジェクトの闇プログラマはなにを学ぶべきか |
| プロジェクトをデスマーチにしないために何をすればよいのか分かっていても、1開発者としてはどうにもならないということもあるでしょう。本稿では、インターネットで語られたある壮大なデスマーチの記録を題材に、自身も多くのデスマーチを体験してきた山崎氏が解説を試みます。貴重な記録を開発者のための「盾」として活かすために、何を学ぶべきか考えていきましょう。 |
| プログラマという職業もいろいろあります。はっきり言ってピンキリです。働き甲斐があって無理なく仕事ができることもあれば、逃げ出したくなるようなひどい職場で働いている人もいます。 筆者もSE/プログラマとして多くのソフトウェア開発の現場に立ち会ってきましたが、開発者の仕事の質や内容は、ほとんど現場によって左右されると言ってもいいでしょう。今回の企画で解説する"軍曹が携帯電話開発の現状語る"は、そうした現場のうちでもかなり悪い（酷い）部類に入ります。しかし、その酷い現場の生の声を聞くことでこの業界の怖さを知るのは開発者にとっての自己防衛の盾となることでしょう。そして、反面教師として1歩でも前に進むことができたら……という想いでコメントさせていただきました。 なお本記事は、インターネットのまとめサイト「笑わないプログラマ」（http://s03.2log.net/home/programmer/）から本文を引用させていただきました（画面）注。 注 同サイトに掲載されている「軍曹」氏のコメントは今年の3月ごろから2ちゃんねる(http://www.2ch.net/)に投稿されたものです(引用部は、書体を変えてそのまま示しました)。 |
| ■いきなりデスマーチ最前線 |
| この長いレポートは、修羅場と化している開発現場にいきなり軍曹、上等兵、2人の2等兵のチームが送り込まれるところから始まります。 |
| 俺たちは、仕様も知らされぬまま横須賀に送り込まれた。 依頼主も孫請けらしく、正確な情報はかなり伝言ゲーム的にそれも口頭でしか伝えられない。 俺たちは、経験5年の軍曹1人と、経験2年の上等兵1人と、新人の2等兵3人の小隊だった。 現地に就くなり、現場は火を噴いた有様だった。 果てしないデバッグの果てに納期を過ぎてペナルティなのか要求項目が倍増したらしいのだ。 俺たちが派遣された場所の前任者（というより部隊）は全員ウツになって戦線離脱したらしい。 引継ぎも全く無いまま、というよりドキュメントらしい物も無かった。 |
| 凄い話です。「仕様を知らされない」「引継ぎが無い」「ドキュメントが無い」といった言葉にデスマーチの匂いが漂います。いや、匂うという程度の表現ではぬるすぎるでしょう。ずばり言います。このプロジェクトは、間違いなくデスマーチです。 そもそも、プロジェクトの途中であらたに人が投入されるということ自体、デスマーチである可能性が高いです。なぜなら、当初の予定から大幅に遅れていないかぎり、あらたに人が投入されることなどないからです。そして、戦線離脱者が出ている時点でこのプロジェクトはデスマーチ確定です。スケジュール（納期）の変更ができず、人を増やすことでしか立て直せないと考えるプロジェクトマネージャーの手駒の少なさや手際の悪さが、きな臭い匂いを漂わせています。 筆者の経験から言っても、できることならこのようなプロジェクトには足を踏み入れたくありません。しかし、匂いを嗅ぎとれない上司、もしくは匂いを嗅ごうとしない上司、過酷な労働環境を知っていても無視する上司、そんな上司の下で働くしか選択肢のない開発者は、そのような贅沢を言っていられないのが実情ではないでしょうか。 普通の開発者としては、デスマーチのような過酷な労働環境は避けたいと願っても、周りがそれを避けさせてくれないというのはよくある話なのです。 |
| ■■コードとの格闘 |
| ■10万行のスパゲッティコード |
| 俺たちが最初に与えられた任務は、10万行に及ぶスパゲッティコードを「ちゃんと動くものにする」事であったが、仕様は何度問い合わせても、問い合わせが上位会社へ何段も口頭で伝えられるうちに伝言が自然消滅してしまうようだ。 俺たちには真上の階層の会社の担当者しか知らされておらず、現地で他のチームの者と口を聞く事も一切許されていなかった。 俺たちと唯一連絡の取れる上位の担当者も、既に何日も寝ていないらしく、何かちょっと込み入った質問をすると容易にハングアップしてしまう。指示内容は1日平均5回は変更された。 |
| 「スパゲッティなコード」からはデスマーチの匂いが漂います。しかし、どちらかと言えばスパゲッティコードは大きな問題ではありません。なぜなら、大量のスパゲッティなコードはデスマーチの結果として作られるのであって、スパゲッティなコードがデスマーチを起こすわけではないからです。したがって、別の言い方をするなら、何日もがんばって徹夜をしてスパゲッティなコードと格闘し、スパゲッティでない、匂わないコードを書き上げたとしてもデスマーチはなくならないのです。「のれんに腕押し」といいますか、「ぬかに釘」といいますか、労力をかけてコードを整理しても、それとは裏腹に現状は改善しないわけです。 このようなデスマーチを回避するには、既存のスパゲッティなコードは顧客の要求を知るためのたたき台として利用するに留めて、すべて破棄するべきです。しかし、このレポートの例からも分かるように、コードが捨てられずに症状が悪化する ということがよくあるのです。 問題は、そんなスパゲッティなコードを捨てられないような組織の体質にあるのです。上からの命令に逆らえず、黙々とコードを書き直しても、モチベーションは下がるばかりです。モチベーションが下がるとミスも多くなり、品質も効率も悪化してしまうのです。 さらに、レポート内の「他のチームと話すことが許されていない」という言葉に筆者は驚きました。理解に苦しむところなのですが、おそらく「他のチームの邪魔をするな。自分の作業に専念しろ」といった意図なのでしょう。 システム開発において、コミュニケーションを遮断するという行為は自殺行為です。なぜなら、情報の伝達量がシステムの品質大きく影響を及ぼすからです。 このようなルールを作る組織は、システム開発（プログラミング）という仕事の本質を理解していないのかもしれません。コミュニケーションは仕事以前に、社会人として（大人として）必要なスキルであり、おおげさに表現するのなら「コミュニケーションが無ければその人は存在していないのと同じ」なわけです。 |
| ■スケジュールは固定 |
| さらにレポートには、スケジュールというデスマーチと切っても切れないファクターが登場します。 |
| ただ、スケジュールだけは何があっても遵守せよと通達された。しかし、仕様は何時まで経っても伝えられなかった。 ただ、目の前の大盛りスパゲッティはスケジュールにとても収まりそうになかった。 上に問い合わせてもまともな回答が帰ってくるのは1/10程度の割合だし、問い合わせ件数が増えると回答率も著しく下がった。 |
| 仕様がコロコロ変わるプロジェクトほど、不必要なルールが多かったり、やたらに回り道をさせられたり、無駄で無意味な作業が山盛りであったり、納期は変えられなかったり、権限が委譲されていない傾向があります。 プロジェクトに参加している個人の能力の問題というよりも、プロジェクト全体を統括する組織の体質と言えます。このレポートの場合は、そもそも全体像が見えません。むしろ誰にも見えなかったのではないでしょうか。そもそも、把握しきれないくらい大きなプロジェクトを始めたことが、デスマーチの発端といえるでしょう。 デスマーチを回避するには、スケジュールそのものの進捗よりも、スケジュール（納期）に対する柔軟な対応ができるかどうかが鍵になると思います。このプロジェクトは完全に巻き込まれた状態ですが、スケジュールが変えられないという部分がなんと言っても大きな問題だと思います。 たとえば、みなさんが家を買うとしたら、納期はキッチリ守るが品質がボロボロの欠陥住宅と、納期が遅れるが品質は良い家のどちらを選びたいですか? ちなみに筆者は後者です。こう考えると「顧客は常に品質よりも納期を優先している」といいきれるでしょうか? 開発会側の「なにがなんでも黒字にしたい」といった過激なコスト意識や、無理矢理顧客にねじ込んできた案件であるためこれ以上無理が言えないといった「大人の事情」が末端の開発者を追い込むのかもしれません。どちらも顧客の価値（社会貢献）を考えると的を外している行動です。 |
| ■仕様を固定した方がよいのか |
| ちなみに、こういったケースの対応策として、仕様変更をなくすこと（仕様を確定させて変更させないこと）を求めることも多いのですが、その方向性はお薦めできません。なぜなら、一般的に仕様の変更とは顧客の価値を高める作業だからです。中にはネガティブな変更もありますが、仕様変更を受け入れないということは、顧客の意見を受け入れない、すなわち「顧客の感じる価値を高める努力は行わない」と公言することになるからです。開発とは、顧客の望むモノを具現化すること、そして価値を最大化することが主な目的なのですから、この原則を判断基準に用いて決断し、行動すべきです。 このようなケースでは、開発者は仕様変更を拒否せずに受け入れ、代わりにスケジュールの変更を要求すべきでしょう。今回のレポートではそれも受け入れられないという現場です。仕様が変わったのにスケジュール（作業量）が変わらないというのはそもそもおかしな話です。中にはスケジュールの変更を求めると、「おまえらは能無しか?」とか、「他のやつらと入れ替える」などと言い始める傲慢な上司もいます。そのような時は、素直に人の入れ替えに応じてデスマーチなプロジェクトから脱出しましょう。身の危険を感じる現場であればなおさらです。 今回のレポートもそうですが、スケジュール変更の代案として最も厄介なのは「スケジュールはそのままで人を増やす」という決断の場合です。人が増えても多くの場合、即戦力になりません。逆に既存の戦力を割かれ、コミュニケーションが薄くなり、現場はさらに混乱するのは必至です。 人月で作業量を計算する管理者は多いのですが、極端にたとえるなら、400mリレーを40人で走っても4人の時より10倍早くなる訳ではないのです。むしろバトンを落としてしまうリスクが増えるということを理解すべきなのですが、現場を知らない管理者ほどこの間違いを犯します。 納期の決定権は、多くの場合、顧客が持っているので、そういった意味からも顧客とのコミュニケーションを密にして、日ごろからの信頼関係の構築に労力をするべきといえます。 |
| ■変数名はval0→val1→val2 |
| 部隊はさらに、スパゲッティ化したコードにとりくみます。 |
| 仕方ないので、スパゲッティコードを解読してノートに機能を図示しながら理解を進めていくが、変数名もval0, val1, val2のように取って付けたようなものが大半を占め、何をする機能なのかさっぱり分からなかった。 担当する機能の最上位関数を見つけるのに1週間かかった。その時はS上等兵が歓喜の叫び声を上げたものだ。 ノートは1日で平均2冊が消費された。準備してきた物が10冊だったから6日目の朝に売店に買いに行った。 やはり、仕様書にはfunc001, func002のような名前の関数は初版から存在していなかったようだ。変数に至っては、グローバル変数のあまりの多さに、その規模を掴むので精一杯だった。 他のチームの顔色を窺うと、今回の仕様変更はミドルウェアとアプリを根底から揺さぶるドラスティックなものであったらしい。 俺たちはこの時にスパゲッティを廃棄する決断をすべきだったのかもしれない。それを上位の担当者にきつく禁止されていたとはいえ、その決断を見送ったのが俺たちの地獄の始まりだった。 |
| ソースコードの可読性はプログラマにとって大切なポイントです。コーディングとは知的生産活動であるため、なによりもシンプルでわかりやすく読みやすいコードを維持することが、生産活動を高めることに繋がります。 「急がば回れ」といったことわざではないですが、急いで何度も通る道ほど、きちんと舗装され、区画が整備されていることが、全体の効率を高めるのです。 現場のプログラマは、仕様変更が頻繁に行われたり、開発を無理やりに急がされたりすることで、「func001」のような安易な関数名を付けてしまうのですが、この小さな流れが、全体の流れをさらに悪い大きな流れへと変えてしまいます。 「ブロークンウィンドウ理論」という言葉を聞いたことがあるでしょうか。これは、あるビルに割れた窓が1枚でもあると、数日後にはそのビルのすべての窓が割られてしまい、数ヶ月後にはあたり一帯がスラム化してしまうという小さな点をきっかけにして大きな変化を及ぼしてしまうという話です。そういった混沌（無秩序）へのきっかけを放置しないことが大切なのです。この「ブロークンウィンドウ理論」は、ソースコードにも当てはまります。コードの中に美しくない部分があると、そのコード全体の価値が下がり、時間と共に崩壊に向かうからです。 コードの品質を保つには、すべてをキレイに保つこと（プログラマの美的感覚に左右される話ですが……）が大切なポイントになります。 |
| ■■伝言ゲーム |
| ■無駄な会議 |
| その後部隊はレビューに出席することになります。大きなプロジェクトでは会議も必然的に大きくなります。大勢の人間が1つの会議室に集まり、情報を共有しようとするわけですが、実はあまり効果がありません。 |
| ようやく関数群の体系が掴めてきた（大半がfunc001,func002のような命名）ところで、俺たちは仕様書変更レビューに呼ばれた。 質問は上位会社の担当者を通じて口頭で伝えるしか手段が無く、延々と14時間に及ぶレビューでは俺たちに発言権は無かった。 |
| 大きな会議室で発言しているのはたった1人なので、人数の割に流れる情報量は少なく一方的になります。情報の共有は掲示板やスタンドアップミーティングなどの他の手段を使い、会議はアイデアを練る場として限定すべきでしょう。 |
| ■コードへの影響 |
| 派遣から2週間後、俺たちは本部に援軍と再見積もりの要請を連絡した。しかし、「依頼元との連絡が極めて難しい状況なので、今はまだガマンしてくれ」の一点張りだった。 2等兵たちは祭りの意味も変わらずに闘志を燃やして興奮している。 3週間目には、上位会社のSE達数人が集まって、深刻そうな顔をしていた。隣のチームがまた一つ潰れたらしい。 状況を聞こうと上位SEに近付くと、厚さ3センチに及ぶ「バグ報告書」を抱えて走り去っていくところだった。 「お願いします。ソースを1から作らせてください」 「駄目だ。今あるものを最小限の変更で動くようにするのだ。」 「無茶です !」 「分かってくれ。他のチームとのインターフェイスをこれ以上変更できないんだ」 俺と上位担当者とのやりとりを、配下の上等兵達が心配そうに見つめていた。 インターフェイスとは、最上位関数のインターフェイスだけではないのだ。 スパゲッティの中には多くのグローバル変数が操作されている。他のチームも度重なる仕様変更の末に、当初は整然としていたソースが俺たちの請けた物と同じようにスパゲッティ化しているという話だった。 |
| このプロジェクトでは、組織が大きくなってしまい、他のチームとの連携が取れなくなっています。「スパゲッティなコード」を捨てられないのは、むしろこの組織が大きくなってしまったことが原因なのでしょう。 このレポートでは、開発者も管理者も、組織という情報の流れに縛られていると感じます。組織の中のひと全員が、組織の階層図に従った情報の流れを期待しすぎているということです。 命令系統は、組織の階層に従うべきかもしれませんが（筆者はそれもどうかとは思いますが…）少なくとも情報の流れはもっと柔軟に最適化すべきでしょう。このレポートでは否定されているようですが、隣のチームの開発者やプログラマといった担当のレベルでのコミュニケーションを活発にするべきで、顧客などとも直接会って話し合う機会をもっと作るべきです。 「でも、それはマネージャーの仕事じゃないの?」と考える人もいるかもしれません。しかし、それでは自ら被害者になりに行くようなものです。出来る限りのことはやってみるべきでしょう。生物は環境に合わせて進化して（淘汰されて）来ました。しかし、人間だけが環境をも変える力を手に入れました。いま置かれている環境が不満であるのに、文句を言うだけで変えられない状況というのは、人間としての能力を無駄に放置しているといえるかもしれません。 |
| ■盲目そして孤立化 |
| 4週間目、俺は本部に残業代の申請をしたのだが、「もう少し待ってくれ」の一点張りだった。 上位担当者が倒れて1週間、俺たちはプロジェクトの中で盲目となった。 隣の新しいチーム（そこの後続部隊）では、連日ローカルな仕様変更が口頭で伝えられてくるようで、着任早々に祭りになっていた。 俺たちの担当ブロックも、何らかの仕様変更に晒されているはずだったが、連絡は全く来ない。 情報が途絶えてから2週間後、上位会社の担当者が突然替わった。 理由は一切知らされず、業務の引継ぎも無かったらしい。 新しい上位担当者は俺たちから情報を集めて仕事を始めた。 プログラム経験は全く無いそうで、技術的な話になると俺たちの言葉は通じなかった。 派遣開始から1ヵ月半が経ったが、業務上の連絡手段は相変わらず口頭と紙切れメモぐらいで、メールのアカウント申請も伝言ゲームの途上で自然消滅してしまったようだ。 上位会社の担当者は俺たちに構っている暇は無くなり、現場に来ているのかもしれないが、机にはカバンが置いてあるだけであった。 噂を立ち聞きすると、山のようなバグレポートの事務的処理に追われているようだった。 しかし、そのバグは俺たちの前任部隊の頃のもので、あれから仕様の大幅変更が入っているはずだった。 しかし、当時のバグレポートの事務処理を終えてからでないと俺たちの版数からのバグには対応できないとの事だった。 テスト要員チームでも、テスト仕様の変更頻度が彼らの業務処理能力を大きく上回り、前任部隊のバグによるバグレポートを尚も増殖しているところだった。 俺たちのコードはその後回しにされていた。 |
| 伝言ゲームが最悪のケースになると、このレポートのように孤立化に陥ります。無人島に置き去りにされたイメージです。こうなると時間や体力といった貴重なリソースを無駄に浪費するだけになります。しかも、スケジュールは固定されたままです。こんな状況で、いったいどうしろと言うのでしょうか。 開発規模が大きなプロジェクトは、どうしても組織の階層が深くなります。これは単純に「人が足りないので増やす」=「下請けに仕事を丸投げする」=「お金さえあれば労働力はいくらでも買うことができる」と管理者が考えているからです。大きなプロジェクトになるほど、階層が多くなり、デスマーチになりやすくなります。階層が多いと、伝言ゲームの距離が長くなり、伝達速度が遅くなり、ノイズが多くなるためです。最悪なケースでは、このレポートのように情報がなにも伝わらない状態になります。 理想を言えば、ステークホルダー（利害関係者）全員が1つの部屋に集まって仕事をするのが最良です。開発者も管理者も（できれば顧客からエンドユーザまで）すべての関係者が1つの部屋に集まり、壁にスケジュールを貼り、ホワイトボードの前で常に仕様の検討や進捗の修正をする。おそらく、そのような混沌としている現場ほど開発効率が高いはずです。逆に、各セクションが分割され、理路整然と並んだ机に、整理整頓された本棚、しんと静まり返った現場では開発効率は良くないと言えます。 |
| ■フィードバックがない |
| このレポートでは、さらに伝言ゲームの弊害が極限にまで達してきました。 |
| 数日後、上位会社の担当者が仕様書を持ってきた。 俺たちの知らない内に、版数がメジャーで5つも上がっていた。 まず、グローバル変数の大幅な見直しがあった。 共有データの仕様が大幅に変更されていた。 基本クラス内で使用する殆どのメンバ関数の中で、それを参照するように仕様が変わっていた。参照だけでなく、更新もするのだ。 しかし、最上位でオブジェクト間の依存関係を説明する個所が、初期バージョンで暫定的に抽象的にかかれていた時のままなので、今回の変更がどの程度の規模なのか分からなかった。 ただ、関数の一覧リストがまた一新されていた。 スケジュールは当初の予定のまま、固定されている。この件については、上位会社の担当者に何を問い合わせても無駄であった。 |
| 仕様変更が上意下達の一方通行で伝わっています。この状態はとても危険です。ウォーターフォール開発を強化した場合でも同じような一方的な強引さが問題になります。それは開発現場での問題がフィードバックされず、問題が大きくなり、増え続けてしまうからです。 ポイントは、仕様変更の権限が現場にないことです。なにをどう作るべきか。顧客がなにに価値を感じているのか。これらの貴重な情報は現場でしか感じ取れない大切な情報であるはずなのに、それを反映できない、形にできないのではシステムを作る意味がありません。なによりもフィードバックの道のない現場は、開発者やチームのモチベーションを極端に下げ、やる気を殺してしまうのです。 自動車業界に「後工程はお客さま」という言葉があります。筆者はこの言葉を、後工程は本当の顧客に近いため、顧客の価値を反映しやすい（見えやすい）という意味で解釈しています。後工程の意見がフィードバックされない現場にはデスマーチの匂いが漂います。 たとえば、みなさんが北海道への出張が決まったと考えてください。北海道へ出張に行ったことのない部長の書いたスケジュールと、何度も北海道へ出張に行っている後輩の書いたスケジュールのどちらに参考にしますか? 筆者は後輩のスケジュールに従います。なぜなら、実際に北海道に行ったことのある後輩のスケジュールにはフィードバック情報が含まれていると思うからです。 |
| ■無意味な作業 |
| 10万行に及んだスパゲッティは、俺たちの日夜の努力によって5万行にまで減った。 ここへ来て、コメントが普及してきた。そう、俺たちが手がけるまで、コメントなんていうものは全く無かったのだ。 この期に及んでも、下位の関数すら1からの作り直しは許されず、既存のコードを編集して直すようにとキツク言われていた。 修正個所では必ず元のコードをコメントアウトして残すように言われていたが、それを口頭で伝えられた頃にはスパゲッティのサイズが既に1/2に縮まっていた。俺はその事実を上位会社の担当者に伝えた。 数日後、伝言が口頭で伝わってきた。 俺たちが派遣されてきた当初のソースを、全てコメントアウトされた形でソース内に復元させろ、とのお達しだった。 「そんな、無茶ですよ。ソースの可読性が損なわれます !」 「至上命題だ。戻せ。コメント形式で。」 その一言のために、俺たちは丸々1週間、ソースの復元作業に追われた。もはや合理化した個所ですら可読性は原形すら残っていなかった。 全てをやり終えたとき、俺たちには疲れた笑いが溢れた。 久々に表情筋が動いたのか、非常にぎこちなくなっていた。 それでも上位会社とその更に上の者達よりはマシな顔だった。 彼らは全くの無表情、というか、強迫観念に駆られた顔であった。 |
| コメントが全く無いコードも問題ですが、コメントがあればいいのかというとそれも違います。コメントという情報が多くても、その情報がノイズになりかねないからです。適切な量のコメントを適切な場所に書くべきです。 しかし、なぜ元のコードを残す必要があるのか……。筆者も正確な理由は理解できませんが、おそらくバグなどの問題が発生した場合、元のコードに戻せるようにという考えなのでしょう。もう1つは、仕様書が無いため前任者の書いたソースコードを仕様書の変わりにして「仕様を読み取るため」と思われます。しかし筆者はこのような「コードの削除を禁止して、コメントアウトの形で残す」ことにメリットを感じません。可読性が悪くなり、全体の見通しが悪くなり、メンテナンスコストがどんどん上がり、最後には誰にも保守できなくなります。 それは、バグを作りこんでしまう危険性を高くするとともに、生産性や品質を低下させることになります。リファクタリングもまともにできなくなり、変数名ですらまともな名前に変えられなくなります。コードをコメントアウトするデメリットこそ感じるもののメリットは全く感じられません。 本来は、コードはすなおに削除してCVSなどの更新履歴管理ツールを使うべきでしょう。ツールが使えないような環境でも、頻繁にバックアップをとることで同じ効果を期待できます。というより、この程度のツールの使用権限が現場に与えられていないことが驚きです。いえ、たとえツールの使用が規則で禁止されていたとしても、規則を破ってでも身を守るためにツールを使うべきだったのかもしれません。もし筆者がその場にいたのなら、やはり既存のスパゲッティなコードはこっそり捨ててゼロから書き直すと思います。スパゲッティでないコードであっても、変数名やスコープの位置関係は可読性の上がるように書き換えます。もちろん、古いコードをコメントに残すことはしません。それでも、コメントで残せ!というワカランチンな上司がいるのなら、イヤイヤ全行をコメントアウトしてからファイルの前方にゼロからコードを書いていくくらいのことはしたいです。 |
| ■モチベーションの低下 |
| 最初に壊れたのは2等兵だった。 折角5万行程度にスッキリさせたソースに前のソースを復元させるヴァカげた作業のお陰でソースは一気に15万行程度になってしまった。 旧版をコメント行として全て復元させられたのは初めての経験だった。 その頃から2等兵の顔つきが怪しくなってきた。 そのソースを提出した翌日、コンパイル担当の者（朝から晩までコンパイル!）から伝言が伝わってきた。 「ダブルスラッシュなコメントは禁止だと伝わっていなかったのか?」 「は?」 丁度俺は仲間全員分の出張旅費の清算の為に群馬に戻っていた。 上等兵は別件で突っ込まれたドライバの改造作業にハマリ込み、コメント行の話は2等兵達に直接指示が行った。彼らはそれを全て「手作業」で対処した。 |
| 「ダブルスラッシュなコメントの禁止」も前と同じく理由が理解できません。一種のコーディング規約なのでしょうか。古いCコンパイラなどではダブルスラッシュのコメントは通らないという理由から、強引に定められた古いコーディング規約なのだと思われます。こんな無意味なコーディング規約があること…、そして、その規約を変更する、あるいは拒否する権限が現場に無いことが驚きです。 デスマーチになるプロジェクトの多くは、規則が少なくてデスマーチになるのではなく、規則が多いためにデスマーチになります。あれもこれも、やらなければならないことが多すぎてシンプルに価値を提供（創造）できなくなっているのです（そんな足の重いプロジェクトを見た管理者のすることは、さらにルールを増やすことだったりします）。 道路にルールという信号が多くなるほど渋滞が起こりやすくなります。本来の管理者の仕事とは「ルール」という信号を増やすことではなく、信号を減らしバイパスを作り、物事の流れをスムーズにすることだと思うのです。 |
| ■戦線離脱→2等兵2名逃亡 |
| 翌朝目が覚めてみると集合場所には上等兵しかおらず、仕方ないので残りのメンバとは現地で落ち合うことにした。 始業時間になっても2等兵の姿が見当たらなかった。 上等兵たちもワケが分からない顔をしていた。 俺は隙を見て廊下に出て、ホテルに電話を入れた。 「ヌルポさんとデスマさんは今朝早くにチェックアウトしておりますが」 ついに脱走兵が出た。脱走兵が出ると、依頼主からの厳しいペナルティが課せられる。 それからというもの、俺たちは脱走した2等兵の分まで作業ノルマをこなさなければならなかった。 翌日上司に電話すると、「辞めたよ。」の一言だけ聞かされて切られた。 「2人ともですか?」という俺の声が届く前に切られた。 折角ウィークリーマンションを確保できるように会社と交渉してきたというのに、脱走兵が出たという事で俺たちはそのままホテル暮らしを命じられた。 そういえば、上位会社の担当者も1週間ほど顔を見なくなってきた。 彼の同僚に聞くと「変ですね。夏休みは取っていなかったはずですが」と返ってきた。 |
| プロジェクトの途中で戦線を離脱されるのは、プロジェクトを管理する立場としてはとても困った行動です。しかし、個人的には、プロジェクトそのものが壊れている場合、身を守る方が大切だと思います。火を噴いているプロジェクトから逃げるのも辛いし、残るのも辛い。「仕事だから」「そういう契約だから」といって仕事を続けて体を壊してしまったら何にもできません。あえて言いますが、戦線を離脱することが正しい判断であると言えるかもしれません。 人は、作業量の多さには耐えられますが、無意味な作業には耐えられません。モチベーションが維持できないのです。穴を掘って埋め戻すような……そして、その苦労を誰にも認められないような作業を嫌います。どんな作業であっても、そこに意味を感じ取りたいのです。その作業の意味は、顧客からの感謝の声からしか得られないのです。 顧客の声の届かない場所での作業は、意味の見えない作業になりがちです。そういった場所を少なくし、作業者に意味を感じてもらい、モチベーションを上げて、製品の品質も効率も上げ、顧客に満足してもうわけです。この流れの源泉はやはり「顧客の声」なのです。 開発プロセスの1つであるXP (eXtreme Programing)には「オンサイトカスタマー」という考え方があります。開発現場に顧客を招き、顧客と一緒に開発を進めるというものです。顧客にとっても開発の進捗が見えたり、頻繁に情報の交換ができたり、仕様の変更や確認が迅速にできるといったメリットがありますが、開発者にとっても顧客の価値が見えやすく、そして、顧客が喜ぶ声が直接聞こえるというメリットがあるのです。 |
| ■人は感情で動くもの |
| 次に出張旅費の清算に戻った時には、ガラクタ置き場にされていた俺の机の引き出しに何やら包み物があった。 「?」 俺は警戒しながら封を開けてみた。 中にはワイヤレス光学マウスが1個入っていた。 手紙もあった。 「軍曹殿。この度は戦線離脱の非礼を申し訳ありませんでした。自分にはあの地獄は耐えられませんでした。ただ、軍曹殿には本当にお世話になりました。いつも僕たちを人間扱いしてくれたのは 軍曹殿だけでした。これはほんの気持ちです。軍曹殿は現場でいつも朝一番にマウスの動きが 渋いって愚痴をこぼしていたので」 2等兵の1人は、夏の寸志の全額を使って俺にマウスをプレゼントしてくれた。 俺はガラクタ置き場の机の前で、暫くフリーズしていた。 |
| 人は報酬（お金）や地位や名誉のためであれば動くし、大きな罰や屈辱を与えることでコントロールできる……と考える人は多くいます。しかし、それは誤りであることに早く気がついてほしいです。なぜなら、人は感情で動くのであって、理論や理屈では動かないのです。もちろん、理論的に考えて行動する人もいるでしょう。「お金がもらえるから我慢しよう」とか「この地位（椅子）から離れるのが怖くて動けない」とか、感情を殺してでも行動をしようとします。しかし、それは大変なストレスであり、自分の感情を無視しつづけると最後には心が折れてしまいます。 我慢強くない普通の人は、心が折れる前に、自分の感情を爆発させて「やってられるか ! 」「ふざけんな ! 」と戦線を離脱していくわけですが、逆に、普通の人より我慢強い人は、心が折れるまで我慢してしまいます。心が折れてしまうと仕事どころか、人生まで……ときには周りの家族や友人なども巻き込んでしまいますので、割に合わない不幸な結末になってしまいます。 デスマーチに遭遇した場合、我慢強くない普通の人のほうが被害は少ないのかもしれません。筆者は、おかしなプロジェクトに対しては「それはおかしい！」と感情を爆発させるほうがひととして健全だと思うのです。 |
| ■■プロジェクトは混沌へ |
| ■人海戦術 |
| 事態を打開する為に、緊急会議が開かれた。 テスト要員を一気に5倍に増やして、人海戦術によるデバッグが賢明だとトップが判断した。 トップって社長ではないのだが、俺の会社の上位の上位の・・・に位置する本部長なので、とっても偉い。 俺たちの身分から見たら、与党の政治家並かもしれない。 しかし俺たち兵士には選挙権すらないのだ。 なぜなら、選挙の日は必ずデスマ生活を送っているからだ。 そんな衆議院議員並みの政治力を持った本部長（以下、少将と呼ぶ）が決めた方針なので誰も逆らえなかった。 すぐにも近隣の都市から派遣社員の吸い上げに入った。 派遣会社も今までに無い大盛況なので、経験の有無を問わずにフリーターまで含めて確保に走った。 すぐにも現場は雑兵で溢れ返った。 開発現場では猫の手も借りたい状況なので、面接中もヘッドフォンステレオとサングラスを外さないスキンヘッド野郎ですら雇われた。 |
| あまりにもシステムの品質が悪い場合、「テストの量が足りないために品質が悪い」と判断する管理者が多くいます。しかし、システムの品質とテストの量はあまり関係がありません。なぜなら、品質の低下は開発者のモチベーションの低下やコミュニケーションやフィードバックの不全が主な原因であり、これらはテストを増やしたところで回避できないからです。 プロジェクトが混沌とした状態だから品質が落ちているのであって、人が足りなくて（能力が足りなくて）品質が落ちているのではない、というところを確認しておきたいです。 前と似たたとえですが、システム開発とはトンネルを掘るような作業なのです。トンネルの太さよりも多くの人がいても一度に掘り進むことはできません。人が飽和している状態なのに、スケジュールが遅れているからといって人を増やしても、現場は混乱するだけです。たくさん種を蒔いたからといって収穫が早くなるわけではないのです。 管理者なら、なにが開発のボトルネックになっているのかよく見るべきです。デスマーチになるプロジェクトは、スケジュールそのものが無謀であるケースが多いのです。人が足りなくて（能力が不足して）デスマーチになることはまずありません。 |
| ■ハード屋の祭り |
| ハード屋の方で珍しく祭りが起きていた。いや、普段から祭りのようなのだが俺たちが気付いていなかっただけだった。 何でも、ブレッドボードの作成&評価日程がスケジュールから押し出されて、一気にハードだけでも最終製品に仕上げてしまうとの事だった。 俺にはそれはどれほど大変な事なのか分からなかった。所詮はハードの話だ。 所詮はハード、俺たちには無関係。そう思っていられたのは、ES製品のASIC（プロセッサ内臓）に付いているはずのJTAG-ICE端子が基板設計ミスによってボード上に繋がっていなかったと知るまでの間だった。 「ICEが繋がらない?」 「端子にジャンパ線繋げれば出来るはずだろ?」 「それがBGA品なんです。ジャンパは不可能です。」 それを横で聞いている時には、意味が分からなかった。 |
| デスマーチにハマるのは、ソフトウェア開発という仕事だけではありません。ハードウェアの開発部隊であっても、スケジュールがタイトであれば、ソフトウェア開発と同じようにデスマーチになるわけです。おそらく、デスマーチにハマるのはシステム開発という職種が発症する特別な病気ではなく、規模が巨大で、スケジュールが短いプロジェクトでは、業界の職種を問わず発症する病気なのでしょう。 規模が巨大なため仕様が曖昧になり、何をすればいいのかわからなくなり、やってもやっても作業は減らず、報われず、疲労とストレスが溜まり、ひたすら体力勝負の全力疾走を強いられ、これが与えられた仕事だから、周りに迷惑をかけたくないから……といった正義感だけで体を支え、鞭を打って働く。これは、決して個人の能力の無さによって発症するのではなく、単純に「金さえあれば規模や短納期の問題は乗り越えられる」と考える一部の視野の狭い管理職の判断ミスから発症しているのです。 |
| ■上等兵倒れる |
| 日常化したデスマーチに俺の部下の上等兵が倒れてホテルで5日間寝込んだ事があったのだが、3日目に俺が 「食事を届ける為に夕方に一度外出させてください」 と申し出たところ、「許可を得る為の手続き業務に時間がかかるので、もう3日間待ってください」という返答を受けたのだ。 俺が上等兵の身を案じている姿が、彼らには奇妙に映ったらしい。 何故そのような余分な気を回すのかと、無表情な顔から棒読みの口調で質問されたものだ。 何かがおかしいのだが、俺達にはその雰囲気に対して発言する権利を与えられていなかった。 俺はたまりかねて夕方の定時後に抜け出し、上等兵の様子を見に行った。 ホテルの部屋の中で、彼はすっかり病人の色をしていた。 毎朝毎晩、俺は上等兵の様子を確認しに寄っていたのだが、いつも彼は「私は大丈夫です。ゴホッ、ゴフッ・・・、軍曹殿は気にせずに出勤してください」と言って、俺が病院に連れて行くのを拒んだ。 病院へ行く事になれば俺も欠勤しなければならないと気遣ってくれているのだ。 そう、彼は自分の会社ではそのまま欠勤処理されていたのだ。 職場を抜け出して食料と医薬品を調達してホテルに向かうと、上等兵は本当に虫の息に見えた。 バスルームには明らかに吐血したのを隠した跡があった。 「ぐ、軍曹殿。私の事は構わないで下さい。貴方の評価まで傷ついてしまう」 「何を言っているんだ!一緒に群馬に戻ろう」 俺はやせ細った上等兵の肩を抱きしめた。骨と皮じゃないか。 俺の中で何かが切れた。 抵抗する上等兵を上越新幹線に押し込め、俺たちはそのまま高崎へ向かった。 上等兵はそのまま緊急入院する事になった。結核に罹っていたのだ。 上等兵の姉が入院手続きを済ませ、俺に「コボルがこんな酷いことになっていたなんて、一体あなた方はどういう扱いをしてきたんですか!」と責め立てた。 返す言葉が無かった。 病室に戻ると上等兵が「軍曹殿、本当に申し訳ありません。私はもう大丈夫です。軍曹殿まで欠勤処理されると思うと私の胸が痛みます。どうか、横須賀にお戻りください。私の事は心配要りません」と、か弱い声で訴えてきた。 翌日、俺は涙を拭って会社に寄って事情を説明し、横須賀へ戻った。 職場放棄&無断欠勤の容疑を着せられ、俺は始末書を書かされた。 （省略） そんな俺は、8月に入って職場を逃亡した。 群馬に勝手に帰って、久しぶりに好きな登山に明け暮れた。 自分を取り戻していけそうな気がした。 そう、俺の中で何かがはじけたのだ。 もう2つ3つ好きな山を登ったら、会社に手続きをしに行こうと思っている。 携帯電話はうるさいので、1つ目の山の頂上から思い切り投げてしまった。 携帯もこんな空気の良いところに投げ捨てられて本望であった事だろう。 故郷の山の空気は、おいしい。ああ、生きていて良かったな、と思えた。 長らく読んで頂いて、有難う。 |
| 悲しい話です。プログラマという仕事、システム開発という仕事、IT業界のすべての仕事がこのような現場ではないと言いたいのですが、多かれ少なかれこのようなデスマーチな現場があることは事実です。 では、このようなデスマーチな現場に遭遇しないためにはどうしたらよいのか。それは、改善するか、逃亡するか、そのプロジェクトを見て決めるべきでしょう。できれば逃亡するというネガティブな行動は取りたくないのですが、仕事よりも自分の体や人生のほうが大切ですから、逃げるのも勇気と考えるべきかもしれません。 では、どのようなプロジェクトが危険なのか。それを見分けるために、筆者は4つのポイントを挙げたいと思います。 1. 関わる全員が（特に権限を多く持つ人が）プロジェクトの全体を見ようと努力しないこと 2. プロジェクトの根幹をわかりやすくシンプルにしようと努力しないこと 3. 人の増加によるコミュニケーションやフィードバックの不全を放置すること 4. 最後に最も重要な点として、コストを重視し、人の感情を無視し、人を機械の部品のように扱うこと 1は、根性論や全力疾走など、混乱していると、特に盲目になりがちです。盲目でなくても部分最適化をしてしまうことは多いため、常に全体を捉える努力をすることが大切です。どのような価値を顧客や社会に提供しているのか。そして、提供した対価をどのように使うべきなのか……考えなければならないことはとても多いです。 2は、規模が大きくなると、複雑で混沌となります。プロジェクトは、特に小さくシンプルにしようと努力しなければ、自然に混沌に向かうものです。シンプルさの維持が大切になります。 3は、情報の流れです。特に大きな組織になればなるほど一方通行になりやすく伝わりにくいものです。現場の状況や顧客の意見が取り込みやすい環境作りが大切です。 4は、人は理屈ではなく感情で動くということです。感情を無視してコストばかりを追いかけていると、組織そのものが組織である意味を失うことになります。価値を作るのも、価値を感じるのも人であり、人を無視して組織を作ることは無意味なのです。 この4つの点を知っていれば、プログラマとしての快適な環境を得られるはずです。プログラマという開発者の立ち位置からは遠い項目に見えるかもしれませんが、自分の得意な技にばかり頼って問題を解決しようとすることは、部分最適化につながりやすいので注意が必要です。立場を超えて、よく見て、考えて、実行して、判断して、より良い人生を模索しましょう。 |