システム開発における問題解決の方法（私家版）

忙しいときに質問されたら「ここに書いておいたから読んでおいて」というためのブログ記事。システム開発では様々な問題に直面することになるが、その解決方法について経験的に有効だと思う方法について書き連ねておく。考えが変わったらあとでアップデートするかもしれない。私はこうやっているよ、という話。

基本としての「いかにして問題をとくか」

もっとも汎用的な問題解決の手法としては、有名なポリアの「いかにして問題をとくか」を参考にすると良い。書籍は名著だと思うが癖があるので購入する場合はサンプルを確認することをお薦めする。骨子はWikipediaで確認できるのでそれを読むだけでも十分である。書籍ではこの内容を深める（独特の）エッセーが読める。

いかにして問題をとくか - Wikipedia

いかにして問題をとくか

作者:G．ポリア
丸善出版

Amazon

（2022年より前に刷られた活版印刷版が特に味わい深い。書店の在庫や古書店をチェックしてみよう）

まあひとことで言えば次の4つのステップだ。

問題を理解する

計画を立てる

計画を実行する

ふりかえる

あ、あたりまえじゃねーか......と思うかもしれないが、この基本ステップをちゃんとできていない例は多い。ぱっと思いつくだけでも次のようなことが起こりがちである。

問題と願望（こうであってほしい）が混ざり合って、問題を正しく理解できていない。「起こったことだけ教えて」
問題と現象が混ざり合って、問題を正しく理解できていない。「何が問題なの？」
前提知識が不足しすぎて、問題を理解できていない。「問題はどこで起こっているの？」
計画がない。「こどものサッカーか？」
計画がないので無限に時間を溶かしている。「次のチェックポイントは何時？」
計画どおりにやっていない。途中でうまくいかないで別のことを試し始める。「なんで別のことをやってるの？」
ふりかえらずに時間を溶かしている。「で、ここまでで何がわかったの？」

おかしくなった系に有効な「問題の記述」メソッド

ある時まではうまく動いていないものがおかしくなったというパターンは、Brendan Greggの「詳解システム・パフォーマンス第2版」で紹介されている「問題の記述」メソッドが有効だ。

詳解システム・パフォーマンス第2版

作者:Brendan Gregg
オーム社

Amazon

問題の記述は、サポートスタッフが問題に最初に対処するときのルーチン作業である。顧客に次の項目を尋ねて書いていく。

パフォーマンスに問題があると思ったのはなぜか。

このシステムは、良好なパフォーマンスで動いていたことがあったか。

最近の変化は何か。ソフトウェアか、ハードウェアか、負荷か。

その問題はレイテンシか実行時間で表現できるか。

その問題はほかの人やアプリケーションに影響を及ぼしているか（それとも、影響があるのはあなただけか）。

環境はどうなっているのか。どのソフトウェア、ハードウェアを使っているのか。バージョン、構成はどうか。

単にこれらのことを尋ね、答えを聞くだけで、直接的な原因や解決方法がわかることがよくある。そこで、ここでは独立したメソドロジとして、問題の記述を入れてある。新しい問題に立ち向かうときには、最初のアプローチとしてこれを使うべきだ。
詳解システム・パフォーマンス第2版、2章メソドロジより引用

同書はパフォーマンスに関する本なので当然パフォーマンスのことを問うているが、ここを適宜読み替えて（たとえば「機能」とか「画面」とか）使えば良いだろう。自分もよく使っている。

あとはテクニックより知識量

世の中には上記以外の問題解決の手法が大量にある（例えば「問題解決大全」は大変良い本である）のだが、どちらかというと問題解決の手法そのものより、問題を含む全体構造を把握するほうに力を入れたほうが良いだろう。システムに関する問題であれば、アーキテクチャや、インフラに関する全体像がわかっているかどうかがポイントとなる。設計であれば代表的なパターンを知っているかがポイントとなる。

悩ましいのは、問題に直面してから調べ始めると間に合わないという点である。というわけで、突き当たりそうな問題を先読みして、学習を進めておくと良いだろう。

自分が参考にしているような本を参考までに列挙しておこう。