これを読んでいただいている方に、まず最初に知っておいていただきたいことがあります。
私はITが苦手です！
そんな私だからこそわかる、ITがわからない人の気持ちを紹介します。
私がどのくらいわからないか
ITが苦手と言ってもどのくらい苦手なのか。正確に言うと、もともと全然知識もなく、チンプンカンプンの状態でした。スマホを使いこなんて全然できず、ましてやそのアプリケーションがどうやって作られているかなんて考えたこともなかったです。学生時代に必修となっていたC言語でも、
t = t + 1
「？？？・・・」まったく意味が分からず、それ以上は先生におんぶにだっこで、単位だけはとりあえずもらった過去があり、それ以来何も進歩していませんでした。
今では、これまで仕事を通じて少しずつ勉強し、ようやく何となく変わってきているかもしれない。簡単なフロー図と機能一覧くらいであればたたき台くらいは作れて、主に画面構成や画面遷移などの外部設計であれば、会話ができる。というレベルです。
ですので、ソフトウェアを開発することはできませんし、言語も知りません（こちらも過去にJavaにチャレンジしたことはありますが挫折しました！）。ExcelVBAも自力ではほとんど書くことができないため、実際に書けと言われれば、その都度Googleで調べながら書いています。
ただ、ものづくりの世界にいる人は、私みたいな人けっこういるのではないかと思っています。
※そんなことなかったらごめんなさい。
要件定義ってなに？
ソフトウェア開発において最初のフェーズでもある”要件定義”。この要件定義の意味がわかりません。
「要件を定義するんだろうけど、要件ってなんだ？何をしたら定義ってことになるんだ？」
というのがわからない人の気持ちです。わかっている人にこの質問をすると、
「え？！要件というのは、、要するに要件のことで、、それを決めるフェーズのことです。」
的な回答になるのではないかと思うのですが、わからない人にとってはそれでは全くわからないんです。
「要件定義したものを見せて？」
となると、
「フロー図がこれで、機能一覧がこんな感じで、こういうものをまとめて開発を依頼するものをRFPにまとめるんです。」
と返ってきます。そうすると、まぁわからないことも半分以上はあるかもしれませんが、
「あぁ！流れと機能とソフトウェアに求めることをまとめることね！」
という理解をします。ここで既に間違っているので、実務の担当者は業務を再設計しなければならないことには気が付いていませんし、どんな場面でどう使うかを具体的に考えなければいけないこともわかっていませんし、そもそも、ソフトウェアを開発する目的は何なの？という感じで置き去りにされてしまうんです。つまり、ソフトウェア開発において最も重要ともいえる業務要件定義がおざなりになってしまう現象が起きるんです。
機能ってなに？
さて、何となく理解したつもりになっている実務担当者は、ソフトウェアでやりたいことを書き出してみて、それ元に機能一覧を作成しようとします。このアプローチはその通りなんですが、ソフトウェア開発のことがわからない人は、この機能一覧の作成で苦労します。それは「機能」の意味が正確に理解できていないからです。少し言葉を変えると、業務的な意味での「機能」と、システム的な意味での「機能」意味が少し違うんです。
業務的な「機能」とは、『果たすべき役割』のような意味で使われることがほとんどです。そんな人が機能を書くとどうなるか。
「アイコンをクリックすると一覧表が表示される機能」
「製品名を入力したら、関連情報を見ることができる機能」
「結果の数字をクリックしたらグラフが表示される機能」
こんな機能が並びます。エンジニアから見ると「はぁ？！」って感じかもしれませんが、現実そうなります。いわゆる「機能」という簡単な言葉のような認識のズレは実は非常に大きく、エンジニアと業務担当が要件定義でのディスカッションに時間をかけなければならない大きな理由の一つがこれにあるとも思っています。
開発ってどういう意味？
ところで「開発」って何のことを指しますか？
と言われた場合、エンジニアの方は「プログラミング」や「コーディング」と答えるでしょう。つまり特定の作業のことを指している感じがします。ITがわからない人は、実はこのニュアンスを知らないので、要件定義も設計も開発もテストもすべてをひっくるめて「開発」だと思っています。
なぜなら、特にものづくりの世界では、企画・設計・生産準備の量産に至るまでの工程をひっくるめて「開発」という言葉を使うからです。
ですので、打ち合わせ中に「開発」という言葉が出てきたら、認識の違いがあるかもしれないという心づもりでいたほうが良いでしょう。
その単語、どういう意味？
データベース、アーキテクチャ、コンポーネント、スキーム、、、
ITの用語はカタカナ語が多いです。海外で技術が発展してきたので当たり前ですが。このカタカナ言葉、ITを知らない人には全然通じないんです。日本語と英語くらい通じないです。逆の関係で例えると、ものづくり（例えば射出成形）を知らないITの人にとって、バリ、ヒケ、シルバー、ジェッティング、、、の意味がわからないということと同じです。
最初に、このカタカナ言葉を浴びせられると、
「ムリムリムリムリ！勘弁して！」
ってなる人が多いのがものづくりの世界の人です。現場に寄り添えば寄り添うほどこうなります。しかも、当たり前のように話されるので、わからなかったとしてもなかなか聞きにくいということもあります。
可能な限り、易しい言葉を使うことを心掛けなければいけません。
結局なにがほしいの？
要件定義のフェーズは非常に重要ですよね。業務のプロセスを明確化してソフトウェアに必要な機能を洗い出していくフェーズなので、ここで仕様がほぼ決まるわけですから当然です。
ところが、先ほどの機能一覧の例ではないですが、エンジニアに対して何をどんな形にして出して良いのかがわからないんです。例えば、まずフロー図を作成してインプット/アウトプットがわかるようにしてほしいとします。でもこの説明では、どんな形のものにしてほしいのかわからないんです。まず、基本となるフロー図をきちんと描ける人はいないと思ったほうが良いです。ちなみに、ひどい人は（私）はマンガ絵のように描く人もいます。機能一覧も先ほどの例に対して、
「ソフトの機能としてわかる一覧表を書いて」
と言われても、
「ソフトの機能ってなんだ？表示と入力以外に何かあるのか？」
というような感じで、書くことができないですし、フロー図も含めてどんな形でどんな内容が書かれているものがほしいのかがわからないんです。
わからない人を見下してない？
そうこうやり取りしているうちに、エンジニア（そもそもものづくりの技術者もエンジニアって言いますね。。。）の立場からすると、
「こんなこともわからないの？」
「教えてるだけでものすごい工数取られる！」
「納期は守らないといけないの？」
「費用は変わらないの？」
というフラストレーションの蓄積されることもあり、だんだんお客様であるはずの普段接する相手に対する態度が高圧的になっていきます。
こうなると、ものづくりの世界の多くの人は、
「IT屋さんって頭いいのかもしれないけど感じ悪い。。。」
「もうこっちはわからないから、適当にお願いします。。。」
となってしまい、協力することにエネルギーを割きたいと思わなくなってしまうんです。そうなると、要件も抜け漏れなくまとまることは難しくなりますし、ある程度出来上がってきて仕様を凍結したにも関わらず、
「これじゃあ使えない」
「もっとこういう機能を追加して」
と、次から次へと追加要求ばかりが増えて、納期は変わらず、予算も固定化されていて追加費用もなく、システム開発もムリな工数で対応しなければならない。
これが、7割はうまくいかないと言われる業務系ソフト開発の悪循環の正体です。
じゃあどうすれば？
私なりの答えは一つです。
お互い歩み寄りましょう！
お互い、生業としている技術や背景は異なります。まずはお互いが異なる場所で過ごしてきたことを肯定して、その上でわからないことが蓄積されていくことなく、進められることが理想です。
そのためには、エンジニアの方は、相手の業務がどんなことをしていてどんな技術が必要なのかを勉強するように努めましょう。同様に、ものづくりの世界の人は、システム開発にはどんなことが必要で、自分たちからはどんな情報を提供しなければならないかを勉強しましょう。システム設計領域までとは言いませんが、要件定義ではどんなことが必要なのか、近年では本もたくさん出ています。また、これからのものづくりの世界も、IT活用無くしては進歩はありません。要望ばかり押し付ける体質から脱却しましょう。
本来の「なぜソフト開発が必要か」という目的を明確にしておき、担当者間でのコミュニケーションを図りながら、関係者が同じ目的に向かって仕事をする。そうすればモチベーションも高まり、勉強もできて、出来上がったシステムにも満足できる。そんな正のスパイラルに乗って開発出来たら良いですね！
とはいえ、ものづくりの現場も日常業務に追われてなかなか新規のシステム開発に注力する環境が整わないことも現実としてあります。その際には多少の費用をいとわず、コンサルタントにお願いすることも有力な選択肢の一つであると思います。大きな費用をかけて使えないシステムを作るのであれば、リスクヘッジとしてコンサルタントにも費用をかけ、結果、完成度高いシステムで効果を出していく方が良いに決まっています。
ぜひ、私のような人材を活用しましょう！
※最後は宣伝になってしまいました（笑）
