■プロジェクトマネジメントの応用 １６（ソフトウェア開発編）
◆ＳＱＡ，ＰＭＯが役割を果たす
昨今，プロジェクトの規模が大きくなったり，組織的な活動が習熟してくると，開発メンバーをサポートする部隊が，プロジェクトに加わるケースが出てきている。つまり，名称はいろいろあるが，PMO（プロジェクト・マネジメント・オフィス）といったり，SQA（ソフトウェア・品質保証部隊）と云ったり，プロジェクトを第三者的な立場でサポートする組織が作られている。
SQA，PMO活動の必要性
先ず，SQA，PMOと云った役割がなぜ必要なのかを述べておこう。プロジェクトには，開発リーダ始めとする開発メンバーで構成される。品質保証活動は，プロジェクトとは違った縦割り組織の組織があって，その部門が，市場への品質確保など品質に関することを一手に引き受けている（自動車関連では，これまでの呼び名から検査部門と称されることも多い）。
ところが，これまでのハードウェア中心のプロジェクトに比較して，ソフトウェア開発では，品質確保の中枢が初期の段階の設計に纏わることが多く，開発がある程度進行してからの品質保証の参画では手遅れになる事態が多くなり，品質保証部門とは別に，或いは品質部門の中にSQA部門が作られることがある。PMOも同様，プロジェクトのプロセスをコントロールするなど，プロジェクトの進捗をスムーズに行う為に，開発に近い存在として組織化される場合が多い。
それほどハードウェアとソフトウェアの開発に違いがあるのか，と云った点でよく観察すると，開発リーダがしっかり旗振りできていれば大差はないのであるが，ことソフトウェアにおいては，そのバラツキが顕著に現れ，いい加減な設計をされると，市場での品質問題が収拾つかないほどひどいことになる場合がある。要は，いくらテストで修正を加えても，最初の設計が悪いと直しようが無い出来映えになってしまうのである。
また，ソフトウェア開発の中心は，やはりその性格上若いメンバーが中心であり，開発リーダと若い人が抜擢されることが多い。その開発リーダの多くは，ソフトウェア開発のスキルは高くとも，マネジャーとしてのスキルは磨き切れていないケースが多い。プロジェクト・マネジメントを十分習得，経験できていないながら開発リーダを任される。そうなると，自分一人でスキルを縦横無尽に使い担当部分の役割を果たしていたときとは，全く違ったスキルが要求される。即ち，メンバーを使ったチーム力の発揮である。これがなかなか難しい。
ここで必要となるのが，開発から少し離れた第三者の眼である。即ち，プロジェクトを総合的に見て，判断・指摘・支援などをするSQA，PMOの存在で，この役割が，開発リーダを伸ばし，一人前のプロジェクトリーダに育てることになる。
優秀な人が充てられないのが一番大きな問題
殆どの組織での実態であるが，SQA，PMOなどその役割の重要性は誰もが認識しているが，なかなか優秀な人が充てられていないのである。開発には年老いて切れが無くなった人，或いは元々開発のスキルは無く，品質管理を中心に仕事をしてきた人などが担当していることが多い。中には，外部の経験豊かな人材を請負や派遣の形で活用しているケースも見受けられる（実際，私自身が経験してきた）。
本来の役割として，最重要なことはプロジェクトリーダの参謀役的な存在として，リーダをサポートし，プロジェクトを成功に導くことにある。規定通りかどうかチェックしたり，監査的なことをする仕事は役割としてあるが，どちらかと云えば二次的な役割（オペレーションとしての仕事）なのである。しかし，多くのSQA，PMOのメンバーは二次的な仕事を中心に展開している。むしろ，そうした仕事しかできないメンバーが充てられていると云った方が正しい。
その二次的と見なす仕事が決してムダではない。必要な仕事ではあり，一般的な役割としては，どこにでも書かれている仕事なのである。しかし，こうした二次的な仕事を中心にした活動で，開発リーダに接すると，どちらかと云えば，補助的な，開発の援助・支援をする仕事として見なされ，決して対等的な役割の仕事とは見なされない。参謀役には成り得ないのである。参謀役がそれでは開発リーダと対等かと云えば，決してそうとは言い難いが，しかし頼りになる度合いには雲泥の差がある。参謀役として，必要あらば，開発リーダの耳の痛いことも進言することをしなければならないのである。
SQAやPMOの役割を述べるのは，他の参考書物を見て貰えば十分なので，ここでは詳しく述べることはしないが，本来の役割からすれば，開発リーダの参謀役，指南役的な，開発経験豊かな人材（必ずしもベテランでなくともよい）が充てられるべきで，マネジャークラスになれば，そこそこの経験者が充てられているが，その下の実務者のメンバーには，切れ者は見当たらないのが実態であり，開発者不足から開発メンバーを回せない実態もよく判るが，少なくとも一人でも，切れる人材をあてがうことが，一番，SQAやPMOの役割を果たすことになると思っている。
不十分なメンバーでの対応方法
それでは，優秀な人が充てがわれない組織での対応方法はどうすればよいのか？優秀なメンバーがいないので，SQAやPMOの活動ができないと居直っていても始まらない。組織内の誰一人，開発経験が無いと云うことも無かろう。組織責任者，或いは開発経験が一番豊かな，開発のリーダの参謀役になれそうな人がリーダ役となって，メンバーを切り盛りすることが必要となる。
メンバー一人ひとりの対応でなく，すべてのプロジェクトに組織として対応できる方法を工夫することである。組織で対応と云ってもやはり各プロジェクトには担当を割り当てることが必要で，メンバー一人で当該のプロジェクトをフォローさせるのではなく，チームとして各プロジェクトの問題点を把握できるようにすることで，そのためには各プロジェクトの担当者がプロジェクトに張り付いて，見聞きしたことをチーム内で報告，それに対してメンバー始め，経験豊かな人が適切なアドバイスを与え，それを基に，担当者がプロジェクトへフィードバックを掛けるようにすれば，少しはチーム活動的な展開が図れる。
或いは，定期的な報告書（１回／月）などの作成を検討し，その報告書の作成に当たって，当該のメンバーがプロジェクトから気づいたことを指摘，意見を先ず作成するが，それらを基に。メンバー全員でレビューして，報告書を吟味し，レベルアップさせた組織としての報告書として発行し，開発側に提言する形態にすることも一つの方法である。或いは，毎週実施される開発側の会合にて，これも事前に組織で揉んだ中身に仕上げて，メンバーが代表して意見を言うことでもよい。
ただ，これも限度があって，こうすることで視野を広げ，伸び代を伸ばすメンバーは期待できるが，全く期待できないメンバーも居る。特に，開発経験が全く無いメンバーは気づきさえもできない。半年から1年間程度様子を見て，不的確と見なした場合は，本人の為にも仕事を変えてあげた方が望ましい。また，外部の請負や派遣の経験豊かな人の知識を上手く使い，コンサル的な役割をして貰って，メンバーの仕事の補助，支援をして貰うことでも良い。
とにかく，決まり切ったオペレーションを繰り返す仕事に終始するのではなく，小さな気づきで良いので開発リーダに視点を変えたアドバイス的なことが進言でき，プロジェクトの成功に向けた一員としてSQA，又はPMO活動認めて貰えるようになれば十分である。是非とも，これに近い状態になれるように，経験豊かな人がリーダ的役割を果たして戴きたいものである。
SQA，PMO活動のポイント
本来の役割は他の参考書物を見て欲しいと言ったが，最後に活動のポイントについて述べておく。
①ソフトウェア開発計画書がきっちり書けているか？
ソフトウェア開発計画書が内容的に充実し，成功に向けてのストーリーが描けているかどうかは，プロジェクトの成否に大きく影響を及ぼす。形式的なチェックではなく，リーダの成功への自信の度合いなど含め，成功する確率が高いかどうかを判断する材料としての見極めを行う。この計画が不十分，又はリーダの自信の度合いが低い場合は，どこに問題点があるかを見定め，早い段階で解決するように導くことが重要である。
もちろん，開発に計画書を求める以上，SQA，PMOとしての活動もソフトウェア開発計画書を基にして，実施計画を立てて推進することは言うまでもない。
②リスク抽出が確実にできているか？
進捗管理でも述べたように，プロジェクトの進捗状況におけるリスク管理は重要で，常にリスク抽出ができているか，即ち，プロジェクトの先読みができているかどうかを見ることは，成否を判断する上での重要な視点である。
③進捗管理が一次情報（現場確認）を基になされているか？
一見すると問題が無いように見える進捗管理にも落とし穴がある。サブリーダ，或いは間に入ったブリッジエンジニア（オフショア開発など）だけの報告をそのまま鵜呑みにしているようでは心許ない。必ず，重要な点，或いは，実力を判断するポイントなどでは，現場第一線の情報を入手して判断が行われているかどうかを確認しよう。
④リーダの意志がメンバーに十分伝わっているか？（コミュニケーション）
プロジェクトの成否は人の和であり，目標に向かっているベクトルの一致であり，リーダの指揮命令が統率が取れて行われているかどうかは，非常に重要である。この点を，日常活動を通じて見極めることが必要である。意思疎通に問題がある箇所を発見した場合，原因究明，対策案を含め，リーダに進言しよう。
⑤大きな壁で停滞していないか？
プロジェクトに壁（課題，障壁など）は付きもので，これらを如何に乗り越えて目標に向かうかが成否を大きく左右する。僅かの停滞や問題点を逐一リーダに報告するのは，逆に鬱陶しく感じられることもあるので，壁の大きさを見極めながら，大きな問題に発生しそうなことは，事前に打開策を含めて進言しよう。
⑥計画と実績のフォローができているか？
プロジェクトの進捗は，愚直なほど計画と実績を比較しながら進めることであり，その差が大きければ分析，解明して対策を打ちながら計画通りに修正することにある。これができないようでは，プロジェクト・マネジメントができているとは言えないので，この点をきっちり確認することが重要である。
もちろん，予測できない事態の発生，外部・内部要因の変化が伴うので，計画を修正せざるを得ない事態は起こる。そうしたときの対処方法も，速やかに，計画的に，確実に実施できるかどうか，よく見極めよう。
⑦リーダがプロジェクトの成功への自信を持っているか？
プロジェクトの成功の可否はリーダに依存する部分が大である。そうした意味で，リーダ自身がプロジェクトの成功に対して自信を持った動きができているかどうかをよく見る必要がある。自信の無い場合は，どこに問題（自信のなさ）を抱えているか，その障壁となっていることは何かなど，第三者的な立場で冷静に判断して助言をしよう。
[Reported by H.Nishimura 2011.10.06]
Copyright (C)2011 Hitoshi Nishimura
