Chapter1/4

直接取引でお客様の生の声を聞き、企画力を磨く

林：アイミツアワード受賞、おめでとうございます。発注者からは、ユーザビリティなど使い勝手に配慮したシステム開発、あるいはきめ細かな対応を評価する声が多く挙がっていますが、ご自身では御社の強みをどのように考えていますか。

松田：ありがとうございます。今、挙がった点は、昔から力を入れてきたことではありますので、それを評価いただけるのは大変ありがたいことです。ただ、私たちとしては、そうした点も含め、お客様のニーズに応じてオーダーメイドでの最適なシステムを考えられる「企画力」が強みだと思っています。

林：なるほど。システム開発の場合、受注パターンがいくつかあると思いますが、御社の場合はユーザーとの直接取引が多いのですか。

松田：弊社はすべてお客様と直接取引です。北海道では、お客様との直接取引をメインにしているシステム開発会社はあまり多くないので、そこも特徴の1つだと思っています。

林：つまり、お客様と直接取引をしているから、ニーズに応じた最適なシステムを考える企画力が必要になり、それが強みとなっているということですか。

松田：そうですね。直接取引ではなく、下請けとして仕事をする場合に必要なのは、発注先の指示どおり作ることなので、企画力は求められません。どんな技術が必要なのかは、仕様書に全部書いてありますからね。でも、一般のお客様の場合、ご要望を聞いて右から左というようにシステムが作れることはごく稀です。必要な機能を洗い出し、業務に合わせた最適なシステムを考えてご提案できる企画力は、直接取引を重ねなければ身に付かないと思います。

林：お客様の業種や規模に特徴はありますか。

松田：業種は本当にバラバラです。規模は50人程度から数百人というところが多いですかね。

林：中小企業のなかでも、規模としては中の下くらいから上の会社と仕事をしている感じになりますね。

松田：戦略的にそこを狙っていっているわけではないんですが（笑）。

林：それはたぶん、お話にあったように、北海道に直接取引で企画からやれる開発会社が少ないなかで、そういう規模の会社が開発を依頼する先として、御社がはまるということかなと思うんですけれども。

松田：それはあると思います。ある程度以上の規模になると、大手のベンダーやSIerと何らかのつながりがあることが多いので、そちらに話が行くんでしょうね。

林：年間に手がける案件数とどれくらいですか。併せて改修などの形で継続的に仕事をしている会社数などもうかがえればと思います。

松田：開発規模に幅があるので一概には言えませんが、新規案件はおおよそ5～10件です。取引先は30社程度で、システム開発を始めたときからずっと長いお付き合いさせていただいている会社も少なくありません。

Chapter2/4

テクニカルサポートからスタートし、システム開発に進出

林：創業の経緯をうかがえますでしょうか。

松田：1999年に個人のお客様の向けのPCサポートを始めたのが、弊社の創業になります。当初は個人事業でしたが、2001年に家電量販店の店舗でのテクニカルサポートを受託し、その後業務を行う店舗数が増えたことから、2002年8月に法人化しました。

林：と言うことは、システム開発は新規事業で始められたわけですね。システム開発を行うようになったのには、何かきっかけがあったんですか。

松田：新規事業を始めようと模索しているなかで、ガソリンスタンドで給油中の社員が、店員さんにそのような話をしたところ、なぜか本社につないでくれたんです。

林：へえ、そんなことがあるんですね。実際、そこから仕事につながったのですか。

松田：はい。店頭で回収したアンケート用紙をスキャナーで読み込んで、コンピューターで使えるテキストに変換するというものでした。幸い、社員のなかにシステムエンジニアの経験者がいたので、試行錯誤はしましたが、無事に開発することができました。

林：そこから本格的にシステム開発に取り組むようになったんですか。

松田：その会社から追加の発注をいただいたりして、継続的に仕事はしていました。

林：具体的にどんな開発を行ったのでしょう。

松田：いろいろとやりましたが、大規模なものとしては、本社と店舗を結んだ資産管理システムですね。ガソリンスタンドには給油機からガソリンを運ぶタンクローリーまでさまざまな設備機器がありますが、買い取りのものもあればリースで使っているものもある上に、店舗の裁量で導入していることもあるため、本社で全体像を把握することがむずかしかったのです。それを本社で一元管理するためのシステムを作りました。

林：それは、業務システムの部分だけでなく、ネットワークインフラの部分まで、御社で手がけられたのですか。

松田：いえ、ネットワークはすでに構築されていたものを使いました。

林：そうなんですね。資産管理以外にはどんなものを作ったのですか。

松田：予実管理や研修の予約システムなど、大きなものから小さなものまで本当にいろいろやらせていただきましたので、ネットワークを活用した情報処理の仕組みを作ったというところですかね。

林：お話をうかがっていると、ある意味でこの会社に鍛えられたという部分もあるように思えるんですが。

松田：はい、たいへん感謝をしています。

林：話がちょっと戻りますが、PCサポートからシステム開発へと事業を広げてきたわけですが、松田さん自身は技術者だったのですか。

松田：いや、私自身は技術者としての教育を受けたり、仕事をしていたことはありません。ただ、システム開発をやるようになって、高校生くらいのときに技術者になりたいという気持ちがあったことを思い出したんです。システム開発を本格的にやっていこうと考えたのは、そうした想いの部分もあるんですよ。

林：そうだったんですね。ちなみに現在のような形でシステム開発を行うようになったのはいつごろですか。

松田：事業として拡大していこうと取り組み始めたのは5年ほど前からです。

Chapter3/4

入念なヒアリングで真のニーズに沿った要件定義を行う

林：御社の強みは、お客様のニーズに柔軟に対応した企画力ということですが、そのために必要なこと、あるいは心がけていることは何ですか。

松田：お客様のニーズをしっかりくみ取って、使い勝手の良いシステムを作るために、まず必要となるのは業務を知ることです。ですから、こちらが納得できるまで、ヒアリングは徹底して行います。

林：それは、お客様を理解することが必要で、そのために納得できるまで話をうかがうということですね。

松田：もちろん、ヒアリングをするだけで業務が理解できるわけではありませんし、お客様のやりたいことも完全ではありません。ヒアリングに基づいて仮説を組み立て、それをお客様にぶつけてみて、疑問点を1つずつつぶしていくなかで、お客様がやりたいことを実現できるシステムの要件定義をしていくようにしています。

林：例えば、実際にお話を聞くだけでなく、現場を見に行ったりとかということもあるんですか。

松田：さすがに、現場でオペレーションをしたり、ラインに入ったりとかはしませんけど（笑）、なるべく現場の方の意見を取り込んでいくということは、かなり意識しています。

特に、経営層主導でプロジェクトが進んでいるときは、必ず現場の方に参加していただくようにしています。経営層の考える問題点と現場の方が感じていることは違う場合が多いので、そのまま要件定義をして作ってしまうと、実務で使う現場の人たちにとって、積極的に活用したいと思えない、会社側から押し付けられたシステムという意識になってしまいがちです。お話をうかがうことで、現場の方に当事者意識が生まれますし、でき上がりとしても良いシステムになるんです。

林：確かに、会社が作っている公式のマニュアルと別に、現場の方がもっと細かい裏マニュアルを作っているという話もよく聞きます。そのあたりのことを具体的に引き出す感じなんでしょうね。

松田：そうですね。一方で、経営層から任された現場のリーダークラス主体でプロジェクトが進むこともあります。その場合は、ある程度具体化した段階で、経営層の方にも入ってもらうようにしています。現場の方たちのお話だけで要件定義してしまうと、最終的な決裁になった段階で、すべてひっくり返ってしまうことがあるからです。やはり費用対効果や将来の展望といった部分で見方が違うんだと思いますね。

林：ヒアリングが終わってから、実際の開発に入るまではどんな流れになっているのですか

松田：営業や開発が一緒になった「企画会議」を行い、内容を詰めていきます。最初にやるのは、お客様の課題と要望の確認です。ベースになるのは当然、営業がお客様からヒアリングをしてきた、どんな課題があって、システムを通じて何を解決したいのかということですが、その背景にある業種業態の特徴や売上規模、社員数といった会社固有の事情も確認します。特に重視するのは、経営者の方が、次にどこを目指しているかです。それによって解決すべき課題やその方法も違ってきますから。

林：まずは必要な材料を洗い出して、それを多面的に検討するということになりますか。

松田：そうです。その次のステップは、本当に案件ごとでケースバイケースですね。お客様の要望がざっくりしたものであれば、完全にどういうシステムにするのかという提案からに考えることになります。

作りたいものがある程度具体化しているケースでも、それをそのまま仕様に落としていくのではなく、背景なども踏まえて作りたい本当の理由を考え、それが最善なのかを検討します。また、目指している方向性から表面化していない潜在ニーズをくみ取り、要望に入っていない機能追加なども考えるように心がけています。

林：進め方としては、営業の方が聞いてきたお客様の情報と、御社が持っている技術力や経験を、どう組み合わせていったら、お客様に最適なものが作れるかを、それぞれの立場から議論していくイメージですか。

松田：そうですね。得てして技術者は、相談なしに営業が仕事を決めてくると、技術も分からないのに納期や価格面で無理難題を押し付けて、という気持ちになりがちです。ですから、そこの意識のすり合わせがすごく大事だなと考えています。

林：確かに同じ難易度のものでも、「契約しました。これ作ってください」と言われるのと、最初に「こういう話があるんだけど、一緒に考えてください」と言われるのでは、技術者の方のやる気も違うでしょうからね。

松田：ええ。企画会議に参加することによって、技術者がお客様視点を持つこと、そして作るモチベーションが上がることを期待しているんですよね。結論にたどり着くまでの思考プロセスがちゃんとたどれていれば、納得できた状態で仕事ができるんじゃないかなと思います。

林：ゴールに向かって、ちゃんとしたものが一番無駄なくできるように進めていくにはどうしたらいいかを、営業と技術が一体になって考えるということになりますか。

松田：はい。そこで重要なのは、お客様の作りたいというものが必ずしもゴールではないということです。課題解決に最適な方法がゴールなのであって、場合によっては原因がシステムではない場合もあり得ます。例えば、業務フローの問題だったり、それこそ現場のモチベーションの問題だったりすることがありますから。

林：その場合はどうされるんですか。

松田：考え抜いてその結論にたどり着いたのであれば、受注できなくても正直にその結論をお客様にお伝えします。そこでお客様とお話をして、システムを作ることが課題解決につながるという結論になればお手伝いさせていただきますが、無理矢理仕事をすることはありません。無理をすれば後々不満が残るような結果にしかならないので、そこは注意してやるべきだと思っています。

林：本当に要件定義までの段階に、かなりの手間暇をかけ、知恵を絞っているんですね。

松田：手間暇がかかっているように見えても、納品運用後に効果の高いものを作るためなら、その労力を割くべきだと思っています。要件定義のズレがなければ、開発段階でのすり合わせや手戻りがなくなり、コスト削減や納期短縮にもなりますから。

林：家を建てる際に、土壌調査からしっかりやって万全の基礎工事をすれば、上物の工事も楽で、住み心地の良いものができるというイメージですね。

松田：一番重要なことは、お客様の実際の業務フローにぴったり合い、かつ業務を改善できるシステムを開発することで、それこそがパッケージと受託の最大の違いになります。そこで価値を出せないのであれば、パッケージ使っていただいたほうがいいんです。受託でやっている以上は、お客様にぴったりのものを作るということには、本当にこだわらなければいけないと思っています。

林：お話をうかがっていて、実際に現場でどう使われるのか、まさにキーボードを打つ姿くらいのレベルでイメージしてシステムを作られているように思いました。記憶に残っている事例などはありますか。

松田：水産卸会社の販売管理システムを作ったことがありますが、そこの古いシステムを手がけたのは、当社よりも規模の大きな札幌でも名の知れた開発会社だったんです。依頼の内容は、ともかく使い勝手が悪いので相談に乗ってほしいというものでした。

林：そういう依頼もあるんですね。

松田：実際に見て驚いたのですが、言葉のたとえではなく文字通り「言われたことをそのまま」システムにしていたようなんです。

林：えっ、それってどういうことですか。

松田：例えば、販売管理システムなのに有給休暇の申請機能が組み込まれていたんです。それもExcelを呼び出して届け出を印刷するだけなんです。たぶん、お客様から要望があったのでしょうが、それにしても……。

林：簡単な話、そういうニーズがあることに気づいたのなら、別に勤怠管理システムも作りませんかという提案をすればいいことですよね。

松田：まあ極端な例かもしれませんが、これが本当のニーズなのか、どうしたら使い勝手の良いものを作れるかといったことを考えずに開発するというのは……。

Chapter4/4

お客様目線で、より使い勝手の良いシステムを提供し続けたい

林：ここまでのお話で、御社がお客様から評価されている理由がよく分かりました。とりわけ、強みのベースとなり、他社との大きな違いとなっているのは、会社のルーツがテクニカルサポート事業だということだと思うんです。話の端々に、現場のことをきめ細かく把握し、それにフィットしたシステムを作っていきたいという想いが感じられたのですが。

松田：具体的な方法論として他社と何が違うかを明言できるほど業界研究をしているわけではありませんが、テクニカルサポートの仕事というのは運用支援である、というのが弊社のスタンスなんですよね。

つまり、使う上での困りごとやトラブルの解決を支援するということで、そういう考え方がシステム開発にも反映されているのは間違いありません。ですから、作って納品したら終わりという考え方ではなく、それをいかに活用してもらうか、活用するにあたって障害があるのであれば、それを解決するところにまで踏み込んでやっているわけです。

林：松田さんの考え方がとてもよく理解できました。ですが、組織全体がそうした考えのもとで動くようにするのは大変なんじゃないですか。

松田：これも特徴と言えるのかもしれませんが、弊社のシステムエンジニアのなかにはPCのテクニカルサポートを担当していた者もいるんですよ。サポートのベースとなる考え方を理解しているので、それが開発にも反映されていると思っています。

林：そうなんですね。テクニカルサポートからシステムへの異動というのは、ジョブチェンジのような形で継続的にやられているのですか。

松田：これまではケースバイケースというか個別対応ですね。例えば、テクニカルサポートをやっていた者が家庭の事情で退職するという話になったときに相談をして、システムの勉強をした上で在宅のエンジニアとして働いてもらうようになったケースもあります。人材の確保、育成ということを考えると、今後は組織的な対応というのも視野に入れる必要があると思っています。また、人の部分だけでなく、事業としてテクニカルサポートとシステムをもっとシナジーさせていくことも考えています。

林：それは具体的にはどんなことですか。

松田：一例として言えば、テクニカルサポートの部隊で、システムの運用サポートもできるようになれば、単独で事業化できる可能性もありますし、それが新規の受注につながることもあるのではと思っているんです。

林：開発から運用までを、きめ細かく一気通貫で対応できる体制にしていくわけですね。

松田：使い勝手の良いシステムを提供できるかどうかを決めるのは、単なる技術力ではなく、本当にお客さんの立場に立てるかどうかだと思うんですね。規模は小さくても、そういう部分ではどこにも負けない会社だという自負は持っています。

インタビュー後記

考え方の根底に、お客様目線や使い勝手という視点のあることが、よく分かったインタビューでした。それは、やはりパソコンのサポートからスタートしたという、システム開発会社でも珍しい創業経緯を持っているからでしょう。事業に役立つシステム開発を標榜する会社は世の中にたくさんありますが、真の意味でお客様にフィットしたシステムを開発できる会社だと感じました。

株式会社エムテックに関する詳細情報はコチラ