昔働いていた会社の話をします。
かなり狭い業界の話でして、具体的なことを書くと一発で特定されてしまいかねない為、製品名や技術名称などについては伏せて書きますがどうかご勘弁ください。
その会社の名前を、仮にA社としてみます。
A社の主要な収入源は、とある業務に最適化されたパッケージソフトの開発と保守、導入支援や運用支援等でした。
まあCADみたいなもんだと思ってください。
その業界で当該ツールを作っている会社は精々2,3社しかなく、業界は寡占に近い状況でした。
そもそも業界のパイ自体があんまり大きくないので、「GAFAみたいな大企業が黒船のように乗り込んできて皆がなぎ倒される」といったことが起きる心配もそれ程なく、比較的ぬくぬくとした環境であったように記憶しております。
今どうなってるか知りませんが。
で、当然ながらほぼBtoBの商売しか行っておらず、顧客は殆ど全てが「大口顧客」。
顧客層もある程度限定されており、業務も似通っているので、「お客様の声」というのは非常に重要でした。
「こういう機能欲しいなー」とか「こんなこと出来るようにならないかなー」という声が、受託開発かよっていうレベルで重視されました。
あんなこといいな、できたらいいなの世界。皆様のドラえもんです。
「できたらいいな」のレベルとはいえ、なにせ利用範囲が狭いツールなので、お客様のビジネス上の必要性も具体的ですし要件も明確です。
要望に応えないで競合他社の製品に切り替えられてしまうとそれだけで会社が傾きかねないので、対応する側としても必死。
要望イコール受託開発、っていう言葉もあながち大げさではありません。
その時は、とある大口顧客の要望を受けて、主力ツールを補完するような立ち位置の補助ツールが開発されようとしていました。
今まで開発したことがなかった機能で、技術難度はそこそこ。
現状のスキルや実績で実現可能かどうかについて検討が行われ、私自身フィージビリティ(実現可能性)の検討MTGに出席して、あーでもないこーでもないと議論しました。
結局、既存のスキルセットで実装は可能だしパフォーマンスも担保出来るけど、あれこれ工夫しないといけないし工数はそこそこかかりそうだよ、というのが検討の結果でした。
その時、社内のとあるエンジニアが、こんなことを提案しました。
「これ、〇〇っていうフレームワーク使えば簡単に実現出来ますよ。ぼく前似たような開発したことがあります」
ほほう、と上層部は興味を惹かれました。
そのエンジニアを仮にBさんとしますが、Bさんの見積もった工数は、既存の技術で実装した場合の2割から3割程度、ライセンス費用等の心配もありません。
なにより「一か月もあれば結合テストまで終わる」という、開発のスピード感が魅力的でした。
ただ一つ問題点として、その技術、社内にBさんしか詳しい人がいなかったのです。
ちょっとだけ触ったことがある、という程度の人が一人。
「聞いたことはあるけれど中身は全然知らん」という人が数人(私もその中に含まれます)。
あとのエンジニアは誰も、フレームワークの名前を聞いたことすらありません。
社内のエンジニアであればほぼ誰でも使える既存技術か、Bさん以外はほぼ中身を知らない新技術。
どっちを使って開発するか。
もちろん上層部も、保守や導入支援に当たって「その技術を知っている人材の厚さ」が重要だ、ということは認識していました。
あるいは認識しているつもりでした。
Bさん一人ではとても運用支援や保守は回せないので、開発自体は出来たとしても、その後当該スキルを持った人員を育成、あるいは採用しないといけません。
それも考えるとそこまでコストが削減できるわけではない、ということまでは、上層部も理解していました。
上層部に足りなかったのは、「スキル習得」や「スキルを持った人員の採用」ということの、実際の難易度に関する認識。
そもそもA社は、どちらかというと枯れた技術で堅実な開発をやることに特化してきた会社でして、オープンソーステクノロジーの導入を始め、「新規技術の導入」ということに実績や知見を持った人はあまりいませんでした。
上層部自身エンジニア出身ではあったのですが、同じく枯れた技術でメインフレームやら基幹システムの開発をしてきた人たちです。
人材豊富な技術畑における開発や育成しか経験がなかったんです。
もしかすると、「新しい技術を導入する為のいい機会」だという考えもあったのかも知れません。
ただ、なにより「既存技術だと野暮ったくて泥臭い開発になるけど、新しい技術だとすっきりスマートにかっこよく解決出来る」というのが決め手になったのではないか、と、当時の空気から私は推測しています。
なんにせよ上層部が、「まあ人が足りなかったら育成なり採用なりすればいいや」という程度に考えていたことは間違いありません。
結局Bさんの意見が採用され、数人の開発チームが編成されました。
メインの開発者は当然Bさんで、技術メンバーはBさんからスキルトランスファーを受けつつ技術習得、最終的には当該チームで運用支援まで回す、という見込みでした。
***
以下は後から聞いた話です。
結論から先に言うと、「スキルトランスファー」というのは絵空事でした。
一休さんに「ではスキルトランスファーを絵から出してください」と言われそうな状況でした。
大口顧客の要望から始まった当該開発は、社内プロジェクトなのに何故か開発期間が非常にタイトでした。
BtoBといっても顧客との力関係というものはあります。
当該顧客は業務上の必要性から早急にそのツールを必要としていましたし、競合他社への切り替えを匂わせることが大きなプレッシャーになることも熟知していました。
上層部がBさんの提案に飛びついた理由の一つもそれでした。
結果、Bさんはプロジェクトの初期から全力で設計・開発に取り掛からなくてはならず、メンバーに技術説明をしている隙など全く発生しませんでした。
プロジェクトの初期に当該技術についてのBさんによる説明会が行われましたが、全8回で一通りの内容を伝える筈だった説明会は、結局最初の1回しか開催されませんでした。
それならばと、プロジェクトの残りの開発メンバーはwebから当該技術についての知識を得ようとしましたが、すぐに愕然としました。
資料もドキュメントも殆どwebにないのです。
日本語の技術書籍すら発売されていません。
当該技術のコミュニティがあるにはあり、そのコミュニティに参加することで多少のフィードバックを受けることは出来たのですが、そのやり取りは全部英語、かつやり取り自体そこまで活発ではない。
セミナーなりなんなり参加しようとしても、セミナーはアメリカとオーストラリアでしか開催されておらず、しかも次の機会は再来月、というような状況でした。
結果、Bさん以外の開発メンバーは、ドキュメント作成とテストケース作成以外何もやれることがない、という状況に、プロジェクト開始早々なってしまいました。ヤバさマックスコーヒーです。
当然上層部は慌てました。
これも狭い業界の悲しさか、それとも営業の脇が甘かった為か、大口顧客には既に「当該機能を実現した補助ツールが〇月にはリリースされる予定ですよー。
だから保守更新よろしくね」と言ってしまっていたばかりか、他の顧客にも「こんなツールできますよ。導入しません？」などと言ってしまっていました。
今更プロジェクトの線を引き直すことなどとても出来ません。
結果、当該技術が使える人がBさん以外誰一人いない、という状況のまま、Bさんの頑張りでツールはリリースされてしまいました。
そう、「されてしまった」のです。
大変なのはここからです。
当たり前ですが、業務パッケージというものは「リリースしてそれで終わり」というものではなく、それ以降の支援業務が一番重要です。
お客さんへの導入支援や、技術的な対応でお金をもらわなくては会社は回りません。
そして、社内にそれがちゃんと出来る人はBさん一人しかいません。
結果、リリース直後からBさんの工数は保守・運用で完全に埋まり、開発完了後もスキル移譲の時間などこれっぽっちも取れませんでした。
他メンバーの技術習得も遅々として進みません。
それなら採用だ、となったんですが、これもある意味当然のことながら、「そんな珍しい技術が使えて、しかも就職市場でたまたま空いている人」などどこを探しても見つかりません。
大手人材紹介会社のエージェントもお手上げ。
たまたまスキルを持った人を見つけても、所属している会社でがっつり開発に入って全力ホールドされている、という人ばかりでした。
悪いことは重なるもので、殆ど余裕がないスケジュールで動かざるを得なかったBさんは、この後メンタル面で調子を崩して退職。
会社はどうしたかというと、フリーランス扱いでBさんにサポートの仕事を請けてもらいつつ、結局1から既存技術で丸々開発をやり直すことになってしまいました。開発費用丸損です。
Bさん自身、実際は「当該技術の人材が薄く、特に国内には殆ど人材層がない」ということは多分知っていたんじゃないかなーと推測でき、当初は「社内での自分のプレゼンスを高める」という意図が多少はあったんじゃないかなーと邪推してしまうのですが、それがあまりにも効き過ぎてしまった格好です。
以上が、最終的に誰も幸せになれなかった案件の顛末です。
***
この事案から、私は幾つかの教訓を抽出しています。
・多少野暮ったく見えたとしても、「誰でも使える技術」で実装することの価値は代え難い
・技術は、「マイナーな技術である」というそれだけで習得難易度が跳ね上がる
・マイナーな技術を持った人をそう簡単に採用出来ると思ったら大間違いである
・システムに限らず、「誰か一人しか出来ない」という仕事の存在は会社にとって致命的であり、何を措いても解決しなくてはならない
・だから、「特殊な仕事を誰でも出来る内容に置き換えられる」という能力を持った人は滅茶苦茶貴重である
・受託でもない開発案件で顧客にリリース時期の約束をした営業は強めにおなかこわして三日くらいトイレにこもれ
こんな感じです。
人員の冗長化、大事ですよね。
「自分一人しか出来ない」でプレゼンスを得るという戦略は時には成立するんですが、それでも会社にとっても当人にとってもそれ滅茶苦茶リスキーだよ、という話でした。
今日書きたいことはそれくらいです。
-スパークル株式会社- 1.企業の課題解決に向けたDX推進人材の採用・育成に関する状況 -ティネクト株式会社- 1.「営業リストが尽きた時に次に取るべき行動とは？」
（文責-ティネクト株式会社 取締役 倉増京平）
【ウェビナーのご案内】
中堅・中小企業の経営者や人事担当者様向けに仙台を拠点に活躍するベンチャーキャピタル・スパークル株式会社様と共催セミナーを実施します
営業リストが尽きたらどうする？生成AIを使って自社で始めるDX人材育成とweb集客
社員が主導で新規顧客を呼び込む体制づくり ～成功事例をベースにわかりやすく紹介～
＜内容＞
2.DX推進人材の具体例とスキル要件
3.人材育成の進め方とそのポイント
4.弊社の支援内容の紹介
2.【STEP 1：自社で始める生成AIを使ったWEB集客の基本ステップ】
3.【STEP 2：成功事例で学ぶ生成AIを使った具体的なアプローチ】
4.生成AIを使った自社社員が動ける仕組み作り
5.まとめと次のステップへ
日時：
2024/11/22（金） 10:00-11:30
参加費：無料
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。
お申込みは
ティネクトウェビナーページ
ご覧ください
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
（Photo：Illya Kondratyuk）
