読者です 読者をやめる 読者になる 読者になる

「ソフトを他人に作らせる日本、自分で作る米国」が指摘する日本のITの課題

きたる2014年4月25日に、超高速開発コミュニティ第一回総会が開催されます。
http://www.x-rad.jp/

その記念講演として、日経BPビジョナリー経営研究所の谷島 宣之氏をお迎えしました。近著「ソフトを他人に作らせる日本、自分で作る米国」についてお話いただきます。

日経コンピュータや日経ビジネスなどで谷島氏の記事を読まれたというビジネスマンは多いと思います。かくいう私もその一人です。当日は直接、谷島氏のお話を伺える絶好の機会です。講演会は無料ですので、是非ともご参加ください。(なお、続く交流会への参加者へは、本書の贈呈もあります。これは超高速開発コミュニティからのプレゼントですので、お得です!)

ということで私も当日は交流会参加時点で一冊いただけるわけですが、実は総会に先立って購入しました。事前に読んで講演を拝聴するとさらによくわかるだろう...ということで、読後の感想を綴っておきます。

自分で作る(内製)ということの意味

"日本のソフト開発技術者の大半はIT企業に所属するが、米国は一般企業に所属している。" のは周知の事実です。今から10年以上前の経済産業省資料によると、日本ではソフト投資の内訳の七割前後が外注で、内製は二割弱、パッケージ利用が一割強となっており、現在もその比率は変わっていないと筆者は感じているそうなので、これを前提にします。

ところで "競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。" という筆者の主張には全く同意します。戦略的とは他の真似ではないものですから、事業部門と情報システム部門が試行錯誤しつつ開発することが求められます。明確な仕様が存在しない開発であり、もちろんパッケージソフトなど存在しません。そのような開発現場に、多段階発注(再委託)やアウトソーシングなどは到底、なじみません。その比率が低いということは何を意味するのか。つまり本書のタイトルが示す問題提起は、

日本は、競争優位につながるような戦略的なソフトの開発が苦手なのか?

と解釈できます。以降の章では、開国から現在まで日本が辿った足跡と、その時代に登場したさまざまな人物のコメントを織り交ぜながら欧米と比較し、どこでこの違いが生じたのか?を明らかにしようとします。戦艦大和や夏目漱石の講演記録など、日本人の多くが知ってる出来事を引用しながらの検証はわかりやすく、説得力があります。

日本ができない、ということではなかった

日本はハードウェアでは一矢を報いた形になっているものの、ソフトウェアでは常に欧米の後追いという印象ですが、本書には先見の明をもった日本の経営者、技術者の例も紹介されています。私が感心したのは、NTT初代社長であった真藤氏の次の語録です。

客先の要求が出るからパターンはできないというのは、バカの言うことである。逆にパターン・モジュールができているから、客先の要求は容れられないとつっぱねるのも、バカのやることだ。

ビジネスは顧客一極集中と、利益一極集中のはざまにあります。この解決には全体を見通す「グランドデザイン」が必要だが、日本はこれまで、この思考体系を学んでこなかった... 詳細は本書に詳しいので割愛しますが、見えている人には見えていた、ということです。そしてデザインを学ぶことは可能だが、実践するためには「強い思いとやりとげる意思」が必要です。ここで日本の「和を重んじ異端を排除する」文化とぶつかります。

欧米の "Collaborative" が日本で馴染んでいない

日本で「協調性」と訳される言葉ですが、欧米のそれとはニュアンスが異なる、ということを本書で知りました。日本では「おだやかに和をもって」と解釈されますが、欧米では「異文化をもつ他国や他社と協力し、優れた共同成果を出す」こと、とのことです。

日本では社会人になるまでの教育で、怒鳴り合いながらもお互いの意見の違いを認識し、その上で合意をとって前に進めるという経験を積ませることがほとんどありません。それは協調性がないとして減点されることもありそうです。意見の違いを際立たせるのは人格の否定につながるのではと恐れられます。しかし知的作業の現場では、意見は違うが彼は信頼できる、という関係性はありえます。

なぜ私が本書のこの説明(Collaborativeの解釈違い)に刺さったかというと、情報システムの失敗プロジェクトの原因の一つに、徹底した議論の不足があるのではないかという思いがあったためです。"品質は上流工程で作り込まれる"、"最初から不要なものはつくらない" という概念がありますが、その実現には部門の軋轢を超えた議論が避けられません。それをあいまいにしたまま(境界をぼやかしたまま)進めていって失敗しても、誰もその真の原因を追求することなく、スケープゴート(その多くは情報システム部か、請負業者)の責任となってしまうという例を何度も見聞してきました。

本書でそのように書いてあるわけではありませんが、谷島氏が示すさまざまな情報の切片がヒントとなり、私には「議論を尽くすという姿勢を貫く、トップがそれを実践し、部下を支える」ことができる企業が、システム内製化を成功させる重要な鍵になるという思いを強くしたところです。内製化というとプログラミングスキルが...という技術論になりがちですが、本質論はそこではありません。

この議論はコミュニティがカバーすべきもの?

私の中では Yes です。超高速開発ツールを導入したら何もかも解決、などと思ってほしくありませんし、各ツールの機能評価を○×することが自社成功の近道とも思っていません。ツールの選定ありきではなく、何のためにシステム内製に回帰するのかという構想を固めることが先です。そのきっかけを個々のベンダーの立場で行うのは難しいため、中立的なコミュニティが関わることに意味はある、と考えています。

25日の講演会、とても楽しみにしています。

Wagby開発スタッフ募集中です!