こんにちは！25卒エンジニアの夕田です！
「このプロジェクト、本当に終わるのかな？」
エンジニアであれば、誰もが一度はそんな不安に駆られたことがあるのではないでしょうか。
漠然としたゴール、曖昧な要件、先の見えない課題の山……。
まるで霧の中を手探りで進むように、開発の現場には常に「不確実性」がつきまといます。
私自身、学生時代に指揮者として団体を率いてきた経験があります。
音楽の世界も、エンジニアリングとよく似ています。
演奏会という「本番」に向けて、多くのメンバーがそれぞれのパートを練習し、最終的に一つの「作品」を創り上げます。
しかし、楽譜通りに音を出しても良い演奏はできません。
そんな時、指揮者に求められるのは、まさにこの「不確実性」をマネジメントし、チーム全体を最高のパフォーマンスへと導くことです。
私が指揮者として学んだ知見は、形は違えど、エンジニアのチーム開発に応用ができると気付きました。
本記事では、学生時代にオーケストラの指揮者として培った経験と、新卒エンジニアとして現場で得られた学びを融合させ、両者に共通する不確実性やチームビルディングの重要性について共有させていただきます。
経歴
広島市立大学にてマンドリン・ギター部に所属し、大学ではマンドリン奏者・指揮者として活動。大学院では指揮者に専念。三大学合同定期演奏会にて50名規模の指揮を担当（第25回三大学合同定期演奏会）。その後、中国学生マンドリン連盟が主催する、中国ブロック定期演奏会の全大学参加大合同ステージにて100名規模の指揮を担当。（第62回中国ブロック定期演奏会 大合同指揮、第64回中国ブロック定期演奏会 大合同指揮）
不確実性の高い「音楽」をアジャイルで合奏する
アジャイル開発という概念に触れた際、私は自身の指揮者としての経験との間に共通点があると気が付きました。
それは私が指揮をする合奏練習で、曲の難易度に関わらず行っていた「ルーティーン」です。
私の行う合奏練習は、まさしくアジャイル開発でした。
具体的には、以下の3つのステップを繰り返していました。
成果物の全体像把握（スプリントレビュー）
練習の冒頭に、楽曲全体を一度通しで演奏します。
これは、現在の成果物（合奏）を「ユーザー」（指揮者である私）に提示し、全体的な品質と方向性を評価するプロセスに相当します。
不確実性の高い要素の優先的解消（バックログの管理、スプリントの実行）
全体像を把握した後、詳細な修正作業へと移行します。
この段階で最も重視したのは、「特にまずい！！」と思った箇所から優先的にフィードバックを行い、改善に着手することです。
例えば、極端なパート間における拍のずれや、オーケストレーションのバランス調整などがあげられます。
このアプローチは、まさにエンジニアリングにおける「不確実性の高い要素から優先的に処理する」ことの実践でした。
継続的な改善サイクル（イテレーション）
合奏を通じて得られた具体的なフィードバックを基に、次回の練習（スプリント）でチームが取り組むべき改善点を明確に提示します。
各メンバーはそれを受けて個別の練習に励み、次回の合奏でその成果をアウトプットします。
この継続的なサイクルを繰り返すことで、楽曲の不確実性を段階的に低減させ、最終的に聴衆がストレスフリーに聴くことができる、最高の演奏という「完成されたプロダクト」へと昇華させることが可能となるのです。
いかに複雑で不確実性の高い開発課題に直面したとしても、「フィードバックを積極的に取り入れ、不確実性の高い要素から着実に解消していく」アプローチは極めて有効です。
完成度を追求する前に、まずは全体像を把握し、課題の根源を特定します。
この原則は、指揮者の曲作りとソフトウェア開発において普遍的に適用されるものであると考えます。
マエストロがするチームビルディング
チームビルディングにおいて、私が最も重要視しているのは、単なる情報伝達を超えた「関係性構築」です。
「指揮棒から音は出ません」
私がどれほど熱意を込めた指揮をしても、実際に音を出すのは目の前にいる奏者たちです。
あくまで指揮者は「お願いする」立場です。
私の中にある最高の音楽を作るためには、奏者たちとの間に言葉では表現しきれないほどの信頼関係が不可欠でした。
彼らが私の意図を汲み取り、自らの音で表現してくれるからこそ、一つの音楽が生まれます。
これは、ソフトウェア開発におけるマネジメントにおいてもそのまま当てはまると考えます。
マネージャーがどんなに素晴らしいビジョンや設計を描いても、実際にコードを書き、プロダクトを形にするのはエンジニア一人ひとりです。
まるで指揮棒から音が出ないように、マネージャーが直接コードを書くわけではありません。
どれだけ言葉を尽くしても、メンバーとの間に深い信頼関係がなければ、最高のパフォーマンスは引き出せないと思います。
だからこそ、私はメンバー間の関係性構築、特に心理的安全性の確保に積極的に時間を投資しました。
そこで行ったのが「マエストロがするチームビルディング」です。
ここからは具体的な取り組みについて紹介します。
1. 開発研修での目標設定：未来像から見出すチームの可能性
「開発研修が終わったときにどんなエンジニアになっていたいか」という目標を共有しました。
あるメンバーは技術的なリーダーシップと分かりやすい説明を重視し、また別のメンバーはチームへの貢献に重きを置いていると共有しました。そして、私自身はマネジメントと組織開発への関心を示しました。
これらの目標共有は、単に個人の志向を知るだけでなく、チームとしてどのような強みや役割を持つメンバーがいるのかを理解する貴重な機会となりました。
それぞれの目標が明確になることで、不確実な開発課題に対し、誰がどのような視点から貢献できるのかという見通しが立ちやすくなりました。
2. 5年後になっていたいエンジニア像：個人の夢がチームを動かす
「5年後になっていたいエンジニア像」を共有する場では、さらに深い、メンバーの価値観や人生観に触れることができました。
大胆な起業の野望を披露するメンバー、音楽や趣味に対する強い情熱を共有するメンバー、T字型人材を追求するメンバー、その未来像は多岐にわたりました。
ここで行った共有は、メンバーがお互いの多様な価値観を理解し、より深いレベルで人間関係を構築する上で非常に有益でした。
個人の夢や情熱を知ることで、互いへのリスペクトが生まれ、それがチーム内での協調性を自然と高めていくことにつながったと感じています。
3. 「ito」で深まる信頼関係：遊び心から生まれるチームビルディング
1～100までの数字が書かれたカードを使い
お互いの数字を言葉で表現し合う協力型パーティゲーム
出典：ArclightGames ito https://arclightgames.jp/product/ito/ (2025/7/10アクセス)
「ito」では、お互いの価値観や感覚を言葉にすることで、それぞれの個性を見ることができました。
ちなみに1時間プレイしましたが、1度もクリアできませんでした。。笑
これは情報が不足している中で、お互いの意図を深く汲み取ろうとしなかったり、あるいは誤解したまま判断してしまったことが原因です。
しかし、この経験を通じて、情報共有の重要性はもちろん、普段の何気ないコミュニケーションがいかに重要かをチーム全員が肌で感じることができました。
加えて、ゲームを通じてメンバーの人間性が垣間見え、それが後の開発における心理的安全性の向上にも繋がったと感じています。
4. 今持っている技術力：強みの可視化で不確実性を減らす
最後に、「学生時代に学んだ今持っている技術力」を共有する場を設けました。各自がこれまで培ってきたスキルや経験を武勇伝形式で発表し、質疑応答を行いました。
Web開発と機械学習をバランス良く習得しているメンバーや、AI領域の専門性を持つメンバー、さらにはアマチュア無線といったユニークなスキルも共有されました。
この技術力共有会は、チーム内でのスキルの「見える化」を促進し、誰がどのような分野に強みを持っているのか、またどのような興味を持っているのかを明確にしました。
これにより、今後の開発において、タスクの割り振りや困った時の相談先が自然と見えてくるようになりました。
それぞれの専門性を知ることで、高め合える関係性が構築され、結果的にプロジェクトの不確実性を減らし、効率的な進行につなげることができたと感じています。
おわりに
本記事では、指揮者としての経験と新卒エンジニアとしての学びから、開発現場に常に存在する「不確実性」、そしてそれを乗り越えるための「チームビルディング」についてお話ししました。
最高のパフォーマンスを出すには、日々のコミュニケーションを通じて心理的安全性を確保することが重要です。
心理的安全性を担保することで、メンバーが安心して意見を交わし、失敗を恐れずにチャレンジできるようになります。
この強固な信頼関係こそが、不確実性を乗り越え、最高の成果を生み出すチームの強力な武器となるでしょう。
最後までご覧いただきありがとうございました！
25年度新卒研修に関する記事はこちらをご覧ください。
