Digital Heroes: Guide to IT World

うわっ、プロジェクトってこんなに人がいるのか！ 若い頃、大規模システムプロジェクトの会議室に入った瞬間、そう思ったのを覚えています。 私はこれまでIT屋として、多くのシステム構築プロジェクトに関わってきました。 日本だけではありません。インド、中国、ポーランド。いまやITプロジェクトは完全にグローバルに広がっています。 大きなシステムになればなるほど、プロジェクトは巨大になります。 そしてその構造は、実はとても複雑な「多段の社会構造」になっています。     プロジェクトの裏側にある「多段構造」 システム開発の世界では、よくこんな言葉を聞きます。 「システムはシステムのプロが作る」 これは半分正解で、半分間違いです。 確かに設計やアーキテクチャは専門家が担います。 しかし、大きなシステム、大きなプロジェクトになればなるほど、最後は人海戦術になります。 テスト作業、データ確認、操作確認。 パソコンが触れればできる仕事は数多く存在します。 日本語ができなくても、パソコンは触れる。 言われた通りにテストはできる。 こうして世界中から人が集まり、プロジェクトはどんどん拡大していきます。 知識労働ではなく「人数ビジネス」 しかし、この構造にはもう一つの側面があります。 プロジェクトは、元請けから順番に費用が抜かれていきます。 そして末端のエンジニアに届く頃には、かなり安価なコストになっています。 つまり、評価されているのは知識ではなく「人数」です。 人を集めれば売上になる。 だから価格競争が起きる。 そして、縄張り争いが始まります。 プロジェクトの現場で起きること 当初考えていない作業が出てくると、 「それはうちの責任ではない」 簡単な作業が出てくると、 「それはうちがやる」 責任は押し付け合い、 作業は取り合いになる。 管理者たちは、その中で自分の領域を広げるために、 コミュニケーション、調整、そして飲み会に奔走します。 こうしてプロジェクトは進むのですが、 その裏では多くの人が疲弊しています。 鬱になる人もいる。 プロジェクトは遅延する。 そして最後には、責任の追及が始まる。 残念ながら、この構図は世界中であまり変わりません。 PMBOKでも解決できないこと もちろん...

巨大システムの裏側にある、小さな一歩の積み重ね うわっ、金融機関がJavaフレームワークに挑戦するのか!? そう思ったのが、そのプロジェクトの最初だった。 当時、私はある 大手金融機関のお客様 のプロジェクトに関わっていた。 その金融機関は、日本でも有数の巨大な企業体。社会への影響力も大きく、システムに障害が起きれば社会全体に影響が出る可能性すらある。 だからこそ、 基幹システムは依然としてCOBOLが中心 だった。 長年動き続けてきた、安定した仕組み。 金融の世界では、それは「守るべき資産」でもある。 しかし、同時にこういう声もあった。 「新しい技術にもチャレンジしていきたい」 そのプロジェクトは、 Javaのフレームワークを金融機関で適用する初めての試み だった。 とはいえ、金融機関である。 いきなり基幹システムに導入するわけにはいかない。 そこで出てきたのが、非常に興味深い考え方だった。 新しい技術は、まず影響の少ないところから使う。 それは、Webシステムなどの 周辺システム だった。 金融機関が考えた「安全なチャレンジ」 当時の金融システムでは、まだ 帳票文化が主流 だった。 帳票は公式記録。 そこに誤ったデータが出てしまうと、業務への影響は非常に大きい。 だからこそ、技術適用の順序にも工夫があった。 まずは 入力システムではなく表示システムから 。 理由は明確だった。 入力システムにバグがあり、誤ったデータが基幹データベースに登録されたら取り返しがつかない。 しかし、表示システムならどうか。 もし表示ロジックに問題があったとしても、データそのものが壊れるわけではない。 つまり 出力・表示 → 入力 → 基幹 という順序で、慎重に技術を適用していく。 さらに言えば、帳票に誤ったデータが出るより、 Web画面での表示の方が痛手は小さい 。 こうした議論を、金融機関の担当者と何度も重ねた。 その議論を聞きながら、私は思った。 「金融機関は新しいことに挑戦しない」 世の中では、そんなイメージがある。 しかし実際は、まったく違っていた。 「守る責任」があるからこその計画 金融機関の人たちは、決して挑戦を避けているわけではない。 むしろ逆だ。 社会を守る責任があるからこそ、計画的に挑戦...

うわっ、また夜中のローンチか！ 昔のプロジェクトルームでは、そんな声が当たり前のように聞こえていた。 私の経験上、 システムのローンチは夜に行われることが多い 。 それも、かなりの確率で。 なぜか。 理由はとてもシンプルだ。 次の日から使えるようにするため だ。 夜にローンチする理由 システムの変更は、できれば「区切りの良いタイミング」で行いたい。 たとえば、 ・夜中に切り替え ・翌日から新システム ・もしくは土日作業 ・月曜から新システム この形は、説明がとても楽だ。 「 月曜日からシステムが変わります 」 これだけで済む。 ユーザーにとっても分かりやすいし、 管理側も整理しやすい。 プロジェクトというのは、 技術よりも説明の方が難しいことが多い。 だからこそ、 区切りの良いローンチ が選ばれる。 金融システムはさらに特殊 特に顕著なのが 金融系システム だ。 金融の世界では、 平日の昼間はお金が動いている。 つまり、 平日昼間にシステムを止めるわけにはいかない。 その結果どうなるか。 作業は土日になる。 これが長年の常識だった。 さらに大きな変更になると、 GW（ゴールデンウィーク）作業 も珍しくない。 「GW中に変更作業を行い、 GW明けから新しいシステムになります」 金融プロジェクトでは、 この言葉を何度聞いたか分からない。 システム屋のGWは存在しない 私の若い頃、 システム屋にとってGWは特別な意味を持っていた。 休みではない。 むしろ 最大の作業タイミング だった。 システムローンチが控えている年は、 GWなんて存在しない。 プロジェクトルームに泊まり込み、 深夜の切り替えに備える。 そして夜中。 コマンドが打たれる。 ログが流れる。 沈黙。 「……よし、上がった」 その瞬間の空気は、 今でも忘れられない。 私は長い間、 システム屋ってそういうものだ と思っていた。 しかし時代は変わり始めた 最近、この常識は少しずつ変わってきている。 理由はいくつかある。 まず、 土日に人を集めるのが難しい。 働き方が変わったからだ。 さらに、 月曜日の高負荷タイミングで新システム というのは、 リスクが高いという考えも広が...

古びたプロジェクトルームにあった“最強の道具” うわっ、こんな部屋で巨大プロジェクトが回っているのか――そう思った瞬間があった。 当時、私は金融系のプロジェクトでお客様のシステムを支えていた。 場所は、新しいわけでも古いわけでもない、どこにでもあるオフィスビル。そのワンフロアを丸ごとプロジェクトルームとして借りていた。 実はこのフロア、長年にわたって日立のプロジェクトが使ってきた場所だった。 いわば、歴代プロジェクトの“戦場”のような空間だ。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       昭和の匂いが残るプロジェクトルーム 部屋に入ると、ふわっとタバコの匂いがする。 おそらく、昔はここで多くのエンジニアが夜通し働いていたのだろう。 机を見ると、片足が折れているものもある。 隣の机に寄りかかることで、なんとかバランスを保っている。 床を見ると、何度も開け閉めされた跡があり、ネットワークの配線が飛び出している。 インフラ工事を何度も繰り返した証拠だ。 そんな古びたプロジェクトルームの中に、いくつものチームがいた。 フロアの中で「場所」で分かれている。 あのチームは開発。 あの場所はテスト。 あちらはインフラ。 まるで昔ながらのプロジェクトの縮図のような空間だった。 プロジェクトに本当に必要なもの もちろん、プロジェクトには必要なものがたくさんある。 パソコン。 机。 会議室。 そして、飲み会。 どれも大事だ。 しかし、私が「一番重要だ」と感じていたものがある。 それが ホワイトボード だ。 ホワイトボードは万能ツール ホワイトボードは不思議な道具だ。 課題管理のツールになる。 図を書けばプレゼン資料になる。 みんなで囲めばアイデア会議の場になる。 パワーポイントのように完成された資料ではない。 その代わり、圧倒的に“活動的”だ。 人が立ち、書き、消し、議論する。 ホワイトボードの前では、プロジェクトが動き出す。 プロジェクトを回す人の習慣 私はプロジェクト管理を担当するようになってから、 暇があるとホワイトボードを掃除していた。 もちろん、オフィスの掃除も大切だ。 机の整理も大切だ。 でも、なぜか私はホワイトボードだけは必ず綺麗にしていた。 ...

多重下請けプロジェクトで見えた、“開発ではない仕事”の正体 うわっ、リーダーってこんなに“作業”しているのか――そう思った瞬間があった。 金融機関のシステム開発プロジェクト。 社内フレームワークを適用した、約1年の開発案件だった。 Webとバッチ。 ベンダーは2社。 さらにテスト工程から、中国系ベンダーも入ってくる。 ここまでは、よくある大規模開発の話だ。 しかし構造を少し見ると、別の姿が見えてくる。 多段ベンダー構造という現実 一次受けは我々。 開発ベンダーは二次受け。 だが、その内部には三次受け、四次受けが存在していた。 つまり、 非常に多段の構造 になっている。 当然、それぞれの層に リーダー がいる。 では、この多くのリーダーたちは 何をしているのだろうか。 コードを書いているのだろうか。 実際の仕事は「調整」だった 実際には違った。 確かに半分は開発をしている。 しかし、それ以上に時間を使っていたのは 管理と調整 だった。 誰がいつ入るのか。 人数は足りるのか。 席はあるのか。 パソコンは足りているのか。 開発スキルは十分なのか。 そんな人員調整をひたすら行う。 さらに、 3カ月のテスト見積もり。 見積もり根拠の説明。 その後の交渉。 そして契約。 夜には、関係を作るための飲み会。 気づけば 開発よりも、はるかに多くの作業をしている。 見えてきた構造 ここで一つの疑問が浮かぶ。 リーダーとは 開発者なのだろうか。 それとも プロジェクトを成立させる調整役なのだろうか。 構造再定義 少し構造で整理してみたい。 表面の問題 リーダーの仕事が多すぎる。 しかし本質は違う。 本質的ボトルネック 多重下請け構造では 開発よりも 組織間調整コスト が増える。 つまり リーダーの仕事は 開発ではなく 関係の調整 になっていく。 リーダーの本当の役割 ここでリーダーを再定義すると リーダーとは 複雑な構造を動かす存在 なのだ。 異なる会社。 異なる契約。 異なる文化。 これらをつなぎ プロジェクトを前に進める。 そのため リーダーの仕事は コードを書くことではなく 制御できない要素を扱うこと になっていく。 経営へ...

金融プロジェクトの現場で起きていた静かな麻痺 ああ、私は人の痛みよりスケジュールを優先していた。     金融系の大型プロジェクト。 Javaのフレームワークを適用し、標準化し、品質を担保する。 遅延は許されない。レビューは連日続く。 現場は常に緊張していた。 「来週5人来るから机を用意してほしい」 「パソコンもお願いします」 「いなくなった人のPCはどうしますか？」 ほぼ毎日、この類の話をしていた。 1週間しかいない人もいた。 「新しい責任者です」と紹介された人が、翌週には来なくなったこともある。 重鎮エンジニアは次のプロジェクトへ引き抜かれた。 人の移動は“イベント”ではなく“前提”だった。 Javaフレームワーク適用の裏で失われた対話 その中で、私は後輩にきつく当たった。 品質を守るため。 納期を守るため。 その言葉に、私は疑いを持たなかった。 彼は次第に休みがちになり、やがて別プロジェクトへ移った。 だが私は、それを大きな出来事だとは思わなかった。 多くの担当者の移動と同じように処理した。 感覚が麻痺していたのか。 それとも冷徹だったのか。 プロジェクトは回っている。 成果は出ている。 それで十分だと、どこかで思っていた。 後輩の異動を“通常運転”と処理した私の構造 しかし後に、その後輩が鬱になったと聞いた。 自分からも連絡が取れなくなった。 私は一人で食事に行くようになった。 それでも、仕事のことを考えていた。 スケジュール通りに終わらせること。 そこに集中していた。 それが“普通”だと思っていた。 ここで問いが生まれる。 私たちは、成果を守るために何を犠牲にしているのか？ 人の入れ替わりを構造として処理することで、何を見落としているのか？ 成果と関係、どちらを守る経営か　～ 構造の再定義～ 表面の問題 人の入れ替わりが激しい。コミュニケーションが難しい。 本質的ボトルネック 人を「役割の単位」でしか見ていないこと。 関係を“交換可能な資源”として扱う組織慣性。 再定義 プロジェクトとはタスク遂行の場ではない。 “関係を設計する場”である。 移り変わる人の中で、変えてはならないもの 抽象化すれば、これは経営判断の問題だ。 短期成果を最適化すると、関係コストは後回しになる。 だが関係は、後...