処方箋⑩
デスマーチの記録に見る運命の分かれ道
体験記にみるプロジェクトの闇プログラマはなにを学ぶべきか
デスマーチの記録に見る運命の分かれ道
| 山崎敏 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つの点を知っていれば、プログラマとしての快適な環境を得られるはずです。プログラマという開発者の立ち位置からは遠い項目に見えるかもしれませんが、自分の得意な技にばかり頼って問題を解決しようとすることは、部分最適化につながりやすいので注意が必要です。立場を超えて、よく見て、考えて、実行して、判断して、より良い人生を模索しましょう。 |
私の所は65万行です（欝
1年で、脱走ではなく”退却”者２名
(表向きは会社間の契約の揉め事という理由で)
やっと1/6程度は、機能から関数名や変数名がGrep掛けずに出てくる程度にはなりましたが