July 30, 2023

Twitter振り返り(2)

Ws000088

人工地震とは、一般的には地中探査のために起こされる人工的な地震動ということになっている。そして、それ以外の意図を持って、誰かが人為的に(悪巧みとして?)起こす地震のことは人工地震とは呼ばないようだ。

テレビや新聞を見ていても「この間の◯◯地震は人工地震だったかもしれない」なんていう話は一度も聞いたことがない。人工地震の定義が上記のとおりだとすれば、どこかで地中探査しただけのことにニュースバリューは無い。なので、今後は人為的地震だったのかどうかを問題にすべきなんだろう。

しかし、◯◯地震が人為的地震だったかどうかを気にする人が世の中にどれだけ居て、さらにそれを調査しようと思う人がどれだけ居るだろうか? 仮に調査しようとする人が居るとして、それに誰がカネを出すのだろうか?

仮に、◯◯地震が人為的地震だったと断定出来た(どうやって?)としたら、その地震で被害を受けた人々はその地震を起こした張本人を探せ!ということになると思われるが、その張本人がそこらをウロウロ歩いているオッサンではあり得ないから、相当なカネ持ちか資産家、あるいは敵対国家ということになる。そして、そのような人たちならテレビや新聞の報道を作り変えることなんて朝飯前なんだから、結局は表に出て来ないのだろう。

| | Comments (0)

Twitter振り返り

Ws000087

 

2021年Twitter振り返りというタイトルで書き始めたのだが、どうせなら最初から振り返って見たいと思い、仕切り直すことにした。

 

2011年8月23日のこのツイートが初投稿だったようだ。今から4359日前(11年11ヶ月前)。書き終わったのはこのブログではなく他のブログだったことが、このブログのアーカイブを見ると当時の投稿が無いことから分かる。

 

この年の3月11日に東日本大震災が起こり、セミもカエルもほとんど鳴かない不気味な夏だったことを思い出す。放射能のせいか、たまにヘンな頭痛もあった。

 

そして、たぶん人生2度目の憂鬱な案件の対応が始まった年でもあった。その後4年間、その案件の対応は続いたが、二度とその顧客の対応はしなくて良くなった?のは幸運だったかもしれない。

 

BGMは、メディアプレーヤーでその時たまたまかかっていた曲だったのだろう。その曲は当時を起点にしても31年前に、最初に買ったLPレコードの1曲目だった。空の番人が地上を見渡して憂鬱になっている様子をメロトロンの唸りで表現したかのような、印象的なイントロの曲。今でもよく聞く。

 

| | Comments (0)

March 12, 2023

ノーコード(3)

前2回で書いた内容を要約すると、だいたいこんなことを書いた気がする。
・会社でノーコードを活用していこうという話が出ている。
・ノーコードが一般化するとプログラマは不要になるのか?
・コンピュータはプログラムコード通りに動く。
・ノーコードは意図した通りに動くのか?
・ノーコードの販売戦略?
・ノーコードで要望通りに動くシステムが出来上がるのか?
・ノーコードはスモールスタート出来るか?
・ノーコードで作ったシステムの権利関係は?
・ノーコードのうまい活用方法?

では、実際にノーコードを扱う案件を自分が担うとしたらどうなるのか?についてアレコレ考えてみよう。

 

【案件のゴール】

客(エンドユーザ)が何を望んでいるかによって案件のゴールが決まる。これを見誤るとその案件は途中もしくは完成時期に火事になる。ただし経験上、これは非常に不思議なことだが、客は自分が一体何を望んでいるのか分かっていないことが(大いに?)あり得る。よって、客の要望をヒアリングする場合には、十分に注意しないといけない。ノーコード案件に限って言えば、客はノーコードという名のツールを欲しがっているのか?それとも社内のある業務をコンピュータ活用によって改善したいのか?を問うべきだろう。

まず、客は自分が本当はどうしたいのかが分かっていないことが多い。そういう客はベンダが何か良い提案(のように見えるもの)を持ってくれば、それに乗っかろうとする。しかし、自分が何をしたいのかすら分かっていない客が、ベンダの提案内容を理解し、自分の要望(のようなもの)と合致しているか判断出来るとは考えられない。そういう場合は、問題を単純化するしかない。

購入:自分(客)の要望に敵うノーコードを購入したい。
構築:ノーコードを使って自分の要望に敵うシステムを構築したい。

購入目的なら、現時点で存在するノーコードを調査し、数点ピックアップして比較検討すれば良いが、最も重要なことは「どのノーコードを買うかは客が決定する」という点だ。その基本に立つならば、ノーコードを提供するベンダを連れて、一緒に客の要望を聞くなんてことはしてはいけない。もちろん、ベンダがノーコードにものすごく精通していて、客の話を聞いただけで、最適なノーコードを選定し提案出来るのなら話は別だ。しかし、そんなベンダが元受けのアンダーでノーコードを売ろうとするだろうか?そんな提案力があるなら、自分たちで営業して客と契約するだろう。わざわざ元受け会社と利益を分ける必要など無い。購入目的の場合は「このノーコードではやろうとしていたことが出来ないではないか!」というクレームが来ないようにすることが最大のリスク管理と言える。

では、構築目的の場合はどうだろうか?要望に敵うシステムを構築する手段として、ノーコード導入が最適解であると客が言い切るのであれば、それすなわち構築目的ではなく購入目的に切り替わる。よくあるポン知恵レベルの話として「ノーコードを使って構築すれば、運用中に発生する変更の度にベンダに依頼するのではなく自分たちで対応出来る!」というのがあるのだろう。しかし、たかだか自分たちでも構築可能な単純なシステム?を高価なノーコードという手段で実現する必要があるのだろうか?

何かある度にいちいちベンダに依頼することなく、あとで自分たちで変更出来れば良いという発想は、プログラムであれ、ノーコードであれ、自分たちでその仕組みを理解出来ることが前提となる。逆に言えば、ノーコードで構築し得ることには自ずと限界があるということだ。仮に社内の人間であっても、その人が時間をかけてノーコードと格闘し、トライアンドエラーの末にようやく実現したシステムを容易に変更可能なのは、せいぜい外見(画面の表示、文字の色やサイズなど?)と内部の固定値くらいで、それ以上の変更をしようとすれば作り直しになる可能性が高い。もちろんノーコードのクセや制限に引っかかることもある。

そもそもエンドユーザが構築手段に注文を付けること自体が間違っているのではないか?上記を踏まえれば、ノーコードを活用して実現可能なのは大したシステム(と呼べるような規模)ではない。その程度のものを高価なノーコードで実現する必要があるのだろうか?そんなものなら、ノーコードなんて使わなくても非常に安価に簡単に作れるだろう。必要なら運用上の変更にある程度耐えられる作りも不可能ではない。

ノーコードをやりたいという客からの引き合いにどう対応すべきか?については、安易に相談に乗るのではなく、それ自体が一体どういうことなのかをよく考える必要がある。


| | Comments (0)

September 11, 2022

ノーコード(2)

さて、ノーコードはシステム開発の救世主になり得るか?

私はノーコードを使ったことはない。トライアル版(機能制限無しの?)を使ってみて、あれこれ試行錯誤した結果、ノーコードに適した案件があり得ることくらいは分かるのかもしれない。おそらく、組織的(会社として?)にノーコード適用条件を明確化する必要があるだろう。単なる思い付きで案件にノーコードを適用して、高額なライセンスを購入したあと、土壇場になってノーコードの制約(バグ?)に引っかかったり、ノーコードの実装を理解していないと書けないような難しい追加コードを要求されたら、その時点でその案件の構築は破綻してしまうのではないか?

ノーコードに無視出来ないようなリスクが有るのなら、小規模案件から徐々に適用し、経験値を上げていけば良いではないか?と、誰でも考えるような当たり前のことを言うのかもしれない。その場合、ノーコード開発環境はその案件のベンダ側が購入し、ノーコードにより作成したシステムオブジェクトの実行環境を顧客側が購入することになるのだろう。開発環境と実行環境を分離できないノーコードの場合、顧客に開発環境まで買わせることになるので、小規模案件から徐々に適用するは不可能だ。また仮に分離出来たとして、ノーコードに起因する問題はすべてベンダ側の責任になるので、多少なりとも免責したいと思うなら、要件定義、見積段階から、ノーコードの使用を顧客に告げておく(承認してもらう)必要がある。そうなれば、顧客はノーコード実行環境の購入費分を値切ってくるのは明らかだ。そうでなければ、ベンダ側がノーコードの良いところ(開発効率向上?)だけを享受し、リスクはすべて顧客に丸投げとなりかねない。

ノーコードの開発環境と実行環境の分離は重要な要素である。分離出来れば、ソースコードの権利はベンダ側に留保し、顧客にはプログラムの使用権だけを渡すといった、従来からよくある契約が可能となる。分離出来ない場合は、構築が終わった時点ですべてを顧客に引き渡すことになるので、それ(ソースコードの権利移転)がイヤならあらかじめ契約で謳っておく必要がある。しかし、ノーコードにソースコードはないのだから、いったい何を留保しているのか分からないし、それを参照するには顧客に買わせたはずのノーコードをベンダ側もずっと持っていないといけなくなる。結局、ベンダ側もノーコードに初期投資(継続投資?)せざるを得ないわけだ。

プログラムコードならフリーのエディタがあれば参照出来るが、皮肉なことにノーコードではそういうわけにはいかない。いや、もしかしたらxml等の形式でエクスポート出来るのかもしれないが、そのコードが何をしているかを解読出来るかどうかは疑問だ。しかも、ノーコードはまだレガシーにはなっていないと思われるので、外国製品なら日本語化はされていないだろう。ノーコード特有の用語が混じった表示がすべて英語では、非常に扱いにくいのではないか。

もちろん、構築が終わったら全部顧客に渡して、一切運用や保守に関与しないという考え方もあるだろう。しかし、そんなことを事前に顧客に説明して(不安にさせて?)、その案件を受注出来るのだろうか? さらにその前に、そんなことを提案書に書いて顧客に説明する前に、ベンダとしてノーコードに手を出すかどうかをよくよく考える必要があると思われるが、どうだろうか?

うまいやり方があるとすれば、ノーコードシステムをまず顧客に購入させる。そして、必要ならそれを使用したシステム構築を客先常駐で実施する。そうすれば、準委任契約でシステム構築を実施出来るので、ベンダにとっては願ったりかなったりではないか? そうじゃないと、顧客の好みで採用したノーコードシステムをいくつもベンダが抱えることになる。抱えているノーコードのサブスクリプション費用は誰が払ってくれるのだろうか?

これらのことはノーコードだけでなくローコードにおいても言える。一見してプログラムを書かなくてもシステム構築可能!というウラには、今までに無かったようなリスクがあるし、顧客にしてみれば、プログラムを書かないならもっと早く安く出来るだろうと言うに決まっている。だとすれば、相当慎重に考えないと危ないのではないだろうか。


 

| | Comments (0)

June 18, 2022

ノーコード

心の奥底ではクスクス嘲笑しつつ、なかなか頭から離れてくれないのがノーコードというトレンド。会社(上層部)がコードレス開発?によるシステム構築を望んでいるらしいからだ。いや、実はそんなにハッキリした方針として断言しているわけではない。彼らにはそう断言できるほど開発経験があるわけではない。ただ、われわれより多少口が達者なだけだ。上層部と言っても、今やオレより歳上はほとんど居ないし?!(笑)

まるで、コードさえ書かなければ今あるシステム構築上の多くの問題がソッコーで解決するかのように言うが、果たしてホントにそうなのか? コードを書かなくてもホイホイシステムが出来上がるなら、われわれのような底辺SEやシステム構築ベンダは全員お払い箱ということなるのか?

最も基本的なことは、コードを書いて動かすプログラムは書いたようにしか動かない。書いてもいない処理が勝手気ままに動き出すなんてことはあり得ない。しかし、コードを書かなくても動くプログラム?は極力コードを書かなくても済むようになっている(はず)ので、そのプログラムの仕様や動作条件を熟知し、それらを制御しなければ、当然期待しない動きをすることもあり得る。いきなり極論すれば、出来の良いノーコードであればあるほど、プログラムに余計な動きをさせないよう縛る必要があるということになる。しかも、どう縛る必要があるかはノーコード自体の仕様以外に、それによって出来上がったプログラム?が、新たに引き起こす副作用に気を配らなければならなくなる。

もしそうでないとすれば、動かすためのシナリオや個々の処理を細かく設定してやらないといけないことになる。それって、処理ライブラリが豊富なRPAじゃないの?ということになりかねない。RPAなら、描いたシナリオどおりにしか動かないかもしれないが、ノーコードはどうだろうか?

意図しない動きに苦心するというのは、オブジェクト指向システムのフレームワークやテンプレートをカスタマイズしたことがある人なら分かるだろう。要するにノーコードは、それをプログラミングやソフトウェア工学に無知なエンジニア?や、口煩い身の程知らずのエンドユーザ向けに可視化したものということになるのではなかろうか? 「プログラムを書く必要が無い」を目的化すると、そういうおかしなものがさも最新テクノロジーであるかのにように華々しく登場する。しかし、中身をよく見ると過去の遺産の焼き直しでしかないことが分かってくる。

おそらく、ノーコードのサプライヤーはそのようなことは百も承知だろう。ノーコードというキーワードに異常興奮してしまった人が衝動買してしまったあとで、あれ?と思ったときに「月額???百万円で如何様にもサポート致しますよ?!」という魔の手が待ち構えているわけだ。ノーコードに瑕疵担保という概念はない。残るのは、買ってしまった以上使えない(活用できない)では済まされないという焦りだけだ。

ここまでのネガティブ要素に目を瞑り、ノーコードを導入したとして、それを使いこなせるのは結局経験豊富なソフトウェアエンジニアということになるだろう。プログラムはただ動けば良いというものではない。大勢の人が同時に伝票入力したとして、都度5分も10分も待たされるようでは困るし、深夜にスケジュールした日次タスクが早朝までに終わらなければ、翌日の業務を開始できない。そういう当たり前の日常を担保しているのは、ユーザ要件通りにシステムを組み上げる技術力なのであって、ノーコードではないのだ。


 

| | Comments (0)

January 02, 2022

2021年Twitter振り返り(4)

【カッコのネストが気になるプログラマー?】

Ws001027

結論から言えば、カッコがいっぱいネストしているくらいで、そんなプログラムは読めない書けないと言っているプログラマーなんて、どうせ大したこと無いから気にしない。

Lispは、関数と引数をカッコで囲んだリストが並んでいるだけの、非常に単純な書式のプログラミング言語である。なので、20代前半の頭が柔らかい新入社員なら、立ちどころに習得してしまうのではないか?と思ってビクビクしながら研修テキストを作ったのだが、その期待は見事に裏切られた。おい!オレみたいな低脳オジサンでも理解出来ることが、なんでアンタ等若いもんに分からんの?!

最近は、プログラミングなんか全くやったことがない、授業でやったことはあるが、そんなもんとっくに忘れたわ! オレたちはプログラムを作る人じゃなくて、作らせる人でしょ?という顔をして、堂々とSEの職場に配属されてくる新入社員が多い。そんなんでホントにこの先大丈夫なのか?オマエ等は! SEとしての価値をどうやってアピールしていくの? と、こんなことをいくら言い聞かせても彼らには分からない。

もうすぐAIロボットが出てきて、人間がプログラミングするのは時代遅れと思っているのかもしれない。果たしてホントにそうか? AIロボットが人間の代わりにどんどんシステム構築をするようになるのか? そのような単純で楽観的な考えで、AI時代を生き抜けるだろうか? 現時点で答えはノーだ。おそらくシンギュラリティ以後のAIがすぐに登場すると錯覚しているのであろう。

場合によっては、たかが銀行システムさえ上手く動かせない程度の英知で、どうやって登場間もないAIと付き合っていくのか? 彼らの考えていることが理解出来ない。


 

| | Comments (0)

2021年Twitter振り返り(3)

【デフレ克服】

Ws001026

このツイートをした頃は、デフレ克服?インフレにすれば良いんじゃないの?くらいに思っていたかもしれない。克服という言葉を使うほど対処するのに難しい問題なのか? 日本の経済問題を話題にするニュースや番組を見ていると、デフレ克服を阻害する要因って何なのかを突き詰めて語る人があまり居ないという印象を受ける。原因が分からないければ対処出来ないが、何となく原因が分かっていても言わないようにしているのではないか?

デフレを克服するとどういう良いことがあるの?とか、デフレだと物価が安くなるからその方が良いんじゃないの?という人がいる。働かずに生活出来ている人(ニート?)が言いそうなことである。物価がどんどん安くなっていけば、企業の収入はどんどん減っていき、支払われる給料はどんどん減っていく。逆に、インフレになって物価がどんどん上がっていく(相対的にお金の価値が下がっていく)と困るのは、ニートや不労所得を得ている人たちということになる。つまり、大金持ちがデフレ克服に反対しているのかもしれない。

日本の国益を考えれば、デフレよりはインフレの方がマシだが、インフレも度が過ぎれば世の中が破綻する(ハイパーインフレ?)。よく2%のマイルドインフレにするのが望ましいという言い方がされるが、本来は失業率を下げる(就業率を上げる)のが目的であり、失業率が下限に至るときに相関してインフレ率が2%程度になっているということのようだ。しかし、このことはいくら対策をしても半年や1年で成果が出るわけじゃないので、多くの外圧や工作を跳ね除け、自分の政治生命も顧みない国益重視の政治家が集まらない限り実現は難しいだろう。

戦後76年経って瓶の蓋は開いているのかもしれないが、まだ瓶の中に居ることに変わりはない。


 

| | Comments (0)

2021年Twitter振り返り(2)

【新型コロナ騒動】

Ws001025

2020年の初めに「武漢熱」や「COVID-19」などと呼ばれる、新型コロナウイルスが引き起こす風邪が大流行?し初めた!ということになっている。当初より、このウイルスにはSARS、HIV、おたふく風邪などの遺伝子配列が混じっているという噂が広まり、医者や一般の人々を震え上がらせたが、一方では、あっけらかんと毎年流行するインフルエンザと何が違うの? 感染者、患者なんて全然少ないんじゃない?という冷静な分析も有った。

そもそもこのウイルスは何者なのか?については大きく2つの考え方がある。一つはコウモリなどの動物が媒介した自然発生であり、もう一つはウイルス兵器(人為的に作られたということ)である。どちらにも共通しているのが、武漢にあるウイルス研究所から発生したという点であり、その研究所は例によって封鎖・隠滅され、調査の手が及ばない状態になってしまっている。これにより、将来同様のことが発生し得るリスクを残したままとなった。

報道ベースでは、ウイルス兵器というのはデマ、都市伝説の類であり、もっぱら自然発生ありきの、コウモリの体内にはさまざまなウイルスが溢れている? 研究所の所員が実験に使った動物を市場に売った? アノ国の人は日本人には理解出来ないような動物を食べる? などのホントかウソか分からないようなことを専門家と称する人たちが話していた。

重要なことは、過去からの言い伝えにある。風邪を封じ込めようとしてはいけない!ということ。コロナウイルスをこの世から完全に消去し切れるのなら、それも一考かもしれないが、コロナウイルスが常に身の回りにあるのなら、まずはそのコロナウイルスに感染しない、あるいは感染しても重症化しない身体にするというのが最も重要なことではないだろうか? それが出来れば誰も苦労しないと言う人が必ず居るが、自分の身体の免疫、抵抗力を低下させないよう工夫して日々生活している人がどれだけ居るだろう? それをしないで、何も考えようとしないで、ただ単にワクチンを射てば良いんでしょ? などと考えている人たちは、結局コロナウイルスに翻弄されるんだろうね。


 

| | Comments (0)

2021年Twitter振り返り

Twitterにつぶやくようになって、ブログ投稿がめっきり減った(いや、たぶんTwitterをやっていなくても減っていた)。ふと考えたこと、思ったことはすぐに書き表しておかないと、どんどん忘れていってしまい、あとで思い出して書けばいいやと言っていられなくなった。それで考えたことをまとめた文章を書くより、その都度つぶやいていこうということに自然となっていった。年齢的な理由ではあるが、Twitterを始める前から既にそういう状態になっていた気がする。こんなに物忘れがひどいようでは、定年退職したら非公開小説でも書いてみようか?なんていう夢も徐々に霞んでくる。

しかし1個のつぶやきは140文字である。返信でつなげばいくらでも長い文章を投稿できるとは言え、ひとつひとつのつぶやきの裏には言い足りなかったことが山ほどある。文字数制限内に収めようとするうちに、考えていたこと、言いたいことから微妙に離れてしまったこともある。もしも、つぶやいてはみたものの、何となく言いたかったことから逸れてしまったとか、言い足りなかったこととか、があるのなら、それは今でも頭に残っていて、ホントはこうだったんだという内容がどんどん出てくるのではないか?という気がしたので、過去のつぶやきを見ながら少し振り返ってみようと思ってみた。


【子供にとっての未来?】

Ws001022

子供だった頃、未来をどう考えていたのか? 幼稚園児だった頃、小学生だった頃は「大きくなったら何になりたい?」あるいは「将来どうなりたい?」と、よく聞かれた覚えがある。「未来についてどう考えているか?」などと聞かれたことはほとんど無い。未来という言葉は、タイムマシンの時間軸?という感じだった。そういえば「現在、過去、未来~♪」という歌い出しの曲があったし、言語の文法に未来形はあるが? 将来形というのは無かった。タイムスケールが10~20年くらい先のことを将来、100~200年あるいは1000年くらい先のことを、何となく未来と呼んでいた。また「今は出来ていないが、将来は出来るようになるだろうね?」とか「人類の未来には想像を絶する困難が待ち受けている?」という感じの使い分けを無意識のうちにやっていた気がする。

さすがに、特撮ドラマや近未来映画のような現実がホントに目の前に現れるとまで思っていないものの、ずいぶん悲しい気持ちになったり、不安になったりしたものだ。でも、未来には興味があった。テレビ、映画、SF小説など、未来を描いたものを見る度に、世の中がそのようになるまで生きていられたら良いなあと、普通に望んでいた。未来に現れるもののとして顕著に描かれていたものというと、宇宙人、宇宙船、ロボット(AIを含む)、タイムマシン、さまざまハイテク(たとえば腕時計型のテレビ電話とか?)などなど、それぞれ今は無いが、あったら良いなあと単純に思えるものが多かった気がする。まあ、宇宙人は別として。

今ある問題は将来必ず解消される? その先の未来には想像を超えた素晴らしい世界が待っている? それってホントなの? たぶん、そのように考え、それを目指すことが重要なのだろう。そういう未来がやって来ることを保証してくれる者は居ない。素晴らしい未来を期待するのなら、今ある世界や文明をちゃんと制御出来ないとダメだろう。そうでなければ、人類が生み出したものによって滅ぼされるだろう。


 

| | Comments (0)

January 05, 2019

システム開発の現状

一般的に、普段我々がシステム開発と呼んでいるのは、実際にはアプリケーション開発であり、しかもそのほとんどはWindows上で動くアプリケーションの開発である。ただ、1個のアプリケーションで全ての要件を満たそうとすることは非常に稀であり、普通はいくつかのアプリケーションが連携して動作し、エンドユーザに利便性や効率性を提供する。しかし、システムって何ですか?と聞かれて、それはWindowsアプリケーションであると答える気は毛頭ない。たしかに、システム開発とはアプリケーション開発であると言ったばかりだが、それは定義ではなく、現在の状況に過ぎない。

本来のシステム開発であれば、システムに求められる要件定義のあとで、ハードウェア、ソフトウェア(OS機能も含む)それぞれの方式検討、仕様規定、設計、製造、テストが並行で行われ、次に開発されたハードウェア上で、開発されたソフトウェアを動作させ、正常性、安定性を確認する。こういったシステム開発は、Windowsアプリケーション開発に比べて、開発期間が長く、工程が進んでいくにつれて作業がどんどん過酷なものになっていく傾向がある。過去の開発では、進捗キープや納期厳守のために徹夜のテストやバグ改修になることが常であり、そのために1つの開発が終わると、関係者は身も心も弛緩し、次の開発に着手してもなかなか本来の調子が戻らず、気が付くとまた徹夜続きの毎日に戻っているという不健全なスパイラルに陥りやすい。つまり、常にコンスタントに作業することがむずかしい仕事であるということだ。今風の言い方をすれば、ブラック認定間違い無しの業態である。

では、上記のような本来のシステム開発とアプリケーション開発との間にはどんな違いがあるのか?

おそらく、どんなシステムにも性能要件がある。何らかの操作をしたあとで、その結果がいつまで経っても表示されないことを許容してくれるエンドユーザは皆無と言って良いが、ではシステムがどの程度の性能を発揮すれば良いかを規定するのは意外にむずかしい。大した技術的裏付けがなくても普通に時間がかかりそうだと分かることを瞬時に実行するにはそれ相応の費用がかかるので、エンドユーザもヘタなことは言えなくなる。また、同期的に処理するか、非同期的に処理をして完了したら通知するか、などの考え方もある。が、いずれにしても性能はケースごとに数値で定義しないと確認できないのは確かだ。アプリケーション開発でどんな厳しい性能を要求された場合でも、それを実現することが可能なのかと言うとそれは非常に困難である。

性能要件を満たすための方法とは、システムの動作シーケンスを計測可能な箇所で区切って、その区切り毎に想定秒数を決め、シーケンス全体の秒数を合計した時間が妥当かどうかを検討し、その通りの時間で動くハードウェアとソフトウェアを作り上げることである。性能の作り込みというのはそういう地道な作業の積み重ねであり、性能要件を満たすのに必ずしも優秀なSEやプログラマが必要というわけではない。そして、アプリケーション開発でそれをやろうとした場合、開発するアプリケーションの中は同様の方法で性能を作り込むことがある程度可能かもしれないが、アプリケーションがOSの機能を要求した場合に、そのレスポンスタイムを制御することは出来ないという問題がある。もしも、厳しい性能を要求された機能を実行している最中に、マシンがWindows Updateの確認をし始めたら、通常では余裕で性能要件を満たしていたとしても期待する動きにはならないだろう。

Windowsパソコンを使っていれば誰でも経験すると思うが、アプリケーションをどんどん起動していくと、搭載メモリを使い切るちょっと手前あたりでピタッと動きが遅くなる。これは、起動されたアプリケーションを動かすために、実メモリからディスクに退避可能な領域を探し出して掃き出す処理をしながら空きメモリを確保しているからである。仮想記憶によって、実メモリよりもたくさんのメモリが使えると言われてはいるが、それを実用的な性能にするにはそれ相応の性能の(1シークで大量のデータを読み書きできる、大型コンピュータで使うような)ディスク装置が必要になる。これらのことを考えても、アプリケーション開発において性能を要求されても、それを阻害する要因をアプリケーションから制御可能な方法で排除できる仕組みがなければ、ほとんど実現不可能と考えて良いだろう。

普通に考えれば、空きメモリが残り1GBしかないのに、2GBバイト使用するアプリケーションを起動しようとしたら、何らかの警告が必要だろうと思われるが、Windowsはそういう動きはしない。ひたすら空きメモリを確保して、そのアプリケーションを起動しようとするだろう。その結果、たとえばパソコンの動きが止まったように見えたとしても、その処理を決してやめようとしない。これは、ネットワーク上の他のコンピュータから機能要求された場合でも、同様の動きをする。つまり、トラヒック制御をする機能がない。さらに、外見上止まってしまったように見えている状態を自ら検出する機能(故障管理)もない。

それはフォルトトレラントと言って、普通のコンピュータやOSには無い高価な機能だとエンドユーザには説明するのかもしれないが、そんな話を聞いても誤魔化されているとしか思えないだろう。要するに、最初からアプリケーション開発で性能要件など満たせるはずがないことを前提に話を進めなければいけないのだ。


さてここまでは、何年もシステム開発をやっていれば誰もが普通に感じる疑問というか、問題というか、インチキなのだが...ここ数年、民需系の案件を大小問わず何件かこなしてきて新たに浮上した大きな問題がある。これについてはツイッターで断片的に何度か書き込んだが、あまり芳しい反応は来ていない。

すでに死語であるかのように誰も口にしなくなった、ダウンサイジングという言葉がまだ生きていた頃、企業が導入するシステムは大型コンピュータからPCサーバへ、ソフトウェアはスクラッチ開発からパッケージ&カスタマイズへ、アプリケーション開発からWEB迅速開発へ、などの流れでどんどん進化、低価格化していった。このようにシステムの構築技術は進歩したが、エンドユーザは依然として置き去りにされたままだった。

エンドユーザはシステム開発の専門家どころか、コンピュータの仕組みもロクに知らないので、システムの中身がどうなっているかなど分かるはずがない。ところが、システム構築を行なう上で必要となる、要求事項の整理、システム仕様の承認、システムの動作確認を正しくタイムリーに出来なければならないことが暗黙のうちに前提となっている。出来上がったシステムがエンドユーザの望みどおりでなかったとしても、開発者は「ちゃんと仕様確認しましたよね?議事録承認もしてもらいましたよね?エビデンスありますよ?」と言って自分たちには何ら責任がないと主張するのが常だが、それでは問題は解決しない。

このような問題が起きる背景は明らかだ。企業がシステムを導入する場合、たいていそれを担当する人が主に開発ベンダと向き合い、その他の人は本業が忙しいので、誰が何処で開発を進めているかも知らないかもしれない。そしてある日突然、システム担当からシステム仕様の照会がまわってくる。次年度導入される予定のシステムの画面、帳票、大雑把な操作手順などが記されたドキュメントを突然見せられて、的確にコメントが出来る人が居るだろうか?

かなり会社に好意的に振る舞う人でさえ、突然見せられたシステム仕様に対して出来るのは、おそらく現在の仕事のやり方に沿っているかどうかのチェックくらいだろう。そして、どこの職場にも居るキーマン的な社員は忙しいので、それを丹念に読み込んで理解しコメントしているヒマなど無い。結果的にシステム仕様の確認は、現在の仕事のやり方に合っているかどうかの確認になる。それ以上のことを社員に期待しても無駄だろう。

しかし、ここで立ち止まってよく考えてみると、そもそもシステムへの投資目的は何なのかという疑問が湧く。会社によっては、今どき何処の会社でもコンピュータを使って仕事をしているのだから、うちの会社もそうしないといけないんじゃないか?と、経営層から社員まで漠然とそう考えているだけかもしれないが、普通の経営者なら、システムへの投資は将来回収してもなお余りある利益となって返ってこなければおかしいと思うだろう。ものすごく単純に考えれば、現在と同じ人員で売上が拡大するか、同じ売上を出すのに今より少ない人員で...のどちらかしかない。そのいずれにしても、今までと同じやり方をしていたのでは到底達成できないと考えるのが普通じゃないだろうか?

その上で、現在巷で行われているシステム開発を振り返ると、誠にお粗末な状況であると言わざるを得ない。企業が導入するシステムは、その会社の業務を効率化し、さらなる利益をもたらすものでなければエンドユーザは満足しない。ところがほとんどの案件では、提案段階で示されるコストパフォーマンスが絵に描いたモチでしかなく、結果的に業務のシステム化というよりは、業務のペーパーレス化+煩雑な操作性を提供するものでしかない。さらにそのような状況においてさえ、5年毎にやってくるシステム更改の度に初期構築並みの費用が必要になるという、最悪の事態がいたるところで散見される。このお寒い状況の中で近い将来、業務のシステム化から、業務のAI化への波が否応なく訪れるが、まだシステム化も満足に出来ていないのに、AIの導入に進んでいけるのだろうか?

もともと日本の企業の形態、および日本人の性質は、業務のシステム化には向いていない。終身雇用の社員が大勢居る中で可能な業務改善は、せいぜい部分最適化であり、業務の抜本見直しが行われることはない。もしも、終身雇用の老若男女がめいめい業務改善案を口にし始めたら、今までは一体何だったのか?ということになる。今までのやり方を是として継続してきた以上、システム化するからといって急にやり方を変えられるわけではない。さらに、売上拡大の見込みもないのに業務を効率化すれば、いずれ何人かは解雇されることになるだろう。

そろそろ中規模企業のシステム導入も、初期構築をほぼ終えて、すでに2~3度のシステム更改をしている会社もある。そうなると、どこの会社でもシステムの更改費、運用費の決裁がどんどん厳しいものになっていくだろう。今までどおりの業務フローをただコンピュータで実施するというだけのシステムに、毎度々々多額の投資をするほど経営者もバカじゃない。納期間際の確信犯的炎上ごっこも、そう何度も通用するわけではない。


では、どうすればよいのか?まずは、これまでシステムに払ってきた投資を社員に向けることだろう。システム化が単なる不便なペーパーレス化に陥っている責任の半分は、エンドユーザサイドにある。業務の効率化や抜本見直しを開発ベンダがしてくれるわけではない。それはその会社の社員がすべきことなのだ。もし社員にそのリテラシーが不足しているのなら、適当な業務パッケージソフトを選んで購入し、そのパッケージに合わせて仕事をしてみることだろう。そうすれば、システムを構築、更改、運用していくより安くて済み、さらに自分たちの業務をどうすれば導入したシステムに合わせられるか考えるようになる。これをやっていくうちに、社員のリテラシーはイヤでも向上せざるを得ないだろう。

社員のリテラシーがある程度向上したら、次に行なうべきことは業務をコンピュータで実施するだけでなく、社員一人一人の行動や意思決定をナレッジ(どういう場面で誰が何をしたか?その行為を誰がどういう理由で承認したか?)として蓄積していくことである。それを数年続ければ、あとはそれをAIが読み込んで有効な支援をしてくれるようになるだろう。


 

| | Comments (0) | TrackBack (0)

«年末ブログ:歌音ちゃん