PMO

最近、うちの会社でも（最近はやりの？）PMOというものの導入がされています。でも、恥ずかしながら、PMOってどういうものなのかよく知らないのです。
で、グーグル先生に聞いてみたところ、次のサイト(http://www.atmarkit.co.jp/aig/04biz/pmo.html)に解説がありました。

******************
大規模な組織において、組織全体のプロジェクトマネジメント（PM）の能力と品質を向上し、個々のプロジェクトが円滑に実施されるよう支援することを目的に設置される専門部署。「プロジェクトオフィス」「プロジェクト支援部門」などともいう。
。。。云々。。。(詳細は上記サイトを見てね)
PMOの機能や役割、設置形態は、導入企業によって大きく異なる。ITや製薬／バイオ、建築業界では、業務のほとんどがプロジェクトであり、その品質こそが企業の業績と将来を左右する。そのため、継続的なPM能力の維持・向上を目的に、経営レベル直結の形で設置する例もある。
*******************

う～ん、分かったような分からないような・・・。

でも最近、プロジェクト管理を、人を管理することと勘違いする人が多いなぁということをよく感じます。ソフトウエア開発プロジェクトのリソースはほとんどが人なので、そう勘違いするのは、しょうがないことなのかも知れませんが、でも、私は違うと思うんですよね。

プロジェクトを管理するということは、プロジェクトが目的とする製品やサービスを作り上げる過程を管理することこそが本質だと思うのです。

ですので、うちのPMOさん達には、これから作る製品の仕様も分からずにプロジェクトを管理できると思うなよと言ってあります。仕様ひとつひとつがスケジュールどおり進んでいるか、またそのアウトプットが品質を満たしているか検収するのが君達の仕事だよと。

で、ゲキを飛ばしたこともあり、今、一生懸命、仕様を勉強してくれているようです。先日は、３５００項目にもなる仕様のチャート（忙しい最中、自分で作ったんですよ・・）を渡して、それぞれの仕様が誰がいつまでに何を作らないといけないか示すガントチャート作ってね！ときつい要求もつきつけることも。

でも、プロジェクトの土台を支える立場なら、これくらいやってくれないと安心して任せられませんし、せっかく私が統括するプロジェクトに参加してくれているのだから、単なるお手伝いさんで終わらせたくないと思っています。この気持ち分かってくれるかなぁ・・。

仕事の進め方

少し前に忙しくて、首が回らないという話を書きました。
しかし、まだまだ甘かったですね。今はそれ以上の忙しさでいつ倒れるか？と自分で自分の体が心配になってきています。最近は左胸から左肩が痛くて、やばい病気の兆候じゃなければよいですが・・・。幸い診断では異常はありません。ストレスかなぁ。

体調がおかしくなるくらい忙しいので、実務となると人に任せるしかありません。今までは任せるとは言っても、細かなフォローをしていったのですが、今はとても余裕がありません。ほとんど丸投げしかないような状況になっています。

こういう状況になってくると面白いもので、大きな課題を与えると、人それぞれ課題に対するアプローチが大きく異なるのを発見しました。分類すると下記のような感じでしょうか。

１）　人間関係の構築からはいる人
２）　ツールから入る人
３）　勉強から入る人
４）　仕様の検討から入る人

１）は課題の周辺にいる人たちと、まずミーティングを設定して雑談レベルから人間関係の構築をしていき、人間関係の中から課題形成を徐々にしていく人です。

２）はＩＳＯなどのプロセスや、スケジュール管理や課題管理のツールを整備し、それらのツールを使ったワークフローを定義し、課題を管理する方法を確立していく中で課題形成をしていく人です。

３）はまず課題周辺の技術書やソースコードを読み込んでいき、知識を身に着けることを優先し、課題がなにかを理解しようとしていく人です。

４）は課題の最終的なアウトプット、商品やサービスの仕様など、をまとめ、自らの課題を明確な形で形成しようとしていく人です。

私はどちらかというと、３）と４）の間といったところでしょうか。
これらは、どれがいいということはありませんが、個人的には、４）の進め方をする人を私は好みます。なぜかというと、任せた仕事のアウトプットが明確に分かるからです。

プログラムは所詮、人が記述するものなので、コードの中身まで管理することは難しいですが、アウトプットは管理可能です。また、その人の生産性、すなわち優秀さが明確にわかります。

あくまで私の経験上ですが、それぞれタイプの強い人は、下記のような傾向をもっていると思います。

１）の傾向が強い人は、情に流されやすいです。あまり有能でない担当者を変えるということができずに、うまくいかなくなる傾向があります。チームの和が乱れる可能性が高くなります。

２）の傾向が強い人は、課題そのものを担当者から申告させるケースが多く、プロジェクトの全体像を掴みにくくなる傾向があります。デスマーチの可能性が高くなります。

３）の傾向が強い人は、技術の全体像を掴むことを優先するあまり、肝心のアウトプットがなかなかでない傾向があります。要するに生産性が低いです。チームワークはよいですが、デスマーチ以前に、何もアウトプットがないまま終わる可能性が高くなります。

４）の傾向が強い人は、アウトプットを優先するあまり、担当者に無理を強いる傾向があり、生産性は高いですが、チームのメンバーは疲弊する可能性が高くなります。

まぁ、いずれにしてもほどほどがよいようで・・・。

ソフトが巨大化していくと、課題形成そのものも難しくなっていき、このようなアプローチの差が出てくるのだと思います。
最近、巷で多いのは２）のケースではないでしょうか。チームリーダーが課題形成ができずに、担当者に課題を出させたあげく、ツールで担当者を管理してしまうというような。こうすれば、管理者になった気になれますからね・・・。

さて、あなたはどのタイプでしょう？

人材が足りない！

どこの会社も人材不足に悩んでいると思いますが、多聞に漏れず私のプロジェクトでも人材が足りません！

自分ですべてができればよいのですが、担当するビジネス範囲が広くなりすぎて、一つ一つのプロジェクトをケアすることもできなくなってきました。それをカバーすべく日本だけでなく世界各地から人材獲得のために動いているのですが、それでも足りません。う～ん、困りました。

ソフトウエアはよく工数で換算されることが多いですが、そんな線形の理論で片付くほど簡単なものではありません。例えがいいかどうか分かりませんが、工数ですべてが片付くなら、今川義元が織田信長に負けるはずがなかったのです。

数人の英知をもった人間が、不可能と思われるプロジェクトさえも可能にしてしまうのがソフトウエアプロジェクトです。ソフトウエア製品にかかる投資のほとんどは人（プログラマ、テスターやデザイナ）です。逆に言うと人をうまく使えれば、ROIが高くなるということです。

ということを考えると、人をうまく使える英知をもった技術者が獲得できれば、ソフトウエアプロジェクトが成功する可能性が高くなるということです。

人をうまく使えるということは、人格的に卓越したものがなければなりません。また、プログラマを使うという点においては技術的にも卓越したものがなければなりません。

しかし、そのような人材はソフトウエア業界のダイヤモンドというべき存在であり、世界的にもなかなかいるものではないということをあらためて痛感しています。

でも、なんとかしなきゃならん現実が・・・困った！！

プログラムの書き方（その２）

今回は、私の癖について紹介したいと思います。
地味ですが、カンマの位置についての話です。

多くのプログラマにとっては、以下のように変数や定数を区切るカンマを変数や定数
の後につける、後カンマが常識となっています。
後カンマは、Ｋ＆ＲやＡＮＳＩの書式でも推奨されているので当然の習慣でしょう。

/* sample 1 */
enum condition_list {
　　CONDITION1,
　　CONDITION2,
　　CONDITION3
};

/* sample 2 */
void hoge(int a,
　　int b,
　　unsigned char c,
　　unsigned long d)
{}

しかし、私は、変数の前にカンマを置くようにします（前カンマ）。
すると次のようになります。

/* sample 1 */
enum condition_list {
　　 CONDITION1
　　,CONDITION2
　　,CONDITION3
};

/* sample 2 */
void hoge(int a
　　,int b
　　,unsigned char c
　　,unsigned long d)
{}

このようにするのは、私なりの理由があります。たとえば、enum に実験的に値を追加
したい場合や、関数にデバッグ用に引数を追加したい場合に次のようにすることができます。

/* sample 1 */
enum condition_list {
　　 CONDITION1
　　,CONDITION2
　　,CONDITION3
#ifdef TEST
　　,CONDTION_TEST
#endif
};

/* sample 2 */
void hoge(int a
　　,int b
　　,unsigned char c
　　,unsigned long d
#ifdef TEST
　　,unsigned long * probe
#endif
　　)
{}

これが、後カンマの場合どうなるでしょうか？ちょっと不恰好ですよね。

/* sample 1 */
enum condition_list {
　　CONDITION1,
　　CONDITION2,
#ifndef TEST
　　CONDITION3
#else
　　CONDITION3, /* カンマのありなしを意識しなくてはならない！ */
　　CONDTION_TEST　　　
#endif
};
（注：enum の場合は、後コンマの場合でも最後にMAX_CONDITIONを加えることで、
この問題を回避できます）

/* sample 2 */
void hoge(int a,
　　int b,
　　unsigned char c,
#ifndef TEST
　　unsigned long d
#else
　　unsigned long d,　/* カンマのありなしを意識しなくてはならない！ */
　　unsigned long * probe
#endif
　　)
{}

私の経験上、一番最初の宣言は変わることがほとんどありませんが、最後の宣言は、
開発途中やデバッグなどで変わることがしばしばです。
前カンマにすることで、ちょっとした手間をはぶくことができます。

また関数の呼び出し時にも、前カンマを習慣をづけることで、関数呼び出しと引数との
違いを人目で見分けることができます。

以下の例では、hogehogeの中で、SomeFuncが手続きとして呼び出されているのか、
foo の引数の一部として扱われているのか直感的には分かりません。

/* sample 3 */
void hogehoge(void) {
　　　foo(argument_a,　argument_b,　
　　　　SomeFunc(argument_c),　argument_d);
}　　

しかし、前カンマにすれば、一目瞭然です。

/* sample 3 */
void hogehoge(void) {
　　　foo(argument_a ,argument_b
　　　　,SomeFunc(argument_c) ,argument_d);
}　　

このようにカンマの位置をひとつ工夫するだけで、ちょっとした手間を省くことができます。

一般的なコードの書き方とはちょっと異なるので嫌がる人もいるかも知れませんが、
たいして気になる程のものでもありません。皆さんも、試してみてはいかがでしょう？

プログラムの書き方

職業柄、他人の書いたコードをよく眺めるのですが、プログラムって書いたその人の個性が
よく出るものです。クレジットが明記されていなくても、あっ、これは誰々が書いたコードだな
とすぐに分かります。

自分にも癖があり、それに慣れてしまっているので、他人の癖のあるコードを見るのはちょっと
つらいものがあります。そこで、見やすくするために、indent などのプログラム整形ツールなど
を使って、自分なりの書式にあわせからソースの解析などを行います。

しかし、コード整形ツールで整形しても理解するのがつらいコードってあるんですよね。
今までの経験から、理解し難いコードは、特にif文の扱いに特徴が表れるようです。
大きくは以下の2点でしょうか。

１．if のネストが深いコード
２．if文の中で関数の戻り値を比較するコード

たとえば、以下のようなコードを見てみましょう。

/****************/
/* sample function */
/****************/

void hoge(int a, int b, int c) {
　　if (a != VALUE) {
　　　　if (hogehoge(b, c) != CONDITION) {
　　　　　　foo();
　　　　} else {
　　　　　　printf("hogehoge is in CONDTION\n");
　　　　}
　　}
　　return;
}

これは、単純な例なのでたいしたことないじゃん。などと思うかも知れませんが、これが
千行以上のコードになるとなかなかしびれるものがあります。if のネストも深すぎて、
すでに追うことが不可能なレベルになることもしばしば。

if のネストはできるだけ浅く、関数の戻り値を直接if文の中で比較しないというルールに
従うと、上のコードは以下のようになります。

/****************/
/* sample function */
/****************/

void hoge(int a, int b, int c) {
　　enum condition_list result;

　　if (a == VALUE) {
　　　　return;
　　}

　　result = hogehoge(b, c);

　　if (result != CONDITION) {
　　　　foo();
　　} else {
　　　　printf("hogehoge is in CONDTION\n");
　　}
　　return;
}

if 文のネストを浅くするコツは、関数を返せる状態ならすぐ返すことを心がけることです。

また、呼び出した外部関数の戻り値を if 文の中で直接比較せずに、一度受けることで、
CONDITION がどのような型で比較されているのか理解することができます。

いかがでしょう？ちょっとしたルールを適用することで、コードのロジックがとっても分かり
やすくなったと思いませんか？