【ゆかむアドベントカレンダー】10日目問題の切り分けについて - 業務エンジニアの攻撃は最大の防御ブログ

ゆかむと仕事について話していて、どうもゆかむはまだ「問題の切り分けにまだ慣れていない」と思っているように見えました。
よく言われる「難しい問題は分けて考えろ」というアレです。

問題の切り分けって、普段仕事をしてると無意識にできる時はできるます。でもできない時はできなかったりします。
あらためて、どういう風な思考経路を辿って問題を切り分けてるのかと考えだすと、ちょっといっぱつでは説明しにくいです。

なので分けて考えます。

問題を切り分ける時の思考経路は二種類に分けられると思います

1.過去に得た知識や経験を元に、細分化の粒度を考える
2.仮説ベースで切り分け方を模索する

1.過去に得た知識や経験を元に、細分化の粒度を考える
こちらは、過去に得た知見がフレームワークになり、そこに現在の問題をあてはめて考える方法です。
例えば、テーブル設計をやっていて、ある項目をテーブルを分けるか既存のテーブルの項目として持たせるかを迷った時に、過去の失敗や書籍で得た知識を元に切り分けていったりするやり方です。

2.仮説ベースで切り分け方を模索する
こちらは初めて経験する課題への対処です。
仮説を立てて検証したり考え方を深めたり観点を変えたり新たなデータを引っ張ってきたりして、問題の粒度の落ち着け先を模索するのです。
例えば、一度も経験した事のない機能の実装（仮にレコメンドエンジンにしましょうか）を任されたとします。
アルゴリズムはググったら色々と出てきます。でも細かい事を考えだすと色々とはまりそうです。ライブラリを使うのか自前で実装するのか、データ構造やクラス設計はどうするか、正解はないので色々と仮説を立ててやるしかありません。

1は知識や経験が増えれば増えるほど効率よくなります。当てはめるべきパターンのレパートリーを増やしていけばいいわけです。
しかし2はマインドやセンスに左右される気がします。私はヘタでなかなか上達しません。
これも慣れるしかないのか、良い考え方があるのか、私はまだ答を出せないでいます。

うーん、結論らしい結論には至りませんでしたが、とりあえず今日はこれでしめます（ごめん）