「できる領域」のやり方を、「できない領域」に転用する——そのために必要だったのは、暗黙知を「構造化」することだった

※この記事は、2025 Speee Advent Calendar 22日目の記事です。昨日の記事はこちら

---

はじめに

こんにちは、SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの北田です。

この1年で、事業として実現したいことの難易度が大きく上がりました。それに伴い、設計・調査の難易度も上がっています。結果として、私は「実装はできるのに、設計・調査になると見積もりが大きくズレる。対策を立てても改善しない」という壁にぶつかりました。

この記事では、そこから私がどうやってその壁を突破したのかをお伝えします。結論を先に言うと、「できる領域」で無意識にやっていることを構造化し、「できない領域」に転用することで突破しました。

同じように「できる領域」と「できない領域」の差に苦しんでいる方にとって、この考え方が何かしらの助けになれば嬉しいです。

課題：なぜか「できない領域」がある

私にとって、設計・調査は「できない領域」でした。

見積もりが大きく乖離することが続いたのです。2営業日で終わる想定が6営業日かかる。そんなことが何度も起きました。

振り返って対策を立てても、うまく改善しない。なぜか。「Whatを考える」「立ち止まる」「相談する」といった対策は出せても、具体的に何をどうすればいいかがわからなかったからです。

対策として「やるべきこと」はわかっていた。でも、その「やり方」が具体的になっていなかったのです。

では、その「やり方」をどうすれば明らかにできるのか。

気づき：「できる領域」には暗黙知がある

ヒントを探すために、比較対象を探しました。自分の中で「同じような状況でも、うまく回せている領域」はないか。

私にとって、それは実装でした。実装では、見積もりが大きくズレることはありません。たとえズレても、何が原因かはすぐにわかる。

では、なぜ設計・調査ではそれができないのか？

考えてみると、実装では無意識に何かをやっている。つまり、「できる領域」には、自分でも気づいていない暗黙知があるのではないか。そう考えました。

問題：暗黙知のままでは転用できない

しかし、暗黙知があるとわかっても、それだけでは何もできません。

改めて私がやりたいのは、実装で無意識にやっていることを、設計・調査にも転用することです。しかし「無意識にやっている」ことを、どう明確にすればいいかわからない。だから、何をすればいいかもわからない。

暗黙知をどうにかして明らかにする必要がありました。

解決策：暗黙知は「構造化」する

では、暗黙知を明確にするには、どうすればいいのでしょうか。

私はそこで、まず要素に分解し、関係性を整理してみることにしました。いわゆる「構造化」というアプローチです。

実際に、実装でやっていることを構造化してみると、次のような進め方をしていることがわかりました。

1. 要件・やりたいことを把握する
2. どう実装するかのイメージを書き出す
3. テスト方針として、contextを整理する

そこまでやって、ようやく実際にコードを書き始めていました。

つまり、コードを書くという具体作業に入る前に、目的・方針・検証観点といった全体像を整理していたのです。

構造化することによって、「具体作業に入る前に、全体像や関係性を整理する」という原則を実装では行っていることがわかりました。これが、実装では無意識にできていて、設計・調査ではできていなかったことの正体であり、私にとっての転用できる武器でした。

実践：「できる領域」のやり方を、「できない領域」に転用する

「具体作業に入る前に、全体像や関係性を整理する」。この原則を、設計・調査に転用しました。

設計なら、具体的な検討に入る前に：

1. 目的・要件を整理する（何を解決したいか、どこまでやれば完了か）
2. 制約条件を洗い出す（既存影響、期限、依存関係など）
3. 問題を分離する（複数あるなら切り分ける）
4. アプローチの選択肢を出す
5. 選択肢を比較して決める

調査なら、手を動かす前に：

1. 目的を確認する（何を明らかにしたいか）
2. 完了条件を確認する（何がわかれば終わりか）
3. 仮説を立てる（こうなっているのではないか）
4. 調査手順を整理する（どの順序で確認するか）

これはあくまで私が出したステップであり、完璧なものではありません。そのため、まだ見積もりとズレることもあるでしょう。

ただ、武器を転用してステップとして明確化したことで、ズレた時の対処ができる状態になりました。「どのステップで詰まっているか」がわかれば、相談もできる。振り返りでも「意識が足りなかった」で終わらず、「どのステップを抜かしたかまたは足りなかったか」という具体的な改善につなげられる。

暗黙知を構造化したことで、「できる領域」のやり方を「できない領域」に転用でき、その結果、設計・調査のやり方を明らかにできたのです。

まとめ

「できる領域」には、自分でも気づいていない暗黙知があります。

それを構造化することで、「できない領域」にも転用できる武器が見つかります。

私の場合、その武器は「具体作業に入る前に、全体像や関係性を整理する」という原則でした。これを設計・調査に転用し、具体的なステップに落とし込むことで、振り返りの精度も上がりました。

もしあなたが「なぜかうまくいかない領域がある」と感じているなら、まずは「できる領域」で何をやっているかを構造化してみてください。そこに、転用できる武器が眠っているかもしれません。

最後に

Speeeではときに失敗をしながらも、各メンバーがサービスの改善やその先にあるミッションの実現に日々向き合っています。

Speeeのエンジニアの事業への向き合い方について共感していただけた方、Speeeでは一緒にサービス開発を推進してくれる仲間を募集しているので、ぜひ以下のフォームからお申し込みください！

新卒の方はこちらより本選考に申し込みが可能です！キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！