1. 適切な方法でググる力
エンジニアとしてググり力は大事！人に聞いてばっかじゃなくてググれ！とよく言われますが、本当にその通り。
しかし、ググってもでてこないわ..！(泣)という初心者は少なくないでしょう。それはググり方が悪いです。
例えば、Pという問題(Problem)を抱えていて、Gというゴール(Goal)に向かいたいとしましょう。
初心者エンジニアはだいたいこうググります。
「P 防ぐ 方法」
「Rails G やり方」
一発で解決してくれるソースを見つけようとするとハマります。
もちろん簡単なケースや頻出ケースはこれでうまくいくこともありますが、これでは、PやGが多少複雑になった場合、ユニークなケースだった場合、いつまでたっても自分の環境に合う解決策が見つからずさまよい続けるなんてことになりかねません。
良いググり方とは何か。
① P -> Gまでの道のりを細かいパーツに分解しましょう
道のりのパーツの中で、自分が確信を持てない、問題を引き起こしている容疑者をマークします。最終的にすべての容疑者を調べ終えたら犯人がはっきりしていて、ゴールに到達しているように洗い出しましょう。
② 細かい問題毎にググる
細かく汎用的な問題に落とし込めていれば、解決策は大抵くそ簡単に見つかります。これで、一つ一つ確信を持てる状態にして潰していきます。
③ 細かい問題毎にデバッグする
常に、ゴールの状態になったか最後を見るのではなく、細かく潰していくために、細かい問題毎の状態を常にデバッグするようにしましょう。分からなければデバッグ方法も都度調べます。
この細かい問題に分解する意識があるかないかで、ググりによる問題解決能力が飛躍的に変わります。
2. 設計図を描く力
ある程度規模が大きかったり、複雑なアプリを書くときにいきなりコードを書き始めるのは止めましょう。絶対に書き直す事になります。時間がもったいない。
① 仕様をまとめましょう。それをどう描くか、をある程度頭なり紙にまとめます。
② 仕様側の人にそれを持って行ってすり合わせる。
③ コードを書く。
④ コードを書いている最中に生まれる仕様/設計の変更等は①にまとめる。→②からくりかえす。
仕様とその設計図をまとめておくと、大きいイシューになったときに全体感が掴みやすくなります。そうすると例えば、あとで変更点が出てきたときに、変更すべき点を見つけるのがすごく簡単になります。あとは、全体感をつかめているので、あらかじめリファクタを意識したコードを書きやすくなります。
[設計図] Taskを細かく分解+時間の見積もり
設計図に関して具体的にすべきこととして、あるイシューに対するコードを書き始める前に、そのイシューを突破するためにすべきtaskを細かく分割して把握しましょう。
想定不足でいきなりコードを書き始めると、書いてる最中に気づいたパターンへの対応などで、これまで書いたコードがゴミになったりすることが多々ある。Task分解による、想定でその無駄を省けます。
また、想定不足で当初の予定以上にだらだら時間をかけてしまうとともに働く人の信頼を失いかねないので、時間の見積もりもしておきます。
3. 不確定要素を把握する力
設計図を書きたいとはいえ、コードを書き始める前にはなかなか想定しきれないこともあるでしょう。
そういう場合は、「〜〜には地雷がありそうだから、ここ不確定」というようにどこが不確定で、どこが確定(作業ゲー)なのか、はっきりさせておきましょう。
そして、確定の作業ゲーをやるのは、気持ちいのですが、先に不確定要素に関する調査をして、不確定度合いを下げましょう。そうすることで、無駄にコードを書くことを避けます。
それは、使えるかわからない技術かもしれないし、仲間との仕様のすり合わせかもしれません。