見出し画像

【お客様事例#3】メインのエンジニアが抜けてしまうので、なんとかしてほしい

不動産会社向けのホームページ作成ツールを完成させたい

メインエンジニアがぬけてしまい、開発が進まなくなったC社。
引継ぎエンジニアが見つからず、弊社に相談がきました。

━━━━━ もともとオフショア開発で失敗していて不安だった

インタビューアー(以下、イ)  最近、インタビューさせて頂いた内容に似てますね。
こちはどんなシステムだったんですか?

PM:5万店舗が登録する不動産会社向けのホームページ作成ツールで、ポータル型の開発でした。
ポータルに登録された不動産情報を取得して自社のホームページに掲載する事ができて、更に管理画面からデザイン変更、ページ追加、会社概要やニュースリリースも作成できるというものを要望されてました。
SEO対策もでき、特集ページも作成が可能になります。

イ:デザインの変更となるとテンプレート、人によっては拘りたい方もいらっしゃるのではないかと思うのですが・・・

PM:そこもバッチリと対策を取って、テンプレートは10種類以上、カラーフォントのカスタマイズやHTMLソースで編集も可能にしたいと相談がありましたね。

イ:機能を聞いただけでも最近インタビューした内容と似ている気がするのですが・・・
ちなみになぜ、うちの会社に相談がきたんですか?

PM:元々はSESを使って開発をしていたようです。
ですが、メインのエンジニア、その他のエンジニアがぬけてしまって引継ぎのエンジニアが見つからなかったようです。
SESだとエンジニアの体調不良や色んな都合で入れ替えが発生するので、代替えが見つからない事もあるんです。
日本のIT人材不足は深刻なので、ハイスキルなエンジニア、手を動かすプログラマーレベルでも見つからない事は多いんです。

イ:あー!私も以前SESの営業をしていたので分かります!
なんらかの事情でエンジニアが抜けると代替えが、と相談が来ることがありました!

PM:はい、まさにその状況がお客様に発生したんです。
更に付け加えれば、お客様は以前、オフショア開発で失敗をしていたのもあり、体制を作る際はそこを考慮しました。

イ:どのフェーズ、体制で提案したんですか?

PM:フェーズとしては詳細設計、実装、検証、保守から入りました。
それと元々の開発体制がチーム制だったのでラボ型のチームで提案をしました。
更にオフショア開発で以前失敗していて不安があったということだったので、失敗の原因もなんだったかが予想がついていたので、更にオプションをつけました。


━━━━━ 立ち上げ期の苦労

イ:ラボ型のチーム体制で提案は分かるんですが、『オフショア開発で失敗していて不安』という部分はどう解消したんですか?

PM:オフショア開発での失敗例は色々あるんですが、大多数がコミュニケーションが一番の原因です。

日本語ができるブリッジエンジニアを使う企業が多いのですが、思ったほど日本語ができていなかったり、日本語は上手だが技術知識が浅かったりと完璧に両方できるブリッジエンジニアって少ないのです。

さらに運よくそういうブリッジエンジニアを確保できたとしても、そこにかなり依存してしまう為、転職や昇給要求など属人的なリスクが大きいのが実態です。

イ:うーん、確かに中途半端なブリッジエンジニアを使っても、間違って理解したら伝えた仕様と違うものが出来上がってくるので困りますよね。

PM:そうなんです。優秀なブリッジエンジニアと出会えて成功している開発も勿論ありますけど、ただでさえ日本語は表現が多様なので難しいうえに、技術だけでなく商習慣も分かっていないと要件を間違って理解することは多々あります。
たぶんですが、今回のお客様もそこで失敗をしたんじゃないかと思ったんです。

イ:確かにコミュニケーションがうまくいかないと開発は進められないですよね・・・うちの会社の場合は日本人PMが必ず付くというラボ型パッケージになってますけど、それでは発注してもらえなかったんですか?

PM:そうですね。お客様側で既にオフショア開発の失敗体験があったので、それが根強くあったのかもしれません。
なので、対策としてお客様先にオフショアマスターをアサインしました。

イ:出ましたね、オフショアマスター!

PM:はい、オフショアマスターがお客様の隣で蜜にコミュニケーションすることで仕様やコミュニケーションノウハウをしっかり蓄積してもらい、それによって開発が円滑にできるようになります。
なによりも、お客様のそばにいることでの安心感もあります。

緊急障害対応が割と頻発していたこともあり、伝達と改修をスピード感をもってやらなきゃいけなかったので、オフショアマスターをアサインしたのは正解でした。

イ:オフショアマスターが入ると現場で出てくる話なんかもすぐにキャッチできますもんね!

PM:はい、やっぱりそこが一番なんです。
オフショアマスターも開発チームにとっても重要なのはコミュニケーションです。お客様の目線に立つ、寄り添うということが大事なんです。
単純にお客様に指示されたことだけを開発をすればいいう訳ではないのです。


━━━━━エンジニア不足の問題解消後

イ:チーム体制の構築と開発がスムーズに進んだことによってお客様は満足されたんじゃないでしょうか!

PM:そうですね、エンドクライアントから新規サービス対応の依頼も獲得できて、お客様の新規案件の獲得に繋がったと聞いています。
さらに嬉しかったのはシステム設計のフェーズからコミットして欲しいと要望もいただけました。

イ:今回の案件の参画フェーズより更に上流からやってほしいと仰ってくださったのですね!

PM:新規の機能追加が積極的にできるようになったので、サービス利用アカウントが増えたと聞いています。
品質もサービスも向上したんですよね。
追加した新規機能の品質が高いと評価もいただきました。

イ:品質がいいと評価いただいた、という点はどう維持しているのか、今度聞かせてください!

PM:もちろん!
これは話すと結構長くなるので、他の話と絡めてお話ししますね。


開発体制と技術セット

日本人PM: 1名
プロジェクトリーダー: 1名
技術リーダー: 0名
COM: 0名
OM: 1名
開発メンバー: 1〜4名
QC: 1〜2名

技術セット: Zend(PHPフレームワーク)、MySQL、AWS

この記事が参加している募集

企業のnote

with note pro

この記事が気に入ったらサポートをしてみませんか?