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

システム開発において、「上流工程」が重要であることは、言うまでもないことでしょう。
要件定義が間違っていたり、いい加減であれば、その後の基本設計がスムーズに進むことはありえないからです。

だからといって、基本設計、詳細設計、プログラミング工程等のあらゆる工程において「重要でないもの」は、ありません。

今回は、プログラム詳細設計に焦点をおいて、基本設計との違いを軸に考えてみたいと思います。

SEは基本設計書を基に詳細設計書を作るわけですが、この2つのドキュメントの目的は明らかに異なります。

それは、基本設計書はお客様に確認してもらう為の設計書であり、詳細設計書は、プログラマに説明する為の設計書である、という点です。

ですから、基本設計書は、お客様が理解できる言葉で表現される、業務内容に沿って説明されたものであるべきです。

一方、詳細設計書は、SEがプログラマに指示を出す為のドキュメントとなるわけですから、むしろ業務内容の説明ではなく、そのプログラムの構成や、細かなプログラミング工程となるものです。

しかし、プログラミングをするのが人間である限り、そのプログラムが、どの画面で、どんな役割をもって使われ、誰が、いつ、どのように使うのか？といった、意味をつけて引き継ぐことが、プログラマにとって、大きな理解に繋がることは間違いありません。

プログラムがどのように使われるかもわからず、ただ、詳細設計書から読み取って、さまざまな想像をすることは、理解する為に余分な工数を使わせることだけでなく、勘違いを引き起こしたり、考えなくて良いような余分な作業を重要とみなして、コーディングしてしまったり、といったことを引き起こします。

もちろん、プログラマがそれなりのキャリアを積んでいる場合は、プログラマからSEに質問があがることでしょう。
だからといって、あがってきた質問に答えればよいという仕事の引継ぎ方法は、間違いの元となります。

詳細設計をSE同士で確認レビューを行うように、プログラマへの引継ぎも、できれば1対1ではなくて、1対2以上の関係で、引継ぎをする者と、引継ぎチェックを行う者がいることが望ましいでしょう。

詳細設計書に書いてあることを、一字一句守ってプログラミングすることは、プログラマにとっては当たり前のことです。
しかし、その詳細設計書が間違っていない、と誰が保障できるでしょうか。

人間が作っている以上、コピーしてきたものの未修正や、思い違い、うっかり、といったミスはつきものなのです。

頭ではわかっていたことが、ドキュメントとなると正確に表現できていない、というのは、ドキュメント作成者のミスだけでなく、人と人との「伝言ゲーム」的なコミュニケーション能力に起因することもあるわけです。

ありとあらゆるリスクを廃して無駄なことを省く。

その為には、一見無駄なように思われる「複数人数でのレビュー」や「ドキュメントチェック」を確実に行うことが、後々の工数の何倍もの節約になるのです。

「急がば回れ」といった諺を思い出すのは、こういうときなのです。

SEに成り立ての頃でした。

お客さまとの打ち合わせにおいて、システムにおけるデータの流れを全部把握して、お客さまからの質問や要望に即時で回答できる先輩を見て、感動したことを覚えています。

その頃の自分といえば、一つの帳票の出力順や項目の意味を考えることがやっとの段階でした。

常に自分の未熟さを痛感し、どうしたら幅広く、かつ奥深く考える力が付くんだろうかと思ったものでした。

一体どうしたら、システム全体を頭の中に入れることができるのか、そしてそれを、どうやって学べばよいのかも分かりませんでした。

何年かのキャリアを経て、やっと分かってきたことは、システムの考え方には「王道が存在する」ということでした。

どのシステムも違うようでありながら、設計する場合の一つの基本線は、みな同じであると気づくわけです。

では一体、「王道」とは何なのでしょうか。

「常にシステム全体を意識すること」

これは、あらゆる側面からシステムを眺めることができるか、語ることができるか、ということなのです。

同じストーリーを、時間帯をずらしたり、別々の登場人物を主人公として見せる映画を、皆さんは観たことがあるでしょうか？

実は、私の大好きな宮藤官九郎さんという脚本家が得意とするやり方です。

主人公は一人だけではなく、ある場面で脇役だった登場人物でも、別の場面では主人公になって、ストーリーを展開するということが多いのです。

それぞれの瞬間においては、そのストーリーは自然であり、主人公である人物から観た主観となって表現されます。

そしてそれは、システムにおいても同じなのです。

入力画面においては、その画面の果たす役割を意識し、一番重要な役割に特化して活躍させるのです。

帳票においては帳票の果たす役割、例えば日に一度、締めてから出力されるのか、いつでも好きなとき（例え、月次締めの最中であろうとも？）に出力できることが必要なのか、といった、個々の役割を深く意識するのです。

しかし、システムというのは、全体の流れ、各機能の係わり方が重要になります。

そのため、データの流れを意識することが必要になります。

全てのデータは、どこかで入力されて（生まれて）、どこかで更新され（教育され）どこかで何かを出力し（働き）、そしてやがて消去される（死んでいく）。

という、人の一生やドラマと同じなのです。

システムは、人が複数集まって関係性を持ち、成果を出す会社と同じく、機能が複数集まって関係するものなのです。

どんな人にも役割があるように、どんな画面にも帳票にも、そして項目1つにも役割があるのです。

彼らを舞台に登場させて、そのキャラクターを生かし活躍させ、退場させることが、SEの仕事なのだと思ってきたのです。

そう思って、仕事を楽しんできたのです。

システムにはさまざまなトラブルがつきものです。

トラブルが、作りこんだアプリケーションのバグである場合、問題は大きいが、トラブル自体はシンプルなのです。

このようなことを書くと、「ひんしゅく」を買ってしまいそうですね。

なぜシンプルなのかというと、この場合は、障害であるプログラム、もしくは、設計内容を改めることでトラブルが解決する、というように、解決方法が明確であるからなのです。

また、開発側は、申し訳ないという加害者意識や、責任を明確に持つはずですので、はっきりしていて、シンプルなトラブルだと表現しました。

トラブルの原因を発見する能力もSEには重要です。

例えば、

・テストサーバーでは、正しく動作するのに、本番機では、正しく動作しない。
・数ヶ月間、順調だったにも関わらず、突然、正しく動作しなくなった。

というようなトラブルであれば、環境、データ、操作の「何が違うのか」といったことを調べる必要があります。

このとき、思い込みは禁物です。

「何も触っていない、何もしていない。だからプログラムのバグではなく、顧客の運用に問題があるんだろう」

このような安易な考え方こそが、解決への障害となることが多くあります。
だからこそ、若いうちに上記のような失敗の経験をしておくべきなのです。

本当に、バグが原因でないかどうかは、どんな時でも、具体的に証明することが求められます。
バグが原因でないと証明できる前に「自分の問題ではない」と決めつけてはいけません。

さて、問題は、原因は分かったものの、誰の責任なのかが分からないときです。

例えば、うまく動かない原因が、複数の環境やデータの組合せであったとか、動くはずの設定で動かないとか・・・まぁ、いろいろ考えられますね。

こういった場合に、SEが一番陥ってはいけない状態は、「当事者意識の欠如」でしょう。

お客様が「当事者意識が高い」のは、当たり前のことです。
自分の注文したものが、正しく動かなければ、納得するわけがありません。

ところが、時にシステムに携わるSEが、「OSやハードのメーカのせいじゃないか？」とか、「どうしたらいいか分からないが、当社の責任ではない」といったところに気持ちが行ってしまうことがあります。

それは、一つには、目先の仕事の忙しさのせいかもしれません。
確かに、自分がやらなくてよいことまで、手を拡げることができるほど、余裕はないものです。

しかし、仕事が目先、忙しくない人がいるのでしょうか？誰しも常にやるべきこと、スケジュールに縛られて仕事をしています。
その中で、アクシデントのように、トラブルが舞い降りてくるわけです。

「もともとの提案がいけない」「営業が安易に請けるからいけない」などという思いが出てきたとしても、そのような気持ちは、即時で判断すべき、行動すべきことの足かせになるばかりなのです。

解決方法に、「受注そのものをキャンセルさせていただく」という究極の方法があります。

しかし、「その仕事をやらなくてもよかった」ということは滅多にないでしょう。
本来は、解決すべきであるはずなのです。

解決できないトラブルが幾つもあることは、この世界に生きる人であれば分かっています。

しかし、システムというのは、常に思いがけないトラブルがつきものなのです。

「何がうまくいっていて（正しく動いていて）、何がうまくいっていないのか（正しく動かないのか）」

細かな検証を、1つずつしていくことが、まず第一です。

次に考えられるのは、顧客と現状の確認をしながら、妥協できるところは、運用やコストで妥協していただく、ということでしょう。

直せないとしても、諦めてはいけないのです。
しかし、直し続ける間、顧客がどう運用すべきかをきちんと確認する必要があります。

大切なのは、結局、どんな対処をするにせよ、どこまでやるか、やらないかは、SEと顧客の意思にかかっていることを忘れないことでしょう。

トラブルに負けないコツは、

・当事者意識を強く持つ
・できること、できないことをなるべく早く切り分ける
・別の方法をありとあらゆる角度から調査する
・小さなテストを実行する
・顧客と、とことん誠意をもって話しあう

他の会社の人も含めて、相談ができる技術者を、多く味方につけることも、重要なポイントといえるでしょう。

今回は、ちょっとカッコいいタイトルにしましたが、作業方法ではなくて、「判断基準」のお話です。

受託開発をしていて、一番、判断に悩む問題は、「どこまで丁寧に作るのか？」「どこはシンプルな作りで構わないのか？」ということだと思います。

理想像は、全ての機能において、「かゆいところに手が届く」ように作られていることなのでしょう。

こう考えている若手SEは、多いはずです。
これは現実問題としては、有り得ないことなのです。

しかしながら、実現する方法が全くないというわけではありません。

それは、どこの開発会社もやってきた、そして、現在もやっている方法ですが、元となるフレームワーク自体に徹底的に注力し、「良いもの」にして、使い回すという方法です。
部品として、再利用できるものを増やしておくのです。

この場合、「良いもの」とは、

・プログラムがシンプルである。
・操作性が良い。
・ミスが防げる。
・何かあったとき、直ぐに問題の箇所がわかる。

ということを指します。

フレームワークで実現できることだけであれば、何の問題もありません。
しかし、フレームワーク外として個別に作り込みを要求される機能は、必ず存在します。

そのとき、それを機能の重要さや、使用頻度に関係なく、一律に「丁寧に作るべきだ」と考えてしまうことは、生産性を低め、結果としてシステムの効果を下げてしまいます。

実際には、この判断基準をどう考えるか、というのが若手SEが成長する一つのステップなのかもしれません。

結局は、一定のコストと時間の中で、実現できることを絞り、選択しなければならないからです。

しかし、若手SEは、全ての機能に対して同じように「操作性が良いもの」「多機能なもの」を提供しようとします。

そのため、

「納品直前に理想のシステムが実現できないことがわかる」

「既に多くの工数費やしてしまって、後戻りできない状態でやっと気が付く」

といった状態に陥ります。

そこには、いろいろな理由があるでしょう。

「理想のプログラムは高機能で難易度が高く、ハイレベルの技術者が要求されるが結局、そこまで人員が手配できなかった」

「大抵において、プロジェクトには、予想外のトラブルや問題が起きるものなので、そちらに工数がかかってしまった」

など、など。

そして、志半ばで倒れてしまう。

であれば、各機能に対して、最初から徹底的に、優先順位付けしておけば、お客様にも迷惑がかからなかった。

ということがよくあるのです。

残念なことですが。

技術でも工数でも、必ずバッファを持つ、といったスケジュール管理も大事ですが、何に力を入れて、何をシンプルにするかといった、運用側のことを考えた「勘」がSEには要求されるのです。

わたしがいつも考えているのは、次の2点です。

1）その機能を入れ込むのに何時間かかるか？技術者の能力は合っているか？

2）その機能を入れることによって、節約できるお客様の時間はどれくらいか？

つまり、システム開発としてのROIを考えて判断するのです。

例えば、システムの初期稼動時にしか使わないような機能は、操作性や機能を重視する必要はありません。
それよりも、入力ミスをしてしまう可能性を無くすことに注力すべきです。

また、使用頻度の低い機能であれば、操作を忘れても、画面を見ればわかるように、メッセージを入れることに気を使います。

毎日、毎日、複数の人が頻繁に使う機能については、操作性を良くし、操作ミスに対してすぐにアラームが発生するように、そして、10秒でも、5秒でも節約して、作業ができることに注力します。

結局、そのシステムが稼働して、1年、2年というスパンで見た場合の「運用コスト」と「開発コスト」を比較して考えるのです。

つまり、システム開発は、トータルコストで考えるのです。

RDBを使うシステム開発においては、レスポンス（応答時間）がかかることも、障害の一つにあげられます。

画面では、3秒ルールというものがよく言われていますが、どんな機能においても、3秒以内の応答を確保できるという保証はありません。

基本設計時には、どういう処理がどのくらい時間が掛かるかをSEが知っていて、お客さまに、その時間で許されることなのかを確認する作業が必要になります。

もちろん、ハードウエアの選択、ネットワーク、同時使用人数など、さまざまな条件において、レスポンスは変わってきてしまうわけですから、何を標準としてレスポンスを計るかの前提条件も重要になります。

実際、わたしなどは短気ですので、社内テストにおいても、画面の操作で、ボタンを押してから数秒間何も表示されない状態は、本当に嫌いなのです。
（そういう意味では、人よりも許せる範囲が少ないので、SEに向いているともいえるでしょう）

ましてや、操作しても応答までに数秒ではなくて10秒、ひいては1分もかかるということであれば、後から「何とか速くならないか」というクレームが入るのも、当たり前のことなのです。

こういった場合、後からSQL文を直すということで対処することが多いのですが、実際のところは、詳細設計中やその前のデータベース設計時、そしてその前の基本設計時に、レスポンスについてどれだけ考慮して打ち合わせしているか、設計しているかで、ほぼ決まってくる話なのです。

レスポンスについては、オラクル社やMicrosoft社の、DB製品に特化したチューニングの書籍に任せたいと思っています。
私は、これらの本を読むことで、さまざまな示唆やアイデアを得ることができました。

さて、今回、敢えて確認したいことは、プログラム単体のレスポンスではなく、データコンバートや、移行、テスト環境の構築といったものについての作業時間の話です。

日々のバッチや締めのバッチもそうですが、こういった処理は、決められた時間内に作業が終わることが、必須である処理なのです。

例えば、お客様が使用していない深夜0時から朝9時までに行う、などです。

こういう処理の予測時間を想定しないで実行することはあり得ません。
必ず、どの順番でどの処理を行い、どのくらい掛かるかを、シュミレーションして行うことが必要です。

そして、10時間余裕があるとしたら、リスクバッファと終了後のチェックを含めて、半分の5時間が最大使用時間だと思っています。

また、最初に必ず「バックアップ」を行い、どの段階で処理を中断しても、「元の状態に戻せる」、つまり、最低でも、作業を始めるときと同じ状態に戻せることが、最重要です。

1,000万件の処理を行う場合、可能であれば、テスト環境で、同じ件数でどのくらい時間が掛かるのかを、全て網羅してシュミレーションしておくことが必要です。

RDBの場合、処理によって件数が多くなればなるほど、遅くなるものが一般的です。
100件と1,000件と比べて10倍、10,000件は100倍といかないのです。

インデックスを付けて処理を行なうのか、削除して行うのか。
どんなデータを確認して、正常処理が行なわれたと判断すべきなのか。

処理の前にシュミレーションを行い、準備しておくことは、ここでも重要なのです。

そしてもちろん、どのような環境下において、どんな処理が、何時間掛かったのかを記録し報告することは、他の仕事にも役立つことなのです。

新卒採用の説明会で、必ずと言っていいほど出る質問があります。

「私は文系なんですが、ついていけるでしょうか？」

実際のところ、私自身が文系なので、「何の問題もありません」と答えることが多いのです。

しかし、文系としてこの業界に入って、SEになり、悩むことが何もなかったわけではありません。

まず、自分自身の「論理的な思考」というところで、一番悩みました。

どうすれば、論理的な思考ができるのか？

一つには、自分が女性であるという、ジェンダーの悩みがありました。
何かを判断するときに必ず、「好き」「嫌い」といった感情が出てしまうのです。

それも「なんとなく」、つまり理由もなく、その日の、その瞬間の気分次第ということがあるのです。

そんな私でも、プログラミングやシステム設計を何十年も（!!）続けてくることができたのは、何故でしょうか。

採用説明会では、何度も話したのですが、紙に書くことから、プログラミングを始めたことが、論理思考を育むのに、大きかったと思うのです。

紙に書いて、何度でも読み直す。

これが、作ってしまったプログラムを、違う視点で見直す力を作ってくれました。

コンパイルするよりも、動かすよりも何よりも、ソースを読むことが生産力アップの最短距離であることを理解したのです。

そして、プログラミングで身に付いた知恵は、システム設計でも役に立てることができました。

システム設計を始めた頃は、プログラマとしての感性が勝ってしまい、細かなことばかりを気にしてしまって、全体を見通す力にどうしても欠けていました。

30本から40本くらいの小さなシステム構築だったので、なんとかやっていたのだと思うのですが、システムテストの最後の最後になって、重大なデータの抜けに気が付くこともありました。

そんなときに、他社のエンジニアが書いたプロセスフローに出会ったのです。

実際はなんと呼ぶのかはわかりませんが、私はプロセスフローとか、システムフロー図と呼んでいます。

一つ一つのプログラムを、別の紙に描き表すのではなく、1枚の紙に描くのです。

そこでは、各プログラムが作り出すデータ（実際にはテーブルとして描きます）と参照するデータを細かく描いていきます。

1枚と言っても、A3横の紙に書くと1枚に20本くらいの機能しか描き切れませんので、実際には何枚にも渡ってしまいます。

それでも、サブシステム単位に区切れば、1枚に描くことは可能です。

ポイントは、全てを描き切るということです。これに尽きます。
とにかくシステムの全部を考える。

若手エンジニアには、この作業を打ち合わせの途中から始めることをお勧めします。
大きな全体図を見て、その中の部分としての機能を考える。
この視点が、実は一番大事なことなのです。

細かな操作性、凝った造りに終始してしまい、大事なことが抜けてしまう若手を何人も見てきました。

全体を見る。

その為に、設計前に必ず、プロセスフロー図を完成させる。

文系の女性エンジニアでも、私が、システム設計をやってくることができたポイントは、これに尽きます。

全体の重みを知れば、お客様の細かな要望に対応すべきか、すべきでないかも判断できるはずです。

デジタルで文書を作成するのが常識になり、メールで即時納品も出来る世の中になりました。

しかし、それでも印刷したドキュメントは、必要なものです。

例えば、要件分析や基本設計のときに、ブレーンストーミングしたりする場合を除いては、顧客側も開発側も、互いに相手に説明するための資料（ドキュメント）を用意して会議に臨みます。

このドキュメントが、やがて要件定義書や基本設計書になるわけですが、ドキュメントの作成必須条件とは何でしょうか。

当たり前すぎるほど当たり前のことが幾つかあるのですが、どうも、「雛形」や「テンプレート」でドキュメントを作ることしか知らない人達には、必須事項として理解されていないことがあるようです。

1）どんな目的の資料かをはっきりさせ、意味なく余分な説明を入れない。

親切心から記入したとしても、その文章や説明が、逆に主な目的を曖昧にしてしまったりするのです。
複数の目的を兼ねた資料というのはマトリックスの表を除いては、むしろ良くないと思っています。

2）どんな場面で使われるのかを想定して作成する。

これに関しては、後で詳しく述べたいと思います。

3)タイトル、作成日付（更新日付）、ページ数・全ページ数をつける。

こんなことも知らない人がいるのか？とお思いでしょうか。
いえいえ、かなりいます。
一度、「雛型」無しで説明書きや報告書を作成されてみたらいかがでしょうか。

4）A4横または、A3横に統一する。

もちろんA4縦であっても良いとは思います。
要は印刷して閉じたときに、同じスタイルにできるように心がけるということです。
B4サイズの用紙は不適です。

5）図解やイラストを用いて一目で理解できたり、補足できるようにする。

6）1つの記号を複数の意味に使わない。

記号を使った図を描く場合には、丸やひし形、二重線で囲まれた四角などの意味を明確にするべきです。
さらに、記号の判例をつけなくてはなりません。

7）同じ注意書きをいたるところに書かない。

コピー＆ペーストはミスの元凶です。
複数個所に書かないで、符号化して一か所にまとめて、統一的に扱いましょう。

8）とにかく記号・番号をつける。

年月日だけでなく、文書番号、段落番号、項番といったものを付けて、分類することで、一意のものとして特定できるように心がけましょう。
できれば、大→中→小→詳細といった場合に、その親の分類がわかるようなつけ方が望ましいものです。
例：
大分類　1. 2. 3. 4.
中分類　1-1. 1-2. 2-1. 2-2
小分類　1-1-1. 1-2-1. 2-1-2
※数字はこの分類だけにして、他の図や説明には、「a b c d」「(1)(2)(3)(4)」といったように、違う意味で同じ数字（記号）を使わないようにする、といったことも考えます。

他にも、フォントを揃える、フォントを9ポイント未満の大きさにしない、印刷物のパンチ穴を意識して余白を作る、ホッチキスで留める位置は左斜め上とする、…等々、細かいことを言い出したらきりがありません。

しかし、ルールを部下や他の人に徹底させることも重要ですが、何より、そのルールは、どういう理由で(Why)そうなっているのかを考えさせて、納得した理解をさせることが最重要だと思っています。

2）で挙げたように、その文書が「会議で資料として使われるもの」なのか、「最終確認用で配る」ものなのかによって、記入しなければいけない内容の精密さが変わってくるのです。

もし会議で資料として使われるものであれば、口頭で説明して頭にすっと入ってくるものについて、いちいち文章で書いてはいけません。

会議資料をたとえ前日に配っておいたとしても、会議の時間になるまで資料を読まない人は多いものなのです。

その場で字を読むことに集中したら、会議の意味は薄れてしまいます。

だから、会議で使う資料は、図や簡単な分類だけにとどめ、各自が同じ資料の同じ場所を見ていることを確認し、それぞれの顔を見て理解度を測りながら、口頭で説明することが望ましいのです。
そういった意味でページ数の表記や章番号は絶対必要なのです。

会議の出席者全員に、「自分の頭で考えて理解させる」そのための資料であるべきなのです。

時々、プレゼンテーション資料や会議資料に文章をツラツラと書き綴り、そのまま読み通す人がいます。

この場合、判を押したように、声は小さく早口になっています。

文章を読みあげるというスタイルで、出席者全員が理解し、納得することは無いということを知るべきです。

ただし、会議で使った資料を最終確認資料とする場合には、参加者の共通理解のある用語を使った文章で、確認に至った流れに沿ってまとめることが必要になります。

とにかく、どんなドキュメントにも、「目的」や「使用する場」があるのです。

読み手を意識したドキュメントを、ルールを守って応用的に作ることができてこそ、真のSEなのです。

実際のところ、当社は100%受託開発を行っています。

もちろん、ユーザー様との直案件だけでなく、大手ベンダーの営業さんや、システムソリューション部隊からも、お仕事をご紹介いただいています。

受託開発で全部、社内で賄っていくというのは、ある意味、奇跡に近く、営業がいないわけですから、仕事が来る経路はいくらあっても構いません。

どうしても、「営業がいない」→「営業に無関心」ということになりがちですが、それは必ずしも、そうであるとも言えません。

なぜなら、飛び込みや電話による「新規営業」はしなくても、Webをご覧になったお客さまから、直接のお問い合わせがあることもあるのです。

また、営業がいない為の苦しみというものを散々味わっているので、案件に対しては、必死に食らいつこうとする根性は生まれます。

営業部隊がお客様に提出している提案書にも、興味津々です。

さて、開発費用が数千万以上になると思われるシステム提案書を集めてみると、どの提案書も似た形式で書かれていることに気づきます。

企業の基幹業務についてのシステム・リニューアルを例にとってみますと、御社業界の状況、御社の置かれた状況、御社の課題、問題点といった、お客さまの現在状況を分析し、そこから問題点を抽出して、どうやってその課題を解決するのかといったことを中心に、将来像、あるべきシステム展開を絵にして語るといった、「提案型」がほとんどを占めているのです。

正直、提案書の書き方といった書籍を読んだり、いろいろな提案書を集めてみると、こういうものがほとんどです。

もちろん、「提案書」だから、「提案型」であるべきだと考えることはよく分かります。

しかし、こういう提案書を幾つか見ますと、同じ業界であれば使い回し、同じ業界でなくても、文書管理、在庫管理といった、共通のシステム内容であれば使い回しが行われていることが、見た瞬間に分かります。

つまり、汎用的で抽象的な「カッコいい言葉の羅列」の提案書にすぎず、お客様に対しての関心や思いやり、サイズに合った提案が入っていることが少ないと言いたいのです。

「これを受け取ったユーザー企業の担当者は、どこを見るんだろうか」と考えると、「機能一覧＋スケジュール＋コスト」だけのような気がします（すみません）。

結局、経営者や情報システム部が余りにも忙しいのか、ITシステムに興味がないのか、両方なのか分かりませんが、こういったコンサルタント的提案書（決してほめ言葉ではありません）が、まかり通っていることが本当に不思議です。

では、多少、近視眼的だとは思いますが、私が考える「よく出来た提案書」について考えてみたいと思います。

それは、現場なり、ユーザーのシステム部の方々が見たときに、「当社のことがよくわかっている」とか、「ここまでいろいろなことを考えてくれるんだ」と思わせるような、気持ちを揺さぶる提案書なのです。

その為には、提案書は、「こうあるべきだ」の形ではなく、お客様が、個別に自社向けに提案されたと実感できる機能を、具体的な運用と同時に表現し、盛り込んで、その中の「お勧め」が、はっきりと具体的に書かれていることではないでしょうか。

「とにかく営業しなければ仕事が無い」、「提案しなければ始まらない」というのは確かなことです。

しかし、IT技術力を使うことで企業文化なり状況を画期的に変える、素晴らしい提案書を作ることが使命だと思っているのか、ともすれば、「絵に描いた餅」のようなビジョン系のシステム提案を作り、お客様を見下したような提案書の形が多いのが気になります。

提案先の企業の文化の変革を唱えながらも、一方では、使い回しした提案書がまかり回っているのも事実だから、矛盾していると思うのです。

もちろん、「万事がこれ」とは言いたくありませんし、中小企業のソフトハウスとは違うんだと言われてしまえば、そうなのかもしれません。

ただ、相手によって、また、場合によって、提案書の中身をちょっと違う視点で発想してみることも、必要ではないかと思うのです。

なぜなら、「ルーチン化」してしまうことが、仕事の最大の敵だと思っているからなのです。

当社ではシステム開発を専門で行っているわけですが、専門が故に、「思い込み」や「先入観」といったもので頭が束縛されてしまっていることがあります。

例えば、「こうあるべき論」とか「理想の形」といったものがあります。

しかし、「それは本当に理想の形なんだろうか？」ということについて、今までどこまで熟考したことが、あるいは、されたことがあるんだろうかと疑ってみることも必要です。

設計手法やチームビルディングでは、大きな理想・目的といったものも必要ですが、細かなことを1つずつチェックし、最適化していくことも役に立つのだと信じています。

では、今回から数回にわたっての課題は「番号」です。

コードと読み替えてもOKです。

コードといえば、わたくし自身、若いときに「取引先コード」で失敗した経験があります。

とにかくその当時は、業務をシステム化するのが初めてといったお客様が多かったのですが、販売管理を発注して下さったお客様から、「得意先コード」をどうナンバリングしたらいいのかといった相談を受けたわけです。

当時、わたしの頭の中にある「コード」とは、あくまでも、「一意のためのもの」にしか過ぎませんでした。

例えば、「頭1桁の"1"は得意先分類、といったような意味を持たせてしまうと、いつかはコード体系が破たんする」という考えが先にきてしまいました。

「得意先分類」や「●●区分」は、得意先コードの体系中に含まれてはいけないと信じきっていました。

得意先管理表を印刷する場合は、金額の多い順や名前順に印刷する方法もあることですし、「得意先分類別」といったような形で印刷すればいいからと考えたのです。

「コードに意味を持たせる必要はありません。適当に付けて下さい」

SEからそんな冷たいことを言われたお客様は、一生懸命考えて取引先グループごとに分けて、「100000～は、このグループ」といったように付けていったようでした。

もちろん得意先コードがシステムの裏側でだけ役に立つのであれば、そういったアドバイスも有効だったでしょう。

しかし当時は、売上伝票を入力するのに、得意先コードを、「得意先名」ではなく「コード」で入力することが必須でした。

名前で照会する画面を作るほど、システム開発の生産性は高くなく、お客様の予算の中ではコード入力、コード範囲指定での印刷が通常だったのです。

そこで、手書きした売上伝票に得意先コードを記入してから、画面入力をする必要がありました。

現場で使ってみれば、毎日毎日、番号チェックをして記入していくので、番号を暗記してしまうお客様がいらっしゃいます。

そうです、頻繁に売上がある「上得意先様」です。

そこで、上得意先の番号をきちんと分かりやすい番号に決めていくといったことも考えられます。

最初に私が考えたように、「コードに意味付けをしたら破たんしてしまう」というものだとしても、コードに振る番号に意味を持たせることは、実際には、とても重要でした。

なぜなら、意味づけされているコードは覚えやすく、また、コード表からの検索も一瞬でできるからなのです。

特に、一覧表や元帳といった帳票系では、得意先分類や区分の次の、第2ソートキーとなるのが「得意先コード」ですから、それも考えるべきでした。

5年後、10年後に取引先が増えて、コードの意味づけが破たんするかもしれないからといって、最初につけるコードが何でも良いわけではなかったのです。

現場の担当者に対する思いやりに欠けていた自分を思い出すたびに、情けない申し訳ない気持ちになるのです。

前回からですが、「番号・コード」シリーズに突入しています。

「毎週、何を書こうかと大変でしょう」と言われることが多いのですが、さすがに150回を超えている理由は、「悩まず書く」、これに尽きます。

ひょっとしたら何度か同じことを書いているかもしれませんが、きっとそれは、特別重要なことか、杉山がボケているかのどちらかなのでお許し下さい。

飲むと忘却度が各段に上がる杉山ですが、このメルマガを書いているときは常に素面（しらふ）です。

さて、今回は「伝票番号」もしくは「連番」といったものについて考えてみたいと思います。

データベースには「IDENTITY」という自動連番機能もありますが、これを実際に使うことはあまり無いのではと、私の経験から思います。

「ワークテーブル」と呼んでいる、何か処理する度に削除して作り直すというタイプのテーブルでは使うべきだと思うのですが、マスタやジャーナルといった、何年にも渡って存在するテーブルの項目に使うのは、開発テスト時や保守の事などを考えると、あまりお勧めできません。

伝票番号を画面から手入力するという場合はもちろん、システム機能として伝票番号を付加する必要はありません。

画面から手入力する場合というのは、番号がプレプリントされた伝票を使う場合ですね。

例えば、宅配の伝票番号や、チェーンストア統一伝票番号などです。

もちろん自社伝票を使って先にナンバリングしてあるところもあります。

一般には、伝票番号は自動でシステムから付ける場合が多いのではないでしょうか。

また、「伝票番号」というような運用の形態が無いとしても、入力した画面の登録処理ごとに連番を付けるのは常でしょう。

連番の取得方法として、だいたい以下の2つの処理に分けられます。

1) 売上伝票であれば、売上伝票ジャーナルの伝票番号の最大値をもってきて、それに1を加えて番号を獲得する

2) 伝票番号テーブルといったものを作っておいて、最終番号はテーブルに更新されているので、その番号に1を加えてから番号を獲得する

これら2つのうち、小さなシステムでデータも大容量でない場合は1)でも良いのですが、私は常に、2)を採用します。

これに関して言うと、1)を使っていたシステムではレスポンスに関する問題が起きることがあるのですが、2)で問題が起きるのは、排他処理の問題くらいです。

もちろん、SEとプログラマがどのようにリスクを考えるかで変わってきます。

データベースや言語といった開発環境のクセ、組み方、お客さまの運用を理解して吟味している場合には、どちらでも良いのかもしれません。

ただ、2)を選択していたことでラッキーだったことはいくつかあります。

例えば、現状で「357688番」まで番号が進んでいるシステムを新システムに移行する場合、新システム番号は、「1000001番」から採番するといったことが簡単に実現できます。

この場合、新システムで新規に登録した伝票と移行された伝票とが、一目で確認できるといったメリットがあります。

また、この伝票番号取得の部分は、各エントリでそれぞれコーディングされるのではなく、ストアドプロシージャとして共通に用意され、使われることが望ましいでしょう。

「頭に年度を付けた伝票番号」といった場合も同様に、伝票番号テーブルの主キーに年度を含むだけで同じ処理を行います。

2008年も終わりに近づいています。
今年もこのメルマガをご愛読いただき、本当にありがとうございました。

このメルマガは、自分がシステム設計するときに、どういう視点でどういったことを考えて設計しているのかを主に書かせていただいています。

それは、若い技術者にとって少しでも何かヒントになればいいなという気持ちからです。

ここで何度も語ったことかもしれませんが、「業務」をシステム化するという一番よくある、それでいて一番奥が深いことについて再考してみたいと思います。

この仕事を始めた若い頃には、私にとって業務という言葉は何を意味するかわからず、ただコンピュータプログラムを作ることだけが業務システムの入り口でした。

しかし、どんなシステムを作ってきたのか？と思い返してみれば、その類似性に驚きます。
業務フロー図といわれるものがありますが、要するに業務フロー図をシステム化することがほとんどの仕事でした。

今でもシステムを作る場合には、「システムフロー図」だけでなく「業務フロー図」を作成することを自分に課しています。

それは、業務システムを構築する上で一番重要なことは「流れ」だと思っているからなのです。

どこでその情報が入力され、付加され、更新されるのか、そして、どこでその情報が出力され、参照され、削除されるのか。

しかし、技術者の中にはシステムの一番重要な箇所は入力や更新だと思っている人がいます。

なぜなら、プログラマにとって入力や更新がバグを生みやすく、難易度が高い箇所だからです。

しかし、システム設計から考えれば、一番重要な箇所はどこでもありません。
すべてです。

すべて重要と言ってしまったら身もふたもないですが、実際はそうなのです。

システム全体の流れをすべて捉えて、その一箇所一箇所のどこででも正しい情報が出力されることが重要なことだと思っています。

そのために、業務フロー図をきちんと細部まで描き、お客様とともに「ここではどんな視点で帳票が必要なのか」「どんな視点で操作しているのか」をシミュレーションしながらシステムの妥当性を問う必要があるのです。

ただ、最初の頃は主体的に業務フロー図を描くことがなかなかできませんでした。

ビジネスのことを考えたこともない、やったこともない私が他の会社の知らない人がどうやって、何を考えて業務をしているかを想像することは不可能でした。

しかし、ある時考えました。
「コンピュータが無いときに人はどうやって業務を遂行していたのか？」「コンピュータが壊れたらこの会社はどうやって業務を遂行するのか？」と。

今となっては24時間無停止のシステムが普通にあるのですから、こんなことを考える必要は無いのかもしれません。

しかし、私のシステム設計の出発時点はこれでした。

コンピュータが無かったとしたら、どうやって業務を遂行するのか？

それを解決してくれたのは―――――。
次回はそのお話です。

先週の続きです。
今回も私のシステム設計の出発地点をお話したいと思います。

「コンピュータが無いときに人はどうやって業務を遂行していたのか？」
「コンピュータが壊れたらこの会社はどうやって業務を遂行するのか？」ということを考え始めたときに、様々なことに気がつき始めました。

その1つの例が、レジのレシートです。

現在のレジの多くはオンラインでリアルタイムにサーバーにレジデータが保存されますが、中にはオフラインでサーバーに繋がっていないレジもあります。

そのようなネットワークに繋がっていないレジを使用している小さな商店やレストランを例に考えてみましょう。

レジの計算結果は、レシートに印刷され、お客様に手渡されます。
同時にレジの中には、計算結果のデジタルデータが保存されます。

では、このレジが突然壊れてしまったらこのお店はどうやって業務を遂行するでしょうか？

おそらく電卓などを用いて計算し、レシートは紙に書いてお客様に手渡すでしょう。

しかし、レジが復旧出来ないとしたらそれまでの細かな売上情報のデータはどうなるのでしょうか？

実は、レジのレシートは複写式になっています。
(現在のレジは、複写になっていないものが多いのかもしれませんが・・・)
お客様に手渡したレシートそのままの印字物が内部に保存されています。
つまり、デジタルと紙の両方でデータの保存を行っているのです。

そのため、最悪レジが故障して復旧不可能になっても、複写された紙からデータの復旧が出来るというわけです。

当たり前だけど、素晴らしい。

私にとっては、そんな小さな発見が業務を理解するための1つの入り口でした。

身近な所で小さな発見をすると、次から次へと見えてくるものがありました。

では、企業間の取り引き、つまり B to B の仕組み、また、社内業務ではどうなっているでしょうか?

次回に続きます。

とうとう本年最後のメルマガとなりました。
2008年も大変お世話になりました。

未曽有（この言葉、気に入ってすぐ使っちゃいます）の世界的経済危機の中、いろいろな思いで年末を迎えることになりました。

リーマン・ブラザーズが倒れ、あの「トヨタ」ですら営業赤字になる可能性が報道されています。（12月19日現在）

営業利益が2兆円を超え、我が世の春を謳歌した（？）あの3月から1年も経たないうちに…、誰がこんなことを予想したのでしょうか。

と、他社のことを憂いている場合じゃありませんね。

「なんでもあるんだ」ということがこれほど、実感できることも今までなかったわけですから、「なんでもある」→「なんでもできる」といった風に前向きにとらえていくチャンスだと思っています。

前置きは以上にして、前回はレジの話をしました。

POSレジなんてメーカーは限られているし、請負や派遣の仕事には関係無いと思っているあなた、レシートひとつをとっても、そこから学ぶことは幾つもあるということが分かっていただけましたか？

例えば、忘年会のゲームとしてこんなイベントをしてみてはいかがでしょうか？

コンビニで買った商品を3つほど見せて、ここからいかに本物のレシートに印刷されている項目を予測するかという「レシート再現コンテスト」を行うのです。

こんなことを考えるのは仕事中毒の証拠ですね。

さて、社内業務の仕組みでレシートに代わるもの。
それは、「伝票」です。

伝票という言葉がすでに「何？それ」という感じかもしれませんが、簿記を勉強された方や、販売管理システムに携わった経験をお持ちの方であればご存知のはずです。

前々回からのテーマである、「コンピュータが無いときに人はどうやって業務を遂行していたのか？」ということなのですが、コンピュータが無い時代には、売上伝票、仕入伝票、入金伝票、支払伝票、振替伝票、出荷伝票・・・という様々な種類の伝票を使っていました。

他部門や他社との関係の中で「発生した取引」を簿記では、仕訳（しわけ）という言葉を使い、伝票に記入していました。

これを「仕訳伝票」といいます。

「モノ」「カネ」が動く場合は、必ずその部門の担当者が仕訳伝票を記入し、その伝票を経理の担当者が記帳していたのです。

ただし、企業規模が大きくなり、「仕訳伝票」だけでは情報を管理することが難しくなってきました。

例えば、取引先を登録する、受注を受け付けるということは、経理の作業とは関係ありません。

それでもシステムでは取引先を登録し、受注を入力する画面を必要とします。

こういったものも仕訳とは異なりますが、「伝票」という紙に書くことはできます。

「取引先登録申請伝票」「受注申請伝票」といったものです。

例えば、新規に取引をしたい取引先が現れたとき、担当者は「取引先登録申請伝票」に記入します。

伝票に記入する理由は大きく分けて、

1)誰が、いつ、どういう理由で何を申請したのかを記載する（発生の根拠）
2)伝票を他部門（他社）に渡すことで情報を受け渡す（情報の伝達）

といったことになります。

だから日付、担当者（記載者）は伝票にとって最重要になるわけです。

取引先登録申請伝票は複写式で、1枚は自分に、そしてもう1枚は部門長に提出します。

自分が保管する伝票は「取引先登録申請伝票（控）」です。

何時その伝票を記載して部門長に渡したのかを控えとして保存することで、万が一に備えるわけです。

このように、伝票には「（控）」というコピーを保存して、

3)万が一の情報紛失に備える

という機能もあるのです。

部門長はこの申請伝票を確認し、承認欄に印を押して、取引先台帳に記載する担当者に回します。

これが部門長一人の場合もあれば、部門長→経理課員→経理部長といったルートで回ることもあるでしょう。

この場合には、伝票上にその個数だけ承認欄として日付・担当者名の捺印欄が必要となるのです。

このように、伝票の項目レイアウト設計をする場合には、業務運用の流れが頭に入っていなければなりません。

だからこそ、伝票に必要な項目がどれだけ思い浮かぶかが、業務運用フローをどれだけ理解しているかのテストになるのです。

こういうときには「5W1H（When，Where，Who，What，Why，How）」はもちろん有効ですが、コンピュータシステムを考えるとき、画面や帳票を考える前に、まず手書きの伝票で業務運用を回すということを考えてみてください。

それでは、良いお年をお迎えください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

という順序になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

わたしの場合はですか？

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

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

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

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

もし、あなたがITシステムで訴訟を起こされたら裁判に勝つ自信がありますか？

「きちんと仕事をしていれば訴訟にまでなるはずがない」「だからIT訴訟に関して興味がない」
なるほど、おっしゃる通りかもしれません。

ただ、あなたが経営者であったり、部門長のような立場ならば、今回の情報をスルーするのは大変なリスクではないでしょうか。

最近の景況感やご時世では、訴訟の数は確実に増えています。

いくら「格好悪いから裁判をしたくない」といっても、相手が訴訟を起こしたら受けて立たなければいけません。

たとえ、どんなに自分は正しいと思っていてもです。

なぜなら、起こされた訴訟に対して何もしなければ「100% 裁判に負ける」からです。

知っておくべきことを知らないといざというときに大変なことになります。

そこで、今回のシリーズはとても過激なテーマですが、「都合の悪いことは考えたくない」という気持ちを抑えて、ITシステム訴訟について考えます。

とは言っても、私は法律について「素人」です。

弁護士が後ろについているわけでも、監修しているわけでもありません。

このテーマをお読みになる上では、その点をご留意願います。

まず、ITシステムで訴訟に発展する内容として考えられるものは、

　1）システム要件を満たさなかったから契約を解除したい。ユーザーがお金を支払う気が無い。

　2）追加要件でオーバーした費用を払わない。追加要件なのか、元々の仕様なのか、バグなのかが問題となる。

　3）システム障害で生じた被害額を保障してほしい。

　4）著作権など知的財産権を侵害している。自社（ユーザー）に著作権が所属していると考えるシステムをベンダが他社に収めた。

ざっと書き出すとこのような内容が挙げられますが、まだまだありそうです・・・。

しかし、いずれの項目についても、基本的には「契約書」がとても重要です。

契約書に、その事項についてどう書かれているかが問題になったときの1つの指針になります。

例えば、3)のシステム障害、セキュリティ事件などの弁償となると多額の賠償を請求されることもあり得ます。

そのため、契約書には保障金額の限度額を明記しておくことが必要です。

しかし、このメルマガの趣旨は決して、システム開発を請け負う側（ベンダ側）がうまい契約書を作成し、問題をすり抜けるということではありません。

なぜなら、下記リンク先に記載されているようにITシステムにおける「裁判」は、勝っても負けてもどちらにも勝者はいないのです。（勝つのは弁護士だけ・・・）

・IT訴訟に「勝者」などいない
http://www.ciojp.com/contents/?id=00001038;t=12

この事例は、圧倒的にベンダが悪い例ですが、ユーザーが勝っても、本来の勝者に与えられるべきものを何ひとつ得ることにはなりません。

「ITシステム訴訟を起こされたら」を考える手はじめはどんな事態がITシステム訴訟になっているのか？を知ることです。

このテーマ、次回に続きます。

もし、あなたがITシステムで訴訟を起こされたら裁判に勝つ自信がありますか？

今回は、前回の「もし、ITシステムで訴訟を起こされたら」の続きです。

まず、ITシステムで訴訟に発展する内容として考えられるものの一番として挙げた

1）システム要件を満たさなかったから契約を解除したい。
ユーザーがお金を支払う気が無い。

について取り上げます。

今回の内容は、いつもにも増して真面目で固い（？）ので覚悟してください。

ユーザーが求める「システム要件」とは何を指すのかを考えます。

現在のシステム構築のガイドラインとなっている、共通フレームワーク2007（※）の開発プロセス1.6.2に
※解説　http://www.atmarkit.co.jp/aig/04biz/slcpjcf.html
システム要件定義について以下のように書かれています。

*------------------------------------------------------*
業務全体に対して定義された利害関係の要件のうち、
システムに関する部分について技術的に
実現可能であるかを検証し、システム設計が可能な技術要件に
変換することである。
*------------------------------------------------------*

また、このようにも書かれています。

*------------------------------------------------------*
開発者が契約に従って、実施または支援する
*------------------------------------------------------*

どういった要件を記述するかということも書かれていますが、一番注目したい個所はそのあとです。

*------------------------------------------------------*
1.6.2.2 システム要件の評価

次の基準を考慮して、システム要件を評価する。
評価結果は文書化する。

(a)取得ニーズへの追跡可能性
(b)取得ニーズとの一貫性
(c)テスト計画性
(d)システム方式設計の実現可能性
(e)運用及び保守の実現可能性
*------------------------------------------------------*

つまり、システム要件については、
●利用・運用・保守を含めて示す。
●ユーザーが期待する効果を技術的に実現できるかどうかの根拠と可能性を示す必要がある。
●ニーズを実現したかどうかの評価方法を前もって決めておく。

こう書かれているのです。
これは、当たり前といえば当たり前のことです。
しかし、開発側は、
・要件定義の肝がこういったものだということをユーザーに提示していないのではないか？
・本来のシステム要件の目的をきちんと理解してユーザーに説明していないのではないか？
なぜなら、開発側には数多くの「本当のことが言い難い」理由があるからなのです。

そこで、
・お決まりのドキュメント雛型に収めてごまかして通してしまうことが多いのではないか。
・言い難いと曖昧にしたことが、トラブルを引き起こすひとつの原因になっているのではないか。
と考えるのです。

開発側が考える「システム要件」とユーザー側が考える「システム要件」の違い、これを次回は考えてみたいと思います。

開発側（ベンダー）が考える「システム要件」と顧客（ユーザー）が考える「システム要件」の違い、これが先週お約束した今回のテーマです。

ユーザーは、システム要件をどのように考えているのでしょうか。

確実に言えることは、ユーザーはシステムを使うことによって

・今以上に便宜を得たい
・利益を得たい

と考えています。

具体的には、

・在庫を減らす
・人手を減らす
・ミスを減らす
・顧客満足度を上げる

といった目的もあるでしょう。

しかし、ユーザーにとってシステムを使うことの最終目的は、企業の利益の追求です。

一方、ベンダーの最終目的も、ユーザーの利益の追求なのでしょうか？

もちろん、そう考えていることには間違いはありませんが、残念なことに、ベンダーにとって一番大事なことは“プロジェクトを赤字にしないこと”なのです。

そのため、ベンダーはシステム要件定義書を作成するにあたって「ユーザー側が描いた理想のシステム」の実現の不可能性についてとうとうと説得を始めるのです。

そして、技術レベルを自分たちの能力で楽々と作成できるところまで落とし、時間と人の制約の中で、実現可能な提案をする、これがベンダーの作成するシステム要件定義書なのです。

結果として、受注後の最初の納品物である「システム要件定義書」は、提案書とイコールのものであることは滅多にないのです。

もし、提案書とイコールであっても、金額がイコールではないのです。

つまり、提案書の金額のまま、システム要件定義書が顧客の要望を網羅していることは非常に少ないのです。

なぜなら、提案書を作るときにベンダーの頭の中にあることはいかに競合相手に勝てる金額を提示するかだからです。

また、その金額におけるプロジェクトの詳細は、ベンダーが勝手に描いたものなのです。

これらの思惑から作成されたシステム要件定義書が、曖昧でどのようにでも解釈できるものなら後々、大きな問題を引き起こすことになります。

例えば、開発途中にベンダーからユーザーに対して金額交渉が入るなどです。

実際に、裁判などでベンダーとのトラブルに至るユーザーは、自分たちが最重要だと考えていることを、ベンダーが当然実行してくれるものだ考えていますが、これは違います。

ベンダーは、自分たちが最重要だと考えていること（例えば、打ち合わせをしっかりしようとすればするほど比例して経費がかかること）をユーザーにはなかなか伝えません。

ユーザーがこういったことを簡単に受け入れてくれない、説明するのは難しいとベンダーは思うのです。

結局、システム要件についての問題は、明らかにベンダーが曖昧に対応し続けることがトラブルとなり裁判となるのです。

自分たちが、誇りをもってシステム開発を行っているのであれば「システム要件」をユーザーの視点できちんと開示して固めることが必要です。

それがユーザーにとっては厳しい現実でも早めからきちんと丁寧に折衝しなければいけません。

それでも、プロとして「挑戦」すべきシステム要件には、逃げないで立ち向かう覚悟と度胸が必要ですし、どんなリスクが起こりうるかについてはユーザーの視点でユーザーにわかるように説明する責任があります。

無責任に「なんでもできる」と言って、契約してから考えよう、後から「うまく金をとろう」などというトンデモナイ営業方法は今の時代には、ハイリスク以上のリスクであり確実にシステム訴訟の種となるのです。

しかし、今やベンダーにとって悪夢の時代がやってきました。

開発費3億円を、1億円でやらざるを得なくなってしまう・・・。

次回は別の視点から契約について考えてみます。

日本人は訴訟を嫌う、と言われてきました。

「裁判になってはいけない。可能であれば示談のほうがよい」という考え方が、長い間、世間の常識を作ってきました。

この“臭いものにはふたをする”という考えが、『オレオレ詐欺』という日本発の犯罪を生む土壌になったのも事実でしょう。

オレオレ詐欺は「自分は大丈夫」という気持ちが被害に繋がるようです。

『オレオレ詐欺』と『システム訴訟』（失敗したプロジェクト）を比較するのはおかしなことだと思われるでしょう。

しかし、システム開発を発注する側も、請け負う側も「自分は大丈夫」と走りだしたプロジェクトでトラブルが起こったときに焦って重ねて地雷を踏んでしまうことがあるのです。

どうも人間の脳は「想定範囲外」のことが起こると固まってしまい、様子を見よう、保留しようとするならともかく、自分ひとりの一存で、できれば隠してしまおうとする傾向もあるようです。

そこでベンダーだけでなくユーザーも、前もってシステム開発プロジェクトがうまくいかない場合を考えておくことが必要です。

もちろん「プロジェクトは、うまくいって当たり前」という考えは間違っていません。

しかし、実際には、大規模なプロジェクトになるほど順調に進むことが滅多になくなるのです。

これは敢えて口に出さないまでも、この業界の常識です。

だからこそ「万が一」を考えておく。

それが契約の基本です。

システム要件を決めるための要件定義や外部設計では、ユーザーが、どれだけ時間を割いて打ち合わせに参加し要件を確定したかといったことが費用のかかり具合を大きく左右します。

プロなんだから「かゆいところまで手が届くように」「言わないこともわかってほしい」といったユーザー側の甘えの論理は、システム開発では、なかなか通用しません。

一方、プロジェクトを請け負う側のベンダーは、「契約書」に書かれていなくても、システム開発のプロとしてプロジェクトマネジメントを適切に行う義務を負うことが求められています。

事実、システム訴訟の判例では、システム開発の失敗の原因の一部がプロジェクトマネジメントにあれば、契約に無くともベンダーに損害を賠償する責任を命じています。

ベンダー側のプロジェクトマネジメント義務として以下のようなことが挙げられています。

・決められた開発の手順、手法を守る。

・プロジェクトの進捗を管理し、問題を発見したら適切に対処する。

・ユーザーに課題を示し、ユーザーが納期までに決定できるように指導する。

・ユーザー要望による機能追加・変更が請負金額、納期に影響する場合は、タイムリーに説明し、要望の断念または、金額の増額、納期の延期を求める。

〔参考：日経コンピューター　2007/10/15　トラブルを招く契約、防ぐ契約より〕

このようなことがプロとしての義務であると判決は判示しています。

つまり、どんなに煩がれても、また、ユーザーの機嫌を損ねることになったとしても、なるべく早く、根拠を明示して金額交渉することがベンダーの義務なのです。

一つのシステムを納品するのには、獏大な時間がかかるものです。

今でもそう思いますが、システムエンジニアとして走り始めた頃は、もっともっと大変でした。

COBOLと索引データベースでの開発がその原因でした。

ツールも良いものが無く、生産性が極端に悪い開発環境だったので、無駄に時間を使ってしまったり、障害を特定できるまでに長時間かかることが多くありました。

たとえば、マスタ8本、ジャーナル12本、主機能40本の販売管理を設計したとします。

主機能40本に加えて、マスタメンテナンス8本、マスタリスト8本

これらのプログラムを作るのは当然ですが、加えてジャーナルメンテナンス12本、ジャーナルリスト12本も作っていました。

今では、RDBMSやAccess、Excelであれば簡単に、メンテナンスツールやリストを作ることができます。

ところが、当時は1本のツールを作ることさえ、一から手作りでした。

だからと言って、これを作ることをさぼると、結合テスト中でも納品後に問題が起きたときでも、原因解明に膨大な時間がかかってしまうのです。

当時は、その問題を追及するためのプログラムを現場で作るということを当然のように行っていました。

今、考えるといかに生産性が悪い方法だったかと思います。

結局、最初からメンテナンス用のプログラムを作っておいたほうが、生産性は高くなるのです。

また、お客さまに納品したシステムエンジニアが、運用保守まですべて引き受けるという慣習があったため、土曜の早朝にいきなり電話がかかってくることもありました。

電話応対で対応できる問題であればなんのことはありません。

ときには、すぐ現地に飛んでいかなければなりませんでした。

いつなんどき「呼び出されるかわからない」というのが当時のシステムエンジニア、そう、私の宿命でした。

しかし、キャリアを経て気付いたのですが、それは私自身の設計に問題があったのでした。

自分が作ったシステムは「正しく動いて当たり前」と考えていたのがその理由でした。

土曜、日曜も関係なく「緊急に呼び出される」システムを作っていたのは自分だったのです。

　請求書が発行できない
　請求書の表記が間違っている
　データの不整合がおきる

とにかく、データが正しく処理されない場合に電話がかかってくるのです。

そして、何がおかしいのか、離れた場所からはわからないので駆けつけなければなりませんでした。

今でこそ、遠隔地からでもリモートメンテナンスが可能ですが、当時はファックスも普及していない時代です。

大変苦労もし無駄な時間を使いました。

システムの開発には「押さえどころ」があるのです。

トータルコストは、お客さまの運用時間だけでなく、システムエンジニアの納品後の稼働率や駆けつけ時間までも含んで考えるべきでしょう。

いかにして「駆けつけなくてもよいシステム」を作るのか

それには、いろいろなコツがあるのです。

（次週に続く）

あなたにGWの宿題です。

前回、トータルコストを下げるのにはコツがあるというお話をしました。

連休前なので長い話や細かい話はやめて、技術者・開発者の皆さんに休みの間に、時間があったら考えていただきたいことがあるのです。

それは、システム開発の工程の割合をどのように考えているのか？ということです。

というのは、トータルコストと言ったとき、どうしても若いころの自分の失敗について考えてしまうからです。

わたしがSEになった当時に、漠然と考えていた工程別コストの内訳は、すべてを100とすると、

・客先での打ち合わせと外部設計　10

・内部設計　 5

・開発（プログラム作成とテスト）　83

・納品　2

こんなイメージでした。

「客先にシステムを納品したら終わり」と頭の中ではイメージしていたのです。

それがどんなに浅はかな考えだったのかは今は理解できます。

なぜなら、経験上、プログラム10本以内の小さな処理だったり現在のシステムの焼き直しであったり、トラブルが起きることの少ないシステムでない限り、イメージ通りにシステム納品が終わったことは実は一度もなかったのです。

現在のわたしのイメージは（もちろんシステム機能の多さにもよりますが）

・客先での打ち合わせと外部設計　20
・内部設計　20
・開発（プログラム作成とテスト）　50
・納品　10

これでも納品に関する工数はまだまだ少ないと感じますし、開発の割合はもっともっと少なくしたいところです。

しかも、これには定期保守に入ってからの工数を含んでいません。

5年先までを考えたシステムであれば、当然、5年間の保守工数が入ってくるので全く違う割合になります。

どうでしょうか？

あなたが考えているコストの割合を今一度考えてみてください。