アイロベックスメールマガジン　携帯版

あっという間に2月です。

不景気などと言っていても、バレンタインは否が応でもやってくる。
イベント事に燃えないなあ・・・。と思うこのごろです。

でも2月3日の恵方巻きだけは食べたいと思います。
特に、今年はこれ！です。
http://www.sej.co.jp/products/ehomaki_kanto.html

さて、システムリフォームの視点からシステム開発を考えるシリーズの3回目は「プログラム言語」です。

一度作ったシステムを、基本はそのままで機能を追加したり修正したりしながら、何年も使い続けることができるのか？
これに対して明確にYesと答えることはできません。

開発者やユーザーの「なるべく長く使い続けるシステムを作る」という意思だけでなく、システムの持つ運にもよると言わざるを得ないからです。

ここで「なるべく長く使い続けるシステムを作る」という意思に立ちはだかる壁は開発時の「目先の生産性」であり「コスト」です。

機能的であり、なるべく安価なシステムを望むことはユーザーにしてみれば至極当たり前のことです。

一方、競合相手と戦って仕事を勝ち取らなければいけないシステム開発会社としてみれば、まず考えることは、保守性ではなく生産性であり、効果性であろうと思います。

そこで、今回はシステム開発の裏側から見たプログラム言語とミドルウェアについて考えてみたいと思います。（タブーでは無いと信じつつ・・・）

なぜなら、ユーザーがもっとも関心がなく、システム開発会社に任せてしまう部分だからです。
それ故にリフォームし難くなったり、リフォームのときに多額の費用を請求されてしまうものが、プログラム言語とミドルウェアなのです。

まず、プログラム言語ですが
・COBOL
・Java
・.NET（VB.NET）
・PHP
・Perl
・C
・C#
ざっと有名な言語を書き出すだけでも、こんなにあります。
その中で大規模用開発の現在の主流になっているのは
・Java
・.NET
というところでしょうか。

別にここで「どの言語はダメ」と言いたいわけではありません。
システム開発会社にはそれぞれ得意な言語があるわけでその言語で開発すれば生産性は高くなるわけです。

しかし、ここに挙がっていない言語であったり、特殊な開発ツールを使う場合は要注意です。

開発者が少ない言語で開発してしまうと「保守性は、悪くなる」これは常識です。

需要と供給の関係からも理解していただけると思います。

某データベースメーカーが開発言語や環境をセットで売り出しておりますが、正直こういうものを「基幹系システム」や「大規模システム」に使うのはお勧めしません。

「餅は餅屋」

１つの分野が有名であれば、他のものも良いわけではありません。

エルメスでは、バッグを買いシャネルでは服を買うべきでしょう。

また、ExcelやAccessは、帳票や分析だけといった一部に使うものであり開発のメインに使うものではありません。

5年以上お使いになる「基幹系のシステム」をお望みであれば、数少ない開発会社しか対応できないような言語をお選びになってはいけません。

現在、このメルマガは、システムリフォームを考えることで、「システム開発をする」ことをもっと注意深く細かく、新たな視点で見直すということを目指しております。

先週まで3回に分けて「システムリフォームを考える」というタイトルで考えを述べてきましたが、この業界に長くいる人であれば「当たり前すぎること」を書いてきたと自覚しています。

しかし、「当たり前」「口に出していうほどのこともない」といった思い込みは、私たちのどんな仕事をも阻害します。

私がこのメルマガで行いたい作業は、1つ1つどんな細かなことも、「本当にそうなのか？」という視点で見直し書き出すことです。

IT業界は常に新しい若い人が新星のように現れる場所でもあります。
しかし、この業界でもやはり経験則が思いのほか役に立ち、思考や決断の軽薄さをカバーしてくれる力となるのです。

「古い時代から同じやり方で仕事をしていること」がいいことなのか悪いことなのか、一概には何とも言えません。

例えば、ある会社に長い時間をかけて先人たちが確立した考えや仕組みといったバックボーンがあったとします。

しかし、若い人は自分の仕事環境、周りのわずかな先輩、教えられた（理解できた）数少ない事柄を正として、「なぜ、その方法や仕組みが決められたのか？その仕組みが無かったらどうなのか」を知ることもなく仕事に従事しているという実態もあるからです。

そして、このメルマガでは私の「現在の考え」を提示するつもりですが、分からないことについても、そのまま提示していこうと思っています。

自分は分からないが、他人は知っていること。
自分も分からないし他人も悩んでいること。

以上のような考えの切り分けに、少しでも役に立ってくれたらいいと思うからです。

システムリフォームの観点からシステム開発を考えると見えてくる現在のシステム開発の姿。

それは、システム開発側が仕事を取らんが為に、ユーザーに媚びた

「速く」
「安く」
「なるべく多機能」

を目指したシステム開発なのではないのでしょうか。

この3つを実現しようとし、結果として

「障害なく、安全に動く」
「実際に現場で役に立つ」
「長期的視野で見て安く使い続けることができる」

という、最もユーザーから要望として上がりにくい点が欠落してしまっているのではないのでしょうか。

ところが、後に述べた3つこそが、システムリフォームを考えるときに非常に重要なポイントなのです。

さて、今回もシステムリフォームの話を続けたいと思います。

システムリフォームを請け負った場合に、最初に調べなければならないことを、175号のメルマガでお伝えしました。

そこでは、OSやミドルウエアや言語、特にソースプログラムが最新かどうかに一番注意しなければいけない。と言いました。

また、その次の号で企業独自のビジネスロジックは、プログラム言語ではなく、データベースにストアドプロシジャとして一元化しておくことが望ましいとお話ししました。

これを読んで「あれ？」と変に思われた方もいらっしゃるかと思います。

もしこれが、システムリフォームではなく新規のシステム開発であったとしたなら、一番最初に必要な調査分析は「業務フロー」であり「システムをどのように運用するか」であるのではないかと思うはずです。

もちろん、システムリフォームといえ、それはその通りであり、業務フロー図がきちんと存在していれば、非常に役立つのです。

しかし、実際のところ、例えば5年以上使われ続けたシステムが、今でも5年前に描いた業務フロー通りそのままに運用されているということがあるのでしょうか？

それは、数少ないと思うのです。

業務フローをSEが作成するのは、システム開発の一番初期の頃です。

現状の業務フローをヒヤリングして、図解して作成します。
次に設計、開発の後、ユーザーがそのシステムを使い出すのです。

そこから5年以上経ったとき、

　すべてのシステム機能が使われているのかどうか？

　システムの業務フローは設計したSEが意図したままで行われているかどうか？

SEは次の新しいシステムに移っていく為、確認できないことがあるのです。

ある部分は、まったく使われていない。ということがあるでしょう。

そして、明らかにSEが意図した使われ方をしていない部分も出てくるのです。

実は、ユーザーから質問が来ないからという理由で、当然、すべてのシステムを使っているはず、と思い込んでいるSEも多くいるのです。

しかし、実際には、ユーザーはその機能がよく分からず、もしくは面倒だからとその機能を使わずに運用で逃げてしまっていることもあるのです。

実は、私も、同じような経験が何度かありました。

業務に携わる現場は、本当に驚愕すべきことが多くあります。
「えっ、そんな風に使うと思わなかった」ということさえよくあるのです。

SEがどんなにがんばってヒアリングして考えて業務フローを作っても、どう使われるのかは分からないのです。

また、使うまで分からないことも幾つもあるのです。

そういう理由で前の号では初期に作った業務フローについては触れなかったのでした。

もちろん、システムリフォームを行う場合に、現在の業務フロー、運用ルールがどうなっているかをヒアリングすることは、必須事項です。

ただ、実際には、ヒアリングよりも先に現状のシステムを掘り起こし、現状のシステムのあるがままを理解するところから始めるSEが多いと思うのです。

なぜなら、お客様から本当の実態、真実のビジネスモデルを聞き出すには多大なスキルとコストがかかるからです。

私も、システムリフォームでは、現状のシステムを分析し、システム側からみた業務フローをまず頭に叩き込んでからお客様にヒアリングすべきだと考えています。

システムリフォームから業務フローを考えるとき、

　まず、現状システムの理解を行い、次に現状の運用フローのヒアリングを行う。

という順序になります。

新システムが稼働してから初めてシステムリフォームが行われるときそれは1ヶ月後、1年後というスパンが多いのではないでしょうか。

1ヵ月後に行われるシステムリフォームは、ユーザーもしくはSE、あるいはその両方に大きな悔いを残したものに違いありません。

つまり、設計上の穴であったり、ユーザーがSEに伝えていなかったこと。
あるいは、声を大にして言わなかったことからSEが運用を甘く考えていた結果なのでしょう。

そして、1か月を待たずしてその問題は浮上し、システムを直さざるを得ないということになるのです。

これをシステムリフォームと呼ぶのは問題があるでしょう。
むしろ、運用テストでの調整といった一連の開発に含んだほうが良さそうです。

しかし、その作業をなんと呼ぼうが、費用の問題が1番の課題となるでしょう。

システム開発の現場では、「追加要望」とか「追加案件」「仕様修正」といった呼び方をします。

この言葉を見る限り、ユーザー側の一方的な理由で作業が発生し、金額を請求することになったような印象があります。

しかし、実際にはそうでないことも多いのではないでしょうか。

例えば、私自身が発注者（ユーザー）の立場に立った、こんな出来事があります。

引っ越しの際のことです。
役員室の内装を業者に依頼し、事務室の一角を区切って役員室を造作しました。
役員室の壁は、シックなイメージに合わせてモスグリーンがかったグレーで塗ってもらうことにしました。

内見の日に、役員室の壁を見て驚きました。

役員室の四方の壁は、ほとんどが窓である面、ガラス張りとドアの面、コンクリートの面、仕切りパネルの面という構造になっています。

ほとんどが窓である面、ガラス張りとドアの面、仕切りパネルの面はシックな色で塗られています。
しかし、もう一面の残ったコンクリートの面を見ると、白い。
つまり元からあったコンクリートの壁のままだったのです。

確かに、「この壁は白いままでよろしいでしょうか？それとも塗ったほうがよろしいでしょうか」とも聞かれていませんし、こちらも「全面を同じ色で」という指定をしませんでした。

これは、どちらの不備なのか？
他の3面は塗っているのに、一面だけ塗っていない部屋というのは常識からいって「ありうる部屋」なのかという思いが沸き起こりました。

そのとき、内装会社の担当者は謝ったとは思います。
しかし言った言葉は、「業者を呼んで塗らせるのに、費用がかかります」といった内容でした。

そのとき、「1部屋で連続している壁の色が違うのはおかしい」とごねることも出来たでしょう。
しかし、結局その一言、つまり「業者を呼ぶ」という言葉に内装業者そのものが動くのではなく、費用が発生するということで、しぶしぶ払うことを承諾せざるを得ませんでした。

例えば、一戸建ての見積もりの場合を考えます。
標準一式一戸建て1500万円という見積もりがあったとします。

この建物のタイルの色が気に入らない。
しかし、タイルを高価なものに変えるのには、タイルそのものの仕入金額が高くなるため、見積もり金額が上がる。

こういう見積もりなら理解できます。

内装会社の出来事も確かに「業者作業がかかるから」というのが一サラリーマンとしての正直な対応でしょう。
でもそれでいいのでしょうか。

そして、私たちが内装会社の担当者になったとき、白い壁を見たユーザーになんと答えるのでしょうか。

業者支払を自腹で払っても、プロとして聞き逃したことの責任を果たすのか。
それとも「業者を呼ばないといけないので費用がかかります」というのだろうか。

システムリフォームも、納品直後のものは、開発会社の覚悟が問われるものだと思います。

わたしの場合はですか？

やはり、どんなことでも全部保証するとまでは言えません。
ユーザーが言わないこともすべてパーフェクトに実現できるとは思っていません。

ただ、パーフェクトでありたいとは思っています。
そして、一方では、プロジェクトである限り、きちんと利益を出すべきだとも思っています。

出来ること、出来ないことがある。というのが答えです。

ただ、自分が気が付けば良かったのだ、という反省だけはきちんとしておきたいと思っています。