PONOS Advent Calendar 2024の9日目の記事です。
はじめに
最も問題を引き起こさない方法は、何も書かない事です。コードが増えれば問題も増えます。
「挑戦には失敗がつきもの。失敗とどう向き合うかが大事だ。」みたいな事を誰かが言ってたような。絶対言ってますね。誰かはわかりませんが。
ということで、初心に立ち帰り「失敗への向き合い方」ならぬ「問題への向き合い方」で、大事にすべき事を書いてみたいなと思いました。
ちなみに、新撰組には厳しいことで有名な局中法度がありますよね。士道不覚悟！と言われた方がなんかビシッときませんか？自分への戒めもこめ、それに倣ってみたいと思います。
１０ヶ条
その壱： 機構を悉皆に知見すべく、力尽くすべきなり
大前提となるのが、対象のシステムをどこまで理解できているかではないでしょうか。
全てを理解する事は難しいですが、点の理解だけで問題を解決しようとすると失敗することは想像に難くないと思います。
問題が起きている箇所だけでなく、できる限り点と線と面で問題を捉える必要があります。
「これは何をしている？」「これはどうなってるの？」と聞かれて「わかりません」「見ていません」となってないでしょうか？
その弍： 可能な限り再現せんこと
言わずもがな、問題を再現できるかどうかは非常に重要。
究極的には素粒子レベルで全く同じ状況を作り出し、同じ入力をすれば同じ結果が得られるはずです（？）
再現できれば、理論上はその全てを調べれば絶対に答えに辿り着けます。理論上は。
手元で100%再現する事が難しい場合もあります。その場合でも出来るだけ条件を明らかにしていく（ピースを埋めていく）事はできます。状況が明らかであればあるほど、より正確な推理ができます。
そんなハズはないというバイアスはかかっていませんか？
情報はできる限り確認しましたか？
実際に起きていることが事実であるにもかかわらず、簡単に「再現できません」と言う結論に至っていませんか？
その参： 分別して思索すべきなり
基本のキですが、問題は一体として見るだけでは難しいので、切り分けて絞り込んでいくのが定石ですね。
「データをサーバに保存する処理がうまくいきません」
「送信に失敗しているの？サーバの保存に失敗しているの？」
みたいな事。
これは一番直感的で、「当たり前やん」というリアクションになるところですが、切り分け方のうまい下手はあると思います。
いくつかのパターンを試そうとして同時に複数の条件をかえていて、効率的でない切り分けになっていませんか？
同じブランチで色々試していて、結局前回の切り分けた状態がどうなってたかわからなくなってませんか？
その肆： 事実と意見の混同を許さず
自分の中で混同していたら、思い込んだまま進んでしまうことがあります。他人に混同して伝えたら、間違った認識をされてしまいます。
例１：
開発者A:「一部のユーザからレスポンスが遅いという問い合わせがありますね。」
開発者B：「ログを確認したところ特定のクエリが遅延している。データベースのスケーリングの問題だろう。アップグレードするためのメンテナンスを行いましょう。」
クエリが遅延していることは事実ですが、それがデータベースのスケールによるものかどうかは仮説にすぎません。
例２：
開発者A：「昨日の負荷試験でエラーは出ていた？CPU使用率はどれくらいだった？」
開発者B：「確認した限りエラーは大丈夫そうでした。パフォーマンスも良好ですよ。」
回答をしているようで、厳密にはしていません。大丈夫そうって何？となります。
エラーが1件もないのか、それともちょっとだけだけど問題ないと勝手に判断したのかわかりませんし、パフォーマンスに対する回答も同様です。
その伍： 文書を読まざる行為は禁忌なり
説明書を読まずに苦戦している人をみたことはないでしょうか？気持ちはわかります。面倒ですよね。触ればわかるやろの精神ですよね。
でも、仕事では「これ読んだ？」って突っ込まれないよう、公開されている情報があるならできるだけ調べましょう。
知っていることでも、変わっていることもあります。
その陸： 集団の知識は確認すべし
自分がぶつかっている問題が世界初という可能性はあまりありませんから、多くの人はWEBで検索すると思います。
でも、検索エンジンは技術的な正しさに基づいて検索結果を表示しているわけではありません。知りたい情報が上のほうに出てこないこともあります。
少なくとも公式コミュニティ、ISSUE、更新情報などは最低でも調べた方がいいです。
その柒： 情報には疑念を持つべし
ネット上の情報は間違っていることが多々あります。間違っていなかったとしても、その後の更新によって既に古くなっている事も多々あります。最近は「AIが間違った回答をする」的な話題をよく聞きますが、そもそもそれは他でも同様です。
普通は自分がわからない、もしくは知らないことを調べるために情報を探しています。ということは、自分にはそれが正しいかどうかを判断できる情報もないんだという事を念頭においておかなければいけないのではないでしょうか？
もちろん正しいケースの方が多いと思いますが、一次ソースを確認したり、情報の裏付けをとる習慣は必要です。
その捌： 問題は整頓し解き明かすべし
問題を切り分けて原因を追求したり、仮説検証をする時についついフリーハンドでやってませんか？
きちっと把握できているなら問題はありませんが、だんだんと「どの条件の時は成功してたんだっけ？」「あの時はどうだっけ？」と混乱してくると本末転倒です。
問題を整理するフレームは色々あると思います。複雑な問題は誰が見てもわかるように整理しましょう。脳のメモリだけで作業する必要はないですし、情報として整理できなければ、頭の中でも整理されていないかもしれません。
その玖： 関与する者との交流は積極的に試みんとす
あらゆる場面でコミュニケーションは重要です。
原因を特定するために他者の知見を得る（外部に対しても）ということはもちろんですが、時にはステークホルダーとのコミュニケーションも重要です。
全ての問題が必ず完全にクリアにできるとは限りません。プログラマが向き合う問題は仮にシステム上の不具合だとしても、その不具合によって引き起こされるプロジェクトリスクは多岐に渡ります。
詳細は書きませんが、リスクマネジメントには4つの選択があります。
| 選択肢 | 内容 |
|---|---|
| 回避 | 抜本的にリスクを回避する手段を取る。 |
| 転嫁 | リスクを外部に移す判断。自分たちでメンテし続けるのがリスクだから外部ライブラリを使うなども含まれる。 |
| 軽減 | 確率や頻度を下げる判断。 |
| 受容 | リスクを受け入れる判断。 |
問題を解決に導くにあたり、どのような手段があり、どのような選択肢を取るべきか、認識の相違なくゴールまで進めなければなりません。
その拾： 時には安息を楽しむべし
疲れすぎて赤信号を渡ってしまう経験はありませんか？無い事を切に祈ります。
十分に脳を使うには、時には休ませる必要があります。大事な判断ならなおさらです。散々考え抜いてどうにもならず、家でお風呂にはいってたらふと答えが出てくるという経験は多くの方がされてますよね。
どうにもならない時は休んでください。
まとめ
言ってみたいだけなんちゃうかと思われそうですが（実際それもありますが）、どれも真面目に感じていることです。
時々見直して見たいと思います。
それでは次回は@sumbornさんです。