問題解決にはまず問題の定義から
2009 年 6 月 4 日 木曜日
プロジェクトマネージャーには問題解決能力が求められます。
たとえばWEBサイトを運用していると、
「サイトが重たい」
状況が発生する場合があります。
PMは”サイトが重たい”という問題を解決しないといけないのですが、
いきなり
・メモリを増設しよう
・SQLをチューニングしよう
・プログラムロジックを見直そう
というアクションを起こすのはまだ早いです。
なぜなら、まだ問題が定義できていないから。
まずはサイトが重たい原因を特定することが先決で、
解決策をいろいろ考えるのはその後です。
問題の切り分け方として僕が意識するのは
「起きていることの正確な理解」です。
”サイトが重い”という情報だけでは少なすぎるので、さらに
掘り下げて何が起きているのか、を理解します。
殺人事件でいう現場検証ですね。
自殺か他殺か、凶器は？指紋は？目撃者は？
という感じでさまざまなことをヒアリングしたり調査します。
これ、すごく重要で、システムの問題だと思っていたら
誰かがオペレーションミスをしただけ、という運用の問題という
オチもあるので聞き込みはしっかりやります。
サイトが重い場合には
・データベースからレスポンスが返ってきていない
・アクセス集中でサーバの負荷が高い
・不要なループプログラムがメモリを食い尽くしている
といったように、１つの事象からでもさまざまな要因が考えられます。
上記要因は単なる一般論なので、根拠を立てるために
聞き込み結果とシステム基礎数値の面からアプローチします。
プロセス数、CPU使用率、メモリ使用率、アクセス数、等々
事象を理解するための手がかりはシステム側からも取得できます。
たとえば、昨日の100倍のアクセスがあったのならば、それが原因の可能性が高いですし、
メモリが振り切れるまで使われているなら、プログラムのどこかでメモリを大量に喰う処理を
している可能性が高いです。
このようなプロセスを経て問題の原因が突き止められてから初めて、
・アクセスに耐えられるサーバ構成にしよう
・メモリを喰わないようにプログラムを変更しよう
という問題解決のプロセスに入ります。
殺人事件には必ず犯人がいます
システムトラブルには必ず原因があります
人間は嘘をつきますがシステムは嘘をつかないので、
後者のほうが解決しやすいんでしょうねー。
