December 14, 2016

マルチスレッド貧乏性(6)

そろそろマルチスレッドをネタにした與太話も終わりにしないといけない。

マルチスレッドでソフトウェアを構成する目的は、極論すればコスパの追及に他ならない。噂によればGoogleのマシンルームにある膨大な數のサーバ羣は稼働率80%に達しているという。これはコンピュータの性能をほぼ100%引き出し、フルに活用していると言って良いのであろう。いい加減なサイジングで構築し、大して活用していないサーバなんて稼働率10%もいかない。そして、サーバ稼働率を上げる最善策がマルチスレッドプログラミングでないことくらい誰でも知っている。

マルチスレッドはコンピュータリソースを無駄なく活用するための一手段に過ぎない。さらに言えば、スレッドライブラリを活用して、複數のスレッドを制御しながら動くプログラムを書くことだけがマルチスレッドではない。スレッドライブラリというものが登場する以前から、UNIX上でのプログラミングにおいてマルチスレッドという槪念はあった。つまり、複數のプロセスを協調させて處理を構成する方法(マルチプロセス)である。

マルチプロセスはマルチスレッドに比べてソフトウェア的に安全であると言われている。マルチスレッドでは、1個のプロセス内で複數のスレッドがグローバル變數を共有するため、場合によっては意圖しない變數の書き換えや參照が發生し、潛在的な問題(瑕疵)が殘留しやすい。さらにスレッドセーフという言葉に集約される、固有のルール(再入などの問題對應)やプログラマのスキル、經驗値が品質を大きく左右する。それに比べてマルチプロセスでは、他のプロセスによる不用意な變更から保護されるので、プロセス閒インタフェースだけを意識してプログラムを書くことが出來る。

そもそもスレッド閒インタフェースなど有って無いようなものだ。そういう問題を覆い隱すために出てきたのが、機能とデータのカプセル化(いわゆるオブジェクト指向)であると思われるが、これについてはここでは觸れない。OOPはそのためだけにあるわけではない。

そういう意味で、これまでのGNU Emacsの實裝理念は正しかったと思う。必要なら複數のEmacsを起動し、相互に協調させたり、それらの處理がすべて終了するのを待つことなど、いくらでも可能である。少なくともスレッド閒のインタフェースを曖昧にしても構わないような方法より大いにマシと言わざるを得ない。今のところ、Emacsにおけるスレッド機能はかなり限定的であり、今後どうなるかは分からないが、一例をあげれば、letバインディングは起動した先のスレッドで參照不可である。スレッドライブラリの使用によりスタックが別になるならそれも當然と思われるが、そのためだからといって起動するスレッド每にグローバル變數が必要となるのはどうなんだろうという氣がする。しかし、それが數多くの既存の資產を守るためであれば致し方ない。現に一部のパッケージに影響が出ているという話もある。閒違っても、マルチスレッドを實現するために既存のlispコードをすべて書きなおすなんてことはあり得ない。

マルチスレッドする前に、マルチプロセスで可能か事前檢討する必要があるだろう。假にそのため1GB餘分にメモリが必要になったとしてもせいぜい數千圓(SE單金で1時閒分もしない?)もあれば濟むではないか(笑)

| | Comments (0) | TrackBack (0)

マルチスレッド貧乏性(5)

さてもさて、冗談はさておき...偶然というか、時代の趨勢というか、アホかっ!というか、マルチスレッド好きが好きにマルチスレッドできる便利な口實が出來つつある。

CPU時閒の殘りカスをいくら掻き集めたって、所詮カスはカスと思っていたのだが、システムはスレッドという名の殘りカスで動作することを前提とすることが主流になり始め、スレッドにより多くのCPU時閒を割り當てる必要があるというので、CPUGPUがどんどん高性能化し、どんどん高集積化し、ナノプロセスルールなどというものが登場した。それによりCPUの低クロック化傾向とマルチコア化がどんどん進んだおかげで、個々のスレッドの性能がどんどん惡くなり始めた。これは私自身も身をもって經驗したのだが、ひと昔前のデュアルコアCPUを積んだサーバよりも、最新鋭6コア、8コアCPUのサーバの方が、バッチ處理などにかかる時閒が目に見えて增大してきているのだ。

この流れは、システムソフトウェアの生產性向上とも呼應して、OSの高機能化、Javaなどのアプリケーション構築環境の充實により、ただでさえ殘りカスのCPU時閒が壓迫されつつある。その上、生產性向上のための對策がよりダメなプログラマを大量生產したため、ソフトウェアの性能はさらに惡くなる一方となった。

整理すると、ひと昔前よりも1スレッドの性能がハードウェア的にもソフトウェア的にも惡くなり、畫面制御もデータベースもバッチ處理もマルチスレッドで組まないとさっぱり性能が出ない、という狀況になった。1スレッドでシリアルにガリガリ動く處理をいくら效率化しても、8コア16スレッドのCPUでは16分の1の性能しか出ない勘定になる。殘りの16分の15CPUリソースを使う唯一の方法が、ソフトウェアのマルチスレッド化ということになってしまったのだ。そしてそのような狀況下でも、高度な整合性を保ってきたGNU Emacsまでもがついにスレッド機能を實裝せざるを得ないハメになったというわけだ。

それでも、優秀かつ賢いSEやプログラマが、マルチスレッドなんてしなくたって、こうすればCPUを餘すことなく使いこなせるぜぇ~と涼しい顏して言えば、それで濟んだのかもしれないが、そんなエース級が客前にチョロチョロ出てくることはなく、ソフトハウスの社運をかけてパッケージ開發に勤しんでいる。スレッドが殘りカスなら、人材も殘りカスということで、そのあおりを食うのはいつもエンドユーザということになる。というのが世の常なのかもしれない。

おかげで誰に後ろ指刺されることなくマルチスレッドしまくれる情勢にはなっているが、問題はそれをするにふさわしいSEやプログラマが居るかどうかだ(笑)

| | Comments (0) | TrackBack (0)

December 13, 2016

マルチスレッド貧乏性(4)

マルチスレッド大好きSEやプログラマを存分にコケにしたあとで、そもそもスレッドって何だろうという基本に立ち返ってみる。

もともとスレッド(タスク)というのは、通信システム(交換機、パケット轉送裝置など)やオペレーティングシステム(OS)が必要な處理を實行して餘ったCPUタイムを割り當てるものだ。OSが自分の處理を後囘しにして、タスクにCPUを明け渡すなどということはあり得ない。それこそまさに本末轉倒。OSがちゃんと動けていないのにタスクがちゃんと動けるはずがない。つまり、タスクとはOSという掌の上で踊っているカスみたいなものだったのだ。私がシステム開發に關わるようになった頃、コンピューターのCPUi80286とかMC68000だった頃はまさにそういうイメージだった。

當時周圍でよく話題になったのが「プロセスとタスクの違いとは何だ?」だった。そして「プロセスとタスクって同じようなものなんですよ」などと、人を小バカにしたようなことを言う若造が多かった氣がする。その頃ターゲット環境とされていたUNIX(なぜがSystemV系が多かった)には、ほとんどの場合タスクが實裝されていなかったので、今思えば無理もないかもしれない。また、システム實裝を檢討する初期段階では、ターゲットマシンもOSも決まっていないことがあるので、プロセスがどうでタスクがこうだみたいなレベルまで想定できないことが多い。

「プロセス⊇タスク」(プロセスはタスクを包含する)というイメージが分かり易いのではないかと思う。プロセスとはリソースの單位であり、タスクとは實行の單位である。プロセスはプログラムの實行に必要となるすべてのリソースを持つが、タスクはプログラムを實行する際のスタックとCPUレジスタの退避領域しか持っていない。プロセスからタスクを引くと、プログラムコード、グローバル變數領域、ヒープ領域ということになる。これが私の長年のイメージであるが、こういう話はちょっとしたことで誤解を招くことが多いので、なかなか深いところまで語るのがむずかしい。正直言って、一緖に開發してきた連中との閒でも、こういう話で盛り上がれることはほとんど無いと言っても過言ではない。しかし、こんな大事なことを曖昧にとらえていて、それでシステムを上手く設計し、品質の良いプログラムを書けると思ったら大閒違いだ。

さっき、タスクとはメインシステムが使ったCPUの殘りカスを使用する、と書いた。タスクはメインシステムの邪魔にならないようにしか動けないので、タスクが動いている最中にメイン處理に何らかの要求が發生すると卽座に割込まれる。むかし開發していた通信システムでは、メイン處理はすべて割り込みから地續きで動いており、割込みが發生すると障害割込み以外すべてマスクして、最優先で處理を實行する。メイン處理が動いている閒は基本チックの周期割込みもマスクされており、そこから起動されるタスクも全く動くことが出來ない。當時のシステムでは5ms周期で割り込みが發生しており、そのとき運良くメイン處理が動いていなければ、そこで初めてタスクが起動される(または中斷させられていたタスクがレジュームする)。よって、タスクとして動かす處理はシステムの中で眞にどうでも良い低優先度の處理だけだった。

コンピュータ上のシステム實裝がそのようになっていたので、システム性能=ハードウェア性能と考えることが出來、さらに性能を設計することも出來た。しかし現在はどうだろう。ほとんどのシステムはUNIXLinux)やWindowsのようなOS上で、いつでも簡單に割込まれる殘りカスのCPUタイムを使って動くことを餘儀なくされている。これで嚴しい性能要件を出されたり、サイジングに無駄は許さんと言われたりしても無理があるだろうと思うが、往々にしてそういう無理がまかり通っており、その都度開發者は苦心することになる。

| | Comments (0) | TrackBack (0)

December 12, 2016

マルチスレッド貧乏性(3)

マルチスレッドが好きな人というのは、とにかく何でもかんでも竝行でやりたがる。そして、そういう人はたいてい不必要に早口で、あたかも何でも知っているかのように噛みながらでもペラペラしゃべる。もしかしたら、その方が人閒としての性能が良い、もしくは多寡である、さらに周圍からも高評價になると思い込んでいるのではないか。少なくとも私にとってはアホか!と言いたくなるくらいトンデモな勘違い人であるとしか思えない。

人閒の頭腦は通常1つのことを考えている。分單位のスケジュールをこなす强慾ビジネスマンでさえ、同時に思考出來るのは1つだけであり、どれだけ多くの課題を抱え、多くのことを竝行でこなしているように見えたとしても、それらを優先度付けして順番に1つずつ考え、上手に中斷しながら效率良く對處していく。そして、いかなる天才であったとしても、テストに出題されている問題を2問以上同時に讀み、考え、囘答をスラスラ書ける人は居ない。居るわけがない。

ところがマルチスレッドしたくてしょうがないプログラマは、そういう物理的にあり得ないようなことを平氣で考え、やろうとする。たとえば、左足は步いているのに、それと關係なく右足では走るというような、根本的に誤ったポンコツプログラムを設計して書いてしまう。何が何でもマルチスレッドにしないと氣が濟まない人というのは、もはや自分がどうやって步いたり走ったりしているのかさえも忘れて、ある意味狂信的にマルチスレッドであろうとする。

まあ、多少の誇張はあるかもしれないが、マルチスレッド好きというのはそんな感じだ(笑)

| | Comments (0) | TrackBack (0)

マルチスレッド貧乏性(2)

このタイトルの最初の記事を書く1日前(つまり2016/12/9)に、あまり肯定的な議論はなかったように見えた竝列Emacsのテストアナウンスがemacs-develメーリングリストに流れた。もしかしたら、40周年を記念してノリでやっちゃったのかもしれないが、豫告通りその後すぐにmasterにマージされたので、こちらでもビルドして試してみた。widgetsと違って、configureでオプション指定とかしなくてもThreadsの機能が使えるようになるのだが...。

端的に言えば、現時點ではコアダンプのオンパレードであり、まだアルファテスト以前のレベルと言わざるを得ない。この品質でmasterにマージすることを決斷したのは、開發者以外のより多くの人にもテストして慾しかったからではないだろうか。少なくとも私が書いた簡潔なTPでも、GUI起動したEmacsではすぐにクラッシュする。しかし、端末から起動(-nwオプション)したEmacsでは動いた。その後、make-threadの引數にファンクション名ではなくlambda式を書くと卽死することが分かった。ここまでで、これ以上お試しする氣が失せてしまった。ダメ出しはいくらでも出來るが、ツイッターでもこの件ではコメントしないと決めた。

src/thread.cmake-threadのところを眺めてみると、スレッド用のリソース確保とスレッド生成の處理を行なっているようには見える。しかし、スレッドライブラリ(POSIX Thread?)のスレッド生成を使うということは、そのスレッドはOSによって制御されるのであり、絲が切れた凧狀態になるような氣がする。實際にスレッドを起動すると、フォアグラウンドのEmacsは操作不能になっていた。これなら非同期プロセスの方がまだマシである。コマンドループとはどのように折り合おうとしているのだろうか。

これまでのEmacsなら、elispを起動すると編集操作がビジー狀態になり、C-g等で强制的にelispを止めない限り操作不能になっていたのを、スレッド起動によりelispがバックグラウンドで動作し、編集の邪魔をしないよう振る舞ってくれることを、誰もがイメージしていたのではないか。

今のままの實裝だとすれば、早晚この機能は誰からも使用されないものとなるのではないかという氣もする。elispが他のスクリプト言語と決定的に違うのは、それがエディタ上で動作しているということであり、エディタの使用性を損ねるような機能では困るのである。よって、スレッドの實裝は自ずと他のスクリプト系言語と違ってくるはずだ。

個人的には、Emacsのスレッド機能はあくまでエディタのコマンドループ上で編集處理がない時閒をスレッドに割り當てるものだと思っていた。つまり、通常のelisp實行が編集をストップして同期的に動くのに對し、スレッド起動されたelispはコマンドループのバックグラウンドで動く優先度の低い處理をイメージしていた。スレッドがいつまでも中斷しなければ、コマンドループに强制的に中斷させられる必要があるので、それをどう實現するかという點に興味があったのだが、まさかスレッド關連のライブラリ關数を呼んでいるとは...。

ここしばらくは、emacs-develメーリングリストの議論から目が離せない(笑)

| | Comments (0) | TrackBack (0)

December 10, 2016

マルチスレッド貧乏性

書こう書こうと思っていて、なかなか書けないこのタイトルの記事。こういうのって、書き始めると頭の中にいろんなことがいっぱい湧いてきて、一氣に發散し、文章を書くどころではなくなる。だから、こういう場合は分かり易い文章を書こうとか、素晴らしい記事にしようとか考えずに、思いつくままにどんどん書いていった方が良いのではないかと思った。もちろん、そこまで開き直って割り切っても、途中で沈沒する可能性はある。

最初にことわっておくが、私はThread(スレッド)を使ってプログラムを書いたことはない。ついでに言えば、別にマルチスレッドを忌み嫌っているわけでもない。

おそらく、現在一般的にスレッドと呼ばれているものは、もともと(私がプログラミングを始めた頃は)Task(タスク)と呼ばれていて、それがやがてUNIXLight Weight Processとして實裝され、その後POSIX Threadになったのではないかと、漠然と認識しているが、このような認識は人によって樣々だろう。今でもLinux上のスレッドにはpidがふられているので、プロセスとして管理されているようなフシがある。

私が今から20數年前に徹夜で沒頭したことがあるのはスレッドではなくタスクの方だ。OSUNIXWindowsではなくCTRON。ただし、CTRONのタスクにも實裝がいろいろあって、ノンプリエンプティブとプリエンプティブがあり、私は運良くその兩方を經驗している。

辛口なSEやプログラマは、プリエンプティブマルチタスクじゃないと意味がないとか?言うのかもしれないが、それはすこぶるナンセンスな話である。眞のプリエンプティブマルチタスク環境においては、任意のCPUインストラクションを實行中にいきなりタスクが切り替わるとイメージして設計し、プログラミングする必要があると考える。しかし、もし本當にそういう動きをしているのであれば、プログラム上のどこでどのプログラムに割込まれても問題ないことをテストする必要があるが、現實問題としてそんなテストが出來るはずがない。だとすれば、そのようなタスク制御の元で動作するプログラムを作ってはいけない、と考えるのが妥當である。もし、そんなプログラムを作ってしまったら、どんなことをしても品質保證など出來なくなる。

こんな笑い話のようなことが現實にある。たとえばWindowsというOSはプリエンプティブマルチスレッドらしいが、新しいバージョンがリリースされると10年閒每月パッチをリリースし續けるという、通常のビジネス開發ではあり得ないようなことを平氣でやっている。そして10年經ってもバグは枯れない(殘存バグがないことを檢證できないという意味で)。その理由は上述のとおりである。

少し卑近な話をすれば、腦がお花畑なプログラマたちがやりたがっているマルチスレッドプログラミングとは、自分のテリトリ(システム上で自分が擔當する機能ブロック、または小規模の場合システム全體)の中で、漠然とココとソコは同時に動かしても良いのではないか?という安易な發想に基づいている。さらに邪惡なプログラマは、自分のテリトリの中に竝行で動かせるものが無いかどうかと必要もないのに探しまわる。

少なくとも、次の事項くらいは考えた方が良いだろう。
①自分のテリトリにあるモジュールは、誰が起動したプロセスのどのスレッドで動くのか。
②自分が起動したスレッドで、誰のプログラムが動くのか。

普通に考えれば、自分のテリトリの中でいくつもスレッドを起動して制御しなければならないようなプログラムなど無いだろう。スレッドを分ける以外に制御する方法が無い場合に限られるのではないか。その證據に、ネットを檢索してもマルチスレッドプログラミングの有效例など皆無と言って良い。

| | Comments (0) | TrackBack (0)

June 21, 2014

プログラムに固定値を書いてはいけません

いい歲をしたSEにこんなことをドヤ顏で言うな!(笑)

プログラマだってこんなことを頭ごなしに言われたら、ヘソを曲げて何でもかんでもデファイン値にすれば良いんだろう?と思うに違いない。過去の經驗で一番笑えたのは、8ビットの0は0x00で、16ビットの0は0x0000というデファイン定義。なんで0x00だと8ビットなの?(爆笑)

まあ、C言語だとさしずめこんな感じ。

#define ZERO8 0x00
#define ZERO16 0x0000
#define ZERO32 0x00000000

こんなくだらない話はいまどきジョークにもならない。

そしてデータ型に關しては、こんなことをする人たちもいる。

typedef unsigned char BYTE;
typedef unsigned short WORD;

このようにヘッダファイルに定義しておけば、符號なし8ビットを表す型の名前が變わっても、ソースファイル(C言語では~.cのファイル)を書き換える必要がなくなるということらしい。こういうことを言う人たちは、それが一體どういうメリットをもたらすか考えたことがあるのだろうか。假にシステムのハードウェア更改があったとして、ハードウェア仕樣の差異に關わる部分のヘッダファイル書き換え、およびリコンパイルだけで對應出來たので、試驗をする必要がなくなるということなのか。

基本的に、ソースファイルをリコンパイルしたら試驗はやり直しだ。もしも私が顧客ならそれを要求する。ところが上記のような記述をすれば移植性が高いと思い込んでいる人々は、定義變更によるリコンパイルだけなら試驗をする必要がないという根據のない說明をしようとすることが多い。そもそも、見積に試驗やり直しの工數は積んでいないのだ。もしそれを見込むのであれば、移植性の高いプログラムの面目は丸潰れだ。

システム全體に關わるようなヘッダファイルの定義を變更しておいて、それで當然のことながらすべてのソースファイルのリコンパイルがかかったにも關わらず、全く試驗しなくて良いという理屈はあり得ない。こういう勘違いは、プログラムの移植性とソースファイルのメンテナンス性を混同しているということに他ならない。

さらに、ソースファイルに固定値を書くな!というのもよくある話だ。冒頭の0をZEROとデファインするのはその類である。これにもヘッダファイルと同樣のことが言えるが、もっと重要な問題がある。もともと、デファイン定義というのはプリプロセッサが固定値に置き換えるので、システム上はデファイン定義しても固定値であることに變わりはない。

もし本當に固定値ではいけないというのであれば、システム稼働中にその値を自由に變更可能にし、變更後もシステムの正常動作を保證しなければならないが、そんなことを實現出來ているシステムがあるのだろうか?

プログラム中に固定値が出現する場合、その値を變更したら動作しない可能性が高い。たとえば數値を入力する機能において、最大入力桁數を10桁にしている場合、入力が10桁以内かどうかをチェックする處理には、まさに10桁以内かどうかを調べるためのプログラムが書き込まれている。それを20桁まで許容するように變更する場合、プログラムに固定値で書かれていなければ簡單に變更出來ると考えるのは明らかに誤りだ。それは、その入力を受け付けて一時的に退避するデータ領域のサイズも入力に應じて可變でなければならないし、最終的にデータベースに書き込まれる場合は、その項目の屬性がそのような變更をも許容するようになっていなければならない。プログラム中に固定値が書いてあるかどうかなど、實に些細なことなのだ。

このようなことをシステム全體においてやろうとすると、おそらく開發に莫大な費用がかかるだろう。またシステム保守費用も當然高くなるだろう。もちろんそのようにして出來上がったシステムなら、些細な變更が發生してもベンダに對應を依賴する必要はなく、運用擔當者が好きなように變更可能になるのかもしれない。しかし、それで今までにない機能まで對應出來るというわけでもないので、機能追加はベンダ對應にならざるを得ないが、固定値にしてはいけないという條件を踏襲すると、大した機能でもないのに高くつくことになる。固定値が可變になったとして、運用中にどの程度變更するものなのか。

實はこのようなことは、時と場合に應じて適切にバランス良く行われているものであり、そこに口出しをするとおかしなことになるという典型例なのだ。賢い人なら、どれかを可變にして他はどうでも良いと言うはずである。

| | Comments (0) | TrackBack (0)

May 18, 2014

複雜なシステムとは單純なものの積み重ね

複雜なシステムはそれなりに複雜な動きをするのだろうと考えている人たちがいる。そうでなければ複雜なことをしているということにならないからだと思っているのだろうか。

高度情報化を目指す企業はたいてい社内に情報システム部門を置いて、會社が求める要望に對應しようとする。彼らのミッションは社内の情報處理を高度化し效率化すること。これにより主に人件費のコスト削減を目指すが、さらにシステムの情報を經營狀態が分かるようサマリ化し、それを元に經營判斷出來るということまで要求されている場合がある。システムに對する要求が高度になれば、それを構築したり運用したりするのがたいへんになるが、情報システム部門が存在する以上、それを成し遂げなければ社内投資でメシを食う彼らはお拂い箱になる...というのが世の常だ。

そもそもシステムがどれほど複雜怪奇な要求に應えるものであっても、プログラムにより動作するものであれば、その枝葉末節までとことん單純化していかなければならない。要求を仕樣化し、その仕樣を滿たすための方式または機能の設計作業は、物事を單純化していく作業なのだ。よって、パッと考えてもどうしたら良いか分からないほど高度で複雜な要求の場合は、まずその要求が具體的にどういうものであり、どう運用出來なければならないかを時閒をかけて明確化しなければならない。そのため、それを依賴する側は要求事項自體の具體的な實現イメージと運用イメージを時と場合に分けて十分に檢討する必要がある。

なぜならば、システムベンダは顧客が抱える要求が高度かつ複雜であればあるほど、要求事項はお客樣ということにならざるを得ないからだ。よって、事前の依賴書や打ち合わせに出てくる資料の内容と發言のみが賴りになり、受け取った内容以上のものを實現しようとはしなくなる。つまり、顧客が具體的に提示していないことまで汲み取って要件定義をすることはない。

しかし、こういう場合であっても顧客の側が實現イメージや運用イメージを提示しなかったらどうなるだろうか。たとえば「情報は一元管理とし、どれかのシステムの設定を變更したら、他のシステムにも反映される必要がある」だとか、「投入されたデータは卽時的に樣々な臺帳類、帳票類、經營サマリなどに反映されなければならない」だとか、そういった要求事項の具體的イメージというより、評價ポイントのようなことしか言わなかったとしたら、誰がいつ何をどうしたときにどういう結果になれば良いかが不明となり、いくらお金をかけてもシステムは完成しない。それはお金をかければシステムベンダが自發的に考えて巧くやってくれる領域ではないのだ。

たいていの顧客は、本當に實現したいことをシステムベンダに傳え切れず、完成後に追加開發を依賴することが多い、これすなわち、出來上がったものを見ないとそれで良いのかどうか分からない證據ではないだろうか。そういう顧客は、コンサルを入れて要求事項を整理させることもあるが、所詮說明出來ないようなむずかしいことを傳えようとしてもダメなことに變わりはない。それは運用レベルの試驗項目を作成するに等しい作業であり、開發經驗のない素人に出來るものではない。そういう事情から、一般的な顧客はシステムパッケージの仕樣を澁々受け入れて運用することが多い。

いずれにせよ、むずかしいことを實現しようとする場合、システムベンダに過大な期待をしてお金を積んでも、顧客自ら積極的に要件定義をしない限り、ロクな結果にならないのは明白だ。


| | Comments (0) | TrackBack (0)

July 07, 2013

パッケージ開発(2)

アクセス解析の檢索フレーズを見ると「パッケージ開發」による檢索が多いようだ。まあ、日々のアクセス數がが極微量なので、その中でも他に比べて多いという程度だが・・・。

この數年、民需系SI案件のSEをやっている。これは職場ではそういう位置付けになっているが、一般的ないし客觀的に見れば案件の監督をやっているようなものであって、SEと言えるほど大した檢討も設計もしていない。そういう作業の多くは下請けベンダがやることになっている。つまり下請けがする作業に問題が無いかどうかを確認する役割を擔っているというわけだ。

しかし、顧客の要望を整理してベンダに傳え(實際には顧客との打合せにベンダを同席させる)、構築・導入させると、要望と合わなかったり、實現機能に過不足があったり、バグがあったりする。そういうことが出來るだけ起きないようにするのが我々のミッションだとしても、これをもし顧客と下請けベンダが直に契約してやったら、一體どうなるんだろうと恐ろしくなってくる。もちろん元請になれば、それなりの體制をとってキッチリ仕事こなすベンダもあるとは思うが、明らかにそういうことが出來ないベンダもある。

なぜそうなるのかと言えば、そういう下請けベンダは案件每の、初期ヒアリング、實現方式檢討、提案、積算・見積など、引き合いから受注前までに發生するオーバーヘッドに耐えられないからだ。逆にそういうオーバーヘッドをも擔っている大規模なベンダは總じて(どれだけ客の足元を見れば氣が濟むの?というくらい)高額な費用を要求してくる。中でも、企業の販賣管理、生産管理、財務會計などの基幹系システム案件ではそういう傾向が強い。要するに元請として對應可能なベンダを下請けにするべからずということだ。

個々の案件に接していて強く感じることは、この程度のことなら箱物のパッケージを買ってきて、會社の業務が分かっている人に運用檢討させれば濟むことじゃないかという氣がすることだ。しかし、事務員が數人しか居ない中小企業なら良いが、パッと見でそれぞれが何をしているか分からないくらい社員數が多い會社では、決してシステムの中身の詳細(特にデータ仕樣)までを社員に任せたりしない。その社員が豫告無しに長期休暇を取ったり、退職したりすることを考えただけでも恐ろしいが、脅迫や背任行爲も懸念される。よって、ある程度大きな規模の企業は假に基幹システムを自前で構築・運用可能でも外部に委託せざるを得ないことになっているし、それによって高額な投資が必要となってもやむ無しという認識になっているようだ。

こうして、大して便利でもない、傳票投入して帳簿を作るという程度のシステムを作るのに何億圓ものお金が使われることがある。また、投入ミスや處理漏れを防ぐためのチェックや見直しに關する業務は、人が擔うべきと思い込んでいることが多く、要件に出てこないことが多い。もちろんそういう機能をシステムに具備したら、首筋が寒くなる人も居るのだろうが、コンピュータの處理を人がチェックするような運用は、何の疑義も無く至るところに存在する。こういう問題を永遠の課題とあきらめるのは齒痒い限りである。

| | Comments (0) | TrackBack (0)

March 19, 2007

パッケージ開発

パッケージ開発とはパッケージソフトを開発することではなく、パッケージソフトを担いで開発することを指す。簡単に言えば、顧客が要望するシステムに必要な機能を開発する(プログラムを作る)代わりに、市販のパッケージソフトが持つ機能を利用してシステムを作り上げることになる。しかし「パッケージソフトを担ぐ」とは、そんな生易しいものではない。

たとえば、顧客にC言語で100KLのスクラッチ開発に相当するシステムを要望されたが、求められている機能の90%は市販のパッケージソフトが持っているものであり、それに10KL程度のコードを追加すれば、顧客が求めているシステムが出来上がるとする。その場合、顧客が想定する開発費用はパッケージソフト代と10KLの開発費で済むことになる。仮にC言語による1ラインあたりの開発費を2000円として計算すると2億円になるが、パッケージソフトを使用した場合は、パッケージソフト代+2000万円ということになる。ではパッケージソフト代はいくらになるのか?・・・しかし誰がどう考えたって、パッケージソフトに1億8000万円かかるとは思わないだろう。そして、顧客の金勘定にはパッケージソフトの代金は入っていても、システム全体の顧客要求仕様をまとめ上げる費用や、追加コードを開発するためにパッケージソフトが最低限どのような仕組みで動いているのかを調査する費用や、パッケージソフトの機能がホントに顧客の要求通りに動作するかどうかを検証する費用などは、ほとんど含まれていない。

世間一般の人がすぐに思い浮かべるパッケージソフトといえば、Windowsのようなオペレーティングシステムとか、Officeのような統合ソフトウェアだろう。これらであればせいぜい高くても10万円程度で購入出来る。当たり前の話だが、それらのソフトウェアを10万円そこそこで開発出来るわけではなく、価格設定は単価×予測販売数+αということになる。したがって、その計算方法は上記のパッケージソフト代にもそのまま当てはまる。WEBを検索してみれば分かるが、エンタープライズ系ソリューションパッケージソフトの値段を晒しているページなんてものはどこにもない。値段はすべて応談である。また、ソフトウェア会社がそのパッケージソフトを使って新たなソリューションを開発し販売する場合は、パッケージソフト会社との間にいろいろと複雑な契約が必要になる。

つまりパッケージソフトと言えども、しょせんは人間が汗水垂らして作ったものであり、多額の費用がかかっているということだ。だからパッケージソフトを開発する会社は、それを担いでソリューションを開発し販売するというソフトウェア会社から、そのパッケージソフトの開発にかかった費用を出来るだけ回収しようとするだろう。契約にもよるが、ソフトウェア会社のソリューションに要する機能が、仮にそのパッケージソフトの機能全体の半分であったとしても、パッケージソフトの開発会社はソフトウェア会社に対して全機能分の価格を要求することになる。「パッケージソフトを担ぐ」とはそういうことなのだ。

顧客の側にしても「パッケージソフトを使って、スクラッチ&ビルドよりも安価にシステム化します」と聞いた途端、妙なパッケージソフトを買わされるんじゃないかと警戒する。高額なパッケージソフトであればなおさらだ。普通の顧客なら、そのパッケージソフトが持つ機能の何%の機能を使用するのか聞いてくるだろう。そして、パッケージソフト会社から個別にパッケージソフトの見積りを取った上で、ソフトウェア会社のソリューションがそのパッケージソフトの機能を100%使うのでない限り、そのパッケージソフトの代金を丸々払おうとはしないだろう。そうなると使われない機能の代金は、すべてソフトウェア会社の持ち出しになる。最悪の場合、ソフトウェア会社は、パッケージソフトの開発にかかった費用と、その後の維持管理費用を全部負わされることになりかねない。当然、その過程で多くの狡猾な駆け引きも展開される。

このように考えると、ソフトウェア会社にとってのパッケージ開発なんてものは儲かるような気がしないし、品質や性能が悪いパッケージソフトを担いでしまったら大変なことになる。社員1000人程度の会社なら、いとも簡単に吹き飛ぶだろう。

| | Comments (0) | TrackBack (0)