Yentaのエンジニアをしている遠矢です。
Yentaにはサーバサイド、フロントエンドに3人のジュニアエンジニアが在籍しています。
先輩という立場上、彼らに業務する上でフィードバックする機会があります。
その時にエンジニアとしての「技術的」なフィードバックもしていますが、 それ以上に「問題解決」に対するフィードバックを意識的に多めにしています。
これは、技術自体は時代と共に移り変わるため、それ以上に問題解決のマインドを醸成して、 その上で技術を使いこなせることが重要だと僕個人が捉えているためです。
※ もちろん技術を蔑ろにしても良いというわけではありません。
本ブログでは、彼らに伝えている普段のフィードバックを元に 問題解決の方法を4ステップに整理して執筆させていただきます。
問題解決の4ステップ
- 問題をちゃんと認識する
- 問題を明確に理解する
- 問題の解決策を考える
- 問題の解決策を実践する
問題をちゃんと認識する
ここが一番難しいフェイズかもしれません。
例として、 ソースコードに変更を加えた結果、一部の機能が動作しなくなったというケースがあります。
このような状況下で、自分が考えて書いたコードが原因で動かなくなったことを認めたくない、といった心理が働きます。 また、チームメンバーからバグですと端的に指摘されたりすると、非常に嫌な気持ちになります。
業務がうまく進められていないとあんまり共有したくないということもあります。 これも自分の状況を問題としてうまく認識できていなケースと言えます。
チームで意見が割れてしまうケースも、この問題認識にズレがあるケースが多いと思います。
問題をちゃんと認識することは、心理的にストレスがかかる行為であるため、 人間としては本能的に自衛してしまうのかもしれません。
解決策としては、
自分がストレスを感じるポイントを理解して、 問題と自分を切り分けるなど客観的に問題を認識できる方法を考えると良いと思います。
問題を明確に理解する
問題を認識したら、その問題を自分が処理できるレベルまで分解していきます。 この時に 「問題をちゃんと認識する」をできていないと、このフェーズでも多大な負荷がかかります。
その場合は、一度立ち戻って問題認識のすり合わせをしましょう。
また、エンジニアは様々な技術を組み合わせて開発を行うため、 問題が複雑に絡まりあっていたり、Aで起こってる問題の原因がBにあるということもあります。
例えば、簡単な例だと Railsでエラーが発生していたが、根本的な原因はDBにある、などが考えられます。
この時にログやソースコードを読み込んでいなかったり、DBに対する理解が浅い場合は、 自分が持っているRailsの知識だけで解決しようとしてしまう場合があります。
その場合は、どのように考えたか？どのような調査をして、どのように考察しているか？を整理しましょう。
ツールとしてはマインドマップなどがおすすめです。
問題を分解していって、末端の問題を自分で処理できるレベル まで分解しましょう。
エンジニア視点としては下記も意識すると良いかと思います。
特定の技術や要素に対する理解が浅い、なども問題として捉えるようにする
そうすることで自分が次に身に着けるべき技術も見えてくるので学習の助けにもなります。
ログやソースコード、ドキュメントを読みとく意識を持つ
大抵のプロダクトはログが吐き出されていたり、ソースコードにアクセスできる状況かにあるはずです。 ジュニア層のうちに一次情報を調査する意識を身につけておくと今後の助けになると思います。
問題の解決策を考える
問題の理解ができるとこちらのフェーズは知識や経験、調査力に依存するだけになります。
分解した問題が発生していない状況や理想の状態の差分をどのように埋めるか考えましょう。
重要なのは、問題の分解を仕切らずに解決策を考えないことです。 またその次の実践まで進めてしまうと、チームにレビューしてもらうなど 客観的な視点が入るタイミングでの差し戻しが多くなります。
極論、問題の認識が間違っている場合は、また0からスタートすることになります。 そのような状況下でまた問題を認識すると認めたくない心理やめんどくささにより、 かなりのストレスがかかります。
問題の解決策を実践する
ここまでくればあとは実践あるのみです。 実践にあたり、不明確なものがあったり、迷いがある場合はそれらを問題として捉え、しっかりと認識・明確にしましょう。
迷っている状況で解決策だと思っているものを実践すると、 うまくいかなかったり、右往左往することが多い気がします（体感です）。
逆に、問題を明確に分解して理解できてる場合、 例えば優先度を変更したり、過不足がないかを考えるなど微調整をするだけでスムーズに動ける状況になったりします。
自分にとってのセーブポイントを作る意識で、問題理解のログを残すことをお勧めします。
問題について人に共有できるようにしよう
4ステップには含んでいませんが、問題が発生した時に自分がどこまでできているか？ などを人に共有する意識を持つとチームメンバーとして一緒に働きやすい人になれる気がします。
例えば、問題が生じた時に一番どうしようもない共有としては「なんかうまくできません」や ネットでネタにされるような「何もしてないのに壊れました」などがあります。
このような状況下で自分の状況を整理すると下記のような共有が可能になると思います。
- それを問題として捉えられてないのですが、詳しく教えてもらえませんか？
- 問題をここまで分解して、この順番で解決しようと思います。ご指摘などはありますか？
- 問題の解決策として、このような方法を取ろうと思います。方針に違和感はありませんか？
- この問題に対して、このような方法で解決しました。
- ....
具体的な共有をできるようになると、安心して大きめの機能の実装などをお願いしやすくなります。
問題解決の方法は、経験則なども影響するためどうしても先輩と言われる人たちの方が長けている場合が多いです。 そのような人たちから効率的にフィードバックを得るためにどのような共有をすると良いかを考えることから始めると良いと思います。
