「ソフトウェア・ファースト」を読んで③
以下の記事の続きです。
デジタルネイティブ企業に本気で対抗していくには、DXを単なるブームとして終わらせてはなりません。「第2の創業」に近い意識で臨まないと、何も変わらない可能性があります。蓋を開けてみたら新しいITツールを導入しただけ……とならないようにしなければなりません。企業として生き残り、社会変革を成し遂げていくには、経営陣を含む全社員の考えや動き方が変わり、組織文化や制度もその変化を継続させるものに進化させなければなりません。それが結果としてソフトウェア・ファーストな企業に生まれ変わるきっかけになるはずです。
たしかに、DXを進めるというときに、ツール導入という手段が先行しがちかもしれません。
WhyからWhatを考えるというのは、組織変革にも重要なことですね。
手段に飛びついてしまうのは、ツールが魅力的だったり成功事例を見聞きするかと思います。
しかし、ツールの性能を最大限発揮できるように、ツールをつかいこなせるかどうかは別の問題です。
また、事例をそのまま模倣しても、「仏作って魂入れず」になりがちです。なぜそれが成功したのか、なぜ他の手段ではダメなのかという理由がわからないと、次に取り組みにつながりません。
ここで言うレガシーシステムとは、「自社システムの中身が不可視になり、自分の手で修正できない状況に陥ったこと」と定義されています。そうなってしまった原因は、マネジメントの問題が大きいでしょう。経営陣にITの価値を理解している人材がいないため、適切なメンテナンスを怠っていたり、システムの開発・運用をパートナー会社に一任してきたケースが多いのです。そのため、開発ノウハウが自社内に蓄積されないという問題が起こっています。
外部に委託する場合も、作ったシステムを社内のだれがどうメンテナンスするのかまで設計する必要があります。
また、委託時にも、システムを理解して設計書を社内で作ることが大事です。
なんとなく、やりたいことを日本語で伝えるだけでなく、システムの仕様を踏まえて、なるべく具体的に抜け漏れなく指示をすることが外部に委託する際は重要です。
自社システムの中身を理解するための第一歩目はそこからという気がします。
それができてきたら、徐々に社内でエンジニアを抱えて、コミュニケーションを取りながらシステムの理解を深めて、システム要件定義書を作ったりコーディングトライしたりするのが良いのではないでしょうか。
DXのような新たな事業を興す時は、仮説検証を行うスピードと、企画から運用まで一気通貫のIT活用が必須になるからです。
外部に委託すると、企画と開発・運用が断絶しがちです。
委託したビジネスサイドの人がやりたいことと、受託した開発サイドが理解したことに乖離がどうしても出てしまいます。
言語化されていないコンテキストを共有しきれないことが問題と考えます。
企画側は考えていること、やりたいことをいかに言語化・ビジュアル化するかが重要です。
それは内製であっても外注であっても、同じ問題かと思います。
仮に外部パートナーを活用するとしても、ITの企画、設計、実装、運用というすべてのフェーズを自らコントロール可能な状態にすること、つまり手の内化していくことが大事なのです。それこそが本書で提唱しているソフトウェア・ファーストです。
そのためには、失敗を恐れずに学習の機会ととらえて、学習し続ける姿勢が必要かなと考えます。「IT」「テクノロジー」と聞くだけで「自分にはできない、難しそう」と思うの人が多そうです。
学習や外部への委託については以下の記事を書きました。
新しいことへのチャレンジと、学びへの投資が大事ですね。