前提

最近、私は部署移動したことにより、担当する仕事の内容が大きく変わってきました。
これまでは、1 つのサービスを 50, 60 人くらいのアプリケーションエンジニアで改修する内の一人で

ボタンや画像の位置を変えたい
ここに表示しているものを、こっちにも表示させたい
CMS のフォームに新しい項目を作って、表側にも表示させたい

ということを 4 年間ほどやってきました。
社内で使ってるフレームワークを触る月日が増すごとに、

この案件の場合は大体ここを触れば解決するな
ここは調整が必要だから事前にやっておこう

ということがだんだん分かるようになり、
「この要件を満たすためには、何をすればいいのか」
と言う答えが、少し調査するだけで大分明確になるようになってきました。

そして最近部署移動した現場では、
複数のサービスを 2,3 人で回すという環境にいます。
更にいうと、成熟した大きなサービスではなく、
小さいサービスで、どういうことをすれば良いのかがはっきりしていない場合が多いです。

これまでは、
「これを実現するためには、このくらいの日数が決まっていて、決まったことをやる」
だったのですが、今は
「大体こういうことができるようになりたい。日数は大体で決まっている。何をすれば良いかは自分で考える」
ということが多くなってきました。

そこで、抽象的な課題や指示に対して、自分がどう動いたらよいのか
最近学んだことを書こうと思います。

要件をちゃんと把握する

当たり前かと思いますが、これがとても大事です。
「そもそも何がしたいのか」「何ができればよいのか」を分析することで
次の一歩に進むことができます。
逆にここをしっかり把握していないのと、後からいろいろ計画したことに変更が出てしまい、手戻りが多くなると思います。

その際、要求を出す側も

「大体こんなことがしたいんだよね」と明確に決まっていない
先輩や上司が、”あえて” はっきりとした要求をしてこない

ことがあると思います。
その時は、

現状の課題の本質は何なのかを調べたりヒアリングしたりして
市場でどのような事例があるのかを調べ
今回どのように活用できるか、あてはめられるのか

を調べて提案してみましょう。ググるのはエンジニアの得意分野だと思います。

まとめると、

要求をしっかり把握しよう
要求自体が抽象的だったら、具体的な形になるまで調査、仮説、提案を続けよう

です。
エンジニアリングとは
「曖昧さを減らし、具体的な状態にもっていくことだ」と、とある本でも書いてありました。

「調べる考える」だけでは終わらないし、「調べる考える」は無限にできる

より最適な解が出せるように
より間違わないように

と、「調べる考える」ことをするのは大事です。
ですが、答えが 1 つではないことに対して「調べる考える」は無限にできます。
仕事において時間は有限ですし、なにより「調べる考える」だけでは何も生み出せません。
逆に、調べれば調べるほど選択肢が増えて何が良いのか分からなくなることだってあるでしょう。
ある程度調べたら、区切りをつけて行動に移しましょう。
ある程度というのは

時間
理解度
「あとは試してみないと分からない」と思う

などで判断するように私はしています。
しかし、最初の頃はどこまで調べたら区切りになるのか難しいものです。
理解度が浅く、もっと調べたほうがよいのではないかと不安になる気持ちも分かります。
なので、そんなときは先輩に
「これこれこういうことを、このくらいの時間かけて調べて、こうしようかと思っているのですが、進めちゃってもよいですか？」
と、聞いてみましょう。

曖昧な状態だからこそ、他人にレビュー（意見・指摘）をしてもらおう

曖昧な状態を、より具体的な状態に移行していこうという話をしましたが、
それを個人で実行した場合、それは個人の主観で決まったことです。

曖昧な状態であればあるほど、答えは 1 つではなく複数存在します。
個人で考えたベストな解があったとしても、
どうしても考慮漏れや、要求されていること自体の勘違いが生まれてしまいます。

そこで、他人の目線で意見や指摘をもらうことで、
案をブラッシュアップさせていきましょう。

こうすることで、成果物の質が大きく上昇するだけでなく
これまで自分が盲点になっていた部分に気づくことができ、次回に活かせることができます。

なので、（悪魔で例ですが）

要件定義が終わったタイミングで一度レビュー
設計が終わったタイミングで一度レビュー
工数を考えた段階で一度レビュー
何か困ったことや他者の意見を聞きたいときは相談

などのように、複数回、他者の意見を仰ぎながら進めていくのが良いと思います。

最初は理想系を考えよう

顧客の要望にバッチリ対応できている
今後何か変更があった場合でもちゃんと対応できる。
今後何か起こった場合でも、人の手を入れずに自動で対応できる

などなど、完璧さを追い求めて理想の形を考えることはとても大事です。

慣れていない頃は、何か要求があった場合は
どういう完成形が理想なんだろう（工数や制約は度外視して）ということから考えましょう。
そこから、工数や運用時の現実などの制約を満たせるように、
理想系から現実的なものへと少しずつ変化させていきましょう。

まだ経験の浅い人にとって理想を最初に定義しておくことは

何かスケールしたい時に対応ができる
スケールすることを前提に考えたミニマムな設計ができる
仮に大きなシステムを設計することになったときの練習ができる

というメリットがあります

最初から工数や制約との兼ね合いを気にして計画を立てられるような、
経験値の高い人はそれでもよいでしょう。

このように、何か抽象的なことを始める際には

要求が何かを分析する
最適な理想形を考える
時間的な制約などから、現実的に実行できそうな解に落とし込む

というフローが必要だと思います。

予想される完成物について、定期的に連絡を入れる

完成物が全て完成してから、求めていた人に見せると

完成物が思っていたものと違う。
完成物が出た段階で、なんか違うことが分かった

ということが起きかねません。

また、抽象的な問題や課題は、
過程を踏むごとに具体的になっていくため
解決されるまでの過程で完成形が少しずつ変わっていきます。
そのため、

この方針で進めて良いか？
このまま行くとこういう完成物になるけど良いか？

ということを、区切りのいいタイミングで求めている人に確認してもらいましょう。

まとめ

仕事において、正解は 1 つではない。（抽象的な問題であればあるほどなおのこと）
抽象的な問題の正解は、落とし所（着地点）を自分で決めていこう
そのためには、たくさん調べて、たくさん経験して、たくさん試してみて、比較検討を行おう（ただし、時間的制約もあるので、ここまで調べたら終わりという区切りもつけよう）
またその際には、区切りがついた段階で、1 ステップずつ、他者にレビューしてもらおう