見出し画像

「現場とともに開発をする」3つの勘所

こんにちは、imaimaiです。いろいろな開発がようやく落ち着いてきて、エモが消えないうちにちょっと書いておきたいなと思います。

当社iSTCのとても大きな特徴が「歩いて30秒で現場に行けるITスタートアップ」というところです。サービスを使いこなしている熟練ユーザーとコミュニケーションを取り、意見を吸い上げながら洗練できるということが品質向上に大きく寄与しています。今回の開発でも、その地の利は最大限発揮されました。本当にやりやすくて助かっています。

しかし、そのコミュニケーションのとり方を少し間違えればかえって効率を落とすことにもなりかねません。現場が強く、開発側がただの現場の御用聞きになってしまったり、無理やり使ってもらおうとして現場との溝が深まったりすることもあるでしょう。今回は、私が現場とコミュニケーションを取りながら開発を進めていくに際し、大切にしている基本動作を3つ、書き留めておこうと思います。

現場に行け、現場を聞くな

画像1

開発側と、実際に現場で働く工場側では、環境が大きく違います。それを知らず良かれと思って提案したことが、相手にとって大きな負担となることもあります。独善的にものを作ってもダメなのです。

一方で、それは相手の意見をすべて製品に反映させる「御用聞きになる」ということでもありません。環境が大きく違うのです。現場の人が知らない知恵を開発側は持っているのです。逆もまた然りです。

大切なのは現場に行き、観察することです。現場の人が抱いている不満の根源は、口に出しているアラートにあるとは限りません。実際に自分の目で見て、現場の現象を抽象化して真因を探ることが大切だと思います。

図1

100の進言 < 1のプロト

画像4

新規開発のとき、様々なアイディアを出してそれを形にしていくと思うのですが、強い熟練したプレゼンター出ない限り、プレゼンするだけでは人々が納得してくれません。人が人のアイディアを具体的にイメージするのはとても難しいのです。そういうときは、具体的なモノを作ってしまうのが一番手っ取り早いです。

物事には、わかりやすい恩恵とわかりにくい恩恵があると思っていて、わかりやすい恩恵というのは、下記のようなものです

距離・時間的制約を解決するもの
ユーザビリティの向上につながるもの
☑ その他困り毎に直接寄与するもの

一方でわかりにくい恩恵というのは、セキュリティ、可用性、スケーラビリティといった類のいわゆる「できていて当たりまえ系」のものです(この尊い恩恵に関しても書きたいことが山程あるのですが、今回はやめておきます)。 ここはもちろん、しっかり作り込まないといけません。

プロトタイプづくりの良いところは、一旦恩恵を理解もらうと「そのアイディアありき」での意見が出るようになるところです。"やる/やらない"で綱引きをしていたフェーズから、"どうやったらもっと良くなるか"の議論にジャンプアップできます。

運用が命

画像4

iSTCのカルチャーの一つかもしれません。IT技術は導入したは良いものの、後々使われなくなっていくことも数多くあります。便利さは、使い込まないとその効果を発揮しないまま終わってしまいます。IoTをIT(Information Technology)とOT(Operation Technology)の融合と捉え、車輪が回るまでサポートする意識を持つことが大切です。このあたりの話は以前ノートに少し書きました。

開発の立場としては意見をもらったら、何かしらのアクションを素早く返すことを心がけています。それはもちろんすべてを反映できるわけではありませんが、真摯な対応を忘れてはいけないと思っています。現場と開発がOne Teamとなってサービスを磨くために、運用への注力を忘れてはいけません。

まとめ

製造業に限らず、特定のドメインに対してなにかのサービスを提供するようなときには、このあたりの意識を持つと、割とうまくいくんじゃないのかなーと思っています。

☑ 現場に行け、現場を聞くな
☑ 100の進言 < 1のプロト
☑ 運用が命

とはいえ、私も余裕がないとこの3つも忘れがちになって、ついつい独善的になったり、口だけで手を動かさなくなったりするので、サービスを磨くため、より一層心がけていきたいなと思っています。

これらのエピソードについても、またどこかで書けたらなと思っています。こういった現場の最前線で最先端の開発をしたい方も募集しています!興味がある方、コンタクトください!ではではっ



サポートいただけると励みになります! よろしくおねがいします!!