今、システムエンジニアに必要な考え方は検討より検証

ITの世界はワタシが社会人になった頃の時間の流れを振り返ってみると、なんとも早くなったことか、とただびっくりするだけです。一方、これだけ技術の進歩が早い世の中になってしまうと数ヶ月前に始めたことが陳腐化しかねないという現実もあります。

業務と技術の時間が違う

ITを適用する、いや業務の一部をIT化するためにどの業務をどう機械化するかを様々なメンバを巻き込んで検討をするのですがこれがとても時間がかかる。１週間経っても全然進まない。

一方、ITの進化は勝手に進む。そりゃそうですよね。ITの技術革新は、特定の組織の業務を意識しているのではなくて、業務をソリューションする、つまり、課題解決するためにソリューションの提供だけを念頭に開発し、リリースしているわけですから。

ひっくり返して言えば、特定の組織の業務の課題解決のための技術革新ではないため、業務と技術の進度が違う、ということです。

配分を変える

そうすると最初っから、業務と技術革新の進度が一致しないこと、業務の課題解決をするために機会をプロジェクトとして持ったとしても、うかうかしているとあっという間に廃れた技術を採用するのかしないのかの検討だけをしていることになってしまう。

そうしないためにどうしたら良いか。

検討する時間を短くして、検証する時間に変えて行くのです。

検討する時間を短くするためには、仮説を建て付けるロジックをさっさと作ってしまうことです。１ヶ月かけていたとしたら、１週間以内で終わらせてしまう。その代わり、検証をして仮説が期待とおりかを検証するのです。

こうして時間の配分を検討に時間をかけるより、検証に時間を回す。もちろん、検証も評価ポイントを絞り込み、間違っていないかどうかの結果を素早く出すのです。

リスクと間違いを受け入れる

この進め方は、今までのように時間をかけて議論を重ねてというやり方を変えるわけです。今までは１００点を取ろうとして時間をかけていた。でも、それでは技術革新とのズレが大きくなるのでより効果的なITを使うために今までのやり方から方向転換して、取り組む必要があるのです。

そのために、検討で１００点を取るのではなく、６０点くらいをボーダーラインとして、それを超えたら検証に移るのです。

つまり、４０点はリスクとしてテイクしよう、と。そういう判断をしよう、と。で、喧騒して間違っていたら、早く進めるやり方をしているのだから、元に戻って検討の仮説を修正して２回目をやろう、と。

これは間違ってもいいとする考え方を取り入れるということです。ただ、間違ったままではダメで、解決する業務の課題は目標時期までに解決するというところは曲げません。