「ITエンジニアやIT業界の住人」を、情報処理技師の略で「情技師」と呼びます。
「非ITエンジニアの人々」を、非情報処理技師の略で「非情技」と呼びます。
非ITエンジニアの安易な意識
最近、新元号対応やサマータイム対応などでシステムの改修を「非情技」の人々の一部は非現実的なほど簡単に考えていることが公になったと思います。
SIer業界の中では非情技の顧客が無茶な仕様変更を考えなしで要求してくることは良くあることなのでさほど驚くことではないかもしれないが、今回の件は非情技の人々がシステム開発や改造というものに無知で簡単に考えていることがよく分かる事件だった。
新元号対応は期日までにシステム対応不可能で平成をしばらく使用し続ける。サマータイムは実施不可能だろう。
社会は広範囲でシステム化が進んでおり、もはやシステム改修無しでは制度改正も出来ない時代になっている。
しかし、一般の人々のシステムに対する意識は低く、相変わらず「システム開発(改造)なんて簡単だろ!」という意識が大半を占める。
2000年問題の時は金融業界だけで4500億もの費用を掛けて対策したという。期間も6年ほどかけている。
この時、特に問題が起きなかったためか、「2000年問題なんでIT業界が金儲けの為に仕掛けた詐欺なのではないか?」というかなり現場で苦労して対応した情技師を侮辱するような声も実際聞こえていた。
情技師の中からは「何もトラブルが起きなくて当たり前。ユーザーはそれが当たり前だと思っていて、そこに多くのエンジニアのリソースを投入しなければならないことも理解できない。だったらいっそ情技師はサマータイムのような仕事を皆断って、トラブルが起きても放っておけばいい。そうしなければITシステムの重要性を一般の人々は理解しないだろう。トラブルが起きて初めてITシステムの重要性を理解できる」という厳しい意見も出てきている。
実は私もこの意見に賛成だ。
どう考えても不可能であったり、苦労のわりには便益の少ない無駄なシステム開発や改修は情技師が断るべきだ。
それでユーザーが損失を被ったり、社会機能の一部が機能しなくなってもそれは、無茶なシステム改修計画を立てた権力者が悪いのだから権力を持つ責任者が責任を取れば良い。
また、安易なシステム改修を要望したユーザーも自ら損害を被るべきだろう。そうでもしない限り非情技の人々が意識を変えることはないと思う。
見えないものは存在しない?
日本人は昔から目に見えないものの価値を認識するのが苦手なところがあります。
これは日本人全てではなく、どちらかと言うと社会的地位の高い権力者が理解しないのかも知れません。
近代化が始まって無線電信が輸入されたときモールス信号を日本語に当てはめました。英語のアルファベットでは文字の出現頻度を計測し出現頻度の高い文字は少ない打刻で頻度の低い文字は多くの打刻で信号を表すように文字を割り当て、打刻回数を最小限にする工夫をしていたそうです。
これに対して日本では文字の出現頻度は考慮せずにモールス信号に文字を割り当てたそうで、通信効率が非常に悪かったようです。
第二次大戦の時、日本では大学の研究室レベルでは電波の研究が進んでいて、画期的なアンテナなどが開発されていたようです。
しかし軍の関心は低く電波の軍事利用に十分な投資が行われることはなかったようです。
一方アメリカはレーダーや近接信管などの開発に十分な投資をし、海上戦で日本を追い詰めていきました。
1990年代になるとアメリカではソフトウェアビジネスが盛んになり、マイクロソフトやオラクルなどソフトウェア企業がIBMやGEなどハードウェア企業に代わり台頭してきました。2010年ごろには米国のトップ10の大半が新興IT企業に入れ替わるほど繁栄します。
一方、日本でも1990年代にはTRONというOSが開発され国を上げて普及を進めていましたがアメリカの301号貿易制裁を受けて頓挫し、2007年にB-TRONが消えていきました。その後も何度か売るチャンスはあったと思うのですが機会を掴むことなく消えました。
1990年代はOS以外にも日本製のRDBやCADなど様々なソフトウェアが登場したのですが国内では売れず殆どが消えてしまいました。
日本でソフトウェア産業が根付かなかった理由として、日本企業が自社専用の業務手順に拘りすぎ、汎用ソフトウェアを使用しない為だと思います。本来ソフトウェアの開発は業務知識をソフトウェアに反映し業務知識共々ソフトウェアを皆で共有するところに価値があるわけですが、日本社会では何故か知識の共有という発想が育たなかったようです。結果として汎用ソフトウェアが育たず、情技師は生産性の低い専用ソフトウェアの開発に従事することになり益々国際競争に取り残されることになりました。
結局日本人はソフトウェアというものの価値を理解できなかったということだと思います。
日本人のソフトウェア技術が低かったのかと言えばそんなことは無いと思います。先のTRONですがTRONの中にはデスクトップ用のB-TRONと組み込み用のI-TRON,ネットワーク用C-TRONの三種類がありその内、I-TRONは国内組み込みOS市場の6割のシェアを握り最近IEEEの国際標準規格に認定されたそうです。
I-TRONはハードウェアとセットで開発されるので投資が進んだのでしょう。純粋なソフトウェアは投資対象にならず成長できなかったのでしょう。
戦争においても日本は諜報機関を重視せず帝国間における情報戦で負け続けていたようです。現代でも日本は国家諜報機関を持たず、外交において不利な戦いを強いられるようです。
つまり、日本はレーダーやコンピュータのソフトウェア、戦争や外交におけるスパイ情報戦など、目に見えない部分の価値を軽視する傾向にあるように思えます。
現代の産業はもの作りでも、商売でもソフトウェアの比重がだんだん大きくなってきていますから、ソフトの苦手な日本が負け越しているようにも見えます。(それだけが原因だとは思えませんが)
ソフトウェア開発はなぜ難しいか
全てが試行錯誤の工程
日本人はソフトウェア開発を誤解している人が多い。特に「設計」「開発」「製造」の工程を誤解しています。
ハードウェアでは「設計」は設計図を書く工程。「開発」は試作品を実際に作ってみる工程。そして「製造」は工場で量産する工程です。
試行錯誤するのは「設計」だけで「開発」と「製造」はただ設計図の通り作るだけという認識を、多くの人が持っています。
ソフトウェアでも同じように考える人が多く、試行錯誤は「設計」だけで「開発」と「製造」は設計書の通りに作るだけ、と考える人が多数派です。(特にSIer業界とその顧客) またどういうわけか「開発」と「製造」を区別しない人が多い。
「設計」に分類されるのが「基本設計」で、「開発」には「詳細設計」と「プログラミング」。
又は「開発」が「詳細設計」で「製造」が「プログラミング」という分類もあります。 分類方法が統一されていないところにも「いい加減さ」が現れていると思います。
ハッキリ言って上記の分類は両方とも間違いです。
正しくは「基本設計」「詳細設計」「プログラミング」は全て「設計」に分類すべきなのです。
「開発」にはテスト・デバッグが当てはまるべきです。ソフトウェアは当初の設計の通りに完成することはなく。作ってみてから想定外の現象に遭遇し試行錯誤しながらプログラムの修正を繰り返し完成を目指します。これは単なるテストではなく立派な開発工程の一つです。
「製造」に当てはまる工程は存在しません。製造は量産であり現代のソフトウェアの場合、ダウンロード販売であればサーバーからダウンロードする瞬間の実行ファイルのコピーのタイミングが「製造」に当たります。DVD販売であればDVDにプレスする工程が「製造」に当たります。
どちらにせよ、システム開発工程には「製造」工程は存在しません。それは「配布」です。
つまりシステムやソフトウェアの開発のほとんど全て「試行錯誤」を必要とする「設計」工程なのです。図面に従いタダ作るだけの工程は存在しません。
一つとして同じ作業の繰り返しが無い
ハードウェアや建築の場合、その開発には「同じ作業の繰り返し」の部分が少なくないでしょう。ビルの建築の場合は二階と三階・四階の作り方に大きな違いが有るようには見えません。実際は強度設計などで違いはあると思いますが大きな違いとも思えません。
車の場合はエンジンのピストンとシリンダーの設計はどれも同じでしょう。四つの車輪の作り方も同じはずです。船、電車、飛行機、家電などハードには必ずこのような「繰り返し構造」があるはずです。むしろ「繰り返し構造」が多い方が量産コストが安く、生産性と品質が高くなるはずです。
つまりハードウェアは「同じ設計(試行錯誤)を使い回せる部分が多い」という特徴があります。
言い換えると「大きさの割には試行錯誤の割合は少ない」と言えるでしょう。それと別に「同じ物を製造する難しさ」がありますが。
ソフトウェアは下手クソな作り方をしていない限り「繰り返し構造」は存在しません。(何事にも例外はありますがここでは触れません)
ソフトウェアは関数やクラスといった単位にモジュールを分割します。モジュールはソフトウェアの中では、何処に存在しても何処からでも呼び出し使用することができます。(例外はあります)
つまり一度作った機能を二度作る必要が無いのです。
言い換えると「ソフトウェアは全てが異なる試行錯誤の成果物」てあると言えます。
組み合わせの数で複雑さが増す
ハードウェアの場合、設計の複雑さがほぼ見た目と一致しているので設計の複雑さや仕事の難しさが理解しやすいです。
ビルを四階建てから五階建てに設計変更する場合、素人でも強度計算など、その複雑さはある程度予測し理解できます。
自動車の右ハンドルを左ハンドルに設計変更するのも簡単では無さそうです。
冷蔵庫をツードアにするかスリードアにするかもそれなりに難しそうであることは想像できます。
しかし、ソフトウェアは初めから実体が見えない為、複雑さが作った情技師にしか分かりません。
ユーザーや非情技に見えるのはスクリーンに映るシステムの「画面」だけで、画面の複雑さだけでシステムの複雑さを「理解したつもり」になるユーザーは非常に多いです。
このようなユーザーはシステムの修正を依頼するとき「この画面を少し修正するだけ」という依頼をすることがあり、見た目があまり変わらないから簡単だと思っています。
しかし実際の修正は「データ構造を大きく変更しなければならなくなる」場合もあり、とてもコストと時間がかかるケースは少なくないです。
これはユーザーには「目に見えない部分の存在を失念しているから」という理由と、もう一つ「複雑さは組み合わせの数で増える」ことを理解できないのが原因です。
ITシステムはクライアントとサーバーで構成されるから画面を修正すればそれに応じたサーバー側とデーターベースも修正しなければなりません。
また、現代システムは単独で動くものは少なく、多くは「他のシステムと連携」しているものです。そちらも修正しなければならない場合があります。
「複雑さは組み合わせの数で増える」の点はたとえ話で説明します。
通常のシステムの複雑さは「項目」「画面」「テーブル」の個数が反映すると考えてください。「項目」というのは例えば個人情報であれば「氏名」「住所」「メールアドレス」などの情報です。
「画面」は「ログイン画面」「個人情報変更画面」「利用履歴一覧表画面」といった機能画面のことです。
「テーブル」はユーザーには見えませんが、通常は「個人情報テーブル」とか「利用履歴情報テーブル」「取引先一覧テーブル」というように目的別にデータを整理して管理しており、テーブルというのはその整理単位だと考えてください。
ITシステムの複雑さは「項目」「画面」「テーブル」の個数の「組み合わせの数」で考えるとその複雑さが理解しやすい。
実際は、そんなに単純ではないが簡単な目安として便利だ。
「画面」と「テーブル」は加算する。
「項目」と加算値の「組み合わせの数」を算出する。
画面=4,テーブル=5,項目=50 なら 組み合わせの数= 2,505,433,700
画面=5,テーブル=6,項目=50 なら 組み合わせの数=37,353,738,800
画面=4,テーブル=5,項目=60 なら 組み合わせの数=14,783,142,660
「組み合わせの数」が画面数とテーブル数と項目数の変化でどのように増えるのかだけ把握してくれれば良い。実際は現れた複雑さを全てシステムで使用するわけではないのでこの変位がそのままコストに反映されるわけでは無い。
テーブル一つだけ、項目が10個だけ複雑になっただけでも、システムは大幅に複雑になるのだ。ということを理解して欲しい。その為にこのような説明をしました。
コストを安くしたければ仕様を単純化して「組み合わせの数」が小さくなるようにすれば良いのです。
たとえばマイクロサービスアーキテクチャという設計方法があります。
これはシステムを小さく単純な部品の組み合わせとして設計することで、全体として「組み合わせの数」が小さくなります。
たとえば、
画面=4,テーブル=5,項目=50 なら 組み合わせの数= 2,505,433,700
ですが、これを二つのマイクロサービスに分割すると
画面=2,テーブル=3,項目=20 なら 組み合わせの数= 15,504
画面=2,テーブル=3,項目=30 なら 組み合わせの数=142,506
15,504 + 142,506 = 158,010
という具合に複雑さを大幅に減らせます。
コスト削減と単純化による品質向上に貢献します。
(実際はこんなに単純ではないが基本的な考え方はこれである)
ソフトウェアの複雑さの増加について説明しました。
システムの開発者は誰と誰なのか
SIerなどのシステム受託開発の発注者を見ていると共通の間違った認識を持っているのが分かる。
「システム開発はITベンダーだけの仕事だ」という認識だ。
この認識は、
「だからシステム開発はITベンダーに丸投げで良いよね」
という「行動」を生む。
その結果は「要件漏れ」「業務に合わない役立たずのシステムが出来てしまった」「業務が全然効率化できない」という結果を生む。
また、派生的に「納期までに開発が完了しない」「品質が実用に達していない」というのも連なる。
結論から言うと「システム開発はITベンダーだけの仕事ではない」。
「システム開発は業務担当者と情技師の共同作業だ」と言える。
より正確に言えば「業務担当者と情技師と経営者の三者の共同作業でシステムは開発されるモノ」
ITシステムというのは業務を自動化したり標準化したものだ。当然システムには「業務知識」が反映されている。システムを企画するには「業務知識を持つ者」が必須だ。
情技師はITの専門家であって業務の専門家ではない。
通常は企業の業務は「その企業特有の業務」であって「他社に業務の専門家はいない」ものです。
(汎用的な業務であれば汎用パッケージソフトを導入すべきです)
従って、業務知識の反映されたシステムを開発するのであれば「業務担当者は業務知識を提供」し「情技師はITを提供」して初めてシステム開発が可能になります。
システム開発をITベンダーに丸投げにすると失敗するのは「業務担当者が自身の役割と仕事を放棄しているから」という、冷静に考えれば「当たり前」の理由からです。
業務担当者と情技師が共同でシステム企画構想を練るとき、両者はモノの考え方が違いますから、当然に意見の衝突が起きます。
現状、受託開発では業務担当者の方が「お客さん」なので立場が強くITベンダーが非現実的な要求や矛盾する要求も呑まされてしまうことが多いです。そしてそれが非論理的であればあるほど「失敗」の確立が増します。
理想的な開発体制は、「業務担当者と情技師が対等な関係で議論しながら試行錯誤」する関係の元で、システムの企画設計開発が行われるのが良いのです。
ただ、両者が対等だと議論が平行線をたどった時、結論が出なくなりますから、経営側の人間が裁定者として開発プロジェクトに参画しなければなりません。
つまりプロジェクトチーム構成として「経営担当」の下に並列対等に「業務担当」と「情技師」が並ぶ構成にすべきなのです。
ほとんどのシステム開発プロジェクトにおいて、この最低限の条件すら満たされていません。そりゃあー失敗するわけです。
システムやソフトウェアはいずれ全ての人間が関わるようになる
最近経済の分野でベーシックインカムの議論をよく聞く。
技術が進歩しいずれ大半の仕事(生産活動)を機械が代行し、労働の対価としての賃金という「所得の分配」が出来なくなる。所得の分配が出来なければ消費の面から市場(資本主義)を支えている中産階級が居なくなってしまうので、賃金ではなく直接所得を分配することで中産階級を維持しよう。というのがベーシックインカムの基本的な必然性だと認識している。
生産活動は近い将来、機械が主役になる。
全ての労働者と経営者はシステムやロボットと無縁ではいられない。
今までは非情技の人々はシステム開発について知る必要が無かった。いや正確には知る必要が無いと思い込んでいた。
しかし今後全ての業務はシステム化機械化されてゆく。人間の労働する会社は、機械化された会社に生産性で叶わないので、淘汰され全ての会社が業務を機械化してゆく。
現状では機械を操るにはシステム(ソフトウェア)を介さなければならない。
もしかしたら50年後は知性を持つロボットに言葉で依頼するだけで適当に仕事をしてくれる時代が来るかも知れないが、しばらくはシステムで制御しなければならない。
これは全ての業務はITシステムと無縁では居られないということだ。
しかし、全ての人々が情技師(プロクラマー)になることは出来ない。
だから経営者や業務担当者は情技師との付き合い方、共同作業のやり方、システムの開発の仕方を知る必要がある。
まず、経営者や業務担当者などの非情技が理解すべきは「システム開発の難しさ」だと思う。
これが分からなければ適切な「物と人と金」の配分が出来ず大きな損害を被ってしまう。サマータイムなどに安易に賛成する人は「危ない」と考えるべきだ。
そういう思いもあって、今日この記事を書いた。
少しでも「システム開発は難しいのだ」ということを理解して貰えれば幸いであります。
