メディア

リーダーとしての問題解決能力を磨く：初めてのプロジェクトリーダー（5）

　今回は、特にプロジェクトの終盤に発生すると厄介なさまざまな問題への対応について、まずその基本的な心構えの説明をし、次にいくつかケーススタディをみていきましょう。

» 2005年07月08日 12時00分公開

[岡島幸男，永和システムマネジメント]

［基本的な心構え］

　問題といっても、技術的な問題や、人間系の問題などさまざまな種類があり、問題の具体的な解決方法は当然ながら千差万別です。そこで、まずは問題解決に対する基本的な心構えの説明から入りましょう。この「基本的な心構え」は、「思考フレームワーク」と読み替えてもらってよいでしょう。つまり、問題解決を図るに当たっての思考の枠組みです。


技術的な問題	人間系の問題
本番環境でのみ発生する ……	いったいわない ……
ミドルウエアのバージョンアップで ……	スケジュールを守ってくれない ……
間際でアーキテクチャ大修正 ……	板ばさみ ……

真実より事実

　まず大事なのは、何より事実をつかむことです。これは技術的な問題ではもちろんのこと、人間系の問題についても同様に大事なことです。主観は必要ありません。まずは発生したそのままの、客観的な事実を集めます。

　技術的な問題であれば、まず現象を把握し記録しましょう。これは、ログファイルや、実験という形で収集できるはずです。人間系の問題であれば、相手がどのようなことをいったのか、いっているのか、正しく聞き出しましょう。どちらにせよ、余計な推測や思い込みは危険です。「真実」の出番は、問題が解決してからです。真実は、すべてが終わった後に作られればよいのです（これが報告書なのです）。

分類と切り分け

　次にやるべきことは、問題の分類をすることです。分類といってもいろいろありますが、まずは、以下の観点で問題を整理、分類します。

別々の問題が交ざっていないか、切り分ける
同じ原因で、違う現象が発生している問題を整理する
問題の本質ではない事柄を排除する

　分類のコツは、「シンプルイズベスト原則」にのっとり、より少なくしていくことです。

理論と理屈

　問題の分類と切り分けが終わった段階で、事実はほぼ整理されたはずです。分類の途中で問題が解決されることもあるでしょうが、ほとんどの厄介な問題は、ここからさらに推論していく必要があります。技術的な問題であれば、原因を特定するために、再現実験を行って検証する必要があるでしょう。その際に、すでに確認された現象や、原因だけではなく、まだ漏れている（足りない）現象、原因を推論によって埋め合わせていくことも必要です。

　大事なのは、理論（ロジカルさ）と、理屈です。これらが欠けると、（技術的な）問題が一見解決できたように見えても、一時しのぎにすぎず、その後さらに大きな問題を発生させ、人間系の問題にまで発展する可能性があります。

現実的な解決策

　問題の原因が特定できたとして、その解決策が現実的でなくては意味がありません。例えば、問題を解決するためには、新しいバージョンの製品を購入しなくてはならず、その価格が、予算をオーバーしてしまう、なんて解決策は現実的ではないのです。

　現実的な解決策をリストアップして、優先度を付けます。もちろんその際には、お客さま（やほかのステークホルダ）の意思を尊重するのは大事ですが、あなたの判断である、「なぜこの解決策がベターか」という理屈を説明できるようにしましょう。

　開発チームだけでなく、お客さまも問題が発生すれば苦しいのです。着実に現状を良くできる解決策が必要です。

責任の取り方

　責任を取るとは……、問題が解決するまでお客さまやメンバーと一緒にいるということです。

［ケーススタディ］

　では、いくぶん単純化していますが、ケーススタディに入っていきましょう。まずは、技術的な問題の代表格である。「パフォーマンス問題」からです。

パフォーマンスが出ない

　特に本番環境でのテスト（実データを使ったテスト）に露見しやすい問題です。

当初のデータ容量見積もりなどをしっかり行っていない場合に発生します
運用を続けると（データが増えてくるに従って）発生する場合があります
アプリケーション設計を（しっかり）行っていないと発生する場合があります
パフォーマンスが課題として認識されていないと発生します

　つまり、以上の逆を行えば、このような問題は発生しにくくなりますが、まだテスト中に発生したのであれば打つ手はあります。次のステップで解決を図ります。

1. 計測する

　まずは事実を集めます。できる限り運用時の環境に近い状態で計測を繰り返します。測定はボトルネックとなっている処理がはっきりと見えるように、細かく行います。

2. 目標を設定する

　例えば、大量のデータの更新処理には、それ相応の時間がかかります。パフォーマンス改善の目標値を処理の分類ごとに設定します（本来、これは要件定義時に設定しておくべき項目です）。何でもかんでも速くしよう、などといったあいまいな目標ではなく、現実的な値を設定する必要があります。

3. 分類し、分析する

　計測結果があまりにも遅いのであれば、逆に問題は解決しやすくなります。問題の原因が特定しやすいからです。例えば以下のような原因です。

複雑なSQLとなっているため、想定しているインデックスが使われていない
ロックが発生することによって待ち状態が発生している

　逆に、微妙に遅い場合は、もう少し厄介です。ほとんどの場合、アプリケーションの設計に問題がある場合が多いからです。

4. 解決する

　原因を突き止めた後は、対処を行って再度計測を行います。なお、問題解決を図っている場合に注意しなくてはいけないのは、「ほかの問題を見つけた場合でも、それらの問題をごっちゃにしない」ということです。特にソースコードを見ながら解決を行っている場合は、ついつい、さまざまな「怪しい」部分が目に付いてくることがあります。このような場合でも、問題を切り分けて、まずは目の前の問題解決に集中します。

リファクタリングしたら、動かなくなりました

　ソフトウェア業界では、「動いているモノには触るな」という格言があります。これを覆すのが、「リファクタリング」です。むしろ、積極的に動いているものに触り、より良いソフトウェアに改善していきます。

　あなたがリファクタリングを許可する絶対条件は「テストをすること」です。このテストは、限りなく自動化されていなくてはいけませんし、もしも自動化テストがない場合は、手動（目）での確認が必要です。運用間際のちょっとした修正により発生した問題は、お客さまの印象がとても悪くなり、修正に必要なコスト以上のダメージを受けることになりますので、細心の注意を払ってください。なお、簡単な修正では不具合を見逃す場合もあります。プロジェクトの終盤では、どんなに簡単な修正でも、きっちりと確認してください。

いったいわない

　最後に、人間系の問題を1つ挙げておきましょう。典型的な問題として「いったいわない」があります。第3回「朝会を15分で終わらせるには理由がある」の記事にあるように、打ち合わせのたびにしっかりとした議事録を書いておけば、基本的にはこの問題は発生しない……はずなのですが、完全に防ぐことは不可能です。お客さまだって、常に一貫した思考や発言を続けることは無理だからです。議事録を突き付けるのは最後の手段にしましょう。

　いったいわない問題に陥らないためには、お客さまを含めたチーム全体として、いかに問題に対処すべきか上手に切り替えていく必要があります。キーワードは、「Problem vs. us」です。

　「そもそも、何を目的にしてやっていたのか？」を、もう一度お客さまを交えて再認識し、課題を共有する場を開きましょう。問題を、人間関係のいざこざに陥らせないようにするのが重要です。

　以上、簡単ですが何点かケーススタディを挙げました。もちろん、現実の問題は、もっとさまざまなバリエーションと、深さがありますので、一筋縄ではいかないことも多いと思います。しかし、今回説明した心構えを持ったうえで場数を踏めば、問題解決能力は着実に向上していくはずです。

　次回は、主にプロジェクト終盤の話をする予定です。チームの継続的な改善に効果的な「プロジェクトの振り返り」が中心テーマです。

「初めてのプロジェクトリーダー」バックナンバー