ちょっと、仕事でばたばたしているうちに、
ブログの更新がひさしぶりになってしまいました。
また、がんばって書きますので宜しくお願いします。

ＳＥに必要とされる能力のうちシステムの内部設計に必要とされる部分は、
いままでブログで述べてきたようにプログラマに必要とされる能力の延長線上にあります。
しかしながらそれは半分でしかなく、
もう半分は現実世界をシミュレーションする能力であると思います。

業務システムの出来ることは「絵が出て、紙が出るだけ」と極論しましたが、
だからこそ業務システムが何を必要とされているかは
「絵や紙が出て何が起こるか」を正確に把握する必要があります。
システムの外部設計をするには業務知識が必要です、
このことは極々言い古された単純なことですが。。。
そしてそれは個々に独自の事情をもっていて、異なります。
それをどのように正確に早く把握するかがＳＥのスキルです。

そのために私はいつも次のようなことを気にかけています。
それは、人、物の実際の動きを出来る限り全体的にシミュレーションすることです。

「この○○一覧の作業中欄の値を見てＡ担当は何を判断してどの様なアクションを起すのか？
それはいったい何故なのか？
（例えば遅延が発生した場合の責任がＡ担当にあるため、
または業務数より遅延業務数が評価基準として重く上席者より叱咤されるため）
また、Ｂ担当、Ａ統括者はどうなのか？」

「Ａ担当が業務を終わらせるとその日時をシステムに入力し、
物がＢ担当に届く前に△△一覧に表示され、
Ｂ担当は△△一覧の□□欄を見て業務の事前準備として、、、、」
といった風にシステムの各所を全体に渡ってシミュレーションすることです。

コツは、出来るだけ早く全体的につじつまがあうようにシミュレーションすることです。
早い段階では、ほんの一部の情報から全体をシミュレーションしなくてはいけないわけですから
全体の九十パーセント以上が想像の場合もあります。

しかし、全体的にシミュレーションできていることが重要なのです。
それが無ければ、お客様との打ち合わせの際の一言で
「ある一箇所の想定が成り立たずに一部分を変えると、他の箇所の想定が覆り、
と言った具合にシミュレーションの全体像を書き換える。」ことが出来なくなります。

つまりシミュレーションの全体像があればこそ、ちょっとしたお客様の一言、
ちょっとした資料の一句から多くの情報を引き出せるのです。
ここで大事なのは、きちんとつじつまが合うことです。
断片的な情報から全体像を作ろうとするので
大きなブラックボックスが出来てしまうのはしょうがないのですが、
既知の事柄に対しては少しの矛盾も発生しないようにしなければなりません。

そしてシミュレーションの全体像があるからこそ、
的を得たシステムの外部設計を行うことが出来るのだと思います。

長い間、業務システム開発のプロフェッショナルとして仕事していれば
お客様と深くコミュニケーションを取れる場合もあれば、
まったくコミュニケーションを取れない場合もあります。
いずれにせよこの方法が有益であると思います。

お客様と話が出来ないとしても、
例えば既存データベースの項目名だけでも多くのことが想像できるはずです。
少なくとも何らかしらの資料は見せてもらえるはずです。
（何にも見せてもらえないのであれば、そもそもシステムを構築していくことは不可能です。）

入手できた情報は、古墳から発掘された壺のかけらのように大事に扱って下さい。
かけら自体は間違っていることはなく、
組み合わせ方のほうが絶対的に間違っているはずなのですから。

ちょっとした細かいことをないがしろにしてはいけません。
必ず得られた情報のバックボーンには現実世界が控えているのです。

おかしいと思えるところがあったなら、それは単に自分が解っていないだけの話なのです。
経験上、ほぼ百パーセントお客様のほうが正しいはずです。
私が経験した中では、ただ私の理解がそこまで到達していなかっただけということが全てです。

落ち着いて考えて見れば、現実世界で行われていることは
その道の数多くのプロフェッショナル達が長い年月かけて作り上げてきたものです。
それに対してシステム開発者側は、その道の実務についたこともない、
何も知らないに等しい素人の思いつきに過ぎません。
どう考えても前者の方が圧倒的に正しいのは当たり前のことです。

もちろん外から客観的に見ているからこそ解ることもあります。
現実世界のシミュレーションが細部まで出来上がれば、
的を得た疑問、問題意識の共有がはじめて可能となるでしょう。
良く良く考えた先にだけ的を得た提案を生む土壌があるのだと思います。

まだまだ、システム設計編が続きます。

「例外を考える能力」ですが、これもプログラミングの話と同様です。
システムの内部設計をしている最中に品質の作りこみを行うためです。

その一つは、設計したプログラム群の動作シミュレーションを頭の中で行うことです。
まあこれはプログラミングの話が大規模になっただけでほぼ同じことです。

頭の中に入るシステム内部設計の量は、
プログラム換算すると５００Kステップぐらいまでが限界だと思います。
さすがにそれを超えて細部まで同時期に把握できている人は、
お目にかかったことがないです。
（でも、そんな人もきっといるんでしょうね。）

と言うのは、設計したプログラム群の動作シミュレーションをする際のコツは、
頭の中に同時期に全部入れてしまうことです。

二つ目は、例外的なケースを想像することです。
実はこちらの方がやっかいで．．．
そこで必要となる能力については次回に書きます。

スイマセン。
今回はたったコレだけでした。

以前にお話したプログラミングの話の中で「シンプル　イズ　ザ　ベスト」と言ったことを述べましたが、
器の話を「データを格納する何か」にまで広げると同じ話です。
つまり、「単一の目的の器を、必要最小限の数だけ、必要最短期間だけ保持する。」
ということを意識しなければなりません。

システム内部設計のレベルで加えて意識しないといけないのは、
器といっても階層があるということぐらいです。
つまり汎用的なリレーショナルデータベースであれば、
カラムのレベルでの器があり、
テーブルのレベルでの器があり、
データベースのレベルでの器があというようなことです。
どのレベルでも同じことを意識しなければなりません。
（まあこれはＤＢの正規化と同じ話ですが。）

良くカラムのレベルでは意識されるのですが、
テーブルのレベルでは意識が薄いことが多いように思います。
コツはプログラミングの場合と同じなのですが「口に出して一言で言えるかどうか」をチェックすることです。

「口に出して一言で言えるかどうか」をチェックする際、
その中に２つ以上のものが入っていたり、
一言で言えたとしても他にも同じものが存在してたりしたら
（当然ながら）ダメです。

まあ言えたとしても、つまるところ、
それは自分の頭の中を整理しただけかもしれません。
しかし、そのこと自体が大事で、
「問題領域のデータをどう捉えるか」自体がポイントなんだと思います。

器の次に意識すべきは手続きですが、
こちらも器の話と同じで階層が深いことを意識する以外ではプログラミングと同様です。
こちらも「口に出して一言で言えるかどうか」をチェックすることは有効だと思います。