うわっ、プロジェクトってこんなに人がいるのか！ 若い頃、大規模システムプロジェクトの会議室に入った瞬間、そう思ったのを覚えています。 私はこれまでIT屋として、多くのシステム構築プロジェクトに関わってきました。 日本だけではありません。インド、中国、ポーランド。いまやITプロジェクトは完全にグローバルに広がっています。 大きなシステムになればなるほど、プロジェクトは巨大になります。 そしてその構造は、実はとても複雑な「多段の社会構造」になっています。 プロジェクトの裏側にある「多段構造」 システム開発の世界では、よくこんな言葉を聞きます。 「システムはシステムのプロが作る」 これは半分正解で、半分間違いです。 確かに設計やアーキテクチャは専門家が担います。 しかし、大きなシステム、大きなプロジェクトになればなるほど、最後は人海戦術になります。 テスト作業、データ確認、操作確認。 パソコンが触れればできる仕事は数多く存在します。 日本語ができなくても、パソコンは触れる。 言われた通りにテストはできる。 こうして世界中から人が集まり、プロジェクトはどんどん拡大していきます。 知識労働ではなく「人数ビジネス」 しかし、この構造にはもう一つの側面があります。 プロジェクトは、元請けから順番に費用が抜かれていきます。 そして末端のエンジニアに届く頃には、かなり安価なコストになっています。 つまり、評価されているのは知識ではなく「人数」です。 人を集めれば売上になる。 だから価格競争が起きる。 そして、縄張り争いが始まります。 プロジェクトの現場で起きること 当初考えていない作業が出てくると、 「それはうちの責任ではない」 簡単な作業が出てくると、 「それはうちがやる」 責任は押し付け合い、 作業は取り合いになる。 管理者たちは、その中で自分の領域を広げるために、 コミュニケーション、調整、そして飲み会に奔走します。 こうしてプロジェクトは進むのですが、 その裏では多くの人が疲弊しています。 鬱になる人もいる。 プロジェクトは遅延する。 そして最後には、責任の追及が始まる。 残念ながら、この構図は世界中であまり変わりません。 PMBOKでも解決できないこと もちろん、世界にはプロジェクト管理...
巨大システムの裏側にある、小さな一歩の積み重ね うわっ、金融機関がJavaフレームワークに挑戦するのか!? そう思ったのが、そのプロジェクトの最初だった。 当時、私はある 大手金融機関のお客様 のプロジェクトに関わっていた。 その金融機関は、日本でも有数の巨大な企業体。社会への影響力も大きく、システムに障害が起きれば社会全体に影響が出る可能性すらある。 だからこそ、 基幹システムは依然としてCOBOLが中心 だった。 長年動き続けてきた、安定した仕組み。 金融の世界では、それは「守るべき資産」でもある。 しかし、同時にこういう声もあった。 「新しい技術にもチャレンジしていきたい」 そのプロジェクトは、 Javaのフレームワークを金融機関で適用する初めての試み だった。 とはいえ、金融機関である。 いきなり基幹システムに導入するわけにはいかない。 そこで出てきたのが、非常に興味深い考え方だった。 新しい技術は、まず影響の少ないところから使う。 それは、Webシステムなどの 周辺システム だった。 金融機関が考えた「安全なチャレンジ」 当時の金融システムでは、まだ 帳票文化が主流 だった。 帳票は公式記録。 そこに誤ったデータが出てしまうと、業務への影響は非常に大きい。 だからこそ、技術適用の順序にも工夫があった。 まずは 入力システムではなく表示システムから 。 理由は明確だった。 入力システムにバグがあり、誤ったデータが基幹データベースに登録されたら取り返しがつかない。 しかし、表示システムならどうか。 もし表示ロジックに問題があったとしても、データそのものが壊れるわけではない。 つまり 出力・表示 → 入力 → 基幹 という順序で、慎重に技術を適用していく。 さらに言えば、帳票に誤ったデータが出るより、 Web画面での表示の方が痛手は小さい 。 こうした議論を、金融機関の担当者と何度も重ねた。 その議論を聞きながら、私は思った。 「金融機関は新しいことに挑戦しない」 世の中では、そんなイメージがある。 しかし実際は、まったく違っていた。 「守る責任」があるからこその計画 金融機関の人たちは、決して挑戦を避けているわけではない。 むしろ逆だ。 社会を守る責任があるからこそ、計画的に挑戦...