第6話　マネージャもプログラムを書け！

スキル

» 2009/08/03

　プロローグで書いたように、わたしは立場的にはPMです。正確にはPM相当でしょうか。SIerではないので（受託開発はやりますが）、顧客からの要求というものはほとんどありませんが、規模は大きくないので企画や開発計画から設計、間に合わないと思えばプログラムも組みます。営業からの要請があれば資料も作ります（実際はなくても作っていますが）。責任がついてまわるのでPMですが、実際は何でも屋です。

　わたしのことはさておいて、一般に上流といえばPMやSEでしょうか。SEは「上流SE」なんていうこともありますが、今回は言葉はともかく、要件から機能設計段階までを担当するエンジニアを対象にして「上流エンジニア」で統一することにします。それ以外は一般エンジニアとします（下流という表現は好きじゃないので）。

注意！

　今回も以下の文章はあくまでわたし個人で感じていることであり、大多数のエンジニアについていっているわけではありません。それを理解して読んでください。

■誰が火をつけるのか

　プロジェクトが火を噴いてデスマーチになるケースは、残念なことに決して少なくありません。デスマーチまで行かなくても「やべー」と思うことは上流エンジニアをやっていればよくあることだと思います。それだけ今のシステムは複雑になっています。

　工程的に「要件」「設計」「製造」「試験」と段階を踏んだ場合、デスマーチになる要因はどこの工程にも潜んでいますが、確率から言えば「要件」と「設計」部分が大半だと思います。ただ、「製造」と「試験」の段階で表面化する事が多くて、スケジュール的に一般エンジニアの人たちがその犠牲になります。

　これを踏まえて考えると、一般エンジニアの人が上流エンジニアの人たちに文句を言いたくなるのは当然だといえます。上流エンジニアのプログラムに対する理解度が低いため、設計の精度が落ちているのです。

　システム開発全体で考えた場合、上流と一般では必要とされるスキルが異なります。上流ではプログラミングスキルよりはコミュニケーションスキル（顧客から要望を聞いて要件を確定させるのに必要）やリーダーシップ、業務知識、そして全体像を把握するためのIT関連全体の知識が必要となります。ソフトウェアという部分を切り出せば、広く浅く知識が求められます。一般の場合は設計されたものをプログラムに落とし込むので、言語やプログラミングスキルが必要となります。反面、自分の範囲以外は分かっているのが理想ですが、必須まではいきません。つまり狭く深い知識が求められます。

　この両者の違いがお互いに理解されないからか、プロジェクトに火がつき始めると、どこからともなく上流は一般エンジニアのスキル不足を責め、一般は上流エンジニアのプログラムに対する理解の低さを責めます。客観的に見ると非常に不毛な争いとなり、論点がズレ始めます。

■ベストよりベターを目指せ

　これは全体の要件をまとめるときに必要な考え方だと思っています。一生懸命なPMほど顧客満足度の向上を目指してよりベストな選択を模索します。方向としては決して間違っていないと思いますが、ボランティアならともかくビジネスですので、どこかで妥協点が必要です。

　社会情勢もあり、最近ではIT関連の設備投資はかなり鈍いです。ただ、システム化は必要なのでニーズは必ずあります。その時、ネックになるのはやはり「費用」です。顧客側からすれば少しでも安く、SIer側からすると少しでも高く、この点だけは必ず反目します。だから、顧客側は費用対効果が一番高そうなところで、SIerは機器のグレードやオープンソース、必須以外の機能削減を行い、お互い妥協点を探ります。これがベターです。

　PMにはもう1つ考慮する点があります。それはメンバーへの配慮です。納期までの期間が短いと、それだけでデスマーチになりかねません。少なくともそこは何とかすべきです。顧客と上手に駆け引きできないPMはそれだけでプロジェクトを破綻させかねません（顧客の言いなりになりかねないため）。このあたりが一般エンジニアと大きく異なるところだと思います。

■プログラミングスキルは磨け

　PMにプログラミングスキルは不要かと聞かれれば、わたしは迷わず「ノー」と答えます。よく考えればこれは当たり前のことで、業務手順を最終的にプログラムロジックに落とし込むわけですから、そのプログラムを知らないと、とんでもない要件や設計が出来上がります。しわ寄せは言うまでもなくPGへ行きます。無理なことは逆立ちしても無理です。

　わたしは要件や設計をしながら絶えず頭でロジックに落とし込む作業をします。お客様と話をする時も、よく頭の中でロジックを組みながら話をします。やっていることはPMやSEですが、考えていることは常にPGです。要するに打ち合わせが終わっているころには、ほぼ方針がきまり、設計が終わると頭の中ではロジックができている状態になります。ですから後からSEやPGが「これは無理です」と言ってきても、やり方や方針をきちんと伝えられます。これができなくなるとSEやPGの負担が増えます。方向性を間違うと品質は確実に落ちて、その責任は結局PMに来ます。

　正直、いまのSEやPGを見ていると、前回書いたようにやや想像力が乏しいと感じます。ついでに柔軟性もあまりなく、なぜか若くても頭がガチガチの人が多いです。でも、だからといってそれを言ったら軋轢を生みます。ですからプロジェクトを成功に導くためには、PMがそれを理解してそれなりに対応すべきです。当然、全員がそうではないので、メンバーのスキルや性格に応じて上手に導いてやることが必要不可欠です。そのためにプログラミンぐスキルは必要だと言えます。プログラムを理解できないPMをPGはあまり尊敬しません。

　よく、システム化に際して保守性（運用性）を理由に自分のスキルの低さを隠すPMがいます。保守も運用もシステム化の一部であり、開発の延長線上なのでPMの立場からするとおざなりにはできません。でも、だからといって何でもWebアプリ、顧客が知らないからVB6、誰も理解できないからSQLは簡潔に……うんざりです。プロを自認するならベターで選択した要件をベストなスキルで完成させるべきだと考えています。安易に楽な方に逃げても顧客の求める品質には届きません。遅かったらスケールアップだなんて、素人でも考えつきます。それで済めばシステム要件なんて決める必要ないです。最初からハイパフォーマンスなマシンにすれば良いだけですから。

　もし、顧客がどうしても、と言うなら、メリットとデメリットを並べて、それでもと言うならそういう選択もありだと思います。でも、本来はシステム化することによって得られるメリットが少しでも減るのなら、PMは顧客にそれを訴えるべきです。運用が不安ならきちんと運用手順を示して教育するべきだし、保守性がと言うならやはり資料を作成して教育すべきです。その手間をPMが惜しみ、安易に妥協して後から追加料金を取るのは悪徳商法となんら変わりません。SEやPGに高スキルを要求するなら、PMはそれ以上に高度なスキルを持つべきです。コミュニケーションスキルとリーダーシップだけでは顧客満足度を上げることは到底無理です。

■理屈だけではプロジェクト管理はできません

　最近はプロジェクト管理やソース管理、バグトラッキングなどが容易にできるツールがたくさん、しかもオープンソースで手に入ります。それに伴いプロジェクト管理の本なども出てきて、個人的にはいい時代になったと思います。

　でも、これらのものが便利すぎるあまり、PMが管理に対して過剰になりすぎる傾向が見えます。これらはツールなので手助けと考えるのは良いのですが、必須と考えると非常に窮屈です。言ってしまえば理屈だけで管理しようとします。

　「管理」するにあたって一番ネックになるのは何だと思いますか？ 実は「人間」だったりします。どんなにいいツールを使っても、どんなルールを作っても、それを履行する人間がいい加減だったら何の意味もありません。管理はさせるものではなく、するものです。そのための手助けをツールに委ねます。

　最近のシステムは複雑化しています。なかなか一筋縄では開発はできませんし、管理も大変です。そのためにいろいろな手法やツールが考え出されているのですが、管理の根本部分を置き去りにしてしまうため、それがすべての至上主義になってしまいます。

　本当はツールなんて何でも構わないと思います。ちゃんとPMが「管理」できれば。

　プロジェクト管理の基本だと思っているのですが、（少なくともわたしは）進捗は必ず自分の目で確認します。人間誰しも怒られたくありませんし、保身を考えます。そうすると自己評価が非常に甘くなり、進捗報告でも隠します。特に今は「分からない」と言い出せないエンジニアが増えているので余計です。後になって結局「できていなかった」となるとデスマーチに突入する可能性大です。これは本人も悪いのですが、管理しきれないPMの責任でもあります。

　PMはプログラムの細かい部分はPGの仕事であって、PMの仕事ではないと思っている人も多いでしょう。でも、それとプログラミングスキルは別の話になります。実際、細かい部分を知らないと何かあった時に対処できません。わたしは途中経過でプログラムを動作させておかしいところは必ずコードを調べ、担当者に聞いて修正をお願いします。全部を闇雲に見るのは現実的ではないので、担当者単位で差分を取るようにしています。

　ちなみに、不可解なコードを見つけても担当者に聞きます。あら探しはしませんが、見つけてしまっては放置できません。前回も書きましたが、頭ごなしにダメ出ししても絶対に受け入れてくれないので、まず意図を聞いてその上でマズかったらどうしてマズいのか話した上で修正してもらいます。PGは自分の範囲で仕事をします。でも、時々他に影響が出そうなコーディングをする時もあります。分業なので、何でも管理してダメ出しするのは逆にPGやSEのやる気を削いでしまう危険性があり、注意が必要ですが、ダメな所はダメと言わないとそのエンジニアのためにもなりません。逆に時々、褒めることも忘れずに。

　わたしは仕事をする時は常に楽することを考えます。これはサボることではなく、負担を減らすことを意味します。その上でいつも後輩に対して自分と同じレベルかそれ以上にスキルを引き上げることを考えています。時々、手柄を独り占めしたくて自分の技術を教えたがらない人がいますが、わたしは非常にもったいないと思います。周りのメンバーのスキルが上がれば、それだけ自分の負担が減って、結果的にプロジェクトはスムーズに回ります。技術なんて大事にしていてもすぐ古くなりますし、これだけ情報が溢れていれば誰かが公開してる可能性の方が高いです。

■エンジニアの前に人同士

　最近の20代から30代はキレやすい、って記事が出ていました。でも実際は、下から上までそれこそ老若男女問わずイライラしている人が多いと感じます。電車に乗っても車の運転しても、余裕のない人が増えたと実感します。

　プロジェクトもそうです。わたしは、エンジニアは技術的なことで議論したりケンカするのは良いことだと思っています。でも、それを人間関係に持ち込むのは良くないと思います。要するに、本当の喧嘩はマズいですが、切磋琢磨は必要だと考えています。

　確かにPM、SE、PGで立場が違うので、それぞれ思い通りにいかないとイライラするでしょう。本当はそうではなくて、相手の立場を考えて行動することがプロジェクトの炎上を防ぐ一番の近道だと思っています。わたしはPG、SE、PM、どれも経験しているので、どれが偉いとか思うのはナンセンスだと考えています。どのポジションでもそれぞれに悩みも誇りもあります。ですから、相手を責める前に、まず相手を理解するようにして欲しいと思います。

　PMでもプログラム経験が浅いならまず自分で組んでみることです。いかに今のシステム開発が複雑なのか理解できるでしょう。SEはどうしてPMがこのような要件で設計するのか考えてみてください。機会があれば一緒に顧客との打ち合わせに参加させてもらうのをオススメします。PGなら自分で機能だけ見て設計してみてください。プログラム技術だけでは難しいことがよく分かると思います。

　1人で完遂できるプロジェクトはごくわずかだと思います。いろんな立場の人が参加しているにはそれなりの理由があります。自分だけがつらい思いをしていることはまずないので、それを常に頭に入れて自分が持っている最高のパフォーマンスを発揮できるように頑張って欲しいものです。それがこれからエンジニアを目指す人を増やすための原動力だと思います。

　次はちょっとこのシリーズはお休みして、せっかくお題をもらったので勉強会やカンファレンスについて少し書こうと思います。