はじめに
株式会社YOSHINANIに技術顧問として参加している、株式会社INFLUのNakano as a Serviceです。
複数のプロジェクトが同時に進行する開発現場。「あのプロジェクトではReact、こちらではVue」「このAPIはGoで、あっちはPython」…気づけば技術スタックがバラバラで、ノウハウがチームに蓄積されない。そんな課題に直面している方も多いのではないでしょうか。
本記事では、そんな課題を解決するために私達が導入した「Notionを活用した技術選定プロセスの仕組み化」についてご紹介します。具体的なNotionデータベースの設計から、導入によってチームに生まれたポジティブな変化まで、実例を交えて解説します。
この記事を読み終えて実践すれば、誰もが納得した上で 自然と最適な技術選択ができる文化 を醸成するためのヒントが得られるはずです。
こんな課題、ありませんか？ プロジェクトごとに技術が乱立する背景
私たちのチームは、小〜中規模のウェブアプリケーション開発プロジェクトを数多く抱えています。そうした環境では、迅速な開発が求められる一方で、以下のような課題が生まれがちでした。
- 場当たり的な技術選定: 納期が迫る中、十分な比較検討が行われず、「Google検索で最初に見つけたから」「個人が使い慣れているから」といった理由で技術が採用されてしまうケースがありました。
- ノウハウのサイロ化と浅薄化: 各々が異なる技術を選定してしまうため、特定の技術に対する組織としての知見が深まって行きません。個々のノウハウは点在するものの、チーム全体の技術的資産として積み上がっていかない状態でした。
- 誰が何に詳しいのか不明: 新しい技術の導入を検討する際や、開発中に問題が発生した際に、「この技術について社内で一番詳しいのは誰だろう？」と、相談相手を探すことから始めなければなりませんでした。
これらの課題は、開発効率の低下だけでなく、メンバーの心理的な負担にも繋がっていました。
解決策は「Notion」での一元管理
課題解決のため、私たちは社内の技術選定ノウハウを一元管理する仕組みをNotion上に構築しました。
DBの全体構成：カテゴリと技術を紐付ける
核となるのは、「技術カテゴリDB」 と 「技術DB」 という2つのデータベースです。
-
技術カテゴリDB:
- 「Webフレームワーク」や「バリデーションライブラリ」といった、技術の大きな括りを管理します。
- それぞれのカテゴリにおける選定方針や推奨技術のサマリーを記述します。
-
技術DB:
-
ReactやVue、Zodといった個別の技術やライブラリを管理します。 - 必ずいずれかの「技術カテゴリDB」に属するようにリレーションで紐付けます。
-
この親子関係により、全体像の把握と詳細情報の深堀りを両立させています。
① カテゴリ一覧ビュー：鳥の目で技術方針を把握する
まず、メンバーが最初に目にするのが 「技術カテゴリ一覧ビュー」 です。
ここでは、カテゴリごとに「何が推奨されているか」「選定基準は何か」といった、チームとしての技術方針がひと目で分かるように設計されています。
これにより、「バリデーションライブラリを探しているんだけど、チームとしては何が推奨だっけ？」といった疑問に即座に答えることができます。
② 詳細ビュー：技術の比較検討と背景を知る
カテゴリ一覧から特定のカテゴリ（例：「日付ユーティリティ」）を選択すると、その詳細ページに遷移します。ここには、そのカテゴリに属する技術が一覧で表示されます。
このビューでは、個々の技術についてさらに深掘りした情報がわかります。
技術のステータス管理
各技術には、現在の社内での位置付けを示すステータスを設定しています。これにより、その技術を今採用すべきかどうかの判断が容易になります。ステータスは、以下のようなフローで変化します。
例えば、ある技術が非推奨になっている場合、その理由（例：「過去にXという問題が発生したため」「現在はYという後継ライブラリを推奨」など）も明記することで、同じ失敗を繰り返さないようにしています。
「誰が使えるか」「どこで使われているか」の可視化
このDBの最も強力な機能が、他のDBとの連携です。
-
有識者との連携:
「メンバーリストDB」と連携させることで、その技術に詳しいメンバーが誰なのかすぐに分かります。「この人が知っているなら、導入のサポートをお願いできそうだ」と、新しい技術を採用する心理的なハードルを下げてくれます。また、メンバーにとっては自身のスキルをアピールする場にもなります。
-
プロジェクト実績との連携:
「プロジェクトDB」と連携させることで、実際にその技術を採用しているプロジェクトを一覧できます。「すでに社内の5つのプロジェクトで安定稼働しているなら安心だ」というように、実績に基づいた信頼性の高い選定が可能になります。
Notion導入でチームはどう変わったか？
この技術選定DBを導入してから数ヶ月。チームメンバーからのヒアリングを通して、多くのポジティブな変化が見られました。
知見の発見と共有がスムーズに
- 「自分の知見が誰かの役に立つ」という実感: 「自分が過去に苦労したあのライブラリの情報を共有しておこう」といったように、メンバーが自発的に知見を登録してくれるようになりました。
- 新たな技術との出会い: 「他のメンバーが推薦しているこのライブラリ、面白そうだから次のプロジェクトで使ってみようかな」と、DBが新たな技術を知るきっかけになっています。
- 探しやすいことの価値: カテゴリでフィルタリングできるため、「フロントエンドのフレームワークで『推奨』になっているものは何がある？」といった探し方ができ、情報へのアクセス性が格段に向上しました。
技術選定の質とスピードが向上
- 意思決定の高速化: 新規プロジェクト立ち上げの際、まずは「推奨」技術の中から検討することで、ゼロからリサーチする手間が省け、スピーディかつ質の高い技術選定が可能になりました。
- 「失敗の再発防止」: 「非推奨」とされている技術には、その理由（例：「過去に深刻な脆弱性が見つかった」「メンテナンスが停止している」など）が明記されているため、同じ過ちを繰り返すリスクを未然に防げます。
- 客観的な判断軸の提供: 選定基準が明文化されていることで、「なんとなく」ではなく、明確な根拠に基づいて技術選定の議論ができるようになりました。
心理的な安心感とコミュニケーションの活性化
- 質問のハードルが下がった: 誰がどの技術に詳しいかが可視化されたことで、「〇〇さん、この技術について少し教えてください」と、気軽に質問できる心理的な安全性が生まれました。
- 「これで本当に大丈夫だろうか？」という不安の軽減: チームの合意として「推奨」されている技術を選ぶことで、選定担当者の「自分の判断が間違っていないだろうか」というプレッシャーが和らぎました。
自然と最適な選択ができる文化の醸成
この仕組みがもたらした最大の成果は、技術選定におけるコミュニケーションコストが劇的に下がったことです。以前のようにメンバーが個別に調べ、議論し、説得し合うプロセスを経ずとも、Notion DBを見れば「なぜこの技術が推奨されているのか」という根拠が分かり、誰もが納得した上で 自然と最適な選択ができる文化 が生まれました。
まとめ
本記事では、Notionを活用して技術選定プロセスを仕組み化し、チームの知見を最大化する取り組みについてご紹介しました。
この仕組みは、単なる情報共有ツールにとどまりません。技術選定の基準を明確にし、知見の属人化を防ぎ、そして何よりメンバー間の円滑なコミュニケーションを促す「文化の土台」となっています。
この記事が、あなたのチームの開発プロセスをより良くするための一助となれば幸いです。
Discussion