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

どんなに頑張って考えても出来上がらなければ分からないことはあります。

何度、何時間、ユーザ－と開発側が会議を繰り返し真剣に討議したとしても
そして、どんなに優秀なSEが設計したとしても納品されてから気づくこと、納品されなければ分からないことが双方に必ず残るものです。

それを修正したり追加したりするのに総機能工数の半分もかかるというのでは明らかにおかしい。

しかし、それが10％の工数で追加できるということであればむしろ、これは当たり前のこととして準備しておく方がお互いの為なのです。

当然、経験のあるシステム開発会社であればこのくらいの工数がかかるといったリスクを想定して見積りをします。

ところが最近では、どんな仕事も合見積りなど競合相手がいる場合が多いため、あらかじめその工数を上乗せした見積りが「高く」なってしまって仕事が取れないということにもなってしまうのです。

もちろん、ユーザーとしてシステム会社から後に追加工数を請求されて納得がいかないという話がよくありますが、それは、原価ぎりぎりの見積りであったかあるいは、どう考えても全くの追加機能であったかのどちらかなのです。

いったん、システム発注をしてしまえば後からの追加修正を全くしないで使いこなすということは、むしろ「テーラーメイド」のシステム開発の良さを享受しないことにも繋がるのです。

「一括納品でいくら」という見積りが出てきた場合ユーザー側には是非、最低でも総額の10％は予備費として追加機能予算をとっておくことを勧めます。

もしくは、そういったことまで「あ・うんの呼吸」でやってくれるシステム開発会社と長く付き合うこともひとつの手なのです。

最近のシステム開発は、要件定義、基本設計といったお客さまとの打ち合わせの工数が、開発工数に比較して、より多くとられる傾向にあります。

これは、上流で失敗してしまったものは、下流で取り返しがつかないということに所以しているのだと思います。

また、実際のところ、上流で失敗したシステムが、それほど多かったのだということの証ですね。

しかし、実際のところ、すべてのパターンにおいて、この要件定義、基本設計というパターンで進むのが良いかというと、そうではないと思います。

正直、「要件定義しなくても良い」と思う開発は多いものです。

SEが2人参加して要件定義、基本設計というスケジュールを作った場合、要件定義に2か月、基本設計に2か月というスケジュールとすると、人月だけで考えても8人月の費用がかかります。

要件定義をしなくても良いというのは語弊がありますね。

「要件定義や基本設計で全力を出し合い、互いのコミュニケーションをきちんと取り合えば、設計は100%固まる」とシステム開発会社側は考えている気がするのが不満なのです。

大きな声で言えない真実がここに潜んでいます。

つまり設計は、長すぎても深すぎても、冗長な打合せが続いたり、重要性の低い些細なことに拘泥して無駄な工数を生むのだと、そのデメリットについてどれだけ理解されているのでしょうか。

ある意味、客とSEのやる気が空回りしてしまうようなものなのです。

実際は、これだけの工数をかけて話し合ったのだから、お互いの認識漏れは無いという風な流れに持っていくことを狙っているのではないでしょうか。

お互いが掛けた時間工数で責任をとり合おうとしているような気がするのです。

山のように意味が薄いドキュメントが出来てしまうのも、同じ理由である気がします。

お互い、開発前の打合せで、ユーザーも開発会社側も、体力、精神力ともに消耗してしまうのは考えものであると思うのです。

開発金額のどれほどの割合を設計で費やしているかを考えれば、よく分かると思います。

わたしは、要件定義と基本設計の期間は、「長すぎても短すぎてもダメ」だと思っています。

基幹システムの大規模開発で、ウォーターフロー開発をきちんと守らなければいけない場合であり、SEが3、4人以上かかわる場合には、ある程度のお約束の形が必要ですが、実際には、そうでない場合が多いのではないでしょうか。

そして、要件定義をするのであれば最大の課題は、開発側とユーザー側に、それぞれ、その設計に専念・集中できるスタッフの確保と、彼らが毎週の中で確実にお互いの時間を無駄にしないような、
協調するための時間がとれるかどうかなのです。

また、お互いに要件定義に夢中になりすぎてしまうことも、負の問題になってしまいます。

細かな問題や道はずれの思いつきに首を突っ込んで抜けられなくなるのを防ぐために、要件定義をするくらいの大きさのシステムであれば、「第三者のコメンテータに、会議のときだけでも参加してもらう」
といった方法をとるのはいかがでしょうか。

ＮＨＫ土曜ドラマ「監査法人」とうとう、終わってしまいましたね。
弊社が、プレシャス・ドーナツの本社として撮影現場を提供していたのにはお気づきだったでしょうか。
ロケ場所提供者の役得として、わたしの机の上にはイケメン「塚本高史」さんのサインと自筆の似顔絵があります。

さて、このドラマ「会計士の監査は正しいことが求められる。
しかし、正しい監査は会社を再生させることが目的であるべきだ」といった結論で終幕を迎えました。

零細企業ですが、企業の経営を行っている者として心に残ることが多くあったドラマでした。
きっと再放送があると思いますので、ご覧になることをお勧めします。

さて、既に何度も語っていることですが当社の開発形態は、受託請負の形をとっています。
つまり、プログラミング、テストといった開発中は社内でずっと作業をすることになります。

これが原因で、開発環境と本番環境の違いに気づかないリスクが生まれてくるわけです。

お客さまの運用環境、つまり、

1）サーバーの性能、容量
2）クライアントPCの性能、容量、OS
3）ネットワークの速度
4）最大データ件数
5）同時使用人数
6）同時実行機能
7）バッチの許容時間

こういったものに関して、SEが最初に調査し、シミュレーションしておく必要があるわけです。

ところが

・SEが若く想定が不足している
・現場が遠い
・正しい情報の確認ができていない

このような場合に、「1+1=2」と動くように作ったのだがそれだけでは現場不適応が生じてしまう。
つまり、「遅すぎる」「動かない」といったことになってしまうんですね。

もちろん、遅すぎるのはバグと認識しています。
ただし、「何をもって」遅いというのか？という問題がつきまとうわけです。

上記に書いた 1）～ 7）の中で、何かこれまでの開発案件と違うものがあれば必ず、小さなテストを行って時間感覚の確認を行うことをお勧めします。

確認を行うのは要件定義終了後、基本設計の途中くらいまでがリミットでしょう。

基本設計終了後に「実は時間がかかりすぎます」といった発言はNGです。

時間がかかるという問題については、別途さまざまな解決策もありますのでまたいずれ紹介することにしましょう。

「月末締め」「請求締め」「期末締め」といったように、企業の基幹システムには「締め」という観念や仕組みが、必ずともなうものとなっています。

また、締めを一つのタイミングとして、各種の他システムとの連携が図られています。

例えば、販売管理システムから会計システムに連携データを渡す場合、月末締めをタイミングとして渡すことが多いのではないでしょうか。

また、連携してしまった伝票は、元のシステムでは修正できないというのが通常のルールとなっています。

販売管理システムにおいて、「借方：売掛金 4,200,000円／貸方：売上 4,000,000円、借受消費税 200,000円」という情報を引き渡してしまってから、返品伝票が抜けていることが分かった場合、この情報を取り消すことはできません。

一番良いのは、抜けていた伝票だけ追加で引き渡すことです。

しかし、間違っていた（抜けていた）と分かったときに追加伝票が入力できないシステムも、世の中には多く見受けられます。

要するに、操作で間違えることを前提としていないのです。

人間は、間違えミスをする生き物なのに・・・です。

「良く考えられたシステム」というのは、正しい値を算出するだけではなく、こういった人間のミスに対処するようにできたものを言うのです。

間違えてしまった伝票を直したり、追加修正したりすることが可能なシステムが、その「良く考えられたシステム」であると言えます。

しかし、もっと便利なシステムがあります。

それは、ミスを予知し知らせる、「見える化システム」です。

人はミスをするものだという前提に立って、ミスしないように、一目で分かりやすいように現状を開示するシステムです。

例えば、締日が20日、25日、月末と3つあって、それぞれの締更新、請求書印刷、締め繰越が別々に機能として動くシステムがあるとします。

締日を入力して請求日付を指定して実行ボタンを押すといった処理を3パターンきちんとやったかどうかは、運用者が記録帳をとって管理する方法だとします。

これが一目でわかるように画面に表示されていたらどうでしょうか。

全締日と取引先件数、請求書枚数、金額、その処理を行った日付・時刻が一目で確認できるのです。

締め繰越をおこなっていない締日は強調して表示されています。

こういった画面で締処理を指示するのであれば、ミスをすることが非常に少なくなりますし、何よりも、安心してシステムの運用を行うことができるのです。

ブラックボックス化したシステムではなく、運用情報を常に開示して、「何をいつ行って、何をしていないのか」が、一目でわかるシステムを構築したいものです。