わからないことはうやむやにしない
プロ意識を持っている中堅以上のエンジニアであれば、決してわからないことをそのまま「わからない」と言って会話が終了するようなことはありません。とくに、日ごろから知識を自慢しているようなエンジニアは、たとえわからないことがあってもプライドが邪魔をして、人に聞くことができないのです。
何か知らない言葉が出てきたときには、その場ではわかったフリをして、後から自分で調べて納得します。専門的な業種についていながら、その専門分野について「わからない」と言わされることは、エンジニアリングを担う者としててプライドにかかわる恥ずかしいことだからです。
実はこれ、昔の私の話でもあります。
いや、今でもそうすることはあります。
こと「仕事」に限って言えば、「仕事」の一端を担う情報でありながら、それを相手よりも知らない…と言うことが、どれだけ後で不利になるか恐ろしくて仕方がありませんでした。今でもそうです。
当時の私は、打ち合わせのなかでわからないことがあると、終わってから自分のデスクに戻って一生懸命調べていました。もちろんそれでもわからない場合だってあります。日々の業務に追われ、いつしか調べるということ自体を忘れて、何がわからなかったのかということすら、うやむやになってしまうこともありました。
しかし、こんなことではお客さまが頭の中で思い描くニーズを、
正確に理解し、提供することなどできるはずがありません
今では、わからないことをわからないままにして仕事をするなんてことはまずありません。お金を払ってくれる「相手に対して失礼」ですし、「プロの仕事の仕方ではない」と思いますし、何よりそんなことで「失敗するなんて結果にしたくない」からです。
ですが、最近では表向き「わからない」とは言わないものの、実は全く分かっていない状態のまま適当な会話でその場を濁し、なし崩し的に「わからない」ことを放置して、プロジェクトを進行させてしまうような開発現場もあるようです。
お客さまはＩＴに淡い夢を見ている
多くのお客さまは、イメージからくる思い込みで、たいていの場合は真のニーズ以上に、「（あわよくば）これも欲しい、あれも欲しい」といってくることがあります。
お客さまは、やりたいことに対して漠然としたイメージしか持っていませんし、その要求の一つひとつがどの程度費用のかかるものなのかも知らないために「とりあえず言ってみよう」となり、そしてSIer側がハッキリと「できない」と言わないままダラダラと時間が経過すると、いつの間にか実現されるイメージだけが膨らみ、最後には「実現してくれないと困る」と言い出します。
要望が実現できるかできないか、どのくらい大変なのかを判断する知識を持ち合わせていない上に、その場で「NO」と言わなかったがために「できるかもしれない」と言う淡い期待を持たせてしまうことになり、うやむやのままに話が進めば進むほど、どうにかすれば実現できるものだと勘違いしてしまうからです。
ひと昔前、ＩＴシステムが「電子計算機」と呼ばれていたころは、導入しさえすれば、会社の売上も自動的に達成できるものだと、当時の経営者は本気で思い込んでいたくらいです。現在、60～80代でまだ経営者をやってらっしゃる方がＩＴリテラシーを持っていない場合、おそらくはSIer企業にとって、「最も嫌な顧客」の１つに数え上げられているかもしれません。
その世代やそれに近い世代が今でも残っていて、同じようにＩＴに対して過度な期待を膨らませる…そんなユーザーはまだまだいます。
当時、ＩＴ技術を導入するだけで、いとも簡単に問題が解決できると喧伝しているテレビＣＭのイメージも手伝って、ＩＴ技術は自分の希望を100％叶えてくれる魔法の杖だと勘違いしているユーザーは多かったのです。
私が新人になったのが90年代後半。それを考えると、ひょっとすると40代半ばあたりから既にＩＴに過度な夢を見ていて勘違いしているユーザーと言うのはいるかもしれません。
みなさんもこの業界に入る前には、そんな夢のようなことが（少なからず）できるものだと「一切思っていなかったか？」と言われると、どうでしょう。
ちなみに、私がこの業界に入った直後のエンジニアとしての将来の夢は
「アプリケーションレベルでドラえもんを作る」
でした。さすがにハードウェアまでは諦めてましたが。
しかし、そんなアプリケーションはまだまだ現代ではありえません（いや、そろそろ…ＡＩ（自然言語翻訳、画像解析）もそれなりにできてきてるし…アレ？ひょっとして…いけるのか？）。
「お客さまを見て、そして足元を見る」と、そこにハッキリ『道』は見えているか？
ただシステムを導入しさえすれば、あとは全自動で「経営」戦略を算出することができ、放っておけば売上や利益が勝手に上がっていくのであれば、経営者なんていらなくなってしまいます。
こうしたお客さまの間違ったイメージを修正して、
「経営のどこにＩＴを活用するのか」
「どこに予算を使うべきなのか」
お互いに理解してから構築すれば、普通は問題なんて起きません。
ところが、実現できるかわからない難しい要求仕様を、プロジェクト担当者が正確に理解することを怠り、うやむやの状態で現場に下ろすとどうなるでしょうか。
現場も、実際には難しすぎて本当はわからないのに、「言われたことを言われたとおりにすればいい」と言う姿勢で、自分で考えることを怠り、スケジュールを理由に適当に作ってしまい、一見動いているかのように見せかけたシステムを組んで納品しようとしてしまいます。
当然、ユーザーの要望とまったく違うものができてしまい、「こんなはずではなかった」というトラブルを引き起こす原因になります。
銀行や通信会社、航空会社などで起こるシステムダウン等のトラブルは、このようなことが原因で起こることが多いと言われています。現場の利用シーンが全くイメージできず、また長年培われたきた現場の複雑怪奇なルールや手順などを紐解くことが難しいという背景もあるのでしょう。
お客さまを見ようとせず、お客さまを知ろうとせず、お客さまのニーズを満たそうとせず、ただ「モノを作るだけ」に執着する開発チームになってしまうと、こういった問題にぶつかってしまいます。
「時間」を味方にしないと間違える
本来なら、難しくて理解できない仕様や要求を受け取ったエンジニアは、自分で調べたり、お客さまに聞いたりして実現の可否を判断し、実現できないような仕様なら、早々にユーザーにそのことを伝え、再考を促すべきです。
中でも、こと『仕様』に限って言えば、
時間が解決してくれるなんてことは絶対にありません。
むしろ、時間の経過は『敵』です。「YES/NO」を言わないまま、時間だけが経過すればするほど、「なんとか実現するために努力してくれている」と誤解し、お客さまの期待とイメージは高まり、最後には「実現してくれないと困る」と言い出すようになるでしょう。
うやむやなまま放置し続けた開発チームは逃げ場を失い、より大きな苦労を強いられ、難解な仕様に着手させられ、著しい品質の劣化を招くと言う負のスパイラルに陥る可能性も出てきます。
マネージャーの視点から見た場合、見積りや受注のタイミングで、まだまだニーズが明確化されていない時期に、「わからないことは、追々詰めていけばいい」と思って、優先度や重要度、影響度などをまったく計ろうとしないでプロジェクトを進行したりはしていないでしょうか。
また、一人ひとりのエンジニアの視点から見た場合であれば、「プログラムに実装する機能」の要否にばかり傾注し、システム構成に影響を与えそうな特殊なニーズや信頼性設計に関係してきそうな事業背景などについて
「お客さまの内部のことだから」
「ソフトウェアのことしかわからないし」
と言い訳して、「誰かがやるだろう」「自分の仕事じゃない」なんて考え方で放置しっぱなしにしていることは無いでしょうか。
自分はわからない、誰かが知っているはず。
自分の仕事じゃない、誰かがやってくれるはず。
「誰が？」
「自分ではない誰か」でありさえすれば見て見ぬ振りをするから、課題や不明点がいつまで経っても解決しないまま、システムテストなどで実際に利用するシチュエーションを想定する頃に、想定外が発覚する…なんてことは実際によく起きています。
システムを取り巻く背景を知らないと起きる問題
たとえば、これから構築するシステムに対し、
利用する人数
利用する頻度、時間帯
操作する人のスキル
操作する人が必ずしも業務についての有識者ではない可能性
こういったところにリスクの有無がないかを想定し、見定め、慎重に設計しなければ、実装した機能とは全く関係ないところで、問題なんて簡単に起きてしまいます。しかも、こうした情報は「お客さまからたまたま能動的に提供された」…なんてことはまずありません。
2011年3月末頃、東日本大震災の直後に振り込みができなくなるトラブルがありましたね。
理由は、
『特定口座に、想定以上の振込件数が集中したから』
でした。こうした問題は利用背景を知ろうとしなければけっこう簡単に起こすことができます。一般的に、データベースで管理される情報は、保存するストレージ許容量の制約もあって、桁数などのサイズが細かく定義されています。
たとえば、ある「金額」の項目が10桁の制限を設けられていた場合、99億9999万9999円までしか入金することはできません。もしも11桁の数字を無理に代入しようとすると、桁あふれを起こしてしまって、エラーになるか、おかしな値になって進行し、業務上の問題になるかのどちらかが起きます。
これはコンピューターを使う上での絶対的な制約です。
通常、開発する側は、常に利用シーンとして起こりうる最大値（＋α）を想定してサイズ設計を行います。もしも「10桁までしか利用されない」と想定していて11桁以上の入金があったのであれば、それは「開発当初の想定根拠が甘かった」か、「運用期間が長すぎて、時代の変化に対応できていなかったか」のどちらかです。
記事の中では、「想定以上の」と説明されていますので、おそらくは前者だったのでしょう。利用シーンとして起こりうる最大サイズ（＋α）が想定されていたはずですが、それでも許容できなかったということは、つまり、
利用シーンをイメージする力が無ければ、
まともに設計することすらままならない
と言う事態になってしまっていたのでしょう。こういう問題を起こさないようにするために、お客さまに色々と根掘り葉掘り聞きだす工程、『要件定義／要求定義』があるわけですね。そこで、わかっておかなければならない情報の管理と、その情報がいつまでに分かるようになっていなければならないかをコントロールできていれば、おそらく事故は起きなかったかもしれません。
わからないことを、わからないままにして、うやむやにプロジェクトを進めるようなことはしないようにしましょう。時間を味方につけ、知らないことは知る努力を行い、早々にハッキリさせることでのみ、こうしたリスクは低減できるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。