ＩＴ企業の業務ハック
以前、こんな問題ありましたよね。
どこのSIerが作ったのかは知りませんが、１８億円もあれば他に何ができたのかと…。
サイバー攻撃などからの情報の漏えいを防ぐため、およそ18億円をかけて開発された国の情報管理システムが、運用を始めてから２年間一度も使われず廃止されていたことが会計検査院の調査で分かりました。
（中略）
総務省は「検査を受けている最中なのでコメントできない」としています。
とありますがその後どうなったんでしょう。この検査。ある種、公金横領と言うかなんというか、他人のお金を預かって無駄にしたという事件なので、責任者どうしろとかではなく再発防止をしっかりしてほしいものです。
さて。
年々重税感が増すにも関わらず、その集められたお金が無駄に消えていくのは誰しも許せないと思います。理由は何しろ、使わないものに大金を投入したのですから、その反省はしっかり行われるべきです。
しかし、国にばかり問題があるわけではありません。
このような無駄なＩＴ投資が行われる背景には、関わるベンダーやSIerの
お客さま目線になっていないことや、
業務に対する理解意欲が乏しい
という現実があるからに他なりません。大半の反応を見ていると、ユーザー側（この場合は政府のお役人）がＩＴ音痴で、無茶な仕様を並べてSIerに作らせたからこうなったという意見が多いようです。対してSIer側としてみれば、要件通りに作って、しかも政府側に検収された（納得して受け取られた）のだから、何の落ち度もないと言ったところでしょう。まぁ、詭弁ですけど。
しかし、ビジネスであり契約によって行われたものですから、ある一方向からだけで見ればそれは間違いありません。一方で、このシステムを作った後の運用や業務の観点からベンダーやSIer側は未来を見抜けなかったのでしょうか？
きちんと利用目的や利用用途を理解できていれば、あるいは具体的な使われ方を想定できていればこんなことにはならなかったのではないでしょうか？
無駄なシステム開発を受注して
自社が潤えばそれでよかったのか
結果残ったのは、ベンダー／SIerに対する信頼の失墜ではないでしょうか。「彼らは「言った通り」にはやるけれども、ユーザーの利まで考えているわけではないんだ」と思われてしまったのではないでしょうか。ユーザー側は次回発注するときは、SIer企業のことをそういう風に見て判断するでしょう。
こんな国民の血税から18億円もの無駄システムを発生させてしまう前にこの未来を予見し、SIer側がユーザーをリードし、無駄金を発生させない努力をすることが、引いてはSIerもユーザーも生産性の高いシステム構築ができるのではないでしょうか。
こんな記事を見かけました。
「難しい事を難しくしか語れない技術者が多い。技術者なのに、なぜ素人に分かるように説明できないのか。難しい事をやさしく説明するのは、専門家としての深い知識が必要だ。反対に、難しく語るのは少し勉強した素人でもできる。だから難しい事を言う技術者は素人（他の分野の専門家）からばかにされる」
まぁ実際には技術者だけでなく、特定の領域を専門的にしている人たちはそんなもんです。狭く、鋭く、尖って極めていくスペシャリストたちは、広さを持たないがゆえに、他の領域、他の業界の人たちとの会話の知り方を知りません。
よく「強みを活かせ」「１つのことに集中しろ」なんていう人がいますが、私は賛同できません。弱みの部分が与えられた業務で必須だった場合、どんなに強みを生かしてもビジネスでは上手くいかないことがあるし、必ずしも強みだけを見て配属や割り振りをしてくれる企業ばかりではないからです。特に日本の場合はそう。強みだけに集中させてくれる企業なんて極稀です。
きちんと説明できないことで、ユーザー側のＩＴリテラシー不足を補うこともなく、この無駄システムを生み、18億円の売上をベンダーにもたらしたものの結局はベンダーへの信頼失墜につながったのではないでしょうか。目の前の18億円は大切なのだと思いますが、それと引き換えに失ったものは小さくなく、将来的に、そんなことをしてきたエンジニアはどれだけ機会損失を今後産み出すかはかり知れません。ベンダー側にも反省すべきことはあると思います。
ちなみに。
たとえばですが、公共入札されたプロジェクトはSIerの社名や金額まで公開されているので隠していてもバレます。官報でも載りますしね（読みにくいけど）。
落札価格が18億だったのか、最終的に膨れ上がった金額が18億だったのかは知りませんが、一生残るデータであることは間違いありませんね。
ＩＴ企業に入ってくる多くの学生は、仕事内容の多くに「プログラミング」を強くイメージします。そして入社してしばらくはプログラミング、または実装されたプログラムのテストに関わらされます。だからますます「プログラミング」が仕事の中心として植え付けられていくことになります。
しかしある時を境に、急に設計をするように言われ、必要に応じてお客さまの前で説明を求められることだってあるでしょう。ある程度経験を積むと何を教わるでもなくリーダーを任され、さらに実績をあげるとよくわからないままマネージャーに任命されるようになります。
ですが何一つ学ばないまま昇格していくので、心の中ではいつまで経っても「お客さまがどう満足するか」「本質的な課題は何なのか」といった顧客満足脳ではなく、「なにを作るか」「どう作るか」を中心にしたプロダクト脳のままです。
プロダクト脳のエンジニアやマネージャーは、プロジェクトを進めるにあたって、常に
「なにを作るか」
「どう作るか」
と言ったことしか考えられません。
打合せをするのは「作るモノ」を決めるため。
課題管理をするのは「作れる」ようにするため。
ユーザーの要望や回答がなかなか得られなければ「早く回答（仕様）くれないと、作ってる時間なくなっちゃう」と言ったように、頭の中では常に「作る」と言う発想しかないのです。まるで「作る」ことが契約で求められた仕事であるかのようにふるまいます。
そして正しくマネジメントを行えないマネージャーは、品質も、コストも、そしてユーザーのニーズもそっちのけで、期日内に作れるかどうかの
"スケジュール管理"
ばかり気にします。
ですが、私たちＩＴ企業の本質はそうではないはずです。私たちに引き合いをくれて、注文してくれるユーザーたちは、今目の前で困っている"何か"問題／課題に対して、
ＩＴならば、解決してくれるはず
と思って、私たちの業界や企業に仕事を持ってきてくれているはずです。そうでなければ私たちに話を持ってくるわけがありません。あくまでも「解決」が目的であって、言われたら言ったとおりに作るだけのロボット的な仕事をしてほしいわけではないはずなのです。
・目的が「解決」であること
・リテラシーにおいては私たちＩＴ業界の人よりも劣るユーザーであること
この２つを念頭に入れて、そのうえでユーザーの要望を最大限叶えるのが私たちの仕事です。後者の条件がある以上、ユーザーが主導的に開発を誘導してくれるとは考えにくいはずです。自分たちの業務を「現状から、理想へ」と言う話はいくらでもしてくれると思います。
ですが、ユーザーはＩＴリテラシーに不安がある以上、より具体的な要望であればあるほど、そのまま鵜呑みにするわけにはいきません。むしろ、よほど詳しい人でもない限り、要望はふわっとしているはずです。
私たちベンダー側の人間は、そのふわっとした要望をくみ取り、且つユーザーの業務や背景を理解し、時に指摘し、時に提案して、本当に求めているニーズを実現するのが仕事だったはずです。私たちの仕事は、ひとことで言えば
「実現」「改善」「改良」「解決」
です。そしてその結果として求められているのは、効果の最大化です。実現効果の最大化、改善効果の最大化、改良効果の最大化、解決効果の最大化、いずれかに相当する成果をあげると言うことです。いわば"業務ハック"することが求められているわけです。「作成」でも「実装」でもありません。それらは、上記の仕事を行う上でのただの手段でしかないのです。
そのことが理解できないエンジニアは、遅かれ早かれ淘汰されていくことでしょう。今のご時世、ただ作るだけだったら、自動的にやってくれるツールやサービスもあります。だからこそ、エンジニアには、そんな安直な対応や姿勢は求めていないということを、知っておいてください。
そうした労力のために、家が何軒建つのかわからない金額をポンと支払ってくれるのです。
18億…その額を捻出するために、いったいどれだけの人が汗水流して働き、納めたのでしょう。少なくとも生活が苦しくなってでも納めたソレ（税金）は、ただ廃棄するためだけに作られ、消費されたわけです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。