世界でも類を見ないほど巨大化している、システムインテグレーション業界の多重下請け構造。この構造によって、顧客の課題解決に真剣に向き合いたい、意欲あるエンジニア・ベンダーまでもが「イチ開発作業請負会社」として埋もれてしまうという問題が起きています。今回は、顧客と直接コミュニケーションし、課題解決に邁進するPM、M.S氏の活躍ぶりを通じ、顧客とベンダーの共創DXにおける「領域撤廃」の重要性についてお伝えしていきます。
M.S氏プロフィール：大学を卒業後、小規模システム会社に4年在籍、その後ERPパッケージベンダーに4年半ほど務めた後、2018年に株式会社情報戦略テクノロジーに入社し大規模な開発現場を担当。
「イチ外部ベンダーでは課題解決などできやしない」という焦り
ー 顧客直のSIerに入社するまでの経緯について教えて下さい。
大学卒業後入社した会社は、小規模なシステム会社で様々な現場を経験しました。プログラムだけを組んでいるという、そういった仕事に就いてプログラムを組むだけで一生が終わっちゃってしまうのかと非常に疑問を感じていました。当時は自分のキャリアプランも全然描けない状態でしたね。
次にERPのパッケージベンダーに転職しましたがこの会社でも4年半やってみてあんまり面白くないなと思うようになりました。その理由はパッケージだと自由闊達な提案なども難しく、やり過ぎるとお金がかかるしやらなければそのまま単にパッケージを納品するだけという単調なことの繰り返しだったからです。
結果、エンドユーザーと直接、パートナーとして関わることができる情報戦略テクノロジーに入社。東証一部に上場しているような大手のエンドユーザー企業と直接仕事ができるというお話を頂き入社を決めました。
ベンダーと顧客という領域を越え見えてきた、本質的課題
ー 参画された当初、現場はどのような状況だったのでしょうか。
参画当初、先に参画していたパートナーさんが、案件が炎上しているからという理由ですぐに抜けてしまいました。参画後はまずその方の抜けた穴を埋めるように立ち回りました。そのような立ち回りをしながら、案件が炎上している状況について私なりに分析を進めたところ、プロジェクト内でコミュニケーションに関連する課題があることがわかりました。
本来システム開発は企画側と開発側が一緒に足並み揃えながら開発しなければいけないのですが、企画側が足並みの揃え方を知らなかったり、揃えようとしないという状況でそれによってコミュニケーションエラーが発生したりと課題だらけの現場でした。結果、開発に必要な情報がすべて連携されない状況に陥ったため、多人数開発の時は横断してコミュニケーションをとることが必要だと思いました。
ー 参画してすぐに課題を見つけることができたのでしょうか？
もちろんこの現場に入ってすぐに分かったわけでは無く、初めは自分の担当する開発作業を担当しながら周りのやり方をチラチラと見ながらこれはどうなんだろうと思いながらやっていました。
こちらから主体的に動いて様々な打ち合わせに参加させて頂いたり、自分で質問をしに行ったりして本当に少しずつ情報を集めていって課題点を見つけるようになりました。今では他ベンダーの開発者の方達とは電話で気軽に話したりできるような関係性になりましたが、当時は積極的に他のベンダー企業の開発者にも声をかけて巻き込んでいって一緒に足りていない部分を自分で対応したりしていましたね。
裁量もやりがいも信頼関係も、領域を超えたその先にあった
ー 課題を見つけても、そこに首を突っ込んでいくのはある意味リスクも伴う行動だと思うのですが、お客様はすぐに受け入れてくれたのでしょうか？
そういう意味でいうと私はお客様に恵まれたと思っています。私が課題だと思った点を指摘させて頂いて、解決に向けて徐々に動いていく中でやり過ぎだと言われたことは無かったですね。では、他のお客様に対しても同じことをやるかと言われたら「やる」と思っています。それがお客様に貢献できる開発者としてのあるべき行動だと思っているからです。
ー 実際に信頼を勝ち取るまでの間で、お客様から評価を頂けたと感じたエピソードはありますか？
三か月に一度、お客様から頂く一言コメントというモノがあるのですが、そこで「外部の調整まで任せられるので助かっています」と言われたときは、自分の行動がお客様に役立っていることを実感できて嬉しかったです。また、現場の忘年会で協力会社として唯一私だけが参加を許され、お酒を酌み交わす機会を頂いたこともありました。
あとは、直接お客様から仕事の依頼をしてもらえた時ですかね。「こういう仕事があるんだけどお願いできないですか？」という相談を持ち掛けられることがあります。これは、私たちだからこそ出来るのではなかろうかとお客様が期待して持ってきてくれていると感じています。そういった話が頂けるということは信頼いただき、評価していただけている証かなと思い嬉しくなりましたね。
視座の高さ・顧客のビジネス背景理解が、領域を越えるための資格
ー エンジニアの領域を超えた提案によって得られる利点はなんですか？
イチ開発要員ではなく、視座を一つ上げ、お客様の課題の相談に乗れること・考えることができることだと思います。PMクラスの人ならば、視座を一つ上げれば、お客様のビジネス視点で話をすることに繋がってくる点は多いです。
ー視座を一つ上げるために、必要なことはなんだと思いますか？
先ずは一にも二にも、勉強するということだと思います。勉強するといっても技術的なことは当たり前ですがそれだけではなく、頂いた仕事をより良いものにするために、お客様に満足して喜んで頂くものにするためにお客様のビジネスや状況を知るということも含まれてきます。たとえば、お客様の会社の沿革から調べ、代表の方の著書を読んだりすることで会社の文化や風土が理解できるようになります。そうすることで実際にお客様が話される話の本質的な意味がわかってくるのでお客様目線で一緒に開発を進めることができます。
最近、良かった本を上げさせて頂くと、
・チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで（市谷聡啓（著））
・クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?（エリヤフ ゴールドラット（著）、三本木亮（著））
自分よりも高いポジションで仕事をしている方々にオススメ本を紹介いただくと、自分に足りていない部分がわかります。高いレベルのインプットをしなければ、高いレベルのアウトプット（提案）もできないですからね。
執筆者
リビルダーズ編集部
