学生時代から合わせると、エンジニアとして約3年近く働いたことになる今日この頃。
エンジニアとしては、より専門的な知識を得るということに注力しがちだが、働き始めて分かったのは、「問題解決能力」（に限らず、ソフトスキル全般）が大事だということ。いわゆる技術力というものは、あくまでも手段でしかないということ。
私のチームでは、「高速・高品質」を理念に開発を行なっている。メンバーはこれを満たすために、どのように施策を進めていくのかを常に考える必要がある。
少し前の話で、お気に入り機能のデータベース移行を行う必要があり、その施策の担当を自分が行うことになった。当初、全てを完了するまでに1ヶ月の工数でスケジュールを見立てていた。
だが、途中で問題が起こり、スケジュール通りにいかないということが明らかになった。
原因はいくつかあった。
まず、設計段階で要件を満たすためにはオーバーエンジニアリングなものになっていたということ。それにより、実装の複雑性が上がってしまっており、実装の工数が思ったよりもかかってしまっていた。
また、データベース移行をやったのが初めてだったのに関わらず、あらかじめつまずきそうなポイントを全く聞いていなかったこと。あらかじめ聞いていれば、つまづかなかったポイントもあったと思った。
あと、スケジュールに間に合わなさそうだと思った時点で、メンバーにヘルプを出して助けを受けるべきだった。大事なのはチームでどれだけ成果を上がられたかどうか。ヘルプを頼むことを多少なりとも抵抗があったのもあまりよくない考え方だったと思うし、チームの成果とは逆行する動きをしてしまった。
これらのことは、以前は技術力で解決する問題だと思っていたが、実は「問題が起こった時にどうふるまうかという考え方」の問題なんじゃないかと思う。
実際に行うべきフローはこうだったんだと思う。
スケジュールが遅れるような問題が起こった。闇雲に複雑は実装をやるのではなく、そもそももっとシンプルな実装で要件は満たせているのではないかと考え直す。他のメンバーにももっといいやり方がないかどうかを確認して、詰まったポイントなどがないかも確認しておく。もしここで技術的な知見が足理てないことが原因であれば、キャッチアップしておく。スケジュールを引き直して、スケジュールではみ出る分がバッファーを超えそうなら、他のメンバーに一部実装をお願いしてみる。当初の予定に合わせに行く。
あくまでもこれは一例だが、問題解決の思考プロセスを確立しないまま闇雲に専門的な知見を溜めても、どこかで壁にぶち当たるなと思った話でした。