具体と抽象を意識したら仕事を進めやすくなった話

この記事は CARTA TECH BLOG アドベントカレンダー2024 の 12/4 の記事です！！

こんにちは！CARTA HOLDINGS の Lighthouse Studio という事業部で「神ゲー攻略」の開発を担当しているエンジニアの yoko です。今回は自分が3年目になって身につき始めた仕事のコツについて話します！具体と抽象を意識的に使い分けることで、より広い範囲の仕事を進めやすくなったという話です。

この記事の対象読者

新人という段階を超えてより広い仕事をするようになった人

具体と抽象を意識することでなぜ仕事を進めやすくなったのか？

最初に結論を述べると「抽象度の異なる仕事に対して意識的に思考を切り替える」ことができるようになったからです。これについて詳細を話していきます。

まず、そもそもの自分の背景としては「3年目になって抽象度の異なる仕事が増えた」というものがありました。

エンジニアとして不具合対応や機能改修といった"作業ベースの開発"をこなすこともあれば、先輩としてチームの目標やスケジュールなどを提示する"方針の探索"のような仕事もやる必要があります。

表にまとめると以下のような変化がありました。

	Before (1~2年目)	After (3年目の現在)
主な仕事	上長や先輩が見つけた課題を解決する	目標達成のために課題を探索して解決する
スコープ	狭い：大まかな課題は提示されている	広い：課題を探索するところから始まる
主に話す人	基本的に開発メンバー	開発メンバー & 事業責任者などのビジネスサイド間
抽象度	基本的に低い	高いものと低いものが混在している

ここで強調したいのが、役割に変化はないためエンジニアとしてアウトプットを出すことが大前提ということです。そのため、方針の探索のような"抽象度の高い"仕事だけでなく、実際に手を動かして実装する"抽象度の低い（具体的な）"仕事もこなす必要がありました。

同時にコミュニケーションが必要な相手も変わりました。Before では開発チーム内で実装や課題についての具体的な話が中心でしたが、After では事業責任者などと方針やスケジュールなどを調整する抽象度の高い話が多くなりました。

今となっては抽象度の違いを意識してこのように切り分けることができましたが、最初はごっちゃになっていたので以下のような問題が発生していました。

問題1：ミーティングで細かい開発の話をしてビジネスサイドが混乱する
問題2：背景を理解しないままタスクを進めてしまい手戻りが生じる

これらの問題は、「抽象度の異なる仕事に対して意識的に思考を切り替える」という解決策で解消できたと感じています。次はこれらの問題と抽象度の意識によってどう解決されたのかを話していきます。

問題1：ミーティングで細かい開発の話をしてビジネスサイドが混乱する

エンジニアとしてビジネスサイドとのミーティングに参加するときに、どの粒度の話をすればいいか困ったことがある方も多いのではないでしょうか。特に、技術的な話ができそうな場面ではそれが顕著に現れると思います。

自分の場合は、ビジネスサイドを交えた進捗報告のミーティングで細かい開発の話をしてしまうことが多々ありました。その理由として、このミーティングの目的とどのレベルの抽象度で話し合うべきか理解していなかったためです。そのため、ミーティングでは「？」が飛び交ったり話がそれる時がありました。

実際には、このミーティングで期待されていたことは以下でした。

目的：事業責任者へ方針・スケジュールを共有して必要であれば軌道修正する
扱う抽象度：高い。基本的に開発の具体的な話は必要なし

より詳細に述べると以下について共有し、目標を達成するための方針を話し合う場でした。

目標
実績
実績と目標のギャップ
ギャップを埋めるために今後どうするか（方針・スケジュール）

これらミーティングの目的の理解と、話し合うべき抽象度を意識できるようになってからは「？」や話がそれることも減り、ミーティングの目的を達成できるようになっていきました。

ただし、反対に抽象度をどんどん下げていくようなミーティングも存在します。例えば、特定のシステム的な課題について話し合う場などです。このような場では、議論を深ぼって抽象度を下げていくアクションも求められると思います。

問題2：背景を理解しないままタスクを進めてしまい手戻りが生じる

エンジニアは困難な課題に対して没頭しければいけない時が多いと思います。これはシステムの細部を詰めていく、つまり抽象度を下げていく作業である場合が多いです。

自分もこのような状態になっている時が多くあります。そして過去の自分は悪いことに、タスクの背景知識が足りないままどんどん細部を詰めていくような感じになっていました。すると、以下のような問題が発生しました。

効果に対してオーバーな解決策を採用してしまう
実はそれほど必要のないタスクに時間をかけていた

したがって、時間をかけて細部を詰めた後に別の対応を検討するという状況になっていました。

しかし、抽象度を意識できるようになってからは以下のように進めることができ、手戻りを減らせるようになったと感じています。

（手順1）タスクの抽象度を高くして課題の本質を見極める
- 例：「ページ読み込み速度を上げる」というタスクの背景には「記事の PV を増加したい」という背景があるのでは？「記事の PV を増加したい」を達成するためには、そもそも「スクロールの不具合」を直すべきでは？
（手順2）タスクの抽象度を低くしていって解決法を詰める
- 例：「スクロールの不具合」を直すには技術的 A が有用である。A を使うためにはどうする？
（手順3）詰まったら再度抽象度を高くして解決法を探索する → （手順1 or 2 に戻る）