課題解決の壁にぶち当たった話

エンジニアとして働いてて久しぶりに力不足で壁にぶち当たったことがあったので記録として残しておきます。

なぜそう感じたかというと 世の中に情報がほとんどない状態でどう課題を解決するか という状態で自分は課題解決や課題調査をしたことがないままここまでやってきてしまっていて、最近その問題にぶち当たって完全に「なんの成果も上げられません」状態に陥ってしまったからです。

具体例は別途技術ブログの方で書いてあるので割愛しますが、エッセンスを抜き出すとあるエラーがどうして発生するのか調べるという課題がありました。

このある課題、ここではある条件下において何かしらのエラーが発生する課題とします。

おおよそこういったケース課題をまずは調べるの最初のとっかかりはエラーメッセージをググるだと思うのですが、ググっても出てこない、もしくは全く明後日の情報しか出てこない場合、ここで次の一手がでてくるか、出てこないかで課題解決ができるかできないかが決まってしまいます。

こういった場合、次の一手として考えられることは公式のドキュメントを読むことだと思います。だいたいは英語で書かれてるので、ここはもはや課題をなんとか解決するために頑張って読むしかありません。

公式のドキュメントを読んだことで解決すれば御の字です。

今までの自分の経験ではおおよそこの辺までで調べことは終わることが多かったのですが、最近ぶち当たってのは公式ドキュメントにすら記載していない、ライブラリの更新に伴うバグで、ドキュメントに記載されていなかったので、次の一手が全く出ずにどん詰まってしまいました。

ググっても出てこない、公式のドキュメントにも書いてない、残るは目の前に存在する動かないコードのみ という状態になってからがエンジニアとしての腕の見せ所なんだなぁと感じ、自分は全く何もできなかったことが悔しかったです。

ここから先は最終手段としてのコードを読んで課題解決の解法を導き出す、までのとっかかりをひたすら探し続ける作業で、どうその作業を進めていくか、というお話です。

というのも、コードを読めばわかる、と言われてもどこからどうコードを読むべきか分からなければ、完全に別方向の調査をしてしまい、永遠に課題は解決しませんきっと。。。

どこからどう読むと課題解決に一番近いのか？という観点を導き出すために、その材料を探しに行く作業を進めていかなければなりません。

そのアプローチを考えてみました。
（なお、これはあくまで僕の課題解決に対する案であり、アプローチの方法はケースバイケースで様々あると思います。）

僕の考える手順は以下です。

1. フォーラムやissue を見る
2. 正常系と異常系の差を探す
  - ログを取る
  - 最小構成でデバックする

まず最初のフォーラムやissueを見る、についてですが、公式ドキュメントに乗っていないことや、ドキュメントの不備は、そのドキュメントが世界中に向けて公開されている以上、世界の誰かが同じ課題に悩んで、問い合わせしてるかもしれない？と探って、自分が解決したい技術領域のコミュニティに問いかけてみます。

実はここでとっかかりをつかめることが多いです。もし掴めない場合は、自身の置かれている状況を説明して、識者（コミュニティの誰かかもしれないし、もしかしたらクラウド事業者のカスタマーセンターかもしれません。。。) に問い合わせてみましょう。

案外聞いてみたら既知の問題だった。みたいなことも十分に存在します。

そして最後に実際にコードを読む、というところですが、闇雲にソースコードを追っかけてもコードの海に溺れて這い上がってこれないので、ある程度的を絞って読みます。

その絞り込みに最適なのが「ログを出すこと」そして「正常系と異常系の振る舞いの差を見つけること」です。

ライブラリによってはデフォルトでログの出力がOFFになっているものもあるかもしれません。そのため、詰まったところに置いてログを出すにはどうすればいいか？を知ってるか知らないかで大分次の打ち手が変わってきます。というか知識のレベルで完全にできることが制限されてしまいます。残酷です。

こういう時に、普段から使っているライブラリの中身を読んだり、コミュニティに目を通しておくことが役に立ちます。

要はしっかり素振りしとけよ、って話なんですけどね。。。

分からないこと、市場に情報が存在しないことを「サッと」調べて知見を共有できると最高ですね。そうなりたい...。