スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

同期が100人プロジェクトを率いていた日 ――「支援」という立場の難しさを初めて知った瞬間

う わっ、 あいつ が こんな 大きな プロジェクト を 率 い て いる の か! プロジェクト を いくつか 経験 した 頃、 私 は 別 の プロジェクト へ「 支援」 として 入る ことに な っ た。 自分 の 担当 プロジェクト が 落ち 着い た タイミング で、 他の プロジェクト を サポート する。 IT 業界 では よく ある 話 だ。 ただ、 今回 の 支援 先に は 少し 驚 い た。 その プロジェクト を リード し てい た の が、 私 の 同期 だ っ た からだ。 同期 が 率いる 100 人 プロジェクト プロジェクト に 入 って み て、 まず 規模 に 驚 い た。 メンバー は 100 人 を 超える。 Web 機能 の チーム、 バッチ 機能 の チーム。 さらに 複数 の ベンダー が 参加 し て いる。 チーム の 数 も 多く、 調整 も 複雑 だ。 それ まで 私 が 経験 し てい た プロジェクト は、 最大 でも 70 人 ほど だ っ た。 その 倍 近い 規模 だ。 そして、 その 中心 で プロジェクト を まとめ て いる の が 同期 だ っ た。 正直、 誇らしい 気持ち に な っ た。 同じ 時期 に 入社 した 仲間 が、 ここ まで 大きな プロジェクト を 任 さ れ て いる。 「 すごい な」 そう 思 っ た。 昔 の 彼 は リーダー タイプ では なか っ た ただ、 少し 不思議 な 気持ち も あっ た。 彼 は 昔 から、 いわゆる リーダー タイプ では なか っ た からだ。 どこか 独特 で、 あまり みんな と 群れる タイプ では ない。 スポーツ を や って い た わけ でも なく、 体育 会 系 の 雰囲気 も ない。 どちら か という と、 静か で まじめ な タイプ。 そんな 彼 が、 100 人 規模 の プロジェクト を リード し て いる。 「 人 って 変わる ん だ な」 そんな こと を 思い ながら、 私 は 支援 メンバー として プロジェクト に 入 っ た。 夜 遅 く まで 残る 同期 プロジェクト に 入 って から 気 づ いたこ と が ある。 ...
最近の投稿

プロジェクトの「支援」はなぜ難しいのか? ――主役でも脇役でもない、もう一つのポジション

うわっ、プロジェクトって終わるとこんなにあっさり次に行くのか! 社会人5年目の頃、私はあるITプロジェクトのローンチを迎えていた。 そのプロジェクトは、特定のフレームワークを適用する役割で入っていたものだった。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       設計、開発、テスト。 何カ月も続いた忙しい日々。 そして、ついに本番稼働。 プロジェクトの一つの役目が終わった瞬間だった。 プロジェクトは終わると、すぐ次が始まる ローンチ後、運用に入る前のタイミングで、上司から呼ばれた。 「山口くん、来月から次のプロジェクトね」 あまりに普通の口調だった。 「場所はここ。入館の仕方はこれ。よろしく」 それだけだった。 さ、次のプロジェクト。 プロジェクトが変わるときは、いつもこんな感じだった。 簡単な説明だけ聞いて、あとは現地。 IT業界では珍しくない。 次のプロジェクトには同期がいた 次のプロジェクトは、証券会社のシステムだった。 金融機関ではあるが、銀行とは少し雰囲気が違う。 ふと気づいた。 そこには同期がいる。 ちょっと連絡を取ってみた。 「最近どう?」 すると返ってきたのはこんな言葉だった。 「結構遅くまでやってるよ」 どうやら忙しいらしい。 しかも驚いたことに、 その同期がプロジェクトのリードをしているという。 まじめな子ではある。 でも、ふと思った。 「彼って、リードするようなタイプだったっけ?」 なんとなく、そんなイメージではなかった。 そんなことを考えながら、次のプロジェクトのことを思っていた。 今度の役割は「支援」 今回の私の役割は、開発ではなかった。 支援。 このポジションが、なかなか難しい。 同期の手前、入りすぎるのも違う。 かといって、何もしないのも違う。 どこまで入ればいいのか。 自分の役割は何なのか。 プロジェクトリーダーは、 私にどう動いてほしいと思っているのか。 答えは、最初からは見えない。 だから私は決めた。 まずは、しっかり状況を見よう。 プロジェクトルームという不思議な場所 そして、新しいプロジェクトルームへ。 そこは都内の一等地にあるビルの一室だった。 初めて見たとき、 ふと不思議な感覚...

プロジェクトは「管理」するものなのか? ――世界中の現場を見て、私がたどり着いたもう一つの答え

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

金融は本当に保守的なのか? ――巨大金融機関が見せた「静かな挑戦」

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

なぜシステムは「夜」に生まれるのか? ――プロジェクトローンチの裏側にある、静かな常識

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

プロジェクトを動かすのはパソコンではない

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

リーダーは「作業」をしているのか?

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