株式会社オーディオテクニカは、1962年にレコードプレーヤー用カートリッジから始まり、現在はヘッドホンやイヤホン、マイクロフォンなどのオーディオ機器で世界的に知られるメーカーです。特にカラオケ用マイクロフォンでは国内90%近くのシェアを誇り、北米では業務用・プロ用マイクロフォンの分野でも高い評価を得ています。
そんな同社で、ワイヤレスマイクの回路設計を20年近く手がけてきた内藤さんが、基幹システムの導入プロジェクトをきっかけにBalusと出会い、設計業務にも展開していった経緯について伺いました。
複雑で理解困難なシステムをどのようにして可視化し、チーム全体の情報共有を改善していったのか、その実践的な取り組みをご紹介します。
内藤さん
株式会社オーディオテクニカは、主にオーディオ機器の製造販売を行っております。最近は、国内ではヘッドホンやイヤホン関係が主力です。当初はレコードプレーヤー用カートリッジから創業した会社です。実はレコードプレーヤーもカートリッジもいまだに作り続けています。
マイクロフォンについては、日本国内でも様々なところで使われていますが、主に海外、特に北米で業務用・プロ用のマイクロフォンが多く出荷されています。カラオケ用マイクロフォンに関しては、国内の90%近くのシェアを当社が持っております。
変わったところでは、「オーディオテクニカ」という社名ではありますが、特機部という事業部ではシャリを握る寿司ロボットやおにぎりを握るロボットなども手掛けています。
私自身は、入社以来ワイヤレスマイクの回路設計を担当してきました。昨年度までは設計部署のマネージャーとして、今年4月からは新しく設立された別の部署で、ワイヤレスマイク以外のカテゴリー製品も含めた実装設計を担当する部門のマネージャーをしています。
今の部署は、私がもともと専門としていた回路設計だけでなく、メカ設計／基板設計／基板実装なども見なければいけないので、普段からYouTubeで色々調べたり、実際のものづくりの現場に足をはこんで自分の目で見たりしながら色々と勉強させてもらっています。
内藤さん
何かツールを導入しなければならないという課題意識があったわけではなく、たまたまQuadceptさん※との打ち合わせで使われているのを見て興味を持ったのがきっかけでした。
Quadceptさんとの打ち合わせは基本的にリモートで行っており、打ち合わせをしながら画面に議事録を書き込む様子が非常に分かりやすく、解釈の違いが生じないところが良いと感じました。
Balusを使う前は、WordやExcelなどで議事録をまとめていました。しかし、議事録を文章でまとめて後で確認してもらう方法は、やや非効率に感じていました。また、進行状況を可視化しながら議論するのが難しいなど、少し使いづらい部分もありました。
しかし、Balusでは1つのノードに要点が端的にまとめられるので、確認作業も効率的です。
今年度よりこれまで自分が携わっていないカテゴリーの製品設計も担当するため、知らない分野について聞きながらまとめる際、打ち合わせ相手と一緒に私がBalusの画面に書き込みながら確認を進めました。その際、「これはこうですね」「これはどうでしょうか」と言いながら進めることで、効率的に進行でき、確実にまとめることができたのが良かったです。
また、基幹システムの要求仕様をまとめるのも、最初はほぼ1人でいろいろまとめていましたが、だんだんプロジェクトのフェーズが先に進むにつれて、いろんな人に協力してもらわなければいけないという状況になりました。
そこで、今まで自分がBalusでいろいろ資料を作ってきたものをメンバーに共有して、それを参考にしながら、さらにそれを広げていってもらうという使い方をしました。設計業務の方にも活用したいと思い、うちの課のメンバーには全員使えるようにライセンスを導入しました。
内藤さん
正直なところ、当初は基幹システムの中身が全く分からなかったんです。どんな操作で何ができるのかも全くわからない状況でした。そこで、実はBalusを使って基幹システムを自分でモデリングしてみました。
モデリングでは色分けを活用しました。基幹システムでやることをオレンジ色、別のシステム（CAD、連携PC等）でやる作業を緑色、アウトプット（書類やファイル）を青色、実際のアクションを紫色、実際に使う人（社内のどのグループか）を黄色として整理しました。
これをベンダーさんに「このシステムはこういう風に動くという認識で合っていますか？」と確認しながら理解を深めていきました。
また、要求仕様を作る過程では、いろんな部署にヒアリングをして、現状やっている作業について教えてもらいました。今の作業の手順や流れ、その中で困っていることや「本当はこうしたい」という要望があるかを確認しました。
相手先に出す要求仕様も、最終的にはBalusでまとめました。基幹システムでやらなければいけないこと、やりたいことを大きく分けて、システムとして動いてほしい内容をBalusで作成しました。
それを相手先に渡す際は、画面共有しながら実際の業務手順に従ってBalusを見せながら説明し、「システムとしてこういうふうに動かしてください」という説明に使いました。
内藤さん
最初は、「自分たちの書式に落としてくれ」と言われてしまいましたが、嫌だったので断りました（笑）。最終的に、URLを共有していつでも先方が見れるようにしました。実際にシステム設計をやられている方も参考にしてくれているんじゃないかと思います。
定期的なベンダーさんとのミーティングで、Balusに書かれている内容について確認の質問が来るようになったので、必要に応じて細かい説明を入れたり、別の資料を作ってより詳しく説明したりしました。このようなプロセスを経て、お互いの理解も深まっていったと感じています。
また、基幹システムでの成功を受けて、設計業務にもBalusを展開しました。
設計業務では比較的大人数で1つのプロジェクトを進めていましたが、共有できているようで、きちっと共有できていないようなことがちらほら見えていました。そのため、もう少しみんなにわかりやすく、様々なことを情報共有できるようにしたいと思っていました。
そこで、Quadceptさんのやり方を参考に、定例ミーティングなどで、議事録自体をBalusを使って取るようにしたのですが、結構好評でした。
設計をした後の振り返りもBalusで整理して、次に行うべきステップを確認するなど、徐々に活用し始めました。
内藤さん
私は元々、議事録などの文章を長く書いてしまうタイプでした。Balusを使うようになって、小さなノードの中に文章をまとめる必要があるため、無意識に端的にまとめられるようになったと感じています。
今まではまわりくどく分かりづらい伝え方をしていたかもしれませんが、Balusを使うことで短く的確に相手に伝えられるようになりました。文字が小さくなるのが嫌なので、意地でも4行で収めようと心がけています。これが端的にまとめる練習になっているのかもしれません。
内藤さん
今期から試し始めているのが、メンバーの目標設定とレビューでの活用です。社内では、決められた人事評価システムがありますが、期初の目標設定と半期ごとのレビューで使用しています。
日頃の設計業務の中では、Balusを使って期初に設定した目標に対しての細かな進捗確認を定期的に行い、課題の洗い出しとより細かなタスク管理等を行っています。一緒にBalusのビューを共有し話し合いながら各メンバーの状況を確認し、より細かな指示を出すようにしています。設計業務では突然の仕様変更なども発生しますし、設計を進めて行く中で予期せぬ不具合等も起こり得ますので、都度状況を確認しながら対応しています。
私自身、メンバーの状況を把握しやすくなりますし、課題や問題点の明確になり各メンバーもやるべきことがはっきり分かるので業務も進めやすいのではないかと思っています。
今回ご紹介した事例で登場した構造化ツール「Balus」は、どなたでも気軽にお試しいただける無料トライアルをご用意しています。ご興味をお持ちの方は、ぜひ下記のリンクからサービス詳細をご覧ください。
