パートナー座談会 エンジニア編 前編Engineers’ talk

今回集まっていただいた皆さんは、実際の導入支援だけではなく、プリセールスにも携わられていますよね。

UIS 日坂

そうですね。

JCS 松尾

むしろ自分から商談の場に出張っていきますよ。

そこで行うのはデモ（製品を実際に操作して紹介すること）をしたり、ヒアリングしたり、というところですよね。

YJP 深見

基本的にはそうでしょうね。皆さん、営業から引き継がれていく感じですよね？

MSI 大場

ウチの営業は最初の段階から簡単なデモはやっていますよ。引き合いが出た段階になってはじめて私が出ます。事前に営業がお客様から情報をいただいて、それをモデリングしたものを使って紹介させていただきますね。プロトタイプの1つ前の段階、という風なものです。

KSI 小倉

最初の営業段階でそういった情報は集められるものですか？

MSI 大場

もちろん、集められない時もあります。ですが、業種と製品がある程度わかれば形にはできますからね。

KSI 小倉

ウチの場合、お問い合わせやご紹介をいただいてから動き始める、という場合がほとんどなので最初から私が出ることが多いです。生産スケジューラを使ってやりたいことが明確なお客様だったら、それに沿ったご提案をさせていただきますね。私はコンペも担当するので、いただいた提案依頼書に基づいてデモプロジェクトを作って説明します。

提案の段階で見積もり金額も出すと思うのですが、そこで皆さんが気をつけていることはありますか？

MSI 大場

提案の段階で必ずプロトタイプを作成することにしています。それを見積もり根拠にしているのは、もしかしたらウチだけかもしれません。それで導入作業全体の手数がどの程度になるかのあたりをつけるんですよね。

JCS 松尾

弊社は基本的にお客様が求めることに応じて、インテグレーションのグレードをあらかじめ決めています。大きく分けて3種類、見積もりの目安を決めていますね。その後、要件定義ができた段階で改めて見積もるのですが、その時は工数ベースで考えます。

YJP 深見

ちょっと話がズレるかもしれませんが、弊社は請負ではなく工数消費型の準委任契約を結ぶことが多く、そこが他社とは違うところでしょうね。

KSI 小倉

確かに、請負だとリスクが高くなりますよね。

YJP 深見

それもあるんですけど、最初の要件定義の段階で設計に本当に必要なものをお客様が出し切れないことが多いんですよ。いざできあがった時に「こういうつもりじゃなかったのに」ということになりかねないです。それよりも準委任で、確認してもらいながら進めて、要件も揃えていくというスタイルを取っています。

UIS 日坂

弊社はほとんど請負ですが、その点で言うとプロトタイプを重ねてアジャイルな感じでやっていますね。もちろんユーザーさん次第ではありますが。

MSI 大場

そうですね。弊社は中小企業にお客様が多いので、予算が限られている場合が多く、準委任ではなかなかできないです。

YJP 深見

弊社が請負にしてしまうと、どうしてもプロジェクトがウォーターフォール型になってしまうんですよね。そうすると、お客様の本当に求めていることと要件定義、ギャップがあるまま進んでしまうリスクがあるので、準委任契約でできるように提案をすることがほとんどですね。

FLEXSCHEの要件定義で難しいところなどはありますか？

YJP 深見

先ほども申し上げた通り、要件定義で要件をお客様が出し切れないケースが多いというのが難儀なところですね。

MSI 大場

よくあるケースとして工場長と現場の方、計画担当者などがそれぞれ異なる意図を持っていることがあるんですよ。

KSI 小倉

担当者さんとお話して、要件定義書を提出したら工場長クラスがぜんぜん違うこと言っていたりしますよ。そうなると「お伺いした通りに書いてますよ」とは言うんですけど、大抵の場合は要件定義がやり直しになってしまうんですよね。それでもめて、仕舞いには「ヒアリング能力がないんじゃないですか」なんて言われてしまったり……。

JCS 松尾

とりまとめる人がきちんと決まっていないとつらいですよね。

UIS 日坂

弊社ではお客様にも導入に向けてある程度、体制を明確にしていただけるようにお願いしていますね。ご担当者さんはどなたで、要件に責任を持つ方がどなたで、と。そういう体制を組んでいただけると進行もスムーズにいきますね。役員の方にも打ち合わせに参加してもらえるとなお良いです。

YJP 深見

やっぱりシステム担当の方と現場の方、その両方が打ち合わせに出てきてもらえると一番上手く進められますね。それでも最初の要件定義をお客様の本当の意図通りにするのは簡単ではないです。

MSI 大場

私はお客様のところに行ったら必ずホワイトボードをお借りして、質問しながら図を書いていくんです。それでお客様の方でも理解を深めていただかないと、できあがったものが違うと言われてもどこが違うのかはっきりしなくなるじゃないですか。要件定義の段階では数点ピックアップしてプロトタイプを作るんですけど、いろいろな制約条件があることをどんどん掘っていかないといけないんですよね。

KSI 小倉

そうですね。計画担当者さんの頭の中にはいろいろな制約条件などが詰まっているはずなんです。それを要件定義という形で顕在化ができないんですよね。

さきほどユーザーさん側の担当者さんの話が出ていましたが、実際のところどのような体制を組んでもらうことが多いですか？

MSI 大場

FLEXSCHE専任の担当者さんを付けていただけるようにお願いしています。だけど、中小企業ではなかなかそれも難しい場合がありますよね。少なくとも最初だけは、専任の方とバックアップとなる方の2人はいてほしいです。

YJP 深見

生産スケジューラを入れるという作業は本当にものすごい物量が必要な作業ですから、専任がいるとスムーズですよね。通常業務の合間に片手間で、というのは実際には厳しいです。

KSI 小倉

逆に大企業では形式的な要件定義になりがちで、担当者さんとの直接の打ち合わせが浅くなってしまうことが多いんです。担当者さん自身が計画立案業務に精通していないとプロトタイプが正しいかどうかの判断もつきませんから、無理をしていただいてでも実際に計画立案をしている方とも必ずお話がしたいです。

JCS 松尾

やはりいろいろな事情をよく知っている方がいて、その方としっかり膝をつき合わせてご相談させていただけるか、というところが重要ですよね。そうしてはじめて、我々としてもきっちり要件を引き出していくことができます。

そういう風に要件定義を進めることでほとんど全ての要件を出し切ることは可能ですか？

MSI 大場

ケースにもよりますが難しいことも多いですよね。工場によっていろいろな制約条件があるものなので、一つ一つモデリングして掘っていくとあらかたのものは出るとは思いますが、それでも出てこないものもあるんです。そういうのはもう本当に導入の最後の段階でようやく、ということもあります。

KSI 小倉

先ほども申し上げた通り、計画担当者さんも本当はわかっているはずなのにそれを明確に表現できないことが多いですからね。

YJP 深見

やはり要件定義で全てを出し切れるとは限らないので、アジャイルでどんどん確認していただきながら進めることが、お客様が理想とするものと我々が開発を進めるものとの間でギャップが大きくならないようにするために必要だと感じます。

MSI 大場

あとは生産の現場を見せてもうことで担当者さんの言葉から出てこなかったことが見えてくることもあります。

KSI 小倉

そこはよく製造業のことを知っていないとできないですよね。

MSI 大場

そうですね。だからよく勉強して、工場内でもいろいろなところを見せてもらうようにしています。

皆様、FLEXSCHEの導入作業に携わられて10年以上というキャリアをお持ちですが、FLEXSCHEを扱い始めたころのお話を教えてください。

MSI 大場

私は当時、お客様から生産管理システムを求められていたのですが、よくよく話を聞いてみると必要なのは生産管理システムではなく生産スケジューラなのだとわかりました。それで何社かあたったのですが、FLEXSCHEのデータはインターフェースがCSVなどの扱いやすい形式であり、なおかつ柔軟にカスタマイズできるということなので、インテグレーションしやすいと判断して最終的に選定しました。また、生産管理システムは多くの工場で導入されていますけど、それではやれていないことがたくさんあるんだなとFLEXSCHEを扱い始めてわかりましたね。

扱い始めた時の技術的な難易度はどうでしたか？　敷居が高いというイメージもあるようですが……。

MSI 大場

仕組み自体は明快で非常にわかりやすいと思います。以前のFLEXSCHE Componentsの時代はだれでも開発ができるというものではなかったですが、今は計算式でけっこう何でもできちゃうじゃないですか。

YJP 深見

初期のFLEXSCHEではプログラミング、しかもC++のスキルが必須でしたけど、今ではよほど特殊なケースを除いてはC++の出番はないですし、いろいろなことが手軽にできるようになりましたよね。

KSI 小倉

ウチにはFLEXSCHE担当の前任者がいたんですけど、その方が退職してから私が入社するまでに期間があったので、技術的なことを教わることもなく、やることになったので苦労しましたね。独学で進めていきつつ、お客様にも鍛えていただいたと思いますね。

UIS 日坂

私の場合、教えてくれる人がいたので最初はすっと入っていけましたね。でもやっぱり深めていくにつれて苦労はしました。

JCS 松尾

私も営業でプロトタイピングをいくつも重ねていく中で深めていった感じでしたね。

FLEXSCHEのインテグレーションでは皆さん、アドイン開発もなさいますか？

YJP 深見

最近は標準機能がずいぶん充実してきたのでかなり減りましたね。スケジューリングルールにコマンド実行メソッドができたおかげいろいろなことができるようになりました。

MSI 大場

ウチもあまりアドインを入れなくてもいろいろできるようになっています。たまにオプションとしてある機能を使いたい、という時にちょっとしたスクリプトで解決してしまうこうとはあります。

UIS 日坂

スクリプトでできるとアドイン開発の負荷はかなり軽くなりますよね。

今はDLLのアドインを開発することはありませんか？

KSI 小倉

私は結構ありますね。お客様専用の入力画面や、パネルを作って検索しやすくするなどですね。

UIS 日坂

たしかにお客様固有の画面を作るということはありますね。

KSI 小倉

あとは帳票の開発も多いんですよ。ガントチャートのイメージを表計算ソフトで表現してほしい、といわれることがありますね。本当はガントチャートをそのまま印刷してもらっても良いんですけどね。社内の承認過程などがありますから、サイン欄などをその会社に合わせて出力できるようにします。

ユーザーさん独自の文化に合うようなものを、というところですね。

KSI 小倉

そうですね。帳票って皆さん作らないですか？

UIS 日坂

基幹システム側でやってもらうことが多いですね。

KSI 小倉

はあ、そうなんですか（苦笑）。

プロジェクトが滞る時にはどんな理由がありますか？

KSI 小倉

お客様からいただくマスターデータが揃わないというのが問題になりますよね。おおよそのものでも良いからくださいとお願いしてもなかなか出てこなくて、プロジェクトが中断したこともありました。

MSI 大場

受け身でいるとなかなか答えも出てこないですから、無い情報は嘘でも良いからとにかくください、という風に求めます。スケジューリングしてみれば、精度の低さが顕在化するので、かえって全体の進行がスムーズになります。

YJP 深見

そうそう、それがいいですよね。以前に某メーカーへの導入をやらせていただいた時、とりあえず能力情報を集めてスケジューリングしてみたら、現場の方々は「こんなはずはない」と言うんです。そこから修正していって、実現にこぎ着けました。

KSI 小倉

あと長引いてしまうパターンとして、専任の方がいろんな事情で変わってしまう、ということがあります。その後任の方が最初の方と全く違う考えで、真逆のことをおっしゃっていたりとか。それで完全に仕切り直し、ということが過去にありました。

JCS 松尾

私も一度、大変な時がありまして、一年で7回も担当者が変わってしまったことがありました。結局その案件は頓挫してしまったのですが。

UIS 日坂

ある程度の要件定義が済んで、十分な情報が揃えれば開発は進行していきますが、テスト稼働を始めてから検収にたどり着くまでが最後の難関ですよね。10年くらい前の案件なのですが、本来一ヶ月で終わるはずのテストに一年もかかってしまったことがありました。二週間連続で自動スケジューリングができたら検収を上げてくれる、という条件になっていたのですが、実際はなかなかすんなりとはいかなくて。当時は要件定義を十分にしないまま開発に着手していたのが問題だったかもしれません。

KSI 小倉

私もなかなか検収を上げてもらえなかったことがありますよ。以前に「まだ効果が見えないので支払えない」と言われて一年間待たされました。そんなこと言われても要件通り作ったんですけどね（笑）。そこから改善も進めて、結局検収を上げてもらえた後にその会社の別工場にも入れたい、と言っていただけたのでなんとかなったのかなと。

UIS 日坂

そうやって横展開するということはそれだけの効果があったんでしょうね。

KSI 小倉

当時はまだまだFLEXSCHE初心者で苦労した案件でしたが、いろいろと工夫して作ったので、そういったところで効果を実感していただけたんじゃないかなと思います。

YJP 深見

担当者さんは満足しているのにその上司が認めてくれないというケースもよくありますよね。

KSI 小倉

ちなみに要件通り作って検収はあげてもらえたけどまだ課題が残っている、という場合、費用はどうされてますか？

UIS 日坂

基本的には追加でいただくことになりますね。