[AIによる業務改善] 1on1支援ツールを自社開発した話

1on1、ちゃんと回せていますか？

マネージャーとして複数のメンバーを担当していると、こんな悩みに心当たりがあるかもしれません。

• 担当メンバーが増えてきて、毎月の1on1の準備が追いつかない
• 3人を超えたあたりから、誰が何を話していたか曖昧になってきた
• 評価のとき、結局は直近1ヶ月の印象で決めてしまっている
• 1on1の場で、その月の業務の進捗確認だけで時間が終わってしまう
• 1on1の記録はマネージャーごとにバラバラで、引き継ぎができない
• 記録を読み返したいのに、自由記述の文章が並んでいるだけで分析できない

どれも、1on1という業務に固有の「あるある」です。一対一の対話だからこそ、属人化しやすく、改善の手も入りにくい。それでいて、メンバーの成長や、評価の納得感に直結する、非常に重要な業務でもあります。

この記事では、AIを活用して、1on1の準備から記録、振り返りまでを支える社内ツールを自作した話を書きます。何を作り・どう設計し・使ってみて何が起こったのか。できるだけ具体的にお伝えします。

1on1や評価に課題を感じているマネージャーの方はもちろん、自社の業務をAIやツールで改善していきたい方にも、参考になれば幸いです。

1.何を作ったのか：1on1支援ツール「baigieOne」の全体像

まずは、できあがったツールの中身から見ていただければと思います。名前は「baigieOne（ベイジワン）」。社内のメンバー全員が、毎月1回使うツールです。

ツール全体を貫いているのは、「1on1を、ちゃんと人の成長につなげる」というシンプルな目標です。ユーザーは「メンバー」「マネージャー」「経営層」の3つに分かれ、属性ごとに機能が変わります。

1-1. メンバーはどう使うのか？

＜メンバー機能①＞年間目標（OKR）の設定

年度のはじめに、OKR（Objective and Key Results）の枠組みで目標を設定します。大目標 → 小目標と日々の行動 → KR（Key Results）の順に、構造化されたフォームに沿って入力していきます。各項目にはガイド文がついていて、OKRに不慣れな人でも書けるように配慮しました。

＜メンバー機能②＞月次振り返りの記録

メンバーが毎月入力する、このツールの中核となる機能です。OKRで設定した「小目標」と「日々の行動」が、振り返りシートにそのまま並んでいます。行動ごとに「5段階の達成度」「グッド（Good）：意識できた場面や工夫できたこと」「モア（More）：改善したいことや次に試したいこと」を入力します。

＜メンバー機能③＞AIによる下書き生成

行動ごとのGood/Moreを書き終えると、「AIで下書きを生成」というボタンが出てきます。自分で書いたGood/Moreの内容をもとに、その下の「学びと気づき」欄の下書きをAIが作ってくれる機能です。書きたいけど言葉が出てこないときの補助輪として置きました。

＜メンバー機能④＞過去履歴の閲覧

これまでに書いた振り返りや、過去に行った1on1の記録は、いつでも見返せます。年末の評価面談のとき、1年分の蓄積をそのまま材料にできるよう設計しています。

1-2. マネージャーはどう使うのか？

＜マネージャー機能①＞メンバー個人ページで現在地を把握

サイドメニューの「マネジメント」から担当メンバーを選ぶと、そのメンバー専用の全景ビューが開きます。このページには、メンバーが今年掲げているOKR、過去数ヶ月のコンディションの推移、月次振り返りの履歴、そして過去の1on1の記録が、一目で把握できる順に並びます。1on1の前にこのページを開けば、その人の現在地が短時間で掴めます。

＜マネージャー機能②＞1on1セッションの記録

1on1の最中や直後に使うのが、「1on1セッション登録画面」です。本文欄は、本人には見せないマネージャー専用のメモ欄として設計しています。実際の運用では、1on1の後にMeetの文字起こしからサマリーを生成し、ここに貼り付けるという使い方も想定しています。1on1の最中はメモを取らずに対話そのものに集中でき、後から整形する作業も発生しません。

1-3. 経営層はどう使うのか？

経営層は、このツールを毎日使うわけではありません。「四半期や半期に一度、組織全体の様子を眺めるために開く」という使い方を想定しています。

見られる情報は、「チームごとのコンディション傾向」「アクションが案件に乗っているかの傾向」「いろんな状態の人数把握（名前は出ない）」といった、集計・抽象化された情報のみです。個人の1on1の中身やマネージャーの所感メモは、あえて見られない設計になっています。

2. 設計思想：1on1を着実な成長につなげるために

1on1支援ツールを作るとき、最初に決めたのは「何を作らないか」でした。便利な機能をたくさん詰め込むのではなく、シンプルに「1on1を、ちゃんと人の成長につなげられるツールにする」ということを重視しました。

そのために、UX設計の主軸として3つの優先順位を立てています。

• 正確さよりも、続けやすさ→日々の記入のハードルを上げないこと
• 網羅性よりも、意味が残ること→メンバーが自分の成長を実感できること
• 管理よりも、内省と対話→メンバーの本音を書きやすくすること

このツールが何を優先し、何を捨てるか。それを最初に言語化したことで、設計の指針が定まりました。また、関わる人の役割ごとに、このツールが目指す状態も明確にしました。

• メンバー：考えたことが、ちゃんと積み上がる
• マネージャー：日常の会話が、判断に変わる
• 経営層：個人を見なくても、兆しが見える

このロール別の到達状態は、ツールの全体像を貫く設計指針として、最後まで効きました。続いて、ユーザー別の設計思想のポイントを解説します。

2-1. メンバー：「振り返りシート」の設計思想

このツールのメインとなるのが、各メンバーの振り返りシートです。振り返りの土台にあるのは、教育学で知られる経験学習サイクル（具体的経験 → 内省的観察 → 抽象的概念化 → 積極的実践）という考え方です。経験を振り返り、そこから教訓を引き出し、次に活かす。この循環が、人の成長を支えると言われています。

ただ、このサイクルをひとりで全部回すのは、実はとても難しいです。特に「経験から教訓を引き出す」「次にどう活かすかを考える」といった後半のプロセスは、ひとりで内省するよりも、対話を通じた方が圧倒的に深まります。

そこで今回自作した1on1支援ツールでは、経験学習サイクルの起点である「具体的経験」を、メンバーが記録できる状態を用意することに専念しました。達成度・Good・Moreという入力欄は、「その月、実際に何が起きたか」を確実に書き残すための仕組みです。

経験さえ言語化されていれば、その先の「なぜそうなったか」「次どうするか」は、1on1の場でマネージャーと一緒に深掘りできます。ツールが経験を記録し、1on1が意味づけをする。経験学習サイクルを、ツールと対話で分業する設計です。

「学びと気づき」欄に置いたAI下書きボタンも、この思想の延長です。具体的経験（Good/More）は本人にしか書けないので必ず自分で記入する。でも、そこから「学びや気づき」を引き出す作業や、経験を一段抽象化するプロセスは、ひとりだと詰まりやすい。そこに、AIを補助輪として置きました。AIに考えさせるのではなく、自分の思考を前に進めるための存在として配置しています。

そして、シートの最後にあるコンディション欄（1〜5の5段階）をあえて最後に置いています。最初に聞くとその日の気分に引っ張られますが、振り返りを書き終えた後なら「振り返って整理した結果、今こう感じている」という、思考を経た状態が記録されます。

2-2. マネージャー：「メンバー個人ページ」閲覧の設計思想

マネージャーの「メンバー個人ページ」の情報の並び順には、明確な意図があります。それは、5分でメンバーの状況を把握できる順番です。

5分弱で「この人が今、何を目指していて、最近の調子はどうで、今月の準備は整っていて、前回どんな話をしたか」を順に確認できる仕様です。経験から導いた、マネージャーの認知負荷を最小化するための情報順序です。

そして、1on1セッション登録画面には、月次振り返りを複数紐付けられる仕組みがあります。これにより、「今月と先月の振り返りを並べて話す」「過去にさかのぼってまとめて振り返る」といった使い方ができます。

2-3. 経営層：「個人を監視できない」という設計思想

経営層が見られるのは、「チームごとのコンディション傾向」「アクションが案件に乗っているかの傾向」「いろんな状態の人数把握（名前は出ない）」といった、集計・抽象化された情報のみです。

そして、見えないものとして「個人の1on1内容」「マネージャーの所感メモ」「個人評価につながる情報」を明示的に設計から外しています。経営層UXの価値は、「見張らない、でも見逃さない、信頼に基づく可視化」という3点がすべてです。

3. テスト運用で見えたユーザーの声

このツールを、私のチーム内で1ヶ月間ほど限定運用した際のコメントを紹介します。ユーザーの感想をまとめると以下のような点があげられました。

• ＜メンバー＞粒度が固定されるので書きやすくなった
• ＜メンバー＞OKRに紐づいた行動を意識しやすくなった
• ＜マネージャー＞メンバーの1on1準備の質が上がった
• ＜マネージャー＞行動の不足が「見える」ようになり、指摘しやすくなった
• ＜マネージャー＞1on1後のメモを整形して記録に残す時間が減った

4.このツールを作ったきっかけ

私は2024年にマネージャーになってから、チーム運営の施策をいろいろと試してきました。雑談会、勉強会、メンバー同士の1on1など、続けたものもあれば、やめたものもあります。その中で、チーム全体を盛り上げる施策よりも、一人ひとりのメンバーの成長に直接向き合う仕組みのほうが効く、ということがわかってきました。

全体施策にも、場の雰囲気をよくしたり、共通認識をつくれたりする良さはあります。ただ、一人ひとりが抱える具体的な課題までは届きません。各メンバーごとの状況を捉え、目標と支援を考えてはじめて、行動や成果につながっていきます。

さらに、メンバーが成長すると、その人自身が周囲を支えられるようになります。後輩の相談に乗る、自分の経験を共有する、困っている人に気づく。そうしたメンバーが増えれば、支援はマネージャーひとりに集中しなくなります。一人ひとりの成長に向き合うことは、チーム内に「支える側」を増やし、より多くの人を育てやすい状態をつくることでもあると感じました。

そして、その中核に置いたのが1on1です。1on1をはじめたばかりの頃は、振り返りの方法を「人には人のやりやすさがある」と属人性に委ねている部分も多くありました。しかし、続けるうちに、扱いやすい仕組みを整えたほうが全体の質は底上げされるのではないかと考えるようになり、まずはスプレッドシートやNotionで振り返りシートを作りました。

この運用は、それなりにうまく回りました。私が、普段アプリ開発でUI/UXに向き合っているということもあり、仕組みそのものを”使われる設計”として磨いていくことができました。それを続けていくうちに、Claude Codeの登場で社内のDXの動きが加速。その流れから、自チームだけでなく社内全体で使えるAIツールをつくることになり、このツールを開発するに至りました。

5. 開発のプロセス：PMとエンジニアの分担と開発スタイル

このツールがどう作られたかについても、簡単に振り返っておきます。PM（要件設計担当）とエンジニア（実装担当）で動き方が分かれていたので、それぞれの視点で整理します。

5-1. PM側のプロセス

ツールの形になる前、私は1年以上、自分のチームでNotionやスプレッドシートを使った振り返りの型を試行錯誤してきました。経験学習理論を踏まえながら、何度も型を作り直してきた蓄積があります。

そのため、ツールを「作ろう」と思った段階で、頭の中にはすでに型がありました。設計フェーズに費やした実時間は、3日間にわたって各2時間ほど、実働でいえば6時間程度です。その短時間で、画面遷移の整理、Googleの「Stitch」というプロトタイピングツールでの画面イメージ作り、4コマ漫画形式での体験設計、生成AIとの壁打ち、他マネージャーへのヒアリングを並行で進めました。使ったツールは、ほぼFigjam一枚です。

エンジニアとは、コンセプトと方針的な部分を伝え、そこから実装してもらいました。すり合わせ2回、できあがったものへのフィードバック2回、合計4回の対話で初版が完成しています。

5-2. エンジニア側のプロセス

実装は、社内エンジニア1名が担当しました。実装にかけた時間は、ざっくり1日8時間×2週間ほど。内訳は、モックの作成が3日、実装と検証で1週間、残り4日がリリース後の対応、という配分です。

進め方としては、まずPMから渡されたStitchの画面イメージをもとに全体のデザインシステムを構築し、ベースとなる画面のモックを実装。PMとモックを確認しながら全体の認識合わせを行い、その流れの中で出てきた要件を、ミーティングの文字起こしから生成AIで整理して画面ごとの指示書に落とす、という方法をとりました。そこから、データベース設計とフロントエンド実装に入っています。

そして、最後に特定のチーム向けにプレリリースを行い、改善点を反映してから全社展開に進みました。

＜技術スタック＞

採用した主な技術は、以下の通りです。

• フロントエンド：React / TailwindCSS / Shadcn UI
• バックエンド：Hono + Cloudflare Workers
• データベース：Supabase

選定の方針として、最初から完成を目指さずに最低限のMVPとして動くものを作り、そこからブラッシュアップしていく前提でスタックを組みました。Cloudflare Workers と Supabase を中心に据えたのは、サーバー側に手をかけすぎず、開発そのものに集中できるようにするため。基本的なセキュリティ対策が Supabase 側でカバーされる点も、判断のポイントになっています。

＜AIツールの使い分け＞

実装フェーズでは、複数のAIツールを役割ごとに使い分けていました。

【Claude Code】

→設計と実装のメイン。AIで整理した指示書をベースに、コードの設計や実装そのものを担当

【Codex】

→デバッグやレビュー用。ひとつのモデルだけだと判断が偏る可能性があるので、別のAIの視点を意図的に入れる

【ChatGPT】

→壁打ちや、設計フェーズ外の調べ物

エンジニア曰く、「複数のAIを並行で使ってみて、それぞれが得意な場面で動かす方が結果が良くなる」とのこと。ひとつのAIに依存しない、ツールを横断する作り方が、いまの開発スタイルにフィットしていそうです。

6. これからの展望

自作1on1支援ツールはまだ、全社展開してから1サイクルが終わったばかりです。運用しながら月1回という利用頻度の中で何が変わるかをヒアリングし、アップデートを継続していきます。

直近で取り組みたい機能や発展方向もいくつかあります。

【振り返りを書くのが苦手な人への、もう一段の支援】

音声入力で話したことをもとに、AIが対話形式で深掘り質問を返してくれる、といった補助機能を検討しています。「書く」のハードルが高い人にも、考えを言語化してもらえる状態を作りたいと考えています。

【年次評価への活用】

年間の1on1記録と振り返りを総合的に参照し、評価の根拠（エビデンス）が見える状態にしたいと考えています。マネージャー専用に開発した評価分析機能を、今回のツールに統合する予定です。

【月次1on1の「年間版」としての価値】

月次の積み重ねをデータとして蓄積し、年末の評価面談で「1年前からこれだけ変化した」という成長を可視化したいと考えています。本人が成長を実感し、「また来年も頑張ろう」と前向きになれる場として、月次1on1の年間バージョンを設計していく想定です。

【他業務への横展開】

振り返りデータの蓄積は、コンディション把握だけでなく、「成長が早い人の振り返りの特徴」「自社にマッチする人のタイプ」といった分析にも応用できます。採用や育成の判断材料として、組織開発の基盤に育てていきます。

なお、需要があれば、外部への提供も検討したいと考えています。

7. 御社に合ったシステムも、作れます

もとは社内向けに作ったツールですが、ここで使ったアプローチは、そのまま他社の業務システムづくりにも展開できます。

業務システムを作るとき、多くの会社は「機能要件をヒアリングして、画面に落とし込む」というアプローチを取ります。でも、それだけでは「業務の流れと噛み合うシステム」にはならないと考えています。

ベイジのUIUX事業部は今回の開発で実践したように、以下の価値を提供できます。

【業務そのものを理解した上での要件整理】

業務の目的や実際の運用フローを深く理解し、現場ごとの文脈や属人化しているポイントまで踏まえて要件を整理します。単に要望を機能に落とし込むのではなく、本質的な課題の特定から支援します。

【業務の意図を仕組みに落とし込む設計】

利用者の役割や目的に応じて、情報設計や画面構造を最適化します。管理やルールによって行動を縛るのではなく、自然と適切な判断や行動が取れる導線や仕組みを設計します。

【AIや最新の開発手法を活用した、素早い開発・実装】

AIや最新の開発手法を活用し、プロトタイプ作成から本番実装までをスピーディーに進行します。要件が整理された状態であれば、数日〜数週間という短期間で実用的なシステムを形にできます。

• 「この記事で紹介されているようなマネジメントツールを作りたい」
• 「社内の業務ツールを作りたいが、何から手をつければいいか分からない」
• 「AIでツールを作ってはみたが、現場で使われるものにならない」
• 「業務フローそのものから見直したい」

こうした想いのある会社さんは、ぜひ一度ベイジまでご相談ください。

おわりに

このツールを作る中で、何度も自問したのは「これは、本当に作るべきものなのか」という問いでした。ルールで周知すればいいのか、システムにすべきなのか。 全部の機能を盛り込むべきか、削るべきか。 誰の体験を、どこまで作り込むべきか。

「気軽に作れる時代」だからこそ、「何を作るか」「何を作らないか」の判断が、これまで以上に重要になっています。

今回自作した1on1支援ツール『baigieOne』は、その問いに対する、現時点での私たちの答えです。完璧なものではないけれど、月に1回、誰かの振り返りを少しだけ前向きにできているなら、それは十分に価値があるものだと考えています。

これから運用を重ねていきながら、ツールも、そして私たち自身の考え方も、アップデートしていきます。