ロボット開発会社の社員の属人化の解決方法

ブランディング戦略立案の仕事は、企業ごとに課題や方向性が異なるため、高度な提案力や企画力が求められます。

ロボット開発会社の属人化を減らし、営業と開発の連携を安定させる組織づくり

ロボットを活用した受託開発では、お客様の現場環境や目的によって必要な機器、制御方法、ソフトウェア、設置条件などが大きく異なります。

そのため、一社一社に合わせた開発が強みになる一方で、

「案件ごとに一から設計している」
「見積り段階で開発工数を読みづらい」
「営業担当者と開発担当者の認識がずれる」
「特定の技術者に判断が集中している」
「案件はあるのに開発できる人が足りない」

といった問題が起こりやすくなります。

今回ご紹介するのは、東京都でロボットのハードウェアとソフトウェアを組み合わせた受託開発・現場導入を行う従業員22名の企業で、営業・設計・開発・導入業務の属人化を見直した事例です。

大切にしたのは、すべての案件を同じ仕様にすることではありません。

「お客様ごとに変える必要がある部分」と「過去の技術や工程を活用できる部分」を分け、社員の経験を会社の技術・ノウハウとして蓄積できる仕組みづくりを進めました。

お客様が抱えていた課題

今回のお客様は、東京都でロボットの受託開発と現場導入を行う従業員22名の企業です。

案件ごとに求められる仕様が大きく異なるため、設計・開発工数が増えやすく、人的な対応力が事業拡大の制約になっていました。

また、営業から開発への情報共有や提案方法にも担当者ごとの差があり、案件の採算性を安定させにくい状態でした。

【お客様の課題】

案件ごとに仕様が大きく異なり、
設計・開発工数が増えやすい。

過去に似た開発を行っていても、
技術やノウハウを次の案件へ十分に活用できていない。

特定の技術者へ設計や判断が集中し、
案件数を増やしにくい。

営業段階で確認する内容が担当者によって異なり、
開発開始後に追加確認や仕様変更が発生しやすい。

営業担当者と開発担当者の情報共有が、
個人間のやり取りに依存している。

相談や案件があっても開発できる人員が足りず、
受注機会を逃す可能性がある。

つまり、

「お客様の現場に合わせた柔軟な開発を続けたい」

という考えと、

「案件が増えても社員の負担だけが増えない会社にしたい」

という二つの課題を両立する必要がありました。

なぜロボットの受託開発では属人化が起こりやすいのか

ロボットの受託開発では、お客様によって現場条件や実現したいことが異なります。

例えば、

対象となる作業
設置できるスペース
処理する物の形状
必要な速度や精度
周辺設備との連携
安全面の条件
既存システムとの接続

などによって設計内容が変わります。

そのため、個別対応そのものをなくすことは現実的ではありません。

個別設計と属人化は分けて考える

重要なのは、

「案件ごとに設計内容を変えること」

と、

「営業・設計・開発の進め方まで担当者任せになること」

を分けることです。

例えば、

営業時に何を確認するか
どの情報を開発へ渡すか
見積り前に何を検討するか
設計前に何を確定するか
どの段階で顧客確認を行うか
現場導入前に何を確認するか

といった部分には共通化できるものがあります。

一方で、

どの機器を組み合わせるか
どのような制御を行うか
顧客固有の現場条件へどう対応するか

などには技術者の専門的な判断が必要です。

標準化する目的は技術者の判断をなくすことではありません。

「毎回考えなくてもよい仕事」を仕組みにし、技術者が本当に専門性を必要とする設計や開発へ集中できる環境をつくることです。

ロボット・受託開発会社で起こりやすい10の属人化課題

次のような状態がないか確認してみてください。

1．似た案件でも毎回一から設計している
2．見積り時の想定工数と実際の開発工数に差がある
3．特定の技術者しか設計・判断できない業務が多い
4．営業担当者によって顧客への確認内容が違う
5．営業から開発への引き継ぎ方法が統一されていない
6．過去案件の設計や技術を次の案件へ活用できていない
7．仕様変更や手戻りが発生した理由が共有されていない
8．新人技術者の育成に時間がかかる
9．案件が増えるほどベテラン技術者の負担が増える
10．相談や引き合いがあっても開発工数不足で受注しにくい

複数当てはまる場合、

「技術者を増やす」

ことだけでなく、

「すでに会社にある技術や経験を、次の案件でどれだけ再利用できているか」

を確認することが大切です。

属人化を減らすために行った10の取り組み

今回の支援では、個別開発の強みを残しながら、営業から現場導入までの共通化を進めました。

1．営業から現場導入までを見える化する

問い合わせ、現場確認、提案、見積り、設計、開発、導入までの流れを整理します。

2．営業時の確認項目を整理する

顧客が実現したいこと、現場環境、対象作業、必要性能、納期など、開発へ影響する情報を整理します。

3．営業から開発への引き継ぎを標準化する

営業担当者が得た情報を、開発担当者へ漏れなく伝えるための基本項目を決めます。

4．過去案件を分類する

用途、機器、機能、現場条件などから過去案件を整理し、似た案件を探しやすくします。

5．再利用できる技術や工程を整理する

毎回一から作る必要がない設計、機能、処理、確認項目などを会社の共通知識として蓄積します。

6．提案の基本形を整える

よくある案件について、提案内容、確認事項、作業範囲などの基本形を整理します。

7．判断理由まで記録する

「何を設計したか」だけでなく、

「なぜその方法を選んだのか」
「どの条件なら別の方法にするのか」

まで残します。

8．成功・失敗事例を共有する

予定通り進んだ案件だけでなく、工数超過、仕様変更、現場での問題なども次の案件へ活かします。

9．別の社員が再現できるか確認する

資料や手順を作って終わるのではなく、別の社員がそれを利用して案件を進められるか確認します。

10．標準化・ノウハウ共有を人事評価へ反映する

個人の売上や開発件数だけではなく、技術共有、業務改善、後輩育成などを社員目標とし、達成度を賞与へ反映する仕組みを整えました。

営業から開発・現場導入までの流れを標準化する

受託開発の採算性を改善するには、営業と開発を別々に考えないことが重要です。

例えば、

問い合わせ・相談
↓
顧客の要望確認
↓
現場・対象業務の確認
↓
必要な機能・性能の確認
↓
過去の類似案件の確認
↓
実現方法の検討
↓
開発工数の検討
↓
提案
↓
見積り
↓
受注
↓
営業から開発への引き継ぎ
↓
仕様確認
↓
設計
↓
ハードウェア・ソフトウェア開発
↓
社内確認
↓
顧客確認
↓
調整
↓
現場導入
↓
動作確認
↓
運用開始
↓
導入後の確認・改善

という流れです。

全体を見える化すると、

営業段階で情報が不足している
見積り時に技術的な確認が足りない
開発開始後に仕様が変わっている
過去に作ったものを再利用できていない
現場導入時の調整に時間がかかっている

など、採算性を下げている場所を確認しやすくなります。

営業と開発の間にある「情報のずれ」を減らす

営業担当者は「お客様が何を実現したいのか」を聞きます。

開発担当者は「それを実現するために、どのような条件が必要なのか」を考えます。

この二つが十分につながっていないと、

受注後に必要な機能が増える
想定していなかった現場条件が分かる
開発工数が増える
納期が延びる

といった問題につながります。

そのため営業段階から、

何を確認すれば見積りできるのか
何を確認しなければ受注してはいけないのか
どの案件なら技術者の事前確認が必要なのか

といった判断基準を共有しておくことが大切です。

過去の開発を再利用できる形にして案件の採算性を高める

個別開発だからといって、すべてを毎回一から作る必要があるとは限りません。

過去案件を振り返ると、

共通して使用する機能
似た制御方法
繰り返し使う処理
共通する設計
確認項目
導入手順

などが見つかることがあります。

完成品ではなく「部品」として整理する

一つの案件をそのまま次の案件へ当てはめるのではなく、再利用できる部分を分けて整理します。

例えば、

基本的な制御
データ処理
外部機器との接続
安全確認
動作確認
顧客説明
導入時のチェック項目

などです。

こうした共通部分を組み合わせられるようにしておくことで、顧客固有の部分へ技術者の時間を使いやすくなります。

「何を作ったか」だけでなく「なぜそうしたか」を残す

過去案件について、

顧客の目的
現場条件
要求された性能
採用した方法
検討した別の方法
採用した理由
開発にかかった工数
問題が発生した工程
現場導入時に分かったこと
次回改善したいこと

まで整理します。

これによって、過去の開発が単なる実績から、

「次の技術者が判断するときに使える会社の知識」

へ変わっていきます。

会社の課題を社員目標と人事評価につなげる

標準化の資料を作成しても、日々の仕事で使われなければ属人化は戻ってしまいます。

そこで、

会社の経営課題
↓
社員の具体的な目標
↓
日々の行動
↓
達成度の確認
↓
人事評価
↓
賞与への反映

という流れを整えました。

例えば、

「過去の開発を再利用できていない」

という課題なら、

「担当した案件から再利用できる設計・機能・手順を毎月1件整理する」

という目標にできます。

「営業から開発への引き継ぎに漏れがある」

という課題なら、

「開発開始後の追加確認事項を記録し、引き継ぎ項目を改善する」

という目標にできます。

「ベテラン技術者へ判断が集中している」

という課題なら、

「判断が必要だった案件について、判断条件と理由を月3件共有する」

という目標にできます。

「新人技術者の育成に時間がかかる」

という課題なら、

「後輩社員が通常案件の一工程を一人で担当できる状態まで育成する」

という目標にできます。

「自分ができる」から「会社ができる」へ

評価では、

売上
納期
担当案件
品質

などの個人成果に加えて、

技術の共有
再利用できる仕組みづくり
業務改善
後輩育成
営業と開発の連携改善

なども確認します。

優秀な技術者の価値を小さくするのではありません。

その社員が持つ知識や経験を会社全体へ広げたことも、大きな貢献として評価する考え方です。

より具体的な解決方法についての無料セミナーを開催しています

取り組みによって生まれた変化｜売上5,000万円・利益2,500万円増加につながった事例とご相談

今回の東京都・従業員22名のロボット受託開発会社では、

営業から現場導入までの見える化
営業時の確認項目の整理
営業から開発への引き継ぎの標準化
過去案件の分類
再利用できる技術・工程の整理
提案の基本形づくり
判断理由の共有
成功・失敗事例の蓄積
社員目標の設定
人事評価と賞与への連動

などに取り組みました。

その結果、

・社員の属人化解消に対する意識が高まった
・営業と開発の情報を共有しやすくなった
・過去の技術や経験を次の案件へ活かしやすくなった
・開発・導入業務の再現性向上につながった
・会社が抱えていた課題の改善につながった

という変化が生まれました。

結果として、

売上は5,000万円増加、
利益は2,500万円増加

につながりました。

ただし、同じ取り組みを行えば、すべての企業で同じ売上・利益の増加が実現するという意味ではありません。

成果は、案件数、受注単価、開発内容、社員数、技術力、市場環境などによって異なります。

今回の事例で大切なのは、

「個別開発をなくす」のではなく、

「個別開発の中にある共通部分を見つけ、会社の技術として次の案件へ活かす」

という考え方です。

これはロボット開発会社だけではありません。

システム開発
機械設計
製造業
設備会社
IT支援
Web制作
広告・マーケティング
コンサルティング
営業支援
建設業

など、営業・設計・制作・技術のノウハウが特定社員に集中している企業にも応用できます。

サービスは全国のあらゆる業種の企業に対応できます。

「案件はあるのに技術者が足りない」
「見積りより開発工数が増えてしまう」
「営業と開発の連携がうまくいかない」
「ベテラン技術者に仕事が集中している」
「過去に似た案件があるのに毎回一から考えている」

このようなお悩みがある場合には、

「人を増やせば解決するか」

だけではなく、

「これまでの案件で得た技術や経験を、次の案件でどれだけ再利用できているか」

という視点から確認してみる方法があります。

ご相談はこちらからお送りいただけます。

よくあるご質問 FAQ

ブランディング戦略立案の仕事は、企業ごとに課題や方向性が異なるため、高度な提案力や企画力が求められます。