システム開発の途中またはリリース後に設計ミスが発覚した場合、
その原因が解ってみると難しいことでもなんでもなく
設計の時点で検出することが十分可能なことがほとんどです。
ひどい話ですが、設計またはプログラミングの時点で
誰かが解っていた場合がほとんどなのではないでしょうか？

どんな理由があろうとも
（事前に何らかの理由により断りを進言してお客様に了承を得てない限りですが。）
普通に考えれば、おかしな話です。

科学実験ではないですが、理論と実際のあわない場合は、
間違いなく理論の方が間違っています。
「これが常識だから」
「本に書いてあるから」
「過去にこれでうまくいったから」
「すごい誰々さんが言ったから」
雑音には耳を貸さずに一から考えてみて下さい。

間違いもしくは改良すべき点は、
思い込みの中にあることがほとんどなので
最終目的を念頭に一から時間をかけて検証してみることが大切です。
（実は私は仕事の中ではこんな時間をとる余裕がないのがほとんどなので、
実際には通勤中の電車の中とかでしか考えることができないのですが。）

コツは全体的に俯瞰してみることと一から考えることを交互に繰り返すことです。
経験を積むとともに「カン」のほうが
理屈立てて得た結論より正しいことがままあります。
何かしっくりこない場合は、論理立ての出発地の辺りを
よくよく考え直したほうが良いと思います。

論理立ての枠組み自体が間違っていたというのは良くある話です。

何かに囚われずに一から考え直してみると良い突破口が見つかりやすいという話でした。

で作った作品をマイコミジャーナル様でとりあげてもらいました
↓
「QRコードを簡単に作るAIRアプリケーション「QRメーカー」無償提供開始」
http://journal.mycom.co.jp/news/2008/07/23/048/index.html
「フォーエス、QRコードを簡単作成できるAdobe AIRアプリケーションを配布」
http://journal.mycom.co.jp/news/2008/07/23/047/index.html

これも、うちの技術者がタイトなスケジュールの中、
がんばってくれたおかげです。
ありがとうございました。

より多くの人に使ってもらって
機能面、デザイン面、操作性面とかでダメ出しを
たくさんもらえると嬉しいのですが。。。

その一つは、お客様の前で直接会話してシステムに求められる機能をその場で決めていく場合です。
短時間の会話の中で、要求された機能に対してシステム内部のイメージを作り、
出来る、出来ないを決めなくてはなりません。
出来る場合は良いのですが出来ない場合には、現実世界のシミュレーションの中から
お客様の求める効果に近い代替案を考え、さらにはその代替案のシステム内部のイメージを作り、
提案しなければなりません。
そもそもこの仕事はサービス業なので、お客様の案に特別な無理がなく、代替案がなければ、
効果が確実なお客様の案を無理を承知で受けるしかないでしょう。
この部分の難しさは、会話をしながらの短時間のうちに二つのシミュレーションをしなければならない点です。

もう一つは複数会社により連動する複数業務システム開発を行う場合なのですが、
会社をまたがって他システムインターフェースを決める場合です。
通常、他システムインターフェースは基本設計工程で確定され、それ以降変更することは至難の業です。
つまり基本設計工程でプログラミングのイメージを作り上げる必要があるのです。
この難しさは二つ先のシミュレーションを行わなくてはならないことにあります。

最後に、システムの開発工程の中で忘れがちな大事なことをことをもう一つ話させてもらいます。

それは、プログラミング工程で品質の作り込み自体をおざなりにしてしまうことです。
品質の作り込みの九十数パーセントまではここで行われるのです。

プログラミングの後のテスト工程にたよって十分な品質を確保することは至難の業です。
人の頭を開けてみて生産ラインのチェックができれば良いのですが、
そのことは会話またはコード自体から読み取る以外にありません。
あるプログラマが、その時点で求められるスキルレベルに極端に達していないことが判明した場合には、
（そのプログラマにとっては残酷な話ですが）
スクラップ＆ビルドが最も早い選択の場合がほとんどです。

つまるところシステム開発の最終到達点は、
効果的な機能仕様を持った使用に耐える品質のプログラム群を作り上げることです。
正確に作るためのドキュメントはもちろんのこと、
メンテナンスのためのドキュメントを作成するのであっても、
それはプログラミング群がきちんと出来た上での話です。

プログラミング以外の全ての工程は、プログラミングのためにあるのであって、
そのことを忘れてプログラミングをおろそかにして、良いものができるはずがありません。
ですから管理のレベルでは、他の工程を皺寄せたり、端折ったりしてでも、
出来る限り十分な時間をプログラミングのために確保するように努めなくてはなりません。
進捗の遅れをプログラミング工程で取り戻すようなことは、
本当に愚の骨頂でトラブルを招いているようなものであることは言うまでもありません。

実際にコードを編み綴るプログラマの方は、
プログラミングでのあいまいさの排除を
制限つきの時間の中で出来る限り理想的な形で実装し、
それを目視であっても動作を確認しなければなりません。
プログラマは、プロフェッショナルとして、
「硬いコード」を書き、そして確認しなくてはいけないことを、
強く自覚しなくてはなりません。

ウォーターフォールでの開発で陥り易い落とし穴の一つは、
開発の前半において開発工程毎の成果に目を奪われすぎることです。
例えば基本設計工程では基本設計書に、詳細設計工程では詳細設計書を作り上げること自体に
集中しすぎると言うこと自体が問題なのです。

プログラミング直前までで最も大切なのは、一つ先の工程のイメージを作り上げることです。
ですから基本設計書を作成した暁には担当者の頭の中には
詳細設計のイメージが出来上がっていなければなりません。
つまり「備忘録（またしても器のシミュレーション）」で述べたようなイメージは
最低限固まっていなくてはなりません。
もちろん難しい問題領域を解くシステムの場合には、全てが可能なわけではないですが、
難しいほんの一部のブラックボックスを除き大半は出来上がってなくてはいけません。

詳細設計書またはプログラム設計書のようなものを作り上げる場合も同様です。
プログラム設計書を作成しないような場合、詳細設計書を作り上げた暁には、
頭の中にプログラミングイメージが出来上がっていなくてはなりません。

実際開発をしたことがある人であれば、こんなことは誰でも知っています。
でも、プロジェクトがトラブル際には、これが出来ていないことが多いように思います。
見た目はスケジュール通りに進捗が進んでいるにも関わらず、
実態としては（作業者の頭の中では、と言う意味です。）一工程分スケジュールが遅れているのです。

一工程分スケジュールといえば全体の数十％です。トラブらない方が不自然です。
詳細設計工程またはプログラミング工程になってはじめて
矛盾点または無理が発覚して手戻りが多発するはずです。
「こうすればいい」という見通しのないまま進み、
後になって考え直さなくてはいけない部分が明確になる。
誰が考えてもあたりまえのことだと思います。

ただここで一番難しい点は、実務に精通したリーダしか
工場の生産ラインを視察することが出来ず、
その一工程分の遅れを検知できないことです。
そしてそれを改善、コントロールする権限もリーダにしかないのが常なので．．．

今回は設計書等のドキュメントが大事でないかのような
印象をあたえたかもしれませんが、
ドキュメントはコミュニケーション、そしてメンテナンスのためにも
絶対必要で、それを否定している訳ではありません。
（最後に言い訳でした。）

デザイナーさんをコアターゲットとした雑誌で
取り上げてもらえるのはうれしいことですし、
励みにもなります。
毎日コミュニケーションズさん、ＫＡＹＡＣさん
繰り返しになりますが、ありがとうございます。

Ｆｌａｓｈ・Ｆｌａｓｈとは異なりデスクトップでの動きの面での
ＡＩＲの強みを活かしたものを作っていければと思っています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会社としては、特に褒賞的なところも、
強制的なところもないのですが
個々の方のモチベーションの高さに
本当に勇気付けられます。

私も、会社としてそれにこたえられるよう
また個人としても日々の勉強を続けていけるよう
がんばります。

ちょっと話は変わってしまいますが。

最近、ＷＥＢのニュースで
イギリスで数億円の宝くじを当てた男性が
仲間がすきだからという理由で
マクドナルドに店員として再就職した
という記事を見ました。

仕事をする理由はお金以外でも、
人間関係の中にあると言うことだと思います。

モチベーションを高めるといっても
一人ぼっちでは、長い間それを保つことは本当に難しいと思います。
でも、刺激を与えてくれる人が近くにいると
結構、影響を受けて元気が沸いてきたりするものです。

お互いが良い人間関係を築きながらも刺激し合い、
個々が自己研鑽をし続けられるような雰囲気を
会社の中につくっていけたら、
と思っています。

最近（というか今年にはいってから）、小さな失敗を数多く繰り返して
ちょっとヘコむところもあったのですが、
ちょっと癒されて勇気づけられました。

自分自身の中の恐れとか欲とかに打ち勝てるよう、
言い換えれば「強く」なれるようがんばろう、
と前向きな気持ちにさせてくれるきれいな桜でした。