どうしても乗り越えれない技術的課題に立ち向かう方法
技術的な課題というのは、たびたび遭遇します。遭遇する度に試行錯誤して突き進んでいくものです。
しかし、どうしても解決できない技術的課題に直面した場合、どのように対処すれば良いでしょうか？
このドキュメントは、今まで私が立ち向かうために使ってきた方法を備忘録として残していきます。
12項目以降もあると思うのですが、私のビジネス/技術スキルはこの程度です。
0. 課題を整理する
課題を整理することは非常に重要です。解決の成否はこの段階で決まります。
1. 他の人に助言を求める
AIに質問する
AI技術の活用は、現代の技術的課題に対処する有効な手段です。AIに質問を投げることで、解決策やヒントを得ることができます。
チームメンバーに相談する
同じチームのメンバーに相談することは重要です。彼らは同じプロジェクトに取り組んでおり、役立つアイデアやアドバイスを提供してくれるかもしれません。
お客様に相談し、要件を調整する
お客様とコミュニケーションを取り、問題や要件の調整を行うことも重要です。彼らの視点やニーズを理解し、解決策を見つける手助けになるでしょう。
組織全体で相談する
組織内の他のメンバーとも共有し、知識や経験を共有することは有益です。例えば、エンジニア全員が参加するSlackチャンネルなどを活用すると良いでしょう。
2. 一次ソースを参照する
公式マニュアルを読む
公式のマニュアルやドキュメントを参照することは重要です。多くの場合、解決策やヒントが記載されている可能性があります。
GitHubのコードを調査する
GitHub上の関連するコードを調査することも役立ちます。他の人の実装や解決策を参考にすることで、問題解決のヒントを得ることができます。
一時的にAIの使用を停止する
プロジェクトに特化した内容やナウいライブラリの局所の内容だと、AIが提示する解決策が嘘だったり不適切な場合があります。その場合は、AIを利用することの固執を一旦やめましょう。
3. 問題を効率的に分析する
問題の原因と現象を特定する
コンピュータの世界では、すべての問題は必ずどこかにプログラムされています。問題の原因と現象を特定することは重要です。
問題を分解する
起きている事象が複数あるのであればそれぞれに分解する。それぞれに対して解決策を見つけることで、全体の問題を効果的に解決することができます。
スタートとゴールを明確にする
問題のスタート地点とゴールを明確に定義することも重要です。スタート地点はユーザーのアクションやコードの特定の部分であり、ゴールは問題が発生している箇所です。
二分探索的な特定を心がける
スタートからゴールまでのコードの経路において、ちょうど半分ぐらいなところにところにデバックコードを仕込みます。そのデバックコード時点で期待している内容かどうかで以前の部分を見るか以後の部分を見るか検討します。
一つのメソッドだったり数行ぐらいまで絞り込むことができれば問題の原因特定に気づきやすくなります。
バックエンドとフロントエンドを区別する
問題を特定するために、バックエンドとフロントエンドどちらが期待しない状態になっているか把握するのはとても有効です。
バックエンドからフロントに届いたレスポンスボディを真っ先に確認しましょう。大抵はブラウザの検証ツールの「Networkタブ」を見るべきです。
アプリケーションとライブラリを区別する
問題を特定するために、開発しているアプリケーションとライブラリどちらが原因か把握するのはとても有効です。
入力と出力を意識する
メソッドの基本は入力と出力です。入力と出力が適切であればその中の処理は見なくても良い内容であるべきです。効率的に分析するには見るべきコードと見ないコードを判別することが大事です。
リクエストとレスポンスを意識する
リクエストとレスポンスを確認する手段は常に準備しておきましょう。任意の値でリクエストを送ることができてる状態が望ましいです。
4. 開発環境を整える
ローカルでの開発環境を整える
問題解決のために、必ずローカルで開発環境を整えましょう。検証環境やステージング環境ではなく、ローカルで開発することが重要です。
環境を再現する
もしエラーや不具合が本番環境で起きているのであればその環境を徹底的に再現しましょう。
必要な機器やアカウントを準備する
問題解決に必要な機器やアカウントが不足している場合は、それらを調達する必要があります。自腹で機器やライセンスを購入することも検討しましょう。成果を出せば評価され、給料が上がりPayできるでしょう。気軽に壊せる環境を持っていることは技術力向上に寄与します。
もし自己負担が嫌な場合は、経費精算を行うか、権限者との調整を行いましょう。貸与いただいたものは取り扱いに注意しましょう
5. 図表化する
ツールを活用して図にする
課題を図や図表に起こすことは有益です。Figmaなどのツールを使用することをお勧めします。
システム構成図を作成する
システム構成図を作成することで、問題の全体像を把握しやすくなります。
現状と目標のフローチャートを作成する
現状と目標のフローチャートを作成することで、問題解決のプロセスを視覚化することができます。
6. 先人に習う
先人のコードを模倣して作る
丸々模倣するのではなく、模倣できるエッセンスを探して抽出する。
過去のPR・アウトラインを漁る
過去のPR・アウトラインに先人が考えた思考や過程が描かれていることがあります。
過去のSlackを漁る
過去のslackの内容にヒントがある可能性があります。
ライブラリのGithubのISSUE・PRを漁る
同じ課題に対し誰かが先に直面しているかもしれません。
7. 試作する
小さな実装を作成する
複雑なプロジェクトやコードの場合、小さな実装を作成して試してみることは有益です。
オンラインコードエディターおよびプロトタイピングツールを利用する
CodeSandbox.ioなどのオンラインツールを利用して、試作を行うことも可能です。
Dockerを使用する
プロジェクトやリポジトリ内にDockerファイルがある場合、それを使用するか、自分でDockerファイルを作成して必要なものだけを組み込むこともできます。環境の構築方法を知っていることは有益です。
8. 愚直なデバッグをする
コードを1から追いかける
問題を特定するために、コードを1から追いかけることが重要です。
ログを確認する
ログを確認することで、問題の発生箇所や原因を特定することができます。
データベースの実行計画を確認する
データベースの実行計画を確認することで、問題の原因を特定することができます。
9. 実施可能な方法を試す
理解できる範囲で試す
自分が理解できる範囲で実施可能な方法を試すことが重要です。理解できない方法を試しても効果が乏しいため、自分の知識と経験に基づいて試行することが重要です。
先人に依存せずに試す
先人の手法やコードを参考にすることも重要ですが、解決策が見つからない場合は、自分の知識に基づいて試してみることも重要です。自分の知っているコードで実装することで、新たな視点や解決策が見つかるかもしれません。
ネイティブな方法を試す
ライブラリを使用してうまくいかない場合は、ネイティブな方法を試してみることも重要です。
10. リスクを取って試す
1から作り直す
1から作る案は工数的にナシ寄りのナシです。しかし、問題の解決策として、一から作り直すことも検討してみてください。場合によっては早道となる場合があります。
複数連携しているシステムの一部を停止する
ナシ寄りのナシです。しかし、複数の連携システムがある場合一部を停止してみることを検討しても良いかもしれません。停止することで必ず問題が発生します。しかし今まで見えなかった仕様にも気付けるかもしれないです。本番環境ではなく検証環境を用意してやる必要があります。
理由が分からないファイルやコードを削除する
理由が分からないファイルやコードを削除することで、問題が発生する可能性もあります。しかし、そのファイルやコードが本当に必要かどうかを理解することができます。
ネットワークを遮断する
何が動いているかわからないシステムの場合、不意にどこかに通知が入ったり、メールが飛んでしまったりする可能性があります。ネットワークを遮断して試すことで意図しない範囲の副作用を防ぎます。
認証部分をスキップする
システムが複雑で理解できない場合や、特定のアカウントでの現象が発生する場合には、認証部分を一時的にスキップすることが有効です。認証をスキップすることで、システム内部の動作を正しく観察することができます。
11. チームメンバーやコミュニティのサポートを求める
GitHubのIssueに質問する
関連するプロジェクトやライブラリのGitHubのIssueに質問することも有効です。英語で投稿し、他の人からの意見やアドバイスを得ることができるかもしれません。
Youtubeを見る
仕事中にYoutubeを開いてはいけないというのは誤りです。課題解決に必要な手段であれば試聴する必要があります。たとえそれが2時間の動画でも
自分の知識を共有する
自分が持っている知識や経験を他の人と共有することも重要です。勉強会などで発表することで、助けを求めることができるかもしれません。また、周りの人々のレベルも引き上げることで壁打ち相手が増えるかもしれません。
Discussion