忙しいときに質問されたら「ここに書いておいたから読んでおいて」というためのブログ記事。システム開発では様々な問題に直面することになるが、その解決方法について経験的に有効だと思う方法について書き連ねておく。考えが変わったらあとでアップデートするかもしれない。私はこうやっているよ、という話。
基本としての「いかにして問題をとくか」
もっとも汎用的な問題解決の手法としては、有名なポリアの「いかにして問題をとくか」を参考にすると良い。書籍は名著だと思うが癖があるので購入する場合はサンプルを確認することをお薦めする。骨子はWikipediaで確認できるのでそれを読むだけでも十分である。書籍ではこの内容を深める(独特の)エッセーが読める。
(2022年より前に刷られた活版印刷版が特に味わい深い。書店の在庫や古書店をチェックしてみよう)まあひとことで言えば次の4つのステップだ。
- 問題を理解する
- 計画を立てる
- 計画を実行する
- ふりかえる
あ、あたりまえじゃねーか......と思うかもしれないが、この基本ステップをちゃんとできていない例は多い。ぱっと思いつくだけでも次のようなことが起こりがちである。
- 問題と願望(こうであってほしい)が混ざり合って、問題を正しく理解できていない。「起こったことだけ教えて」
- 問題と現象が混ざり合って、問題を正しく理解できていない。「何が問題なの?」
- 前提知識が不足しすぎて、問題を理解できていない。「問題はどこで起こっているの?」
- 計画がない。「こどものサッカーか?」
- 計画がないので無限に時間を溶かしている。「次のチェックポイントは何時?」
- 計画どおりにやっていない。途中でうまくいかないで別のことを試し始める。「なんで別のことをやってるの?」
- ふりかえらずに時間を溶かしている。「で、ここまでで何がわかったの?」
おかしくなった系に有効な「問題の記述」メソッド
ある時まではうまく動いていないものがおかしくなったというパターンは、Brendan Greggの「詳解 システム・パフォーマンス 第2版」で紹介されている「問題の記述」メソッドが有効だ。
問題の記述は、サポートスタッフが問題に最初に対処するときのルーチン作業である。顧客に次の項目を尋ねて書いていく。
- パフォーマンスに問題があると思ったのはなぜか。
- このシステムは、良好なパフォーマンスで動いていたことがあったか。
- 最近の変化は何か。ソフトウェアか、ハードウェアか、負荷か。
- その問題はレイテンシか実行時間で表現できるか。
- その問題はほかの人やアプリケーションに影響を及ぼしているか(それとも、影響があるのはあなただけか)。
- 環境はどうなっているのか。どのソフトウェア、ハードウェアを使っているのか。バージョン、構成はどうか。
単にこれらのことを尋ね、答えを聞くだけで、直接的な原因や解決方法がわかることがよくある。そこで、ここでは独立したメソドロジとして、問題の記述を入れてある。新しい問題に立ち向かうときには、最初のアプローチとしてこれを使うべきだ。
詳解 システム・パフォーマンス 第2版 、2章 メソドロジ より引用
同書はパフォーマンスに関する本なので当然パフォーマンスのことを問うているが、ここを適宜読み替えて(たとえば「機能」とか「画面」とか)使えば良いだろう。自分もよく使っている。
あとはテクニックより知識量
世の中には上記以外の問題解決の手法が大量にある(例えば「問題解決大全」は大変良い本である)のだが、どちらかというと問題解決の手法そのものより、問題を含む全体構造を把握するほうに力を入れたほうが良いだろう。システムに関する問題であれば、アーキテクチャや、インフラに関する全体像がわかっているかどうかがポイントとなる。設計であれば代表的なパターンを知っているかがポイントとなる。
悩ましいのは、問題に直面してから調べ始めると間に合わないという点である。というわけで、突き当たりそうな問題を先読みして、学習を進めておくと良いだろう。
自分が参考にしているような本を参考までに列挙しておこう。
- ソフトウェア見積り 人月の暗黙知を解き明かす
- 見積トラブル用。俺氏SIer
- ソフトウェア要求 第3版
- 要件定義の問題向け
- 詳解 システム・パフォーマンス 第2版
- 性能含む問題全般向け
- 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践
- Web系の問題向け
- スーパーユーザーなら知っておくべきLinuxシステムの仕組み
- Linux系の問題向け
- パケットキャプチャの教科書
- ネットワークの問題向け
- 仕事の問題地図 ~「で、どこから変える?」進捗しない、ムリ・ムダだらけの働き方
- 職場の課題解決用
- 組織パターン
- 組織の揉め事
- チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
- 組織設計関連
- THE TEAM 5つの法則 (NewsPicks Book)
- チームの問題
- ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
- アーキテクチャ関連
- システム設計の面接試験
- アーキテクチャ関連
上記は割と何度も開いているという基準でピックアップしたけれど、忘れている本もあるかもしれないので思い出したら更新する。