本質的なもの、周縁にすぎないもの

私の今の職場のPCには、"Systemwalker"というソフトがインストールされている。
システム担当者に聴くと、ユーザーが何か困ったときに、システム部門側からPCを遠隔操作するために入れているという。

そのこと自体は良いことだと思う。
しかし、そのソフトでないとだめなんだろうか、それって有料だろう。

2016-09-23_150304.jpg 以前、勤務した職場では、フリーソフトの"VNC"を使っていた。やはりユーザーにトラブルがあったときに、システム部門が遠隔から操作するためである。

もちろんフリーソフトというのは、ライセンス方針によっては、組織的利用については制限、あるいは有償となる場合がある。しかし、それを措けば、"Systemwalker"でなくて"VNC"を使って何か問題があるだろうか。

前の別の職場では、VNCがインストールされていると遠隔操作ソフトが入っていると騒ぐ人がいた。何か勝手なことをされると思っているらしい。上記のようにユーザーサポートが目的の場合、「ローカルユーザが接続を受け入れるか問い合わせる」設定にしておけば、勝手に触られるようなことはないはずである(パスワード保護程度では、過去に脆弱性もあったし、パスワードハッキングされるおそれもある)。


そうかと思うと、随分昔のことだけど、ある会社でデータ集配信のシステムを見せてもらっていたところ、データ伝送の前に"lha"でデータを圧縮していることに気がついた。lhaはフリーソフトだが、製品に組み込んで利用するような場合は自由に利用できるか疑問があった。システムは大手メーカーに委託して開発してもらったものだから、そのメーカーがlhaを納品システムに組み込んでいたわけだ。

その場で会社の担当者にそのことを指摘して、メーカーに確認したらどうかと言った。もし無断利用だったら、うまくすればメーカーをいじめる材料になるでしょうと。


私自身が開発に関わったシステムでは、委託先にフリーソフトもあるじゃないかと言ったら、フリーソフトを使った場合、当社としては責任を持てなくなるので、ご勘弁くださいという返事であった。

なかなかカタいメーカーである。もっともその後、OSやDBMSも無償のものが多くなってくると、それも含めて責任を負わなければ商売が成り立たなくなっていると思う。


さて、これら、フリーソフトの使い方の差というのはどう考えるべきだろう。
私がシステム部門の担当者に言っているのは、

業務に本質的なものなのか、単なる便利ツールなのか、それによって判断すべきだ

ということ。
SystemwalkerやVNCの場合、それが動作しない(あるいはそれが悪さをする)場合、遠隔操作をするかわりに現地へ担当が走れば済むことである。これ自体が何らかの情報処理を行うというプロダクティブな性格のものではない。
対して、上に例示したある会社のシステムでは、lhaを組み込むことが情報処理の一部となっている。つまり業務に対して本質的要素になっている。

こうした点を嗅ぎ分ける、つまり、本質的なものと、周縁にすぎないものを弁別する能力というか、そうした物の見方ができることは、このことにとどまらず、システム屋が持っていなければならない能力だと思う。

その周縁的なものばかり凝っているのがマイナンバーのシステム。


スポンサーサイト

システム開発の品質管理

20160829-00000040-san-000-view.jpg 度重なるマイナンバーのシステム障害で、地方公共団体情報システム機構(J-LIS)が、開発委託先の富士通に対し、損害賠償を請求する方針と伝えられていた。

J-LISの対応としては至極当然、いかにもお役所的対応。
問題が起こったら、自分たちの責任を(一旦は受け止めるけれど、実質責任を負わずに済むように)転嫁するというやりかたである。

システムを開発するだけの技術力がないから委託するのは当然として、仕様の合理性をチェックする能力も疑わしい。
というより、仕様を示したら、こんな仕様は非常識ぐらいのことは委託先から指摘されたのではないだろうか、そしてそういう文句に対しては、出来ないというのかと上から目線で圧殺したのではないだろうか。(あるいはRFPをやっても評価できなかったとか)

そう思う理由は、マイナンバーシステム全体の制度設計が悪いこと、そのためITシステムを含んだグランド・デザインが存在しないように見えること、個人情報保護対策がセキュリティ技術の導入で誤魔化されている(そしてそのために高いコストと運用の困難さが伴う)ことなど。

法律を制定するときにシステム全体の妥当性などはチェックされていないに違いない。個人情報保護は修飾語の域を出ることなく、その修飾語のためにお金だけはかける。本来単純な名寄せシステムなのに、名寄せという言葉を嫌ったのか変な情報連携システムをつくって(これはセキュリティホールというか、情報管理を複雑化する要因)、問題を技術におしこめようという態度。
ITが入った途端に、何でもITのせいにする昔から変わらぬシステム音痴。それは法秩序を設計する能力がないことも露呈している。


マイナンバーの悪口はこれくらいにして、今日の本題はシステム開発の品質管理。
知り合いに大手の関連会社で、官公庁のシステム開発に携わったことがあるという人がいる。
曰く、官公庁の仕事はやりたくないそうだ。その理由は、
  • 仕様変更がやたら多く、しかもそれを契約の範囲と強弁して追加コストを払ってくれない
  • 仕様が妥当性を欠くと指摘すると、言われた通りにやるのが受託者の仕事という

私としては、システムを開発するときに、運用開始直前に仕様変更が発生するのはアタリマエのことで、それに対応できないこと自体、設計が悪いというか、受託者の設計能力の不足だと思ってしまうのだけれど、知り合いの言うことも理解できないわけではない。

というか、契約を結んでしまえば、システム開発においては、発注者と受託者は利益共同体だと思う。
受託者が手を抜くことが発注者の不利益になるのは当然だけれど、「手を抜く」というのが簡略化であるなら歓迎すべきことだ。それは開発コストの削減(受託者の利益)であると同時に、後々の運用コストの低廉化(発注者の利益)につながる。
ムリな仕様を押し通したら、システムのあちこちに歪み・綻びが発生してしまう。運用コストの増嵩はさけられない。
どうやったら簡素なシステムになるか、そして予想される仕様変更に柔軟に対応できるかを考えて設計すれば、追加コストの発生はかなり抑えられるし、強靭なシステムを作ることにつながるだろう。

そもそも発注者側の仕様変更なんて、実はたいした問題ではない。表示の桁数や並びを変えろぐらいのものである。あるいは単一テーブルに由来する項目だけではなくて、複数テーブルをマッチングさせた結果を表示してほしいというような(仮想テーブルを作れば済むような)簡単なものばかりである(もちろんデータベース設計がきちんとできているという前提だけれど)。


ところで、こういう発注者-受託者の合意形成において、受託者が品質管理(ISO9000)の認証を受けていると、会議・打ち合わせのたびに、受託者が議事録を作って、確認印を求めてくる。
合意した仕様を確認し、変更が発生すれば追加コストが発生すると言いたいらしい。

とりわけそれでプログラムは発注(多くは中国や東南アジア)してしまってるから、変更はすべてコストとして上乗せされると言う。馬っ鹿じゃないの。


だけど、開発を進めていくうちに、表示項目やレイアウトが変わることなんてアタリマエに起こる。それよりも、どういう変更だったらコストアップなしに可能なのか、つまりシステムの大枠・書法というものがしっかりしていれば、それこそ運用開始直前になっての対応ができるのではないかといつも思う。

そしてそれに対応できないのはそもそも設計が悪い。それだけで罰金ものである。
そういう設計の悪さは、必ずバグや保守性の悪さにつながる。
システムは出来が悪ければコストも高くなる。

以前、運用開始直前になって大量の帳票作成・検索プログラムが未着手になっていて、高額の人件費が発生すると泣きをいれてきた業者があった。そのときは提案書にあったBIツールを具体的には選定も提案もできていなかったので、こちらでBIツールを選定して、これを入れて、これでその大量のプログラムをやってしまえと指示したことがある。そんなものである。


話がそれたけれど、品質管理マニュアルに忠実にやられてもあんまり生産的ではないように思う。
品質管理技能がいくら優れていても、成果物の品質を保証なんかしてくれない。というか、品質管理を盾にとって文句をいう受託者は、たいてい品質に自信がないと思う。

時々思うのだ。受託者の資格条件に「ISO9000の認証を受けていないこと」と書けないかと。

ウォーターフォール型開発

最近はさすがに減ったようだが、ベンダーが持ってくるシステムの開発企画書にはよく「ウォーターフォール型の開発により手戻りが少なく品質の良いシステムを作ります」みたいなことが書いてあった。
もう10年くらい前からだろうか、こういう一文が書いてあると、それだけで企画の評価を下げることにしていた。

falling-water.jpg ウォーターフォール型開発というのは、作る側には都合が良いだろうが、ユーザーには特に恩恵らしきものはない。もちろん開発がうまくいって、品質の良いシステムが手戻りなく、低コストできればそれに越したことはないけれど、普通、開発委託契約をする場合は、特段の変更がなければ、委託費は最初に決まった額であり、手戻りがあろうがなかろうが、支払う費用に違いはない。バグがあれば瑕疵担保責任を問うだけだ。
つまりウォーターフォール型開発というのは、ユーザーの問題ではなく、ベンダー側の問題であり、それも結果論にすぎない。

写真はウォーターフォールならぬ"Fallingwater"(落水荘)。本文とは関係ありません。


もちろん、委託契約を結んだ以上、委託先と発注元は運命共同体であり、双方が協力してプロジェクトを円滑に進めなければならない。そうしないと信頼関係も生まれず、第一、仕事が楽しくない。

ベンダーもわかっていると思うが、ユーザーの要求というのは、システムの姿が見えてくれば、より鮮明になってくる。ここをこうしてほしい、ここは変えてほしい。ところが、伝統的なシステム開発では、画面や帳票のデザインが初期に決定され、この段階でユーザーは仕様凍結を求められる。つまり、システムがユーザーに見えてくる前に、仕様凍結を強いられることになる。

しかし、データ構造やシステム操作手順がわかってくると、画面や帳票への要求は変わってくるのが普通である。ここで仕様変更だと大騒ぎされるとユーザーは困ってしまう。

もちろん、一般にシステムはモジュールの組合せで動くわけで、モジュールの仕様が変わればそのモジュールを使用する他の部分がすべて影響されるから、そういう意味ではモジュールの仕様凍結は重要である。
しかし、画面や帳票の見た目というのは、通常、システム内の他のモジュールに影響を与えるわけではない。かりに表示するデータが別のテーブルなどに由来して異なるSQLを発行しなければ実現しないとしても、それはこのモジュール自身が解決できることであれば、システムの他の部分には影響しないわけだから、仕様凍結をする論理的な意味はない。

仕様凍結をするもう一つの意味は、ベンダー側の再委託という問題である。表示項目、その長さや形まで確定していないと、完全なプログラムとしての仕様書にならないから、プログラム開発を外部委託する場合は、そこまでの仕様が求められる。そしてその些細な変更でもプログラムの再開発として計上されることになる。日本のベンダーでは、このプログラムを海外に委託している例も多いようだから、これが外注経費を押し上げる結果になる。
これはベンダーの無能さの表れでしかない。このコストをユーザーに押し付けられてはたまらない。
一般に、同一システムを開発・運用する場合、そのコストはシステムの品質に反比例する。

品質管理の認証、ISO9000シリーズというのがある。これも嫌いなものの一つだ。
こういう認証をとっている事業所の場合、会議や仕様凍結のたびに、ユーザーに確認を求めてくる。そういうドキュメンテーションがなされないと品質管理の認証を取得できないからだ。そしてこれが正規の書類となって、これへの変更は通常、仕様変更として委託費の増額の根拠となってくる。
ISO9000は品質管理技術の認証であって、製品の品質を直接保証するものではない。
ISO9000を取得していてもいいけれど、それを振りかざされるとユーザーは大迷惑だ、と思うのである。

異論のあるかたも多いだろうけど、これだけは言っておこう。
いやしくもシステム技術者ならば、無批判・無自覚に開発手法を選択するのは恥ずかしいことだ。

歴史性と非合理なデザイン

駐車場で苦労しているドライバーを見てふと思った。

priuscockpit.jpg車のハンドル(ステアリングホイール)は、車輪の向きとハンドルの向きが一致する自転車やバイクのそれとは異なる。ハンドルを右に回すと、車輪は左に切れたりしては論外だが、ハンドルの回転角は通常車輪の回転角の20倍ぐらいになるだろう(ハンドルを2回転ぐらいで、車輪の角度は45°程度)。だからハンドルがまっすぐになっていても、車輪は切られていることもあり、初心者がまごつくもとになる。もともとは、重たい車の車輪を腕力で方向を変えるのは難しく、ネジ式で動かす機構となっていたのだと思う。今なら、電動ハンドルだから、自転車やバイクのように、ハンドルと車輪の向きを対応させることも無理ではなく、初めて運転する人にわかりやすいハンドルも作れると思う。
そうはならないのは、やはり既に普及し、慣れてしまったものにとらわれているのだろう。

lettera34m.jpgタイプライターのキー配列は左上からQWERTY・・・と並んでいる。何故この並びになっているのかいろんな説があるようだ。

フォントフェイスの面積が小さい文字は相対的に力が弱い指で叩くようにしたとか、
高速でタイプしたとき活字のロッドがジャムらないように、連続して出現する率の高い文字を打ちにくいように配置したとか。

今の技術では、力加減の調整やロッドのジャム防止など簡単、というより今は活字をタイプするプリンタがそもそもないから、最も指を動かしやすい配列にしたほうが効率が良く、そういうデザインのキーボードもあるらしい。しかし、QWERTYで慣れてしまった人にとっては、キー配列を覚えなおすなどとても面倒。ある研究では、もし効率的配列にするとタイプスピードは3割ぐらい向上が見込まれるという。しかし「3割程度の向上効果では再訓練コストに見合わない」とも。

bio_codon.gif遺伝学の勃興期には多くの数学者が遺伝研究に携わったと言われている。メンデルの法則はきれいな数学的構造を示しているし、いろんな遺伝にかかる知見が得られるようになると、タンパク質をコードするとかアミノ酸を指定するといったメカニズムの解明に数学が寄与すると考えられた。ところが、まだ、化学的実態がわからない段階での数学者の予想(たとえばコドンとアミノ酸の対応とか)は外れることが多かったという。間違いの背景には「自然がそんな無駄なことをするはずはない」という信念があったと考えられているそうだ。

最近の生物学の知見では、神経ネットワークははじめは至る所につながるように生成され、それが不要なものを間引くという戦略で完成するのだそうだ。無駄なように見えて、それが良いらしい。また、生物進化とは、冷房と暖房を同時に動かすような世界だと、ドーキンスが言っていたと思う(際限のない軍拡競争の謂)。
自然がそんな無駄なことをするはずはないというのは間違いだと気付かれてきたようだ。


われわれはいろんなところで歴史を引きずっているわけだ。

バーチャルということ(その2)

昨日に続いてバーチャルについて考えてみる。

昨日は英語virtualをめぐって、「事実上の」と「仮想の」がコインの裏表であること、また、コンピュータのためにできたような言葉と書いたが、もう少しふくらませてハード的なイメージだけではない点を書き足しておく。

Ptolemaic.png突然だが、地動説にもとづいて星々の運行を計算するのと、天動説にもとづいて計算するのはどう違うのだろうか。
話が逆になるが、本当は地面は動いていないのだが、地動説で計算するほうがシステムを理解しやすく計算が楽になるのだから、地動説を採用しておこう、というのがバーチャルの真骨頂である。
なお、コペルニクスがガリレオのような目にあわなかったのは、そういう便宜上の計算方法にすぎないというスタンスをとったからとも言われている。
Tychonian.png


(真の意味で地動説が受け入れられるのはケプラーを待たねばならなかった。
ティコ・ブラーエはコペルニクスの計算がそれまでより精確であったので、それを取り入れて天動説を精緻化しているそうだ。)



もちろん「そういうことにしておこう」は科学的態度だとは言えない。しかし一方で「オッカムの剃刀」という考え方もある。簡素なものが真実だという。
chidosetsu.png
真実が1つ存在するとしてもそれの記述形式は1つとは限らない。もし宇宙の運行が完璧に理解されているなら、天動説も地動説も等価だが、実際には真実に到達していないから、何が足りないのか、なにが矛盾を引き起こしているのか、というふうに、さらに真実に近づくためには、それを探求できる(しやすい)記述形式の方に値打ちがあり、それは天動説ではなく地動説なのだということなのだろう。


随分脱線したが、コンピュータ・アプリケーションもそれに似たところがあって、中では結構複雑なプログラムが動いているのだけれど、ユーザー・インターフェイスはシンプルでわかりやすいものが喜ばれる。

データベースの世界ではビュー(view)あるいは仮想テーブル(virtual table)という考え方がある。

私の経験では、ソフトウェア・パッケージのメーカーは、データベース構造を示したがらない。以前、SEにこんなことを言ったことがある。
「実際にデータベースがどうなっているかは企業秘密かもしれないから、それを公開しろとは言わない。しかし、ユーザーがデータベースをどう理解すれば良いかを教えてほしい。そうすれば、この操作をするとどのデータに影響するのかなどが予測でき、煩雑な操作マニュアルを覚える必要がなくなり、誤操作を回避する役にたつはずだ。可能ならそれをビューとして定義してもらえればBIツールやデータをダウンロードしてExcelで分析するなどができる。」
すぐには応えてくれなかったが、開発が遅れたため、帳票類のプログラムをBIツール(発注者側で選定・手配したもの)で実現することになり、結果的にはデータベースの公開に近い状態となり、一気に開発がスピードアップしたことがある。

今日主流の関係モデル(Relational Database、理論は既に1964年にできている)では、中心的なデータから冗長な部分を縮ませるいわゆる正規化という操作を行うが、逆に正規化されたデータベースから中心的なデータを、冗長でも1枚のテーブルにすることができれば安心する。
システムの発注仕様には是非入れたい項目なのだが、多くのパッケージ・ソフトは自分自身が崩壊してもデータが有効利用できるという発想では作られていない。別のパッケージへの乗り換えを阻止するため、高い移行料を要求するなど、データ移行をやりにくくする工夫かもしれないと勘繰りたくなる。

バーチャルということ

バーチャル(virtual)という語には、「実質上の・事実上の」と「仮の・仮想の・虚の」という一見相反する日本語訳がついているが、相反していると感じているようでは、virtualという言葉を理解しているとは言えない。
virturalmemory.png
virtualは、語源的には、virtus(優秀性・能力・効力)から出て、「優越性によって影響を与えることができる」⇒「そのものではないが事実上」という用法が15世紀頃に現れたという。この「そのものではないが」から「仮の・仮想の」という日本語訳がはまる場合がある。「事実上の」と「仮想の」は相反するのではなく、コインの裏表なのである。

virtualが「ハードウェアではなくソフトウェアによって見せかけられている」という意味のコンピュータ用語として初出は1959年というが、コンピュータ史を調べると1959年に仮想記憶(virtual memory)のベースとなるページング技術のプロトタイプが出ているようで、多分これが最初なのだろう。


virtual(adj.)
late 14c., "influencing by physical virtues or capabilities, effective with respect to inherent natural qualities," from Medieval Latin virtualis, from Latin virtus "excellence, potency, efficacy," literally "manliness, manhood" (see virtue). The meaning "being something in essence or effect, though not actually or in fact" is from mid-15c., probably via sense of "capable of producing a certain effect" (early 15c.). Computer sense of "not physically existing but made to appear by software" is attested from 1959.

(http://www.etymonline.com)


virtualは、まさにコンピュータのためにできたような単語だと思う。
仮想記憶(virtual memory)、仮想ドライブ(virtual drive)、仮想マシン(virtual machine)、・・・
至る所でvirtualが使われるが、いずれも「実体がどうであるかは無視してそのように機能する」という意味で、ブラックボックスの発想に通ずる。

仮想記憶(virtual memory)もはじめは少ない主記憶を補助記憶装置で補う発想だったのかもしれないが、アドレッサブルな全域を一つのメモリとして扱える仮想空間(virtual storage)へと発展することにより、まさに事実上のメモリ空間になったと言うことができよう。

チーフ・プログラマー・チーム

プログラミングはシステム開発の基本である、仮にプログラミング自体が発生しなくても。

昨日、プログラマー⇒システム・エンジニア⇒プロジェクト・リーダーという階層図を示した(同時に否定した)が、プログラマーの地位が低いというのは、こういう組織論をする人がシステム開発肝心要のところを知らないということなのだと思う。

昔、ソフトウェア・エンジニアリングというのがはやった頃の話だが、システム開発体制としてチーフ・プログラマー・チームというのが有名になったことがある。IBMがプロジェクトを組むときにはこの方式をとるらしい。
CPT2.png
その要点は、チーフ・プログラマーというある意味万能の存在がいて、この人がシステムの全体構成や中核的な部分(たとえばデータベース設計やキーテクノロジーの抽出など)を行い、それを支援するために必ずライブラリアン(ドキュメントを管理し常に最新状態を維持、他にテクニカル・ライティングも)を置く、そしてチーフ・プログラマーの配下に一般プログラマを置き、チーフの指示によってモジュールレベルの開発を担当する。

これが基本構成で、プロジェクトの大きさによってテスター(独立してテストを行う)、バックアップ・プログラマーを置く。せいぜい5~7名ぐらいのチームというわけだが、これで相当大きなプロジェクトを実施できるという。(1年働かせても1億円程度?)

もちろんプロジェクトがもっと大きければ、チームを階層的に設置する必要はあるのだろうが、基本はコンパクトな構成である。「遅れているプロジェクトに人員を投入してはいけない、遅れを酷くするだけだ」と言うが、プロジェクトを動かすには密なコミュニケーションが必要であり、いたずらに膨れ上がった体制は機能しない。
以前、「システムは一人でやるのが理想」と書いたが、チーフ・プログラマーはまさしくその一人である。

この方式の問題点は、多くの人が指摘しているが、チーフ・プログラマーの人材がいないことである。

コンピュータ・システム・エンジニア

単にシステム・エンジニアでも良いわけだが、昨日書いたように、フォン・ブラウンのような仕事をする本物のシステム・エンジニアと区別するため、コンピュータ・システム・エンジニアとした。以後はSEと書くことにする。

さて、SEというのは特定の技能を指す言葉だろうか。世間で普通に使われているのはどうもそうではないようだ。コンピュータ周りで働く人で、金物をいじらない人をSEと呼んでいるように思う。
それで、SEというような一般的な名前では、職務やスキルを表していないという意見があり、最近はITSS(IT Skil Standard)などでは、ネットワーク、データベースといったITの専門分野のスペシャリストということで、ネットワーク・スペシャリストとかデータベース・スペシャリストと呼ぶべきという意見もある。あるいはSEを使う場合でも、ネットワークSEとかデータベースSEという具合である。こういう発想だと、SEは専門性が低く、ITスペシャリストより低い地位におかれている。

しかし、私が思うに、これはフォン・ブラウン型の本物のシステム・エンジニアに代わるものではない。現実にはフォン・ブラウン型のSEなどいないからといって、SEをITスペシャリストと言い換えて済む問題とは思えない。本物のシステム・エンジニアがいないという問題なのだ。
やっぱり、「私はシステム屋ですから」というシステム屋の矜持のようなものを期待したい。もちろん、「ネットワーク屋」とか「データベース屋」というのも立派な職能なのだけど、システムズ・エンジニアというのはそれとは違う存在として考えたい。

システム・エンジニアとITスペシャリストの違いは、言語学者と英語の先生の違いのようなものだ。生成文法と英語の文法の違いである。
Chomsky-crop.jpg

システム・エンジニア

自分のことを「システム屋」と言うことがある。
昔、某コンサルの人(今は某大学の教授)が、会議や打ち合わせの席で「私はシステム屋ですから・・・」と言うのを時々聞いていて、便利な言葉だと思った。
その先生はその時どう思って使ったのかわからないが、「私はシステム屋ですから」というフレーズには「私は職人ですから」というニュアンスを感じる。整然とした理論体系があるわけではないが、経験と勘で最上のものを作ることには自負がある、そんな感じ。そして自分が慣れ親しんで体の一部になっている技術が、急激な技術革新で陳腐なものになって、もう直接には新しい成果を産むことはなくなる、残っているのはものづくりの智慧として昔語りになるようなものだけ、そういうところも職人的。

「システム・エンジニア」は、そういう卑下と自尊のコンプレックスが付着しないドライな言葉だが、システム・エンジニアというと必ず思い出されるのがアポロ計画のウェルナー・フォン・ブラウンである。
フォン・ブラウンは、自分の専門・職業は何かと聞かれたときに、システム・エンジニアだと答えたと伝えられている。
250px-Wernher_von_Braun.jpg

Systems engineering is an interdisciplinary field of engineering that
focuses on how complex engineering projects should be designed and managed.

(Wikipedia)

2年程前に、宇宙教育に関するイベントでJAXAの職員の講演を聴く機会があった。その方がフォン・ブラウンを意識していたかどうかはわからないが、ロケットを開発・打ち上げるプロジェクト全般を運用する仕事を説明されていた。
※ SE(システムズエンジニアリング)とは
システムの目的(ミッション要求)を実現するための工学的方法論(及び、その一連の活動)です。
なお、ここでいうシステムとは、ある目的を達成するために組織化された機能要素の集合であり、組織化により単なる要素和以上の特性を発揮するものです。(JAXA SE推進室ホームページ)

これらの例でわかるように、システム・エンジニアとは、システムあるところ、より正確にはあらゆる事象中にシステムを見出し、最適化までを考えるジェネラリストと考えるほうが良いと思う。

世間でいわれるシステム・エンジニアは、コンピュータ関係の技術者というぐらいの意味で使われる例が多い。そもそもシステム・エンジニアと名乗っている人でも、前述のようなシステムズ・エンジニアリングの意義を理解している人は少数で、「システム」は「コンピュータ・システム」の略だという意識なのではないだろうか。
ところで、講演されたJAXAの方は、「システム」と、を強調されていた(英文では通常複数形)。「コンピュータ・システムのエンジニア」ではないということを強調されたのだろう。

「アプリ→データ」か「データ→アプリ」か

WindowsPCを使い慣れたユーザーは、ファイルを右クリックしてコンテキスト・メニューを出して、どのソフトで開くか指定する使い方をすることが多いと思う。例えば画像データについては、ちょっとレタッチするとか、サイズを変更するとか、一部をトリミングしようとか、何をするかによって使いやすいソフトが違ったりするので、コンテキスト・メニューはとても便利である。「プログラムから開く」でも良いが、1アクション減らすためソフトのショートカットを shell:sendtoに置いておく。
context.png

Androidにはインテントという機能があり、同様のことができる。Androidの場合はインテントで標準アプリを設定することもできるから、Windowsの拡張子からのソフト決定と同じことをインテントの設定で行うこともできる。
乗換案内とか天気予報、ネット放送といった専用アプリはともかく、オフィス系やエディタの類はファイルブラウザ(私はESファイルエクスプローラー)からインテントでアプリを選ぶのが私流。
share_2014-06-10-14-42-50-crop.jpg

iOSでも似たようなインターフェイスを持つアプリがあるが、iOS自体が任意のデータファイルに対してアプリを選択する機能はないと思う。iOSはまずアプリを選択し、次に処理するデータ(選択の余地なく決められたファイルである場合が多い)を選択する。

表計算ソフトは、初期にはLisaというソフトがあり、Multiplan、Lotus1-2-3、Excelと同種ソフトが競っていたが、今はExcelが完全に主流になったと思う。
この種のソフトでは、機能選択→何に、という操作方法と、対象選択→何を、という操作方法がある。どのソフトも両方の操作が混在しているし、まず機能を選ばなければデータの選びようがないものもあって、どちらを主に考えるかという違いにすぎないのだが、使い勝手は微妙に違うと思う。
Excelの基本は「何に対して何をする」で、他のソフトは「何をする、何に対して」が基本あるいは混在していたように思う。

私は「データ→アプリ」派である。

20年近く前のことだが、施設予約システムの開発を企画したとき、はじめにメーカーが用意してきたユーザーインターフェイスは、メニューを順に選択してから対象のコマを設定する(トップメニューが空き検索、予約設定、・・・とあって、次に施設選択、日付選択となるような)ものだったが、多分に個人的好みだが、端末の画面は予約状況を一覧表示する画面を通常の状態にしておくのが便利なはずだから、その画面からグラフィカルにコマを選んで予約を入れるような流れ、Excelのようなインターフェイスにしてほしいとお願いしたことがある。
メーカーにしてみれば開発方針の根本的変更になるわけだが、なんと、私の希望に応えてくれた(もちろん追加費用なしで)。当時はパッケージがなく、ほぼ完全なスクラッチ開発だったのでメーカーもいろいろ新しい工夫をした。
すばらしいSE達だった。

モジュール(サブシステム)の適正評価

今まで、モジュール(サブシステム)をとりあげ、大きなシステムを設計するときには、適切にモジュール(サブシステム)に分割することの重要性を説いたつもりである。
今日は、分割が適切かどうか判断するポイントとなるモジュール(サブシステム)が持つべき性質について考察する。

ところで、モジュールとサブシステムの用語だが、これらは情報システムの設計においては、用語の使い方には微妙なニュアンスの差があるが、本質的には同じ概念を指し示すものだと思っている。
モジュールという語は、それ以上分割して考える必要がない(⇔分割できないわけではない)、単位的な要素である、というニュアンスがある。これに対し、サブシステムは上位システムの目的と同じぐらいのレベルの部分目的を持ち、それ自身単独でも意味がるようなイメージがある。
2014-05-19_102558.png
Wikipediaなどを見るとモジュールの望ましい性質がいくつかあげられている。詳細はWikipediaを見てもらうとして、私なりの理解を()内に付した。
    ・結合度が低い(1つのモジュールの変更が他のモジュールの変更を要求することが少ない)
    ・凝集度が高い(そのモジュールの機能と関連のない動作はしない)
    ・粒度が高い(分担している機能が直感に一致している)

なお、私は「結合度が低い」の裏返しで、「独立性が高い」という言い方を好む。独立性が高いとは、他のモジュールの内部状態に影響されないという意味で、モジュール間の関係は呼び出し時のインターフェイスで規定される。呼ばれる側のモジュールは、機能を実現するために内部状態を保持する必要がある場合があるが、その管理は当該モジュールが行うという意味である。なお、大域的メモリを複数モジュールが共用するシステムの作り方もあるが、大域的メモリを1つのモジュールと考えて管理することで、独立性を確保する。
情報処理技術者試験でもモジュールの意義や望ましい性質が出題されている。システム開発におけるモジュールの意義は強調しすぎることはないから、これは良い傾向だと思う。

私は学生時代にコンピュータを道具としてプログラムを書いたことはあるが、コンピュータそのものを専門として学んだことはないので、就職してコンピュータの仕事をするときに先輩に教えてもらったのが、モジュールという概念、そしてモジュールの独立性という考え方だった。

プログラム言語の世界では、コンパイルの最小単位がモジュールで、これはサブプログラムと一致する。この意味で、プログラマが書いたものをソース・モジュールと言い、コンパイラがそれを機械語に翻訳したものをオブジェクト・モジュールという。サブプログラムの呼び出しは引数の並びというインターフェイスで完全に規定される。たったこれだけの単純な考え方とプログラミング書法を守るだけで、大きなプログラムを開発する効率は劇的に上がる。

FORTRANは、このような書法をとりやすい。私は特に言語を指定されない限りFORTRANユーザーだった。当時、世間ではなんとなく事務処理用言語はCOBOLという風潮だったが、COBOLは、モジュールの重要性を無視したとまでは言わないが、モジュールを基本にプログラムを書くことには向いていない言語である。COBOLで育った技術者は大抵、システム・センスが悪いと感じたものだ。

ブラックボックス

昨日は「頭のよい人はカッコをつける」と題したが、カッコをつけられるようになれば頭が良くなったように見える。
括弧に括る操作は、とりあえずその中身を見ないようにして、括ったものをまとまった1つのものとして扱う、という操作である。人は同時にいくつものことはできないが、括弧に括ることで注目する対象の数を減らすことができる。これが見通しを良くする極意というわけである。
(括弧に括らなくても理解できるのは超人技で、普通は括弧で括らないと理解できないというのが真実だろう)

昨日は、そこからルールの再帰的適用の話をしたので、括弧に括るという操作が強力だということは説明できたかもしれないが、イメージがとりにくかったかもしれない。

そこで今日はモジュールをブラックボックスとして考えることにする。
ブラックボックスというのは、入力が決まれば出力が確定する機能(function)をもつものを抽象化した概念であり、その中で実際に何が行われているかは捨象(隠蔽)される。
blackbox1.png

ブラックボックスという考え方は遠山啓先生の高校数学の参考書で知ったもので、関数(function)を説明するものとして使われていた(ちなみに関数は昔は函数と書き、函は箱のことである)。このブラックボックスの絵も遠山著書にあったものをマネてみた。

例えば、自動販売機をブラックボックスとみると、コインを入力としてジュースが出力となる(商品選択はないものとすると)。
数学の関数というのは、たとえば、 f(x)=x+3  という風に数式で書くことが多いわけだが、この例だと 0を入れると3が出てくるというわけ。

同様に入力が2つある場合、もっとたくさんある場合も考えることができる。
blackbox2.png


何ということもないわけだが、ブラックボックスの考え方を取り入れるだけで、システムの見通しが良くなる。

次に、f  と  g  の2つのブラックボックスをつないで作用させることを考える。
blackbox3.png
このとき、g・f という新しいブラックボックス(数学では合成関数)が1つと考えることができる。その中身である  f  や  g のことは「忘れる」。つまり簡素化される。
blackbox4.png


こうして大きなブラックボックス、小さなブラックボックスが組み合わされて、設計者やその指示を受ける人にわかりやすいものにすることが、システム設計の要諦である。

日常用語としては「ブラックボックス」はわけのわからないものという否定的なニュアンスでとらえられているようだが、本来のブラックボックスは入力が決まれば出力が確定するものを指す。何が出てくるのかわからないのはグレーボックスと呼ぶべきでは。

同じように日常用語が変なのは「抽象的」も。わけのわからないものを抽象的と呼んだりするが、本来抽象とは、対象から本質的なものを取り出すことであるはず。

頭の良い人はカッコをつける

前にシステムを考えるときにモジュール概念の重要性について書いた。
モジュール概念がどれほど強力なのかを説明しようと思う。

本稿の表題「頭の良い人はカッコを付ける」というのは、次のようなことである。

中学校の数学では、数を抽象化してその操作(演算)について教える。
    結合法則 (a×b)×c=a×(b×c)
    交換法則 a×b=b×a
    結合法則 (a+b)×c=a×b+b×c
である。

この三法則から、たとえば (a+b)×(a+b)=a×a+2×a×b+b×b という展開公式を導く。
(抽象化以前では、普通は書かれた順に計算する。(2+3)×(2+3)=5×5=25 というふうに。これで実生活は事足りる)

頭の良い子は、これを直ちに理解する。
    (a+b)×(a+b)
        =(a+b)×S        (ここで S=a+b とする)
        = a×S+b×S
        = a×(a+b)+b×(a+b)
        = a×a+a×b+b×a+b×b
        = a×a+2×a×b+b×b

ここに働いているのが a+b を括弧に括る(括弧に括ってそれをSとする)という操作である。

括弧に括るという操作を覚えるだけで、そして繰り返しそれを適用する(再帰的に適用する)ことができることを理解するだけで、文字式の展開という操作はできるわけで、こういう子供たちは展開することが目的ではなく、次の単元である因数分解(展開の逆操作)のパターンを覚えることを目的として練習する。

このように括弧で括るという操作は大変強力であり、抽象的操作では必須のものである。

システムを考える上でモジュールを設定することは、この括弧で括る操作と同等だと私は思う。
それによってシステム全体の見通しが大変良くなるはずだ。

もう一つ、括弧で括る例。
……「「「鏡に映る様子」が鏡に映る様子」が鏡に映る様子」が鏡に映る様子……
blackswan.jpg


システム開発における分業、システム私論2

昨日は、システム開発は一人でやるのが理想、と書いた。しかし、現実には一人でできることは限られているから、複数人で分業することが多いだろう。昨日と内容的には同様だが、今日は分業に注目してみる。

分業には、大きく分けて2つのタイプがある。
一つはシステムを構成するサブシステムごとに分業するもの。一回り小さくなるが仕事の質は同様、同質分業
もう一つは、開発に必要な技術や外部資源の利用などの専門性に応じて分業するもの。専門性分業
bungyo3.png

同質分業は、サブシステムへの分割が前提になる。
前にも書いたが、多くの人からの情報収集や意見交換を行う必要があっても、1人の中心人物がすべてに参加し、企画をかためなければならない。その過程の中でサブシステムが見いだされてくる。私の経験では「あ~でもない、こ~でもない」と悶々とし、さまざまな情報を脳にぶち込んでいく中で、あるとき「あ、ここで線を引こう」というようにひらめくように思う。(こういうと「ひらめき」次第のようだが、システムの中心となるデータベースを措定して、それとの関連を整理するやりかたが基本。)
そしてこうして抽出されたサブシステムが大きければ、それはサブプロジェクトとして他の担当者をリーダーとして充てがうことになる。

専門性分業は、調達する技術・資源の専門性や、比較優位原理に基づいて効率性を追求するもの。
実際にものを作るという段階になると、適用する技術や外部から調達する資源により、それぞれ得意な専門スタッフを割り当てることになる。
一昔前の汎用計算機によるシステム開発では、適用する技術・言語は与えられた環境に制約された特定のものが使われ、SEとプログラマーの区分も曖昧で、能力の優劣はあっても、質の違いはないスタッフでチームを構成することも結構あったが、近年はさまざまな部品やミドルウェアを組み合わせることになるから、「異能の士」を集めることになる。データベース屋、ネットワーク屋、プログラマーといった具合。

また、プロジェクトによっては、こういう技術が必要になる、という予測があり、その技術がプロジェクトの成否を決める(プロジェクトのキー・テクノロジー)。未だインターネットもブラウザも出始めの頃、ブラウザを使った画面制御をやろうとしたシステムでは、その可能性・限界の確認に努めていた。
なお、専門性分業の考え方は開発チームとその環境に広げて考えるのも有効だ。私には、システム運用時に使用する印刷物等の手配や初期データの入力作業を、開発チームではなく営業の担当者がとりまとめてくれて、すごく助けられた経験がある。
【専門性分業のイメージを持つための簡単な例】
件数不明の複数ファイルが収録されている磁気テープについて、その各ファイル(の先頭数ブロック)をスキャンしてレポートを出すというプログラムが必要になったことがある。
テープマーク(テープに記録されている特殊な磁気パターン、ファイルの切れ目などに記録)への位置づけ・読み飛ばしを行いながら、データ部分を読むことが必要だが、高級言語ではこうした処理はできないから、アセンブラで磁気テープ装置(実際にはチャネル・プロセッサー経由)にこれらのコマンドを送るモジュールを作成する(設計者にアセンブラの技量がないなら、それを持つ人に頼む)。
このモジュールの動作確認ができなければ、全体のプログラム作成に着手することはできない(動作不良なら別の戦略が必要となる)。

システム開発体制の提案や説明を求めると、このような分業体制が示される。多くのプロジェクトでは、過去の経験や同種事例から、ある程度事前に分業の方法やサブシステムの設定がイメージされており、最初からそれに基づいてプロジェクトが組まれるだろう。それはそれで良いのかもしれないが、忘れてならないことは、

どのように仕事を分けて、誰に担当させるか、分業について、きちんと考えたのか、根拠があるのか、
「一人ではできない(のは当然)、だから分業する(のも当然)」という安直な考え方で分業と言っていないか。


分業するということは、それ自身、既に設計が始まっているということなのだ。

開発は一人でやるのが理想、システム私論1

現代のシステム開発では、大規模なものは言うまでもなく、小さなシステムでも、それを動かすためにはさまざまなモジュールが関わっている。
それだからこそ、一人の人間がシステムの端から端まで見渡せ、どこで何をやっているのか、どことどこがどういう関係でつながっているのかをすべて把握できるシステムが望ましい。一人の人間が見渡せる=適当なサイズにシステム規模を抑えることはきわめて重要な課題である。

開発段階のことを考えよう。一人の人間の知的能力はとても大きくて、システムを構成する個々の要素が未分別な混沌とした状態から、要素を分別・抽出し、それらの相互関係を決定するという難問をひらめき一つで解決することもしばしばある。(そうした課題の解決方法は昔から業務分析とか、もっと一般に発想法とかたくさんの本が出ていると思う。ここではどうしたら課題解決ができるかには触れない。これが一人でやらなければならない作業だということを主張したいのである。)
しかし、やみくもに人員を投入し、分担させると、混沌状態から要素を分別・抽出する作用は働かない。裏返して言えばあたりまえのことである。すなわち、要素の分別が終わってからでなければ要素単位に分担することはできない、ということである。
一人で見渡せる範囲
システム規模を一人の人間が見渡せるサイズに抑えると、大規模プロジェクトができないという声がありそうだが、人間の認知能力はシステムを入れ子にすることでいくらでも拡大される。どんなに大規模なシステムでもそれを分解すれば数個のサブシステムになる。一人がシステム全体、すなわちシステムを構成するサブシステムを分別・抽出し、その相互関係を十分に理解しており、別の人間が、一つのサブシステムを自分が担当するシステムとして同様の認知能力を発揮すれば良い。
実際には一人の人間でもこうした深い階層の認知を相当程度やれるのだから、複数人が分担することでシステムの規模はいくらでも拡大できるのである。それが表現されているものが人間の文化、法律や各種制度、インターネットなどの社会システムということになるのだろう。

ところで、こういう入れ子的発想で、ものごとを簡素化することには役人の方が長けているかもしれない。たいていの場合、役人は担当業務の専門家ではない。彼らは担当業務に必要な、資源、知識、コストを綜合化して施策にすることが仕事である。そこに求められるのは、事業を大括りに見通し良くする技術であり、1ページで事業全体を説明するような作文・作画が必要である。

話は少し違うかもしれないが、一般の商品開発でも一人でやることが重要という場合があるそうだ。三宅秀道「新しい市場のつくりかた」(書評は別の機会にしたい)では、ニーズがおぼろげに見えたとき、それを商品にする段階においては、一人の担当者が携わるのが良いということを、例を引いて説明している。商品を一人で作ることはできないかもしれないが、企画は一人(議論をし情報交換する相手はいるが、そのすべてに参加する一人)がやるのが良いのである。


システム私論、その序

昨日、ブログを一貫するテーマを用意しないとネタに困ると書いたわけだが、テーマを設定してお持ちネタがなければ続けられない。ということで、情報システムはどうあるべきかについての私流に考察したところをテーマにしようと思う。

私はシステム開発の経験はそれほど多くはない。それも基本的には発注者という立場であり、自分で設計開発した経験は、そうとう前で、それも小規模なものに限られる。経験ということであれば、メーカーやソフトハウスの人たちの方がはるかに多いに違いない。
それでも、こうしたことを書く気になったのは、発注者として関わったいくつかのシステム開発プロジェクトにおいて、委託先の作業が不透明で、ただ忙しがっている、結論を急ぎすぎる、発注者に理解できるドキュメントが出てこない、などなど不満がいっぱいで、発注者側の責任者として大変居心地が悪い思いをしてきたからであり、そうした開発プロジェクトで、私がいつも繰り返して委託先に求めてきたこと、提案してきたことをまとめてみようと思う。また、その前段階であり、発注者最大の関心事である委託先選定・調達方法、仕様書についても言及していきたい。
logo_iso9000.jpg
ここで書くことは、私にとってはアタリマエのこと、素朴な疑問なのだけれど、なぜか日本のメーカー、ソフトハウスというところはちゃんとしたポリシーを持って開発プロジェクトを進めているとは思えない。
たとえば、品質管理の国際基準ISO9000というのがあり、多くの企業がこれを名刺に刷り込んで宣伝している。しかし、システム開発プロジェクトにおいて、ISO9000のありがたみを感じたことはあるだろうか。私は無い、というかそのためにやたらドキュメントが増える弊害を蒙る。
何故そう思うのか?
答えはシンプルである、品質管理の技術は持っているのかもしれないが、肝心の成果物の品質が伴わないからだ。ISO9000以前の問題なのに、ISO9000だからOKと考えているのではないか。

私は、委託契約の締結後は、発注者、受託者は運命共同体だと思っている。
発注者が無理な注文をつければつけるほど成果物の品質は落ち、受託者は経費が嵩む。無理な注文はしないに越したことはない。システムはシンプルなほうがエンドユーザーにも良く(と私は信じている)、それは開発者にとってもコスト削減になると信じている。

ユーザーと開発者が、良いものを作ろうという思いを共有することが幸せでしょう。
Gallery
検索フォーム

⇒記事一覧

プロフィール

六二郎。六二郎。


定年退職
苦しい家計の足しに再就職
=いつクビになってもええねん
 言うたもん勝ちや!のブログ
リンク
最新記事
最新コメント
最新トラックバック
アーカイブ
カテゴリ
タグ

書評 ITガジェット マイナンバー Audio/Visual 

現在の閲覧者数
聞いたもん