敏腕PMブログ

プロジェクトには、お客様側に「プロジェクトオーナー」という人がいます。
大抵、お客様の会社の社長や役員、事業部長がオーナーですね。

でもこのプロジェクトオーナーって、ほとんど現場には出てきません。
週次の定例会にはほぼ出ない、月一の報告会にもほぼ出ない。
現場からは見えないところで決済の承認だけをしていることもしばしば。

でも最終的に説得しなければならないのが、このプロジェクトオーナーだったりするのです。
で、そもそも会って話ができないので説得ができない。
ではどうやって説得すればいいのか？

会えなくても説得できる方法を考えるんです。
僕はよく、オーナーまで伝わるような資料を作って
現場担当者に託します。
「これ、渡しておいていただけますか」
と言って、現場担当者がオーナーに褒めてもらえるような内容も
盛り込んで渡します。

具体的には提案書、要件定義書、プロジェクト結果報告書、等々の資料をオーナーさんを
読み手と考えて書きます。
オーナーさんは、現場でしか見えない情報を「わかりやすく」「簡潔に」まとめた資料を好みます。

オーナーさんがその資料を気に入ると、いろんな人に回してくれます。
資料は一人歩きするものです。
だから一生懸命作らないといけない、機能する文章を書かないといけない、

以前２５歳くらいで”ITコンサルタント”を名乗っていたら、
「お前らみたいな若造に何ができるんだよ！」と言われたことがありました。
なかなか認めてもらえないので、自分達の仕事をありのままに表現する資料を作りました。
それがきっかけでお客さんと円滑に仕事が進むようになりました。

うまいこと資料を一人歩きさせる技術を身につければ、
プロジェクトをコントロールしやすくなります。

資料に関して「考えて、書いて、一人歩きさせて、反応を見て」という
PDCAをずーっと回し続けるのです。

—–

プロジェクトマネージャーには問題解決能力が求められます。
たとえばWEBサイトを運用していると、
「サイトが重たい」
状況が発生する場合があります。

PMは”サイトが重たい”という問題を解決しないといけないのですが、
いきなり
・メモリを増設しよう
・SQLをチューニングしよう
・プログラムロジックを見直そう
というアクションを起こすのはまだ早いです。

なぜなら、まだ問題が定義できていないから。
まずはサイトが重たい原因を特定することが先決で、
解決策をいろいろ考えるのはその後です。

問題の切り分け方として僕が意識するのは
「起きていることの正確な理解」です。

”サイトが重い”という情報だけでは少なすぎるので、さらに
掘り下げて何が起きているのか、を理解します。
殺人事件でいう現場検証ですね。
自殺か他殺か、凶器は？指紋は？目撃者は？
という感じでさまざまなことをヒアリングしたり調査します。

これ、すごく重要で、システムの問題だと思っていたら
誰かがオペレーションミスをしただけ、という運用の問題という
オチもあるので聞き込みはしっかりやります。

サイトが重い場合には
・データベースからレスポンスが返ってきていない
・アクセス集中でサーバの負荷が高い
・不要なループプログラムがメモリを食い尽くしている
といったように、１つの事象からでもさまざまな要因が考えられます。

上記要因は単なる一般論なので、根拠を立てるために
聞き込み結果とシステム基礎数値の面からアプローチします。
プロセス数、CPU使用率、メモリ使用率、アクセス数、等々
事象を理解するための手がかりはシステム側からも取得できます。

たとえば、昨日の100倍のアクセスがあったのならば、それが原因の可能性が高いですし、
メモリが振り切れるまで使われているなら、プログラムのどこかでメモリを大量に喰う処理を
している可能性が高いです。

このようなプロセスを経て問題の原因が突き止められてから初めて、
・アクセスに耐えられるサーバ構成にしよう
・メモリを喰わないようにプログラムを変更しよう
という問題解決のプロセスに入ります。

殺人事件には必ず犯人がいます
システムトラブルには必ず原因があります
人間は嘘をつきますがシステムは嘘をつかないので、
後者のほうが解決しやすいんでしょうねー。