新潟県南魚沼郡塩沢町に上越国際スキー場という施設があります。
　取引先の親しい友人数人と私は、ある週末、そこでスノーボードを楽しんでいました。

　平和な、平和すぎるほど平和な、日常のヒトコマでした。
　午前中思い切り滑った後、ランチをとろうとロッジに立ち寄った時に、私の携帯電話が鳴りました。当時人気を博していたクラムシェル、いわゆる折りたたみ式の携帯電話で、スキー場など、電波がほとんど入らない場所ですからロッジに入るやいなや電話が鳴るというのは相当な異常事態です。おそらく朝からずっと呼び出しをかけていたのでしょう。

　恐る恐る電話に出ると、すごい剣幕で悲鳴にも似た叫び声を浴びせられました。

　「いますぐ帰ってきてください」

　「いま!?いまって、日曜日だぞ」

　「関係ありません。今、今すぐです。このままではプロジェクトが破綻します」

　「どうして?順調だったと言っていたじゃないか」

　「順調じゃなかったんです」

　「・・・・???意味がわからないんだけど」

　「とにかく戻ってきて!」

　電話の主は、私が管轄するプロジェクトの一つを任せていたプロジェクトマネージャでした。他業種から転職してきた非常に優秀な人物で、私より年長、18歳までアメリカで育った帰国子女なので日本語がときどき不自由なのはご愛嬌。私は彼女に全幅の信頼を置いていたので、よもやトラブルが起きるとは思いませんでした。しかも私はつい二日前に、「全て順調」という報告を彼女自身の口から聞いていたのです。

　しかたがないので私は取引先に非礼を詫びて、一足先に会社に戻ることにしました。

　私が戻ると、プロマネは言いました。

　「このままでは一週間後のリリースに間に合いません」
　

　「ちょっと待て。なんでそんなことになるんだ。単体試験は全て通過して、今日から結合試験の予定だっただろ」

　「それが・・・実は、単体試験は合格してなかったんです。というよりも単体試験そのものが間違った考え方で行われていたんです」

　当時、西暦2001年。テスト駆動開発が発表されたのは明けて2002年、日本語に翻訳されるのは2003年です。
　この頃のプログラマーは試験計画書に基づいた単体試験を自分で書かなければなりませんでした。

　単体試験の細かいルールがあまり定められておらず、さらに高度ではあるが複雑な社内ミドルウェアによるサーバーと携帯電話という非常に制約の多い環境でのプログラミング、当時の携帯電話は当時としてもあまりにも小さい、わずか10KBしかないメモリで、複雑な通信を行うプログラムを動かす必要がありました。これには小さなメモリにプログラムを詰め込む職人芸的な要素と、大規模な通信システムを安定して動かすという保守性と拡張性の優れた仕組みの両方が要求されます。

　プロジェクトの立て付けとしては、一度ベテランのプログラマーが完成させ、実稼働させているゲームサービス(専用アプリと専用サーバーのセット)を、クライアント企業からの依頼を受け、別のIP(インタラクチュアル・プロパティ。知的財産。この場合は既製のキャラクター)を載せてリファインするだけの、かなり簡単な部類の仕事でした。

　人気アニメシリーズのIPを受けた我々営業部隊は、会社のR&D部門にプログラマーを付けてくれるよう要請しました。すると配属されたのが、他業種の中堅企業から転職してきたアプリのプログラマーB氏と、大手電機メーカー系のシステムエンジニアから我々のようなベンチャーに転職してきた変わり種のK氏の二人でした。ふたりとも、転職してきて半年ほどサブ的な仕事をしたことがあるだけで、それぞれがアプリとサーバーのメインプログラマーとなる初めての案件でした。

　とはいえ、基本的にIPを転用するというのは、極端に言えば絵を差し替えて文言を変えるだけなので新人二人でも大丈夫だろう、という楽観的な予測がありました。会社的に新人とはいえ、彼らは他業種で十分な経験を積んでるはずで、優秀という触れ込みで紹介された人々です。毎週の定例でも「順調です」という報告が上がってきているし、万事問題ない・・・まだ24歳でプロデューサーとしても未熟だった私は、そんなふうに軽く考えてしまっていました。

　ところが現実はまるで違ったのです。
　サーバーはまるで調整できておらず、サーバーがおかしいのでアプリの動作もおかしくなっていることがわかりました。
　6ヶ月もかけて、これしかプログラムができていないというのは異常としか言いようのないことです。

　いろいろ調査した結果、大企業で育ったK氏は、「順調です」と答える以外の報告をする習慣がなかったということがわかりました。「順調です」以外では「少し苦しいですけど、なんとか頑張ります」とか、「ちょっとリファクタリングで時間を使いましたけど、今週挽回の予定です」とかです。

　要するに、実際にどのような作業を行ったのか詳しく報告する習慣がなかったのです。というのも、その大手電機メーカーには様々な分野の専門家が集まっていて、それぞれの担当作業が異なります。担当分野があまりに異なり、しかもマネジメントする人間は技術についてほとんどなにも知らないので、自然と「細かい技術的な話は自分にはわからないし、興味もないから、要するにうまくいきそうなのかそうでないのかだけ教えて」という雑なマネジメントになりがちなのです。

　人数が多い大企業のチームなら、それでも誰かが気づいてフォローするのですが、少人数のチームで誰もが前線に立たなければならない零細ベンチャーでは、誰かが問題に気づいてくれることを期待するよりもまず自分から問題を報告する習慣を要求されます。

　私が把握したのは、どうやら思ったよりも事態は深刻なようだ、ということでした。
　私はそれまで、担当したプロジェクトのカットオーバーを延期したことがないということが一つの誇りでした。どれだけ無茶苦茶なスケジュールでも帳尻をあわせてきたつもりです。しかし今回はさすがに難しいかもしれないと唇を噛みました。

　新人の能力の見積もりを誤り、チームの状況を詳しく把握してこなかった自分のミスです。
　また、プロマネの事務能力の高さに目を奪われ、全て丸投げして他の案件に時間を使っていたことも問題でした。しかし、今更泣き言を言っても仕方がありません。私はプロデューサーとしてプロジェクト全体を立て直す責任がありました。サラリーマンとして、というよりも、私個人のプライドの問題として、私の企画したプロジェクトを絶対にやり遂げたいと思っていました。

　残り時間は一週間です。
　休日出勤するとしても、次の週明けまでには完成していなければなりません。
　私は延期工作とプロジェクトの巻き直しを同時に行うことにしました。

　私はチームメンバーを集め、これから全員の時間を30分単位で24時間管理することを宣言しました。
　30分単位で全時間というのは、当然ながら睡眠時間も含みます。もはや通勤などしていては到底間に合わないことがわかっていたからです。

　そしてその場で専用のプロジェクト管理ツールを開発しました。
　誰が、どの仕事をやらなければならなくて、いつまでに、どのように解決するのか。どれが終わってなくて、どれが終わったのか、終わったことを誰がいつ確認したのか、それらを全て一元管理するためのツールです。当時はそういうツールを一切使わずに、せいぜいエクセルの表などで管理していたのです。

　ものの5分程度でツールは完成しました。
　今思えば、これが今、私が「瞬間プログラミング」と呼ぶ、必要な道具を必要になった時点で瞬間的に作り出す手法の源流だったかもしれません。

　エクセルの表と、私の作った管理ツールとの最大の違いは、心理的プレッシャーです。
　左側に残り時間が大きく表示され、右側に担当者の顔写真入りで残りタスクが表示されます。
　次のマイルストーンまでに誰がなにをしなければならないかが一目瞭然であり、誰が有能で誰が無能に見えるかもまた一目瞭然です。

　私は一人ひとりに「あとどんな作業が残っているのか、その作業には何分かかるのか」を30分単位で推定してもらい、私自身が「それにはそんなに時間は掛からない」とか、「それはそんなに早く終わらない」と判断し、見込み時間を修正します。それと平行して、私は休日の夜中でしたが、もとになるゲームを開発したチームメンバーを集め、動かないソースコードを一行一行レビューさせることにしました。
　

　進捗会議は一日に三回、朝、昼、晩と行い、それぞれが30分未満の時間で終わるように調整しました。
　ある人の作業が終わらないと次の作業に取りかかれない、という状況を回避するために作業順序を入れ替え、毎日最低6時間は眠れるように、メンバーのそれぞれが眠るタイミングと起きるタイミングも細かく指示しました。これはCPUの高速化手法の一種であるアウト・オブ・オーダー法と遅延分岐スロットを応用したものです。

　進捗会議では、「とりかかっていた作業は終わったのか?」「次にどんな作業にとりかかっているのか」YesかNoで聞き、実際には10分程度で終わるようになりました。

　一週間後にはほとんどの機能が完成し、動作するようになっていたのですが、それでも一週間という時間はデバッグを万全にするには不十分でした。クライアントの担当者との交渉の機会をいただき、あと一週間延期させて欲しいと依頼しました。

　「半年かけて完成できなかったものが、一週間伸ばせば完成するって信じろと言うんですか?」

　「そうです」

　「なら、いっそ一ヶ月延期するというのはどうでしょう」

　「いえ、一ヶ月もこのテンションは持ちません。あと一週間が限界です」

　気が付くと社内の半分近くのリソースをこのプロジェクトのために使っていて、チームメンバーだけでなく関わる人間が全員疲弊していました。私自身も過労で40度近い熱を出し、寒気に震えながら交渉のテーブルについていたのです。短い人生の中でもこれほど死を意識したことはありませんでした。

　チームメンバーに一週間延長したことを知らせると、皆一様に信じられない、という顔をしました。

　「終わりますか?」

　「終わらせる。きちんとした形で。思い出してみろ。一週間前、全く動作しない状況から大半のバグが直った所まで持ってこれただろ。ここまで来たと信じられるか、一週間前だったら」

　「まあたしかに・・・」

　「今はほとんど完成してる。しかしネットワークサービスはリリースしてからが戦争だ。デバッグが不十分なままリリースすれば、さらなる混乱を招くだろう。だから残り一週間で徹底的にバグ出しをして、完璧な状態にするんだ」

　それから一週間。今度はデバッグが中心なので、まず丸一日プログラマー全員を家に帰し、休ませました。
　その間に残った人間、非プログラマー人員で徹底的にバグ出しをします。

　翌日はプログラマーの出勤と交代して非プログラマーを休ませ、プログラマーは前日徹底的に出されたバグを修正します。
　定例会議は一日二回に減らしました。

　その翌日からは通常通りの勤務に戻そうとしたのですが、やはり大きなバグが見つかり、結局は連日会社に泊まりこんでの作業になります。

　携帯電話のサービスは午前9時スタートだったので、午前9時には全員が会議室にいました。

　もう未完了を意味する赤いタスクは全てなくなり、作業完了およびデバッグ確認完了を意味する青のタスクばかりになりました。
　こうして、二週間に渡る死闘が終わり、サービスは無事リリースされました。

　私はサラリーマン時代、さまざまなサービスの開発に携わってきたのですが、このサービスは運営開始後のトラブルが最も少ないものになりました。

　徹底的にデバッグするということの有難味を改めて噛み締めた瞬間でした。
　アプリ開発を担当したB氏は後にニコニコ動画の開発を担当し、プロマネを担当した女性はその後もプロマネとして大きく生長し、最盛期には同時に8つものプロジェクトをマネージメントするスーパーマネージャになりました。

　この時の経験が、昨年上梓した「文系でも知っておきたいプログラミングとプログラマーのこと」のもとになっています。

　また、今回の記事で使われている映像は、実際に当時の現場で撮影されたものです。

　とかく警戒しなければならないのは、プログラマーの「順調です」という言葉です。順調です、という言葉は、なにも言っていないのと同じです。
　

　次に気をつけなければならないのは、他の組織や他のチームで優秀であると言われていたからといって、自分のチームで優秀に働いてくれるとは限らないということです。

　それから15年、現在は弊社ではテスト駆動開発が導入されています。

　テスト駆動開発はプログラマーが相互監視しやすい環境で、あやふやな言葉ではなく、テストという短いプログラムで本当に必要なものがなんなのかということが確認できるようになっています。言葉で「順調です」というのではなく、テストを見ることでそのプログラマーがなにをしようとしているのか、どこまでできているのか把握しやすくなります。

　このやり方は、プログラマーからの進捗報告を一部ソースコードレベルにするということです。これはひとまず順調に機能しているように見えます。報告はすべてチャットで済ませ、会議時間は10分程度。

　実際にプログラマーが行った作業を見たければgithubを確認すれば作業進捗がわかります。最近ではテスト駆動開発から派生したビヘイビア駆動開発が注目されています。

　このように、開発手法は日々進歩しています。開発手法とは一種の管理手法です。

　プログラマーが経営を行うということは、こうした最先端の管理手法をいかに世間一般の組織に適用していくか、ということなのです。