調査のコツは「思考を全部書き殴ること！」
f4samuraiで活躍中のエンジニアメンバーがお届けするエンジニアブログ。
今回は、ネイティブエンジニアの桑田が社内向けに書いた記事を紹介します！
はじめに
ネイティブエンジニアの桑田です。スマホゲームのプロジェクトでUnityを使った実装を担当しています。
今回は社内向けに書いた記事を紹介します。
記事のテーマは「今までで解決するのが一番難しかった技術的問題」だったのですが、ここではUnityのバージョンを2018から2021に更新した際のビルドエラーとの格闘を思い返しつつ、「仕事をうまく進める上でのちょっとしたコツ」と絡めて書きたいと思います。
本題
Unity2018からUnity2021へのアップデートは三世代アップということもあり、かなり大規模な変更を含んでいたので、修正内容はソースコードからビルド設定の変更まで多岐に渡りました。表面的なソースコードのエラー修正が終わり、エディタ上では動作に問題がないことを確認した後の、アプリのビルドやストアアップロード関連のエラーは特に原因が分かりにくく、苦労させられました。
エラーの原因を要約すると
UnityのFrameworkを生成する処理（2021で追加）よりも先にFrameworkを必要とする処理が存在した
不要なFrameworkを削除する既存処理のせいで、本来必要なUnityのFramework（2021で追加）もまとめて消されていた
普通に誤字があった
となるのですが、これらが複合していたため、どれか1つを正しても別の要因のせいでエラーになり、問題の特定が難しくなっていました。
これらの問題を修正して、アプリビルドとストアアップロードが無事に終了して安堵していたら、その後に「iOS12.2未満の端末でアプリが起動しない」という不具合に直面しました。
調査の結果、原因は「Swiftライブラリの追加を削除した」ことでした。
iOS12.2未満だと標準でSwiftライブラリが導入されていないため、アプリ側で追加する必要があります。
もともとは追加する設定になっていたのですが、色々な検証をしている最中に設定を外してしまっており、それによって問題が起きていました。
どれもこれも後から振り返ってみればシンプルな原因でしたが、これらの原因を特定するために行った調査、検証、修正はものすごく疲れました。
不具合を直すために処理を変えると別の不具合が起きたり、組み合わせ次第によって新たなエラーが起きたり……
実装意図のわからない古い処理や、普段わざわざ確認しない設定項目を洗う必要があり、さらにアプリの運用業務と並列して調査を行っているため、何日間も成果が出ないと焦りも募り、一歩も前に進められていないとどんどん苦しくなっていきます。
それでもなんとか調査を乗り越えて修正まで漕ぎつけられました。
そのコツは、検証作業ログを雑に書き殴っていたことだと思います。
弊社エンジニアの基本方針として、「なるべく調査・検証ログは資料として残して会社全体で共有しよう」というものがあり、自分も不具合の原因の詳細や調査内容についてはNotionページに書き残しながら作業をしていました。
「資料に残す」というと、どうしても綺麗に書かないといけないとか、理路整然としてなければいけないとか、ハードルが高く感じると思います。最終的な資料としてはそのほうが良いのですが、調査段階においては「思ったことを全部書き殴る」くらいの雑さのほうが良いです。
自分が書いていた実際のログを引用してみると、
「よくわからないが多分ここが怪しい」
「いや待て、ここの処理ってなんだ？」
「ipaファイルが出力されてねえ！」
「この仮説通りならうまくいくはず」
「失敗。なんでだよ！！！」
「設定をOFFにしたら通ったっぽい！！！！！！！！！ うおおおおおおおおおお！！！！」
と、主観や感想や感情がめちゃくちゃ入っており、とても全文を載せられないほど文章が荒れ狂っています。
答えを知ってから読み返すと道中の仮説は半分くらい間違っているし、めちゃくちゃ遠回りをしているし、文体もおかしいので資料としては失格です。
しかし感情を乗せまくったことで、自分がどこでつまずいていて、どこを怪しんでいて、何を勘違いしていて、どういう道程で答えに辿り着いたのかという流れは鮮明に理解できます。
思考を書き出すメリット
真っ当な資料としては当然NGですが、未知のエラーを調査するときはこれくらい雑に思考を書き散らすほうが良いと思います。
これには以下のメリットがあります。
1.仮説を言語化して可能性を一つ一つ潰していくのを視覚化できる
頭の中で考えてばかりだと結局どのような可能性が残っていて何を検証したのかがこんがらがってしまうので、文章化は大事です。
2.これまでの思考の流れを思い返せるので、以前の仮説を再現させやすい
検証には何日間もかかるので、どんどん最初に検証した内容を忘れていきます。
いろいろ考えたけどやっぱり最初の方法が正しかったなとなった際に、思考と検証のログを残しておけば当時の状況を再現させやすいです。
3.テンション感も記録できるので自分がどこで詰まっているのかわかりやすい
「どこで一番つまずいたのか」「何が一番わからなかったのか」というのは、綺麗な資料からは読み取れません。
生の感情を直接資料にぶつけて残すことで印象に残りやすくなり、今後類似する不具合と相対したときに気を付けるべきポイントがイメージしやすくなると思います。
4.思考の流れやテンションが視覚化されるので他者からアドバイスをもらいやすい
検証に他者の手を借りる場合、前提や仮説や感想など筆者の思考の流れが全部書かれた資料であれば
「ここの前提の認識に誤りがある」「この仮説であればこっちのアプローチのほうが良い」などの指摘を受けやすくなるでしょう。
結論だけ書いてしまうと、自分の調査内容に問題があったとしてもそれに気づいてもらいにくくなります。
また上述した通り、どこで一番つまずいているかも一目瞭然なので、調査を引き継ぐ際も便利です。
赤裸々な文章を人に見られるのは恥ずかしいですが、背に腹は代えられません。
5.成果が出なくても文章量が増えるので仕事してる感を得られて焦りが緩和される
これが割とバカにならなくて、検証して失敗して別の検証してを繰り返していると、目に見える成果が出ず無駄に工数を使っている感がしてどうにも気分が落ちていきます。
なかなか成果を出せない時間が続くと、短期間で成果の出る別の作業をやりたくなってしまいます。テスト勉強中に部屋の掃除を始めてしまうアレです。
しかし思考ログを全部書き殴ってると、その文章全てが作業の成果として蓄積されていくので、仕事した感が出て自分を満足させられ、ストレスが緩和されます。また、上司に対して「私はちゃんと仕事やってますよ」というアピールにもなります。
6.文章を書くハードルが下がる
ちゃんとした文章を書こうと思うとなかなか筆が進みません。
「ちゃんとしてなくていいからとにかく思ったことを全部書け！」の心持ちでいきましょう。
まとめ
この辺りのコツは、学生の座学とも通じるなあと思います。
黒板の板書をただノートに綺麗に書き写したり教科書の文章に蛍光ペンを引くだけでは頭に入ってきません。
ノートとは自分の思考を書き出して理解を深めるためにあり、綺麗に書くことそのものは目的ではありません。
そこに自分の感情を入れ込みまくって「これなんで？」「こうじゃない？」「こうなのか！」「じゃあこっちは？」「これだ！！！」と落書きをしまくることで自分だけのノートが出来上がり、自分に最適化されたノートが完成します。そうしたノートを読み返したほうが復習も捗るでしょう。
「授業中のノートはメモ書きとして扱い、授業が終わった後に復習がてら綺麗にまとめる」
というのは勉強法としては王道です。「東大生のノートは汚い」という風説もあります。（本当か？）
というわけで、私が思う仕事をうまく進めるコツは「調べ物をするときは、自分の思考の流れをだらだらと書き殴ろう」でした！
▼ おすすめ記事
▼ f4samurai Recruitサイト
f4samuraiでは、一緒に働くメンバーを積極採用中です！「まずはちょっと話を聞いてみたい」というご相談も歓迎いたします。
▼エンジニア採用特設サイトはこちら！
この記事が気に入ったらサポートをしてみませんか？