k1b3

学習塾向けWebアプリケーション開発において、2〜3名の開発チーム（ジュニアエンジニア2名）をマネジメントしていました。プロジェクトの進行管理、顧客折衝、要件定義、技術的な意思決定を担当しました。開発業務全般（機能実装、不具合修正、要件定義、ドキュメント整備）に幅広く従事しながら、チームリーダーとして開発を牽引し、メンバーの成長支援も行いました。

開発チームを「顧客に価値を届け続けられる、持続可能な開発体制」にする責務がありました。 具体的には以下3点です。 **1. 品質とスピードの両立** 顧客の要望に迅速に対応しながらも、技術的負債を蓄積させず、長期的に保守しやすいコードベースを維持する必要がありました。 **2. チームメンバーの生産性向上** ジュニアエンジニア2名のチーム構成だったため、メンバーが迷わずタスクを進められる環境を整備し、チーム全体の生産性を維持・向上させることが求められました。 **3. 顧客との信頼関係構築** 顧客折衝を通じて、ユーザーニーズを正確に把握し、機能の優先順位を適切に設定することで、期待値をコントロールしながら信頼関係を築く必要がありました。

### 1. 基本的な考え方 学習塾生向けサービスの開発チームをマネジメントする際、以下の点を重視して考えました。 #### 1. 目標と目的の明確化 サービスが対象とするユーザーやニーズを詳細に把握し、それに基づいた機能の優先順位を顧客と認識合わせ、設定しました。単に顧客の要望を聞くだけでなく、「このサービスは誰のどんな課題を解決するのか」を常に意識しながら開発を進めました。 #### 2. タスクの詳細化 各タスクのチケットに、背景、目的、期待するアウトプットを詳細に記載しました。これにより、メンバーがタスクの重要性や期待される成果を理解しやすくすることを目指しました。 特に、ChatGPTのGPTsを自作活用して、チケットの内容を充実させ、曖昧な部分を減らす工夫をしました。タスクの背景や目的を言語化する際、GPTsを使って情報を整理し、メンバーが理解しやすい形式に落とし込みました。 #### 3. 適切なタスク割り振り メンバーが進めやすいタスクを振り分けることを意識しました。具体的には、先に私自身が参考となる実装（プルリクエスト）を行い、その実装を基にメンバーにタスクを進めてもらうようにしました。 この方法により、メンバーは「どう実装すればいいか」の具体例を見ながら作業できるため、迷わずに進められます。また、私自身も「育てよう」と過度に期待せず、現実的にチームの生産性を維持できる方法を選択しました。 --- ### 2. 直面した問題と工夫 #### 問題1：生産性の低下 **問題点** チームメンバーがタスクの進行方法に戸惑い、生産性が低下することがありました。ジュニアエンジニアにとって、「何をどう実装すればいいか」が明確でないと、調査や試行錯誤に時間がかかり、結果的にタスクが進まない状況が発生していました。 また、私が「育てよう」と意識しすぎて、メンバーに自力で解決させようとすると、かえって時間がかかり、チーム全体の生産性が低下することもありました。 **対策：参考実装を先に作成し、それを基に進めてもらう** この問題に対し、私は「育てよう」と過度に期待せず、その人自身が進めやすいタスクを割り振る方針に転換しました。 具体的には、以下のような流れで進めました。 1. **私が先に参考となる実装（プルリクエスト）を作成** 似たような機能や、同じアーキテクチャを使う箇所を私が先に実装し、プルリクエストを作成しました。 2. **参考PRをチケットに添付** タスクチケットに「この実装を参考にしてください」と参考PRのリンクを添付しました。 3. **メンバーは参考PRを見ながら実装** メンバーは参考PRのコードを見ながら、同じパターンで実装を進めることができました。これにより、「どう書けばいいか分からない」という迷いが大幅に減少しました。 **この方法のメリット** - メンバーが迷わずに作業を進めることができる - 実装のパターンやコーディングスタイルが統一される - 私自身の作業時間も確保できる（教育に時間を取られすぎない） - コードレビュー時も、参考PRとの差分を見ることで、意図しない実装を早期に発見できる **成果** この方法により、メンバーの作業効率が向上し、チーム全体の生産性を維持できました。また、私自身も開発作業に集中する時間を確保でき、チームリーダーとしての業務と開発業務のバランスを取ることができました。 --- #### 問題2：データ投入運用の効率化 **問題点** 開発中、テストデータや初期データの投入をエンジニア自身が行う必要がありました。しかし、データの内容は顧客側（塾の運営チーム）が最も詳しく、彼らがデータを作成した方が正確かつ効率的です。 エンジニアがデータ投入を行うと、以下のような問題がありました。 - データの内容を顧客に確認する手間が発生 - エンジニアの開発時間が削られる - データ投入のミスが発生しやすい 運用上、データ作成するチーム（顧客側）が直接データ投入できる方が、開発効率的にも望ましいという課題がありました。 **対策：データ投入画面の作成** この問題に対し、顧客側が自分たちでデータを投入できる画面を作成しました。 **実装内容** - 管理画面にデータ投入機能を追加 - CSVアップロード機能やフォーム入力機能を実装 - バリデーションを設定し、不正なデータが登録されないようにチェック - エラーメッセージを分かりやすく表示 **この方法のメリット** - 顧客側が自分たちのタイミングでデータを投入できる - エンジニアはデータ投入作業から解放され、開発に集中できる - データの正確性が向上（データに詳しい人が直接入力するため） - 運用フェーズでも継続的に使える機能 **成果** データ投入画面の作成により、手動作業を最小限に抑えることができ、開発効率が向上しました。また、顧客側も「自分たちでデータを管理できる」ことに満足し、サービスの価値が向上しました。 --- ### 3. 使用技術と開発環境 **使用技術** - AWS - Ruby（Ruby on Rails） - Vue.js（Nuxt.js） - GraphQL（Apollo） - GitHub - TypeScript **チームリーダーとしての役割** - プロジェクト管理：タスクの優先順位付け、進捗管理、スケジュール調整 - 顧客折衝：要件のヒアリング、仕様の確認、納期調整 - 技術的な意思決定：アーキテクチャ設計、技術選定、実装方針の決定 - メンバー育成：参考実装の作成、タスクの詳細化、コードレビュー --- ### 4. 全体を通じて学んだこと #### 学び1：「育てる」と「生産性」のバランス 当初は「メンバーを育てよう」という意識が強く、メンバーに自力で解決させようとしていました。しかし、それがかえってチーム全体の生産性を低下させることに気づきました。 「育てる」ことも重要ですが、チームとして成果を出すことも同様に重要です。参考実装を先に作成し、それを基に進めてもらうことで、両立できることを学びました。 #### 学び2：タスクの詳細化の重要性 タスクチケットに背景、目的、期待するアウトプットを詳細に記載することで、メンバーの理解度が大きく向上しました。また、ChatGPTのGPTsを活用することで、チケット作成の効率も上がりました。 #### 学び3：運用を考えた開発 データ投入画面の作成を通じて、「開発フェーズだけでなく、運用フェーズも考えた設計」の重要性を学びました。エンジニアの手動作業を減らし、顧客側が自律的に運用できる仕組みを作ることで、長期的な開発効率が向上しました。 --- ### 5. 今後に向けて 開発チームリーダーの経験を通じて、「技術力」と「マネジメント力」の両方が重要であることを学びました。特に、小規模なチームでは、リーダー自身も開発者として手を動かしながら、チーム全体の生産性を維持する必要があります。 今後は、フルスタック開発力を磨きながら、テックリードやエンジニアリングマネージャーとして、技術とプロダクトの両面から価値を創出していきたいと考えています。明確な意思決定構造と権限委譲がある環境で、より大きなチームをリードし、開発組織の成長に貢献したいと考えています。

執行役員として、開発組織全体の生産性とエンゲージメント向上をマネジメントしていました。経営戦略立案、組織運営、人材育成を統括し、中長期ビジョン策定や新規事業の企画・推進を担当しました。具体的には、ピアボーナス制度の導入、オープン社内報の継続発信、キャリア支援プログラムの開発など、組織風土改善と経営透明性向上に取り組みました。また、開発業務と並行してチーム管理も行いました。

短期的な業績だけでなく、中長期的に企業が成長し続けられる組織基盤を構築し、技術とマネジメント、ブランディングを横断的に担い、企業成長を牽引することが私のミッションでした。 具体的には以下3点です。 **1. 組織文化の醸成** リモート環境下でも、会社のコアバリューが浸透し、メンバー同士が互いの貢献を認め合い、感謝を伝え合える文化を作る必要がありました。 **2. 経営透明性の向上** 経営陣の意思決定の思考や考え方をメンバーに伝え、会社の方向性を理解した上で自律的に判断できる環境を整備することが求められました。 **3. キャリア成長の支援** 各メンバーのキャリアビジョンを明確にし、それに応じた成長機会を提供する仕組みを体系化・スケールさせることが必要でした。

### 1. 基本的な考え方 執行役員として組織マネジメントに取り組む上で、「良いプロダクトは良い組織から生まれる」という信念を持っていました。他案件メンバーとの関わりが薄く、リモート下での文化醸成が出来ていない現実を経験していたため、以下の3つのアプローチを重視しました。 1. **文化の可視化と仕組み化**：感謝や貢献を可視化し、組織文化を根付かせる仕組みを作る 2. **透明性の高いコミュニケーション**：経営情報をオープンに共有し、意思決定の背景を伝える 3. **スケーラブルな仕組みづくり**：属人化を防ぎ、再現性のあるプログラムを設計する --- ### 2. 具体的な施策と直面した問題、工夫したこと #### 施策1：ピアボーナス制度「よかトークン」の導入 **背景と課題** リモートワーク環境下で、他案件メンバーとの関わりが薄く、日々の貢献が見過ごされがちになっていました。技術的なサポート、チームを盛り上げる発言、業務プロセスの改善提案など、数字や目標達成だけでは測れない素晴らしい貢献が数多く生まれているのに、それが適切に評価されていませんでした。 特に以下のような課題がありました。 - 仲間への感謝を気軽に、オープンに伝え合う文化が不足 - 会社のコアバリューを体現する行動を、きちんと称賛・評価できていない - プロジェクトに関わらず、一人ひとりの貢献を公平に見える化できていない **コアバリューとの連携** この制度は、エミシスが大切にする4つのコアバリューに沿った行動に対してトークンが贈られる仕組みです。 1. **ロジカルに生意気**：論理的思考に基づいた建設的な意見や提案を大切にする 2. **愚痴ニケーション**：単なる不満で終わらず、問題点を建設的に共有し、解決策を生み出す 3. **おせっかい**：自分の担当範囲を超えて、積極的に他のメンバーをサポート 4. **スピード重視**：完璧を求めず、まずは3割で打席に立つ **仕組みの特徴：3つの仕掛け** 単なる称賛で終わらせないため、以下の3つの仕掛けを組み込みました。 **1. 双方向の価値創出** トークンは受け取る側だけでなく、送る側にもインセンティブが還元されます。これにより、「誰かの良い行動を見つけて称賛する」こと自体がポジティブな文化として促進されます。 **2. 透明性と公平性** メンバー全員が評価に参加することで、上司や他部署からは見えにくい日々の貢献も、一番近くで見ている仲間同士が評価し合えます。フラットな組織だからこそ実現できる、多角的で公平な評価の仕組みです。 **3. 文化的価値と経済的価値の融合** トークンには金銭的な価値も付与されており、ただの「ありがとう」以上の重みを持ちます。感謝の気持ちが実質的な還元に繋がることで、より真剣な評価を促し、バリューの実践が正当に報われるカルチャーを創ります。 **運用方法** Slack上で感謝のメッセージと共にトークンを送り合う、シンプルな仕組みとしました。リモート環境でも気軽に感謝を伝え合える設計にしました。 **直面した問題：試験運用段階での課題** この制度はまだ試験運用の段階であり、完成形ではありませんでした。メンバーの声を聞き、改善を重ねながら進める必要がありました。 **工夫したこと：進化を前提とした設計** 最初から完璧な制度を作ろうとせず、「メンバーと一緒にエミシスだけの文化を育てていく」という姿勢で臨みました。フィードバックを継続的に収集し、制度を進化させていくプロセス自体を大切にしました。 **成果と目指す未来** この制度を通じて目指しているのは、単に感謝を可視化するだけでなく、以下のような組織の未来です。 - **個人の成長**：日々の貢献が認められることで、一人ひとりのモチベーションが高まり、バリューを意識した自律的な成長に繋がる - **チームの強化**：感謝と称賛が飛び交う環境が心理的安全性を高め、支え合う文化を育む - **組織の進化**：バリューを軸とした持続的な成長を可能にする --- #### 施策2：オープン社内報の継続的発信 **背景と課題** リモートワーク環境下で、以下の2つの課題がありました。 1. **経営陣の意思決定の思考や考え方が伝わりづらい** リモート環境では、オフィスでの何気ない会話や雑談を通じた情報共有ができません。そのため、経営陣が「なぜその判断をしたのか」「どんな背景があるのか」といった意思決定のプロセスが見えにくくなっていました。 2. **社外への採用面でのブランディングが薄い** 会社の取り組みや文化を外部に発信する機会が少なく、採用候補者に対して「エミシスがどんな会社なのか」を伝えきれていませんでした。 **アプローチ：2週に1本のペースで継続発信** 私自身が執筆・編集を担当し、2週に1本のペースでnoteにオープン社内報を発信しました。経営の透明性を高めるため、以下のような内容を発信しました。 - 新しい制度の導入背景と狙い（よかトークン制度、生産性向上補助金制度など） - 働き方の工夫（フルリモート環境下での対面交流、週報改善など） - 会社の意思決定の背景（宿泊費高騰への対応など） - 技術的な取り組み（AIを活用した社内イントラのリプレイスなど） - エンジニア文化（Slackでの絵文字活用など） **直面した問題1：ネタの枯渇** 2週に1本のペースで継続的に発信するには、常に新しいネタを見つける必要がありました。しかし、日常の中では「特別なこと」が毎回起こるわけではありません。 **工夫したこと：日常の中から価値を見出す** 「特別なこと」を探すのではなく、日常の中にある工夫や取り組みに目を向けるようにしました。例えば、「Slackで絵文字を1020個使っている」という一見些細な事実も、「エミシスのエンジニアがどうコミュニケーションを楽しんでいるか」を伝えるコンテンツになると気づきました。 **直面した問題2：伝え方の難しさ** 社内向けには理解されている内容でも、社外に向けて発信する際には文脈の説明が必要です。また、良くも悪くも「理想郷」に見えてしまうリスクもありました。 **工夫したこと：背景と意図を丁寧に説明** 制度や取り組みを紹介する際には、「なぜその制度を作ったのか」「どんな課題があったのか」という背景を丁寧に説明しました。理想を語るだけでなく、試行錯誤のプロセスも含めて伝えることで、リアリティを持たせました。 **直面した問題3：継続することの難しさ** 執筆は時間がかかり、他の業務との両立が難しい場面もありました。しかし、継続しなければ効果が薄れてしまいます。 **工夫したこと：2週に1本というペース設定** 週1本では負担が大きすぎるため、2週に1本というペースに設定しました。これにより、無理なく継続できる体制を作りました。 --- #### 施策3：キャリア支援プログラムの開発 **背景と課題** メンバーのキャリア支援を行いたいという思いがありましたが、以下の課題がありました。 - キャリア支援が属人化しており、体系化されていない - マネージャーによって支援の質にばらつきがある - 全社員に対してスケールさせる仕組みがない **アプローチ：プログラム化と仕組み化** 以下のステップで取り組みました。 **1. テスト実施** まず、1人のメンバーと1on1を数回実施し、キャリア支援のプロセスを検証しました。どのような質問をすればキャリアビジョンが明確になるのか、どのような対話が効果的なのかを探りました。 **2. プログラム作成** テスト結果を基に、キャリア支援のプログラムを作成しました。質問項目やワークショップの設計を体系化しました。 **3. ChatGPT GPTsとしてアウトプット** プログラムをChatGPTのGPTsとして実装し、仕組み化しました。これにより、マネージャーが誰でも同じ質のキャリア支援を提供できるようにしました。 **4. 全社員とワークショップ実施** 全社員を対象にワークショップを実施し、各自のキャリアビジョンをアウトプットしてもらいました。 **5. 経営陣との面談に活用** ワークショップで作成したキャリアビジョンを基に、経営陣との面談を実施しました。 **直面した問題：「渡して終わり」では機能しない** 仕組み自体には好感触でしたが、**「ツールを渡して、はい終わり」では機能しない**ことが判明しました。 GPTsを使えば自動的にキャリアビジョンが明確になるわけではなく、対人的に話を引き出すことやキャリアプランに落とし込めた人は少数派でした。ツールだけでは不十分で、マネージャーの対話スキルが重要だと気づきました。 **工夫したこと：次の環境への学び** この失敗から、以下のような改善案を得ました。 - マネージャーレベルがキャリア思考のトレーニング・サポートできることを目指す - ツールはあくまで補助であり、対話の質が重要 - マネージャー向けのトレーニングプログラムが必要 **成果と学び** - 仕組み自体は好評だったが、運用には課題が残った - 「ツールを作れば解決する」わけではないことを学んだ - 次の環境では、マネージャーのトレーニングにも注力したい --- #### その他の施策（簡潔に） **社内ポータルの企画開発** AI標準開発の先行実験として、AIコーディングツール（Cursor、Devin）を活用し、コードレスで社内イントラをリプレイス。Next.js + Supabase構成で1ヶ月での開発を実現。また、社内wiki整備、週報データ化により業務を効率化しました。 **生産性向上補助金制度** 全員が決裁者として、透明性と自走力で生産性向上を実現する制度を導入しました。 **半期総会・年次総会の企画** 組織全体での情報共有と一体感醸成のため、半期総会・年次総会を企画・運営しました。 --- ### 3. 全体を通じて学んだこと #### 学び1：「仕組み」だけでは不十分、運用が鍵 よかトークン制度やキャリア支援プログラムを通じて、「仕組みを作れば解決する」わけではないことを学びました。仕組みはあくまでスタート地点であり、継続的な改善と運用が重要です。 特にキャリア支援プログラムでは、「ツールを渡してはい終わり」では機能せず、マネージャーの対話スキルや継続的なサポートが不可欠だと実感しました。 #### 学び2：継続することの価値 オープン社内報を2週に1本のペースで継続発信することで、組織内外への影響が積み重なっていきました。単発の施策ではなく、継続することで文化が根付いていくことを学びました。 #### 学び3：文化は可視化と仕組み化で根付く よかトークン制度のように、感謝や貢献を可視化し、それを評価・報酬に繋げる仕組みを作ることで、組織文化を意図的に根付かせることができると学びました。 --- ### 4. 今後に向けて 執行役員として組織マネジメントに注力する中で、他案件メンバーとの関わりが薄く、リモート下での文化醸成が難しい現実を経験しました。今後は、フルスタック開発力を磨きながら、これまでの組織マネジメント経験を活かし、技術・プロダクト・組織の三位一体で成果を出せるテックリードを目指します。 明確な意思決定構造と権限委譲がある環境で、コードレビューやメンタリングを通じた技術力向上、1on1を通じたキャリア支援、技術ブログなどを活用した採用ブランディングなど、開発組織の成長に多角的に貢献したいと考えています。 特に、キャリア支援プログラムの失敗から学んだ「マネージャーのトレーニング」にも注力し、組織全体でメンバーの成長を支援できる体制を作りたいと考えています。