フォーエスラボ（Fores　Labs）
↓
http://www.fores.jp/labs/index.html

で作った作品をマイコミジャーナル様でとりあげてもらいました
↓
「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

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

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

前回で述べた話は、プログラマとして十分な経験を積みたたき上げたＳＥにとっては当たり前のことです。
システムの開発工程の中で、それでも難しいことが、まだ二つ残ります。

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

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

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

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

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

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

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

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

今回はシステム内部の開発に絞って話をさせてもらいます。
しかも一番古くからあり、一番良くお目にかかる代表的な開発手法である
ウォーターフォール方式の開発手法から話をさせてもらいます。

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

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

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

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

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

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

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