はじめに
エンジニアになって4年目になりました。
1年目の頃、あるバッチ処理の実装を行ったことがあります。
見積もりは1週間でした。しかし実際は、完成するまでに3ヶ月かかりました。
原因は、技術的に難しかったからではありません。
「何をすればいいか分からない」「何が分からないのかも分からない」という状態にはまってしまい、手が止まってしまったからです。何から手を付けていいのか分からず、気づいたら1週間、2週間と過ぎていました。
そのときの経験を振り返りながら読んだのが、牛尾剛さんの『世界一流エンジニアの思考法』です。
この記事では、要約というより、あのときの自分に何が足りなかったのかを、本の内容と照らし合わせて整理してみます。
※あくまで個人の解釈です。
1. 「分からない」を整理していなかった
今振り返ると、あのバッチの案件で一番まずかったのは、「分からない」を放置したまま抱え込んでいたことでした。
仕様を読んでも全体像がつかめない。既存コードを見ても、どこがどう関係しているのか分からない。それでも「分からない」と言語化せず、なんとなく手を動かして分かった気になろうとしていました。結果、同じ場所を何度も読み返すだけで、前に進んでいる感覚がまったくありませんでした。
本を読んで刺さったのは、まず「何が分かっていて、何が分かっていないか」を書き出すことの大切さです。
例えば当時のバッチなら、こんな切り分けができたはずです。
- 入力データの形式:分かる
- 出力の仕様:分かる
- 既存のどの処理を再利用すべきか:分からない
- 異常系の扱い:分からない
これをやるだけで、「全部分からない」という漠然とした不安が、「あと2つ確認すればいい」という具体的な作業に変わります。
あの3ヶ月は、たぶんこの整理を一度もしなかったことが一番の原因でした。
2. 全部理解してから、と思っていた
もう一つの原因は、バッチが依存している既存システムを「全部理解してから実装しよう」としていたことです。
関連しそうなコードを片っ端から読み、関数を一つずつ追い、結局どこまで理解すれば実装を始めていいのか分からないまま時間だけが過ぎていきました。
本には、必要なのは「今使う分だけ」理解することだと書かれています。
使える → 説明できる → 問題を切り分けられる → 内部まで追える
こういう段階があって、最初から一番深いレベルを目指す必要はない、と。当時の自分に必要だったのは、まず動くものを作れる最低限の理解でした。内部の細かい実装まで理解するのは、その後でよかったはずです。
3. 調べ方も整理されていなかった
分からないことがあるたびに、断片的に検索していました。「〇〇 エラー」で調べて、それっぽい記事を読んで、また別の疑問が出てまた検索して。何を調べたか、何が分かったかの記録も残していなかったので、同じことを2度調べることもありました。
エラーの内容、発生条件、直前に変更した箇所を先に整理してから調べる。それだけで、見つけた記事が自分の状況と本当に同じなのか判断できるようになります。
当時はこの一手間がなかったので、調べても調べても解決に近づいている実感が持てませんでした。
4. 今なら、たぶんこうする
同じ案件がもう一度来たら、最初にやることは実装ではなく整理だと思います。
- 分かっていること、分かっていないことを書き出す
- 分かっていないことを「確認すれば分かるもの」と「手を動かさないと分からないもの」に分ける
- 既存コードは全部読まず、今回の変更に関係する範囲だけ理解する
- 詰まったら、詰まっている内容を言語化してから調べる
たぶんこれだけで、3ヶ月かかった案件は1ヶ月くらいに収まったんじゃないかと思います。
まとめ
あのバッチの案件で一番苦しかったのは、技術的な難しさより「何が分からないのかも分からない」状態そのものでした。
この本を読んで、それを解決するのは気合いや慣れではなく、「分からないことを整理する」という具体的な作業なんだと分かりました。
同じように手が止まってしまった経験がある方は、一度「今、自分は何が分かっていないのか」を書き出してみると、動き出せるかもしれません。
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてください！