第１回 プロジェクトに参加する
ここからは、一人前のPMになるためには、どのようにキャリアを積んで行けばよいか、についてお話しします。
当然のことですが一人前のPMになるためには、まず、プロジェクトに参加しなければなりません。プロジェクトに参加し、一般的には「プログラマー → 設計者 → プロジェクトリーダ → PM」の順にスキルアップして行くわけですが、それぞれの段階でできるだけ幅広く十分な経験を積むことが肝要です。
プロジェクトの規模によって設計者、リーダ、PMと役割が変わることもあります。十分な経験を積んでPMとなり開発現場を離れたとしても、プレイングマネージャという形でプログラマーや設計者を直接指導したり、一部人手の足りないところを設計したり、現場に近い作業も仕事に含めると良いでしょう。
技術の進歩は激しいので単なる管理者では息が短くなってしまいます。プログラミングまではやらないとしても、本来やるべき仕事をおろそかにしない範囲で、重要な部分の設計をしたりドキュメントをまとめたりするだけでも、単に進捗管理をするよりはよほど面白いでしょう。
プログラマーとしての心構え
まだ経験が浅い段階では、通常はプログラマーとしてプロジェクトに参加することになるでしょう。プログラマーはまず自分が担当するプログラムの仕様の理解に勤め、バグの無いプログラムを作成することに努力しなければなりません。しかし、単にプログラム作成に満足するだけでなく、もっと視野を広げてプロジェクト全体を見ようとする努力が必要です。
以下のようなことを心構えにすると良いでしょう。
- 与えられたプログラムのテストをどうやるかを考えながらプログラム設計を行う。
- 自分の所属するチームの役割とその中での自分の位置付けの把握に勤める。
- 自分の所属するチームの担当するサブシステムの役割と構造の把握に勤める。
- 他のサブチームとの関連について興味を持ち、把握に勤める。
設計者としての心構え
設計者としてプロジェクトに参加する場合には、まず、設計ドキュメントの分かりやすさに注意しなければなりません。ドキュメントの粒度は、基本設計書、詳細設計書、プログラム設計書によって違ってきますので、プロジェクトフェーズに粒度を合わせる必要があります。とは言え、高リスクの複雑な処理については、基本設計の段階から粒度を上げる場合もあります。
設計者は、プログラマーに説明するだけでなく、プログラマーからのフィードバックを受ける必要があります。設計書が分かりやすいかどうか、曖昧な点がないかどうか、誤解を生む表現がないかどうかなど、直接意見を聞くべきです。フィードバックを受けることにより、仕様書に磨きが掛かってきます。
以下のようなことを心構えにすると良いでしょう。
- 設計書のフィードバックをプログラマーから受け、改善する。
- 与えられた設計作業だけでなく、回りの人たち、他のチームが何をしているのかに興味を持つ。
- 自分の所属するチームの役割とその中での自分の位置付けを把握する。
- 自分の所属するチームで、タスクの抜けがないかチェックしてみる。
リーダーとしての心構え
サブチームのリーダは、チーム内のマンパワー、スキル、コスト、成果といった幾つかのトレードオフに挟まれて、常に苦しい立場に追い込まれます。もし苦しくなければ、その人がよほど鈍感なのか、またはチーム内に優秀なメンバーが何人もいるかです。リーダはメンバーの様子を見ることが大切です。分かっているのかどうか、死にそうにしていないかどうか、リスクの兆候がないかどうかなど、チームの内情に敏感であることが大切です。
また、他のチームとの関連や役割分担などについても考えなければなりません。よく、チーム間での仕事のなすりあいが発生することがありますので、話し合いが必要になります。
以下のようなことを心構えにすると良いでしょう。
- チーム内のメンバーの様子に気を配る。
- リスクの兆候がないか気を配る。兆候があれば何らかの手を打つ。
- チーム間の役割分担の明確化、未着手タスクの割当てなどチーム間で発生する問題を解決する。
- チームを超えて全体に影響を与える問題は必ず明らかにする。報告は義務ではなく権利と捉えること。
人と出会う
色々なプロジェクトに参加することで、顧客、上司、部下、協力会社など、いろいろな人と出会うことになるでしょう。今の世の中、人間と人間の関係は一様ではありません。あるときは顧客と供給者の関係だとしても、別の場合には、逆転します。すなわち、我々は常に買い手にも売り手にも成り得ます。ですから「お客様は神様です」などという古い概念に囚われないことです。顧客の立場を尊重するのは大切ですが、一方で供給者の立場も尊重しなければなりません。顧客と馴れ合いになることなく、常に改善提案ができ、かつそれを顧客が受け入てくれたら、良い関係を築くことができます。そういう顧客と一生付き合えれば幸いです。
いい上司、いい先輩に出会った人は幸せです。少なくとも最初は、そういう人たちに教え導いてもらう必要があります。「上司を偉くできれば、自分も偉くなる」という言葉はほとんどの場合本当ですし、逆に上司に恵まれなければ重要な仕事はできないでしょうし、社内の地位も上がらないでしょう。
いい部下に出会え、仕事で磨きを掛けることができれば幸いです。一人前の人間に育って行き、一塊の仕事を安心して任せられるようになるでしょう。「この人は、この仕事をやりにここに来たんだな！」とか、「この人が来てくれて本当に助かった」と思えるような人間に出会うこともあります。そういう時はプロジェクトも不思議とうまく行きます。
社内に無いノウハウ、リソースを提供してくれ、かつ、きちんとした実施プロセスを提供してくれるような素晴らしい協力会社に出会えれば、安心して仕事の幅を広げることができます。このような協力会社とギブアンドテイクの関係をずっと続けていけると、本当に助かります。
逆に、何でも責任を押し付けてくる顧客や、事なかれ主義で何もしない上司に出会うこともあります。でも、修行だと思ってしばらくはがんばりましょう。こっちが逃げなくても、向こうが先に逃げ出すこともありますし。
プロジェクトと出会う
一般的に言って、規模の小さなプロジェクトの場合には、プロジェクト全体が見えやすくなりますが、一人一人の役割が大きくなり、一人でいろいろな種類の仕事を担当することが多くなります。一方、大きなプロジェクトの場合には自分の位置付けが見えず、また小さなプロジェクトに無い複雑さ、難しさがあります。また、チームの編成もプロジェクトの進め方も、小さなプロジェクトと大きなプロジェクトでは全く違います。従って、若いうちに規模の小さいプロジェクトから大きなプロジェクトまで、様々なプロジェクトに参加することが理想的です。
時として火のついたプロジェクトに出会うこともありますし、ボロボロのプロジェクトに出会うこともあります。どんなプロジェクトにどんな立場で出会うかが、その後の人生を決めることがあります。事なかれ主義を決め込む人もいますし、身体ごとぶつかって何とかやり抜く人もいます。中にはプロジェクトが自分のやりたいことではないことに気が付いて離れていく人もいますが、職業選択は人間本来の自由であり、去る人を悪く言うことは出来ません。
皆さんも、プロジェクトは自分を成長させる栄養だと思ってがんばってみてください。その結果、合えば続ければいいことですし、合わないと思えば逃げ出すもよし、方向転換するもよしです。
プロジェクトから復帰する
大きなプロジェクトに数年間携わり、プロジェクトがめでたく終了して抜け出すと、世の中が本当に変わっていることに気が付くことがあります。私の経験でもIT技術がまるで変わっていて、プロジェクトで使っていた技術がまったく古臭いものになっていた、ということが何度もあり、自分がまるで浦島太郎になったような感じがしたものです。
世の中の流れにどう対応し、乗って行くのか、これはPMに限らずあらゆる人々の課題です。いつまでも前のプロジェクトの余韻に浸ることなく、世の中の流れにどう乗るか、次に何をやるかを考えなければなりません。