プロジェクトリーダーに即位の礼

私は入社してルーキー時代は評価が芳しくなかった。

自分で言うのも何だが、それを挽回すべく試行錯誤したと思う。
多摩市の最深部、その中でも樹海の最深部に会社の寮があったことも幸いし、自己研鑽に打ち込めた。

2年ぐらいすると初めてリーダーに即位する事になった。当然だが儀式のようなものはない。

誰もが通る道なんだけど、自分の若気の至りを書いておくことでデスマーチプロジェクトが少しでも減ればと思う。

フォトウィリアム・クラウゼのUnsplash

私が新人時代にどれだけ落ちこぼれで苦労したかは以下の記事に書き上げました。もしよかったら御覧ください。

(adsbygoogle = window.adsbygoogle || []).push({});

目次【本記事の内容】

• 1.ITプロジェクトのリーダーにとりあえずなる方法
• 　1-1.プロジェクトが始まった時、すべての技術がわかるのは私だけだった
• 　1-2.プロジェクトマネジメントの事は全く知らない
• 　1-3.プロジェクトの顛末
• 2.初めてITプロジェクトリーダーになった時の失敗
• 　2-1.上司の言うことを鵜呑みにしてしまった
• 　2-2.やって学ぶのがいいのか、学んでやるのが良いのか？
• 3.まとめ

ITプロジェクトのリーダーにとりあえずなる方法

プロジェクトが始まった時、すべての技術がわかるのは私だけだった

入社して下働きばかりしていた。

• プリンタ紙詰まりの始末。
• パソコンが止まったというユーザーPCのチェック。
• PCのネットワーク設定。
• ブラウザの設定。

そんな事をしながらExcel VBAやAccess やNotesのプログラムを私は勉強していた。幸いにもどれもVBをベースにしていたので覚えやすかったのだろう。それがあとでリーダーに即位することになるとは夢にも思っていなかったのだが。

ある時に私のところに上司がやってきた。

その時には、ついに私も独り立ちするときがきたかという喜びがこみ上げた。その後のデスマーチも知らずに私は安易に了解した。

上司が私をプロジェクトリーダーに任命した理由は、Excel VBAができてACCESSがわかって、Lotus Notesの3つともわかるのが私だけだったらしい。

いや、正確に言えば他にも適任者はいたのだろうが、そういう人は先輩社員で他のプロジェクトで東奔西走。

それに加えてその案件、下手に仕事ができる先輩社員だったら、無理ゲーじゃね？っていうぐらい無茶苦茶な要求。

1. 一ヶ月でつくって。
2. バッチ処理が3日かかるのを5時間以内にして。
3. 私以外のメンバーは新人一人、ACCESS・Excelがわかる先輩一名、そしてチームリーダー初体験で即位したチンの三名。

何でも別のベンダーがNotesで作ったアプリが、あまりにもおそすぎてバッチ処理に３日か４日かかるそうだ。

それを私の上司が

「うちの技術力なら一晩で終わらせますよ。次のバッチ処理には間に合わせましょう」

という安請け合いをしてきた案件だった。

地獄の始まりだった。

全俺が涙して地獄のパレード。延期できるなら延期してえよ。

これがデスマーチか！というのを経験する。

象徴でいればいいというわけでなかった。

 

そんな案件だったけど、自分がリーダーになれた（させられた）のはなんでかな？ってその後、考えてみたんだ。

1. その分野で一流ではないけど、必要なITスキルを一通り理解していた。
2. 嫌がらずに引き受けた。（というか恐ろしさを知らなかった）
3. 比較的仕事が落ち着いた時期で、今の現場から抜いても影響ないと思われた。（時の運）

3.の運はどうしようもないけれど、1.のITスキルと2.の前向きな姿勢は自分でどうにかできるんじゃないかな。

プロジェクトマネジメントの事は全く知らない

自分も悪かったのだろう。そもそもメインの仕事がプリンタの紙詰まりやパソコンのトラブル解消、Q&A対応だったのでプロジェクトマネジメントなんか未経験ですよ。

自己研鑽していると言ってもプロジェクトマネジメントのことなんか全然勉強していなかった。もっぱら技術系の勉強のみ。現在の自分だったら、このプロジェクトのリーダーやってくれって言われたら退位しようと思う。

進め方も無茶苦茶。進捗管理表も作らずに、まずは動くプログラムを作る。

今思えばアジャイル開発じゃあねえか？と勘違いしそうだが、アジャイル開発だってドキュメント無しで良いなんて言ってない。マネジメントも何もしないのだからうまくいくわけない。

バッチ処理が動くその日、コンパイルが通らなくて困っていた。最後の1週間ぐらいは会社に泊まり込みして朝6時にきた掃除の人が、私を死体と勘違いし騒ぎを起こしていたのだが、その喧騒でやっと目をさますぐらい疲れていた。

先輩と二人で、とりあえずはコンパイル通らないところをコメントにして、プログラムをもって、お客様のデータセンターに向かった。

プログラムを動かせるのはユーザーがNotesを使わないよるの12時から朝の6時までだ。

今考えれば、
「え！、そんなに遅くから早くまでユーザーが使っているのかよ！」
って突っ込むのだが、当時の私は若かった。
未熟だった。
そんなところに突っ込む余裕はなかったのである。

プロジェクトの顛末

結局その日は、落ちてしまうステップはコメントアウトしたまま処理を終わらせた。

お客様の担当の人からは

「いままで3日徹夜するのが普通でしたが、これで枕を高くして寝ることができます。ありがとうございました！」

と言われた。

いやいや、まだ、デバッグモードで動かしているのだが。単体テストも終わってないだが。正直に言うべきだろう。ここで私は高らかに宣言した。

「我、ここに至るに、デバッグモードで動かしていくつかの項目をスキップしたことを宣誓する」

自分でも何を言っているのかわからなかった。担当の人も「え！」って顔をしていた。

落ちた所をスキップしたからエクセル帳票に出力されていない項目があったり、計算結果が合わなかったり。

その日は平謝りで、次の月に向けてバグをペシペシと退治する日々が続いた。しかし取り切れず。

それから半年ぐらいはバグが取り切れず。お客様からは

「もっとまともな技術者はいねえのか？」

と言われる始末だった。そして別のシステムエンジニアが仕事を私から引き継いだ。上司は退位して上皇とならず平社員となった。

初めてITプロジェクトリーダーになった時の失敗

上司の言うことを鵜呑みにしてしまった

今の自分だったらプロジェクトマネージャになった時にいろいろな事をチェックする。

さまざまな角度から徹底的に分析して納得できないことがあれば、納得するまで上司や顧客と交渉する。

先輩プロジェクトマネージャから言われたのは

「顧客や上司だからってプロジェクトマネージャは尻込みしちゃいけねえ。プロジェクトの成功のためには何でもするのがプロジェクトマネージャだ」

ってこと。

そんなこと、初めてプロジェクトをする若者が知るわけもないわけで、プロジェクトマネージャは計画的に育成しなければならない。

プロジェクトマネージャをするときは、見積もりチェック、スケジュールチェックぐらいはしようぞ。

やって学ぶのがいいのか、学んでやるのが良いのか？

最近、悩んでやらないくらいなら、やって失敗する方がよいというポエムをツイッターでよく見る。
でもね、最初からノープランで突っ込むほど無謀なことはないね。大事な時間、金、人のやる気をデスマーチプロジェクトは奪ってしまう。

やって学ぶのがいいのか、学んでやるのが良いのか？

最近、悩んでやらないくらいなら、やって失敗する方がよいという類のポエムをツイッターでよく見る。
でもねITプロジェクトに関して言うと、その考えに私は反対。
最初からノープランで突っ込むほど無謀なことはないね。大事な時間、金、人のやる気をデスマーチプロジェクトは奪ってしまう。

プロジェクトリーダーやるんだったら、せめて数回はサブリーダーを経験してから取り組むぐらいでちょうどよい。
じゃないと私の元上司にみたいにプロジェクトリーダーを任命した人が責任を取らされるから。

まとめ

プロジェクトマネージャはプロジェクトを成功に導き終わらせなければならない。
その時にプロジェクトメンバーが疲弊しきっていたら事業の継続的発展はない。

プロジェクトリーダーに即位してから始まる。
そしてプロジェクトを成功に導くことができるなら、皆さんのプロジェクトマネージャとしてのキャリアは輝かしいものになるんじゃないかな。