Webシステム会社の社員の属人化の解決方法

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

Webシステム会社の属人化を減らし、新規受注と利益を安定させる組織づくり

Webシステム会社では、営業、提案、要件整理、開発、納品、保守まで、多くの場面で社員の経験や専門性が必要になります。

そのため、

「新規案件の多くが社長や営業担当者の紹介から生まれている」
「営業が得意な社員しか新規顧客を獲得できない」
「案件ごとに仕様調整の方法が違う」
「担当したエンジニアしかシステムの詳しい内容が分からない」
「案件が増えているのに利益が思うように残らない」

といった課題が起こることがあります。

今回ご紹介するのは、神奈川県のWebシステム会社（従業員17名）で、営業と開発・保守の両方の属人化を見直した事例です。

ポイントは、社員の専門性をなくすことではありません。

個人の人脈や経験だけに頼っている仕事から、会社として共有・再現できる部分を見つけ、「個人の能力を会社の能力へ変える」ことです。

お客様が抱えていた課題

今回のお客様は、神奈川県でWebシステム事業を行う従業員17名の企業です。

営業では新規案件の獲得が個人の人脈や紹介に依存しやすく、継続的に新規顧客を獲得する営業の流れが十分に共有されていませんでした。

開発・保守では、案件ごとに仕様や顧客の要望が異なるため、仕様調整や運用ルールが担当者の経験に依存しやすい状態でした。

【お客様の課題】

新規受注が、
個人の人脈や紹介に依存している。

営業担当者によって、
新規顧客の獲得方法や提案方法が異なる。

案件ごとの仕様調整が、
担当者の経験や判断に頼っている。

開発で得られた知識や判断基準が、
次の案件へ十分に共有されていない。

保守・運用の進め方が担当者によって異なり、
特定社員へ問い合わせや判断が集中する。

案件数が増えるほど人的負荷も増え、
利益率が圧迫されやすい。

つまり、

「紹介以外からも安定して新規顧客を獲得できる営業の仕組み」

と、

「案件が増えても開発・保守の負担が増えすぎない業務の仕組み」

の両方を整える必要がありました。

なぜWebシステム会社では営業と開発が属人化しやすいのか

Webシステム会社の属人化には、大きく分けて二つあります。

一つは「営業の属人化」です。

もう一つは「開発・保守の属人化」です。

営業の属人化

創業時は、社長や営業担当者の人脈、既存顧客からの紹介などで案件を獲得できることがあります。

紹介は大切な営業経路ですが、

「なぜ案件を獲得できたのか」

が整理されていなければ、別の社員が同じように新規顧客を増やすことは難しくなります。

開発・保守の属人化

システム開発では、お客様ごとに必要な機能や業務内容が違います。

そのため、すべての案件を同じ仕様にすることはできません。

しかし、

何をヒアリングするのか
どのように要件を整理するのか
仕様変更をどう管理するのか
どの情報を記録するのか
納品時に何を確認するのか
保守担当へ何を引き継ぐのか

まで担当者任せになる必要はありません。

「顧客に合わせてシステムを変えること」と「仕事の進め方まで担当者任せにすること」を分けて考えることが重要です。

Webシステム会社で起こりやすい10の属人化課題

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

1．新規案件の多くが社長や特定社員の紹介から生まれている
2．紹介以外の営業方法が十分に確立されていない
3．商談や提案の進め方が営業担当者によって違う
4．顧客へのヒアリング項目が担当者ごとに異なる
5．要件整理や仕様調整の方法がエンジニアによって違う
6．過去案件の開発ノウハウを次の案件で十分に活用できていない
7．仕様変更の経緯や判断理由が担当者の中だけに残っている
8．保守・運用の問い合わせが特定社員へ集中している
9．担当者が休んだり退職したりすると案件の引き継ぎが難しい
10．案件が増えるほど社員の負担も増え、利益率が安定しない

複数当てはまる場合には、

「優秀な営業担当者やエンジニアを増やす」

だけでなく、

「現在の社員が持っている営業・開発ノウハウを、会社として再利用できる状態になっているか」

を確認してみる価値があります。

営業・開発・保守の属人化を減らす10の取り組み

今回の支援では、営業導線の再現性を高めると同時に、開発・保守の業務プロセスを整理しました。

1．新規顧客との接点を整理する

紹介、既存顧客、Webからの問い合わせなど、現在どこから案件が生まれているのかを見える化します。

2．受注につながった営業活動を振り返る

「紹介だったから受注できた」で終わらせず、顧客の課題、提案内容、受注理由を整理します。

3．初回ヒアリング項目を共通化する

顧客の事業、現在の業務、困っていること、必要な機能、予算、納期など、基本的な確認事項を整理します。

4．提案の基本的な流れを整える

顧客の課題から、どのように改善方法やシステムを提案するのか、基本構成を共有します。

5．要件整理の方法を標準化する

案件ごとに内容は違っても、確認する項目や記録方法は共通化できます。

6．仕様変更の経緯を残す

「何を変更したか」だけでなく、「なぜ変更したのか」まで記録します。

7．過去の開発ノウハウを再利用する

似た機能、過去の問題、解決方法などを次の案件で利用できる状態にします。

8．納品から保守への引き継ぎを整える

システムの仕様、注意点、顧客との取り決めなどを担当者以外でも確認できるようにします。

9．保守・運用の対応事例を蓄積する

問い合わせ内容と対応方法を記録し、同じ問題を毎回一から調べる状態を減らします。

10．標準化とノウハウ共有を人事評価につなげる

営業方法の共有、業務改善、開発ノウハウの共有、後輩育成などを社員目標に設定し、その達成度を賞与へ反映しました。

新規受注を紹介だけに頼らない営業の流れをつくる

紹介による営業が悪いわけではありません。

信頼関係から生まれる紹介は、企業にとって大切な営業経路です。

問題は、

「紹介がなければ新規案件が増えない」

状態になっていることです。

そこで、営業活動を一連の流れとして整理します。

見込み顧客との接点
↓
問い合わせ・相談
↓
初回ヒアリング
↓
現在の業務の確認
↓
経営・業務課題の整理
↓
システムで改善できる範囲の検討
↓
必要な機能の整理
↓
提案
↓
見積り
↓
受注

この流れを見える化すると、

見込み顧客との接点が不足している
問い合わせから商談につながっていない
商談はあるが提案につながらない
提案は多いが受注率が低い

など、営業のどこに課題があるのかを確認しやすくなります。

「誰から紹介されたか」だけでなく「なぜ選ばれたか」を残す

紹介案件についても、

顧客は何に困っていたのか
なぜ相談してくれたのか
何を評価してくれたのか
どの提案が受注につながったのか

を振り返ります。

そうすることで、紹介案件からも自社が選ばれる理由を学ぶことができます。

個人の人脈を否定するのではなく、そこから得られた営業ノウハウを会社の財産へ変えていく考え方です。

開発から保守までを標準化し、利益率を安定させる

Webシステム開発では、顧客ごとに仕様が違うため、開発そのものを完全に同じにすることはできません。

しかし、案件の進め方には共通化できる部分があります。

問い合わせ・相談
↓
ヒアリング
↓
現在業務の確認
↓
課題整理
↓
要件整理
↓
提案・見積り
↓
受注
↓
設計
↓
開発
↓
社内確認
↓
顧客確認
↓
修正・調整
↓
納品
↓
利用開始
↓
保守・運用
↓
問い合わせ対応
↓
改善・追加開発

この流れの中で、

「毎回一から考えなくてもよい仕事」

を探します。

例えば、

ヒアリングシート
要件整理表
見積り時の確認項目
開発開始時のチェック項目
仕様変更の記録
テスト項目
納品時の確認表
保守への引き継ぎ資料
問い合わせ対応履歴

などです。

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

システム開発のノウハウ共有では、完成したシステムだけを残しても十分ではありません。

顧客はどのような業務をしていたか
どこに問題があったか
どのような選択肢を検討したか
なぜその仕様にしたか
どこで問題が発生したか
どう解決したか

まで残します。

これによって、別の社員が次の案件を担当するときにも、過去の経験を参考にできます。

案件を経験するほど会社の知識が増えれば、

「案件が増えるほど社員が忙しくなる会社」

から、

「案件を経験するほど次の仕事を進めやすくなる会社」

へ近づいていきます。

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

仕組みやマニュアルを作るだけでは、時間とともに使われなくなることがあります。

そこで今回の支援では、

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

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

例えば、

「営業が個人の人脈に依存している」

という課題なら、

「受注した案件について、顧客の課題・提案内容・受注理由を毎月1件共有する」

という目標にできます。

「仕様調整が属人化している」

という課題なら、

「仕様変更が発生した案件について、変更内容と判断理由を記録する」

という目標にできます。

「保守対応が特定社員に集中している」

という課題なら、

「問い合わせ対応事例を毎月○件共有し、他の社員が対応できる業務を増やす」

という目標にできます。

「開発工数が増えている」

という課題なら、

「繰り返し発生している作業を1つ選び、ひな型化・標準化する」

という目標にできます。

評価するのは、

「自分が売上を上げた」
「自分が開発できた」

という個人の成果だけではありません。

「営業方法を会社に残した」
「開発ノウハウを共有した」
「他の社員ができる仕事を増やした」
「工数を減らす仕組みをつくった」

という組織への貢献も評価します。

「自分ができる」から「他の社員もできる」へ。

そして「会社全体でもっと良くできる」へ変えていくことが、人事評価を連動させる目的です。

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

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

今回の神奈川県・従業員17名のWebシステム会社では、

営業導線の見える化
受注理由の共有
ヒアリング項目の整理
提案方法の共有
要件整理の標準化
仕様変更理由の記録
開発ノウハウの共有
保守への引き継ぎ改善
問い合わせ事例の蓄積
人事評価と賞与への連動

などに取り組みました。

その結果、

・社員の属人化解消に対する意識が高まった
・営業ノウハウを共有しやすくなった
・開発・保守の業務を見直しやすくなった
・過去案件の知識を次の案件へ活用しやすくなった
・会社が抱えていた課題の改善につながった

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

結果として、

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

につながりました。

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

成果は、顧客数、案件単価、社員数、サービス内容、市場環境などによって異なります。

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

「紹介営業をやめること」でも、
「すべての開発を同じ方法にすること」でもありません。

個人の人脈や経験という強みを活かしながら、

「他の社員も活用できる部分を会社へ残す」

ことです。

この考え方はWebシステム会社だけでなく、

システム開発
Web制作
広告・マーケティング
動画制作
営業支援
人材・採用支援
コンサルティング
製造業
建設業

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

全国のあらゆる業種の企業に対応できます。

「新規受注が紹介や社長の人脈に偏っている」
「営業担当者によって成果に差がある」
「案件ごとに毎回一から考えている」
「担当エンジニアしか分からない仕事が多い」
「保守対応が一部社員に集中している」
「案件は増えているのに利益が安定しない」

このようなお悩みがある場合には、営業と開発を別々の問題として考えるだけでなく、

「受注から保守まで、会社として再現できる仕事の流れになっているか」

という視点で見直してみる方法があります。

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

よくあるご質問 FAQ

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