開発がうまく進まないときは、「具体」と「抽象」を行き来してみたらスムーズになった話

法人ディベロップメント課のS・Sです。
マイナビBiz / LIVING の新規開発・保守運用を行なっております。

開発を進めていく中で、こんなお悩みありませんか？

・運用保守で対応した成果物が、事業部が求めているものではなかった
・担当の開発タスクの仕様が理解しきれない or 時間がかかってしまう
・関係各所との調整時に、認識一致に苦戦している

今回は、そんなあなたに向けて、開発において、具体化と抽象化を意識するようになってから、開発がスムーズになった気がする件について、まとめました。

そもそも、具体化と抽象化とは？

私なりの解釈では、それぞれ下記のようなイメージです。

具体化

抽象的な考えや漠然とした事象を、誰もがすぐに行動や理解ができるよう、数字や固有名詞を使ってはっきりした形にすること。

抽象化

具体的なものから重要な共通点や本質だけを抜き出し、他の細かい部分を取り除いて、分かりやすい大きな概念にまとめること。

言葉だけだとイメージしづらいかと思います。
簡単な例を含めて、イラストにしたので、こちらをご活用くださいませ。

具体化と抽象化を意識するようになってから、開発がスムーズになった2つの理由

課題の本質を見極めた上で、適切な解決策や対策を討ちやすくなったから

PJで問題が発生した際に、下記の流れで問題に向き合うことで、適切かつ正確な解決策、対策を討てるようになりました。

・事象を具体化し、具体的な材料を洗い出す
・具体的な材料を元に、問題を生み出している共通の原因が何なのかを集める

この考え方が無いうちは、問題が発生しても、そもそもの事象を曖昧に捉えていたので、原因も曖昧で解決策も曖昧になりがちでした。

その結果、具体的な解決策や対策を打っても、問題が解消されないことが往々にしてありました。

本質をブラさずに、相手に伝わりやすい表現で伝えやすくなったから

エンジニアの当たり前に使っている用語や理解は、エンジニア以外の方にとって？？？であることが多いです。

なので、マーケティングの方ならどんな言葉であれば、理解してもらいやすいのかを選ぶことで、互いの認識ズレを減らしやすくなりました。

この考え方が無いうちは、自分もしくは自分と同じ経験値や近い環境にいる相手にしか適切に伝わりづらく、苦労が多かったです。

極端な例ですが、エンジニアにとっては当たり前である AWS の技術的なワードをそのまま使ったり、React うんぬん等々です。（今思えば、聞いている側はポカンとしてしまうことを言ってしまっていたなと反省しています）

どのように、具体化と抽象化を意識すると良いか 〜実際にやっている3つの方法〜

何となく、具体化と抽象化が大事そうなことが伝わって頂けかな?と思います。

とはいえ、どうやって、具体化と抽象化を意識すればいいのかのイメージが付きづらいかなと思いますので、実際にやっている3つの方法をカンタンにご紹介します。

問題の共通点を探す意識を持ってみる（具体 → 抽象化）

抽象化を意識するために、問題や事象の共通点は何か？を自問してみるのがおすすめです。

例えば、下記の3つの問題があったとします。

１、自担当のタスクが予定時間を大幅にオーバーしてしまった
２、プルリクエストのレビュー修正に時間がかかってしまった
３、自担当のタスクで不具合を発生させてしまった

この3つの問題が発生してしまった「共通の原因」は何かを考えてみます。

・見積もりが余ったから？
・レビュー通知に気づくのが遅かったから？
・気を抜いていたから？

いえ、違います。

このような見方をしてしまうと、また同じ原因の問題を発生させてしまいます。
今回の事例では、3つで共通する原因は、「自担当のタスクへの理解不足」が共通している点です。

タスク理解不足で、この3つが発生してしまっていたんです。

・自担当のタスクが予定時間を大幅にオーバーしてしまった
・プルリクエストのレビュー修正に時間がかかってしまった
・自担当のタスクで不具合を発生させてしまった

このように、様々な問題や課題に対して、共通している根本の原因は何？と考えるようにすることで、抽象化を意識して、原因分析に役立てられます。

具体的な事柄を他のもので例えてみる（具体 → 抽象化 → 具体化）

上記の通りですが、具体的な事柄を他のもので例えてみることで、本質が相手に伝わりやすいワードを選んで伝えやすくなります。

例えば、下記のようなイメージです。

具体：
・AWS の IAM（操作権限を分ける）

本質：
・人や役割ごとに、できる操作を必要最小限に絞ること

他のもので例えてみる：
・会社の入館証と部屋の鍵を管理する仕組み

このように本質と、他のもので例える意識を持つことで、エンジニアではない方に対して、IAM という専門用語を使わずに、やりたいことややっていることを相手に理解してもらいやすくなるかなと思います。

「問題が曖昧になっていないか?」と自問してみる（事象 → 具体化 → 具体化）

何か問題が発生するとつい、反射的に、すぐ目の前に起きている表面への対処を実行してしまいがちですよね。

ただ、この時に、一歩立ち止まって、
「目の前の事象の問題は曖昧ではないか？」
を自問してみると的確な原因究明と解決策を討ちやすくなるかなと思います。

【Before】
・画面表示が遅いから、フロントエンドを軽量化しよう

【After】

<事象>
・画面表示が遅い

<原因（「曖昧ではないか？根本は何か」）>
・ブラウザの開発者ツールで、画面描画・JavaScript実行・API通信のどこに時間がかかっているかを見る
・APIのログで、バックエンド処理、DBアクセス、外部API呼び出しの処理時間を確認する
・遅くなる条件を確認する
・特定の画面だけか
・特定の時間帯だけか
・特定のユーザーやデータ量が多い場合だけか
・エラーログやタイムアウト、リトライの発生状況を確認する

<解決策>
特定の時間帯だけ遅いことがわかった
→ アクセス集中やリソース不足を疑い、オートスケーリング、キャッシュ、負荷分散などを検討する etc…

まとめ

改めて、開発をスムーズに進めるためには、目の前で起きている事象にすぐ対処するのではなくて、具体化と抽象化を行き来することが大切かなと思います。

下記を意識することで、表面的な対処ではなく、原因に合った解決策を選びやすくなります。
また、エンジニア・事業部・関係各所など、それぞれ異なる立場の人とも認識をそろえやすくなります。

・問題を具体化して、いつ・どこで・誰に・何が起きているのかを明確にする
・複数の事象から共通点を探し、根本的な原因を抽象化する
・抽象化した本質に対する解決案を出す
・抽象化した本質を、相手に合わせて具体的な言葉や例に置き換える（必要があれば）

まずは、問題が起きたときに、以下の3つを自問してみてはいかがでしょうか？

１、この問題は、具体的に何が起きているのか？
２、複数の事象に共通する原因は何か？
３、この内容を、相手が理解できる言葉に置き換えるとしたら何か？

具体化と抽象化は、仕様理解・障害対応・見積もり・レビュー・実装・関係各所との調整など、さまざまな場面で活かせる考え方かなと思います