6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

技術検証がうまくいかないときに心がけていること

Last updated at Posted at 2021-12-04

はじめに

この記事は SAP Advent Calendar 2021 の12月4日分の記事として執筆しています。

私が最初にQiitaの記事を書いたのが2018年の11月でした。そこから3年ちょっと、興味の向くまま、あるいは仕事として様々な技術検証をしてきました。技術検証は最初からうまくいくことは稀で、「うまくいかないこと」が多くあります。この記事では、技術検証がうまくいかないときに自分がどのように対処してきたか、振り返ってみることにします。

技術検証がうまくいかないときに心がけていること

  1. 「何が起きているか?」にまず注目する
  2. エラーは出て当たり前と考える
  3. うまくいっているパターンを探す
  4. 最小限でやってみる
  5. 標準で同じことが起きていないか確認する
  6. 技術を一段深く理解する
  7. 派生問題にどう対処するか
  8. 時間をおいてみる
  9. コミュニティに問い合わせる
  10. 「できない」とわかったことも収穫と考える

1. 「何が起きているか?」にまず注目する

問題が起きたとき、「どうしたら直せるか?」とあなたは考えるかもしれません。でもちょっと待って。解決したい気持ちを脇に置いておいて、冷静にまずは何が起きているか調べてみましょう。
私がよく使うトラブルシューティングのステップは、①何が起きているかを把握する、②なぜ起きているかを把握する、③どうやって直すかを考える、です。①のステップにいるときは、他のことを考える必要はありません。探偵になったつもりで起きている事象を追ってみましょう。経験上、何が起きているのか、なぜ起きているのかの順に導き出した対応は、事象の正確な理解に基づいているため、根本解決につながる場合が多いです。

2. エラーは出て当たり前と考える

検証は最初からうまくはいきません。エラーが出るのが普通です。エラーが出たら「よっしゃ」と前に乗り出して原因調査します。エラーメッセージで検索すれば、Stack OverflowやSAP CommunityのAnswersなどで同じ問題が見つかるかもしれません。ソースに手を加えて、また別のエラーが出たとなれば一歩前進なので喜びます。

3. うまくいっているパターンを探す

検証していると、以下のようなケースがあります。

  • あるデータではうまくいくのに、別のデータではうまくいかない
  • サンプルソース(例えば、誰かのGitリポジトリ)ではうまくいっているのに、自分のソースではうまくいかない

うまくいっているパターンがあればしめたものです。うまくいっているパターンといっていないパターンでは何が違うのか、色々な角度から調べてみます。動くサンプルがあれば、動かしてみたり、デバッグしたりしてみます。

4. 最小限でやってみる

ソースコードが複雑になると、問題の原因を探すのが大変です。そんなときは、検証したいことに絞った最小限の部分を切り出して、そこを集中的に調べてみます。問い合わせすることになったときも、「最小限の動くもの」があるとサンプルとして提示できるので便利です。
image.png

5. 標準で同じことが起きていないか確認する

これはSAP特有ですが、標準のアプリやプログラムでも同じ問題が起きているか確認してみます。できればこれは早い段階でやったほうがよいでしょう。標準でも同じ問題が起きていれば、インシデント登録すれば直してもらえる可能性があります。あるいは、すでにノートが出ている場合もあるでしょう。
標準では起きていないとすると、自分の実装に問題があるということで、標準を「うまくいっているパターン」として使うことができます。

6. 技術を一段深く理解する

うまくいかないとき、その技術に対する自分の理解が足りていないかもしれません。裏を返せば、これは対象を一段深く理解するチャンスです。ドキュメントをしっかり読み込んだり、デバッグで変数の中身を確認したり、さらにはわかったことをアウトプットすることで自分を理解のレベルを上げることができます。
image.png

7. 派生問題にどう対処するか

検証をしていると、もともとの問題のほかに別の問題も出てきて、なんとなくそちらを調べてしまうことがあります。私は個人的な検証のときはこれを許容していますが、ゴールに対する現在の位置は意識しておくようにします。派生問題が解決したら元のルートに戻れるように、以下のようなイメージを頭に置いています。
image.png

8. 時間をおいてみる

問題を解決しようとするあまり視野が狭くなり、うまくいかないとわかっていても同じことを繰り返してしまうことがあります。そんなときは時間を置くことが有効です。一旦モニターから目を離して別のことをするのもよいですし、一晩おくと解決策が見つかることもよくあります。

9. コミュニティに問い合わせる

私が最後の手段として頼りにしているのがSAP Communityです。ここにはトピックごとのエキスパートが日々巡回しており、解決できる問題であれば誰かが回答してくれます。自分が奮闘している間に他のエキスパートの頭脳を借りられるというのは心強いものです。ここで回答がもらえなければ、今の限界だと諦めがつきます。

10. 「できない」とわかったことも収穫と考える

どれだけ調べても、問い合わせても解決しないこともあります。本当にできないのか、自分の技術の限界なのかはわかりませんが、現時点でできること、できないことが明確になったのは収穫であると考えます。なお、できなかったことをブログに書くとエキスパートの助言をもらえる場合もあります。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?