「強み」が「弱さ」になってしまう時に
敬愛する齊藤昌義さんのITソリューション塾ブログに「弱み」を「強み」と思い込んでいる残念な人たち、という記事が掲載されました。
https://blogs.itmedia.co.jp/itsolutionjuku/2021/10/post_974.html
|
齊藤さんは文中で、『社会学者のエズラ・ヴォーゲルが、「ジャパン・アズ・ナンバーワン」を上梓したのは、1979年だ。日本はバブルの絶頂期にあり、多くの日本企業が世界の頂点でしのぎを削っていた。「失われた30年」と言われながらも、こうやって、いまの日本が世界でそれなりに評価されているのは、そんな時代の遺産に過ぎない。そして、そこで働く人たちのマインド・セットも、そんな時代を引きずっているとすれば、なんとも残念なことだ。もはや、世の中は、かつて日本が輝いた時代とは異なる競争原理で動いている。その流れに乗り移ることを考えなくてはいけない。』（引用ここまで）、と檄を飛ばしている。本当にそう思い、考察してみることにしました。 |
KEY QUESTION＞
「強い」技術力を発揮して市場にイノベーティブな価値を届けたい。ソフトウェアファーストの時代だから自社の「強い」ソフトウェア開発力を市場で発揮していきたい。イノベーションを連発するソフトウェアカンパニーに憧れる日本企業の「強み」はなぜ「弱い」のだろうか。
CONCLUSION＞
「強さ」の自覚は慢心と自信過剰につながる停滞の罠だ
日本ではソフトウェアといえばプログラミングだ、ソフトウェア工学だと勘違いしているので、ソフトウェアなんて書けばなんでも書けると思っているようです。現代のプログラミングの相当部分が最新のフレームワークと計算科学に基づいたライブラリーで構成されている分業体制であるということに気づいてはいないようです。アプリケーションプログラムであっても、最新のミドルウェアやデータベースが提供する並列性や分散処理を考慮に入れなければ、最新のハードウェアの性能を活かすことはできません。シングルスレッド時代のプログラミングテクニックをそのままアプリケーションに適用してもソフトウェアの最適化は行われません。プリプロセッサやJITコンパラー、アプリケーションフレームワークが最新のハードウェアを使いこなすために最大の努力をしているのだけれど、オープンソースなんて素人集団は信じられないとか、自分たちのソフトウェア工学は世界一だのと言って採用せず、自分で書いてしまう。ひどい時にはシングルスレッドのC言語のプログラムとJavaのJITコンパイラーの実行速度差とか言って（もう、こちらは聞く気もないけど）どうでもいいようなことでなにがなんでも拒否してしまう。確かにそれだけのコードボリュームを職人芸で書き切ることができるのは素晴らしい能力なのですが、その慢心がマーケットのベストオブブリードを学び本質を獲得する努力を阻んでしまっています。
あるプロジェクトでSOAに則って再利用性の高い柔軟なシステムを構築するという課題がありました。先輩のESBの世界的大家に同行して、システムを受注したシステムインテグレーターのアーキテクトとのSOA ESBの詳細打ち合わせに伺った時のことです。WEB Serviceの相互接続のためのSOAPライブラリーやWSDLのダイナミックオーケストレーションなどのミドルウェアを示しながらESBの接続プロトコルの説明を終えた後のことです。件のアーキテクトは「今回のシステムでWeb Serviceは用いない。IIOPで接続するのでESBはルーティングだけ行えば良い。あとはアプリケーションで処理をする」という。SOA以降の皆さんにわかりやすく言うと、gRPCの時代にソケットプログラミングでカスタムフレームをやり取りしたいというような前時代的な話をしているわけです、、、（BSCに逆戻りかよ）。呆れた先輩は日本人にはSOAは早すぎるんだね、といって帰国して行きました。私も現場を離れ、その後そのシステムは完成したようなので、確かにソフトウェアの生産能力は高いのだろうと思います。しかし、多分SOAが目指していた柔軟性も拡張性も得られることはなく70年代と同じくらいの安定度のシステムができあがったことだろうと思います。しかし、ハードウェアやネットワークは最新なのでトランザクションレートは高く、まるで軽自動車のシャーシにF1のエンジンを突っ込んだような運転しにくい怪物システムになっていることだろうと思います。
ロボットや自動車などのハードの世界でも同じようなことが起こっていると思います。「ソフトウェア」にも対応できているといいながら多くのプログラムがラダー型シーケンサーの世界で、ハードウェアリレーを焼き直して「小さく安く」作っているにすぎない（ソリッドステートなので安定してるのは認める）ものだったりします。最新のアーキテクチャによるソフトウェアモデルを実装するよりも手慣れたマイコンプログラミングで機能を実装できたらよいのだ、と割り切ってしまうのです。ここでも前出と同様に最新のハードウェアの並列性や多様なチップを組み合わせたSoC性能を生かしたプログラミングモデルを無視してシングルスレッドで比較した「リアルタイム性能」などが理由で進化を拒んでいる事例も多いように感じます。また、インターネットに接続され相互接続されるプログラミングの世界では、機能を超えた新しいアイデアやユーザーにとって魅力あるエクスペリエンスが求められています。さてここで、簡単に相互接続と聞き流してはいけないと思います。ネットワーク科学（ほどのことじゃないですが）では接続されるノード数のおよそ二乗の接続リンクが存在し、インターネット上の無数に存在しているノードとの相互接続にはこれまでのマイコンプログラミングとは比較にならないほどの接続リンクを取り扱わなければいけないのです。こうしたプログラミングはこれまでは経験したことのないインターネットバイデザインのアーキテクチャであって、モノを中心に設計してきたマイコンプログラミングからサイバーファーストなモダンプログラミングへの進化が見られるべきではないでしょうか。
昨今のプログラミングパラダイムの一番大きな変化は、多様性です。オープンソースプロジェクトでは（偉い人たちは素人集団といいますが）数百人からのコントリビューターが様々なアイデアや実装を試しています。これまでとの違いはその多様性で、大学でまだ学んでいるばかりの理論を持ち込む学生から、情報工学や数学のPh.Dの研究者や、彼らのコードをリファクタリングするコーディングのプロフェッショナル、テストマニアなどが一つのソフトウェアの進化を支えています。私が携わったプロジェクトでは、全体で千人以上で１つモジュールだけでも250名のエンジニアがコントリビュートしています。多くの研究段階のコードは品質的に本番には向かないことが多いのですが、オープンソースではそのコードの進化は早くて驚くべきスピードで最新理論の実装が進んでいきます。企業内で大規模プロジェクトを実行するのに集められる同質な250人のエンジニアにはないダイナミズムが生まれています。こうした事実に目を背け、これまでの「強さ」にすがっているのが今の日本のソフトウェアの実情ではないでしょうか。
RECOMMENDATION＞
「強さ」を武器に。
最先端のソフトウェアはアーキテクチャ構造が重要です。スピードやコストというこれまでの価値観を、生産性や多様な処理の並列性などの新しい価値観に入れ替える勇気を持ちましょう。最先端のソフトウェアが求める本質的な価値を（従来価値と比較するのではなく）発見しましょう。アーキテクチャ構築能力を手に入れて、協働的なソフトウェア開発のための共通言語を身につけましょう。そうすることで、これまでの高品質で高性能なソフトウェアを確実に開発することのできる「強さ」をモダンなプログラミングパラダイムに活かすことができます。いままでのやり方のコストダウンや高品質という価値観を新しい若いプログラマーに教えないでください。「先輩に習うな」とは私が前職で学んだことです。先輩の方法は簡単そうに見えますが「強さ」の罠がいっぱいです。先輩の命令は無視して自分のやり方でやってよいのです（失敗もしますが、今は失敗は歓迎される傾向ですからw）。自ら研究して、先輩には（対等に）疑問をぶつけましょう。このような企業文化を醸成することが「強さ」を「弱み」にしない秘訣ではないでしょうか。
