こちらの投稿、色々な意見頂けてとても嬉しいです。やたら広まっててビックリしました。
参考程度に意図も含めて少し長文で話せたらと思いますが、まず前提として
相手の現場に行くかどうかはぶっちゃけどっちでもいい。
というのは伝えておきたいです。我々IT屋にとって大事なのは「お客さんの課題を解決できること」です。究極的に言えばシステム導入すら必要がないケースも多々あります。
そしてシステム導入が必要であっても、現場に行かなくても適切なものが作れるケースも多々あります。現場に行くのが絶対、なんてこたないです。めっちゃ非効率ですし、お客さんの都合もあるので。
なんなら現場に行くって時点でコストかかるわけなので、要件定義時点でそれやるってなると結構な予算がいります。そういうのもちゃんと加味しないと駄目ですね。
さて。ではその上で僕が何故この考え方を「ベース」にしているかというのを話せたらな、と。
①システム化するための課題の解像度を高めたい
まずはこれですね。
今から何を作るのか、というのをそもそもお客さん含めて誰もわかってないのが最初です。なんとなくイメージとして解決したい課題はあれど、じゃぁどうしたらうまくいくかは誰もわからないので。
それをお互いに理解していく為に、積極的に現場を見たい、というところです。内容によりけりですが自社でコスト取って行く場合もあります。
あ、ちなみに現場に行くっていうのは殆どの場合は「見学」だったり、コミュニケーションをって業務フローを正確に確認するのが目的です。実際に仕事を体験することもなくはないですが、たいてい邪魔なので、避けることが多いですね。工場系だとそもそも危ないというのもあります。
②関係値を作るのに効果が高い
システムを作るだけ、なら別に現場に行く必要性なんて殆どないです。業務理解できたら良いもの作れるのはそうですが、現場に行かなくても良いものは作れます。世の中のシステムやサービスはほぼそれで作ってるはず。
後、業務理解しているドメインエキスパートがちゃんとフロントに出てきてくれているならそれで足りることも多いです。
じゃあなんでって話ですが、まずドメインエキスパートが打ち合わせの場やシステムの内容を見てくれることって僕の経験上ほとんどないです。だって現場仕事で忙しいんだもん。そりゃそう。だから「自分がドメインエキスパートに近づく」か「ドメインエキスパートが出てきたくなる」ようにするしかないです。
で、前者なんてほぼほぼ無理筋なので現実的な選択肢は後者しかないです。だから実際に現場に行って、システム化が誰のためのものなのかの説明もしつつ興味を持ってもらうしかない。
その上で御用聞きみたいなのでもいいから、課題や認識のすり合わせをする。ここで関係値を作るイメージです。
これだけでも①の解像度は変わってくるし、適切なコミュニケーションと課題意識を持ってもらえて、関係値作れたら打ち合わせの場にも同席してくれるようになったりします。
これが良いシステムを作る大事なポイントだと思ってます。DDDの文脈でも大事にされますが、本当にそう思います。
③運用保守時の大変さを軽減する
これは本筋ではないんですが、システム化というのは導入して運用保守に入ってからが「スタート」です。
システム作ってる間って、我々はめちゃしんどいですがお客さんからしたら「まだなにもない状態」なので、出来てからがスタートになります。
ただここでいわゆる現場理解がなかったり、実際に使うユースケースが漏れていたりすると問題が起きます。
②の話にも関連しますが、ドメインエキスパートがどれだけ関われていたかがここに跳ね返ってきます。
現場に出ることで現場の人とコミュニケーションを取れるので、システム化の意図や説明、運用時の大変さをバックオフィスの人だけでなくエンジニア目線でもしっかり伝えていくことが出来たら、このあたりは軽減させやすいです。
要件定義段階だけでなく、それ以降でも現場に確認取るような筋道が出来てると結構ありがたかったりします。
でもそういう動きをするには最初から現場に行きますって姿勢見せておかないといきなりは難しいので、最初に行くという意思表示や考え方というのが大事になると思ってます。
④営業提案時に他社との差別化が出来る
気づいていた方もいましたが、意外とこれが大きいかもしれません。
まず現場に出ることを積極的に営業提案の段階で言う事ってない（営業も言えない）ので、これが出来ると他社との差別化が出来ます。
予算云々はともかくとして受注確度が大きく上がるのと、調整については後でやればいいっちゃいいので、営業側も動きやすくなります。
また上記①②③もあり、現場に行って、品質が低くなるってのは考えにくいのでお客さん的にもありがたい提案になります。
勿論コストバランスや規模・内容で提案するかどうかは検討するわけですが、動き方としてそれぐらいしますよ、という提案は強いです。
まぁでもまず現場まで行って動いて（内容によりますが結構な地方へ行かないといけないことも普通にある）、ヒアリング、調整、要求分析から要件定義までをガッツリ行えるエンジニアって希少なので、そりゃそれができる人がいたら「差別化」になるよねって話でもあります。現場へ行くことの効果を知ってるから出来るってわけでもないので。
とまぁ、こんな感じです。長くなりましたが、ダラダラと纏めました。
単純なシステム開発をするため、というよりはそれ以外の要素も多く含まれていて、全体的に見たときに「こっちのが効率良いな」というのでやっていると思ってもらえればと。
ただ多くの方が言うように現実的には出来ないケースも多いので、心意気として、IT屋として、ちゃんとやる。という意識として持っていると思ってもらえたらと思います。
そして「本当に出来るの？」という方いらっしゃいましたが、私は今月、工場に行きますので、実際にやっている、ということをお伝えしておきます。
Quote
エナミコウジ@RaiseTech代表 | 自走力を鍛え上げるエンジニアリングスクール
@koujienami
客「システム作って業務効率化したいです！」
俺「じゃあ御社の業務一旦確認したいので、数日御社で働きますね！」
これがシステムエンジニアの最初の仕事。
まずプログラムじゃなくて、まず現場体験から。相手が工場とかの製造系なら工場の現場行くところから。