期間：2010/11/15（月）～2010/11/19（金）

内容：

1. ソフトウェア開発概論
2. システム化企画
3. 要求の分類方法
4. 要求の引き出し方法
5. RFPと提案書
6. 論理的思考と表現方法
7. 要件定義
8. 設計作業

11/15～19の5日間に渡ったこと、受講者が全員新人であったこと等、通常の講座とは違う難しさもあれば、この講座ならではの楽しさもあり、あっという間の5日間でした。

こちらは中小企業、取引相手は世界に冠たる大企業ということで、こちらの都合を通せるわけでもなく、先方のシステム・帳票類にうまく合わせながらのシステム構築でした。

多品種少量の発注伝票がダンボールで送られてるという状態だったので、このシステム構築前は見積もり回答を作成するだけでも残業、売上も検収できず、在庫管理もできないという状況でした。

そこで、AccessとExcelを活用した受注管理・在庫管理を構築し、データ登録は市販のバーコードリーダを活用という構成で解決しています。

商品単価が低いため、それに合わせてシステム構築も出来るだけ簡素化し、かつ、構築費用もリーズナブルです。

IT経営力大賞にも応募しているのですが、どう評価されるのでしょうか？

私が担当して2年目ですが、これまで好評ということもあり、年度内に2回開催というのは初の試みです。

「2回目も開催したい」というお話を頂いた時は、「東北というか、仙台近郊の方が中心になると思うので、開催できるか厳しいかな？」と思っていたのですが、何とか開催の運びです。

要件定義から、システム設計までの講義ですが、経営の視点と技術の視点の両方入った講座です。（ただし、システム設計は外部設計までで、内部設計は言語依存のところもあるので含んでいません）

「経営戦略から見た要件とは？」もあれば、「システム設計の書き方とは？」も含まれています。間に論理的な考え方の練習もあります。

2日間ですが、内容は盛りだくさんです。

まだお席に余裕があるとのことなので、是非ご検討ください。

先日、これの内容について話題になったのですが、ざっと見ても細かく書かれすぎて、「これでは重いな～」という印象をもたれた方も多いようです。

確かに、全て決めるのは大変なので、実際には簡素化したり省略するものもあるでしょう。

が、逆にあれだけでは物足りないところもあります。

何を省略してよいか、何を掘り下げるべきかは一意に決まるものではなく、そのシステムの特性に応じて決まります。

この「非機能要求グレード」で公開されている成果物は、絶対的な基準ではありません。

「非機能要求で何を決めるか」を洗い出すための参考資料として扱うのがよいのではないかと思います。

最近は書籍やネット上の情報も充実している。様々な手法も紹介されており、今更ながら感心させられることもある。

が、要件定義工程の実態を見ると、顧客が「これで良い」と言ったら、それで終わりというケースが非常に多い。

DFDを書いたり、ブレーンストーミングをやったり．．．そういうテクニックを使うことで満足しているのではないか。

そのようなITベンダーは、顧客側が開発工程に入ってから要件を変更すると、「仕様変更なので、費用をいただきます」と言うことに恥じることもない。

それを恥じる美学もなければ、反省もない。

これを読んだところで、何を言っているのか理解できないだろう。

小手先のテクニックだけの中途半端な技術者が多すぎて、腹が立つ。

情報システムの開発において予算以上にコストを要したり、予定スケジュール以上に期間を要することがあるが、この原因を見ると「要件定義」に端を発するものが多い。

このため要件定義に関する書籍が増えているというのは好ましいことである。

が、いくつかの書籍を見ると要件定義とインタビューを混同しているのではないかというものが見受けられる。

要件定義からシステム開発まで特定のプロジェクトを一貫して体験した方は分かると思うが、「顧客が欲しいといったもの」と「そのシステムに必要とすべきもの」が一致していることは非常に稀である。

これは要求を出す顧客側に問題があるわけではない。

顧客は要求を出す時点で気付いたことを主張するのであって、その要求の中から「本当に必要なもの」を汲み取るのが要求定義という作業である。

ここではヒアリング能力だけでなく、顧客が要求する機能に限らず幅広いITの知識、それを活用する業務に関する知識なども必要である。

「これが欲しい」という言葉を引き出すのが要件定義ではなく、「なるほど、こういうシステムを作るんですね」という合意事項を作成するのが要件定義である。

今回、Scansnapのデモ機を借りた理由としては、以下の機能を持ったシステムを低価格で構築できるかを見極めるためである。

1. 紙媒体で提供される発注書のうち、製品型番や注文数量などの特定部分を電子化できるか
2. 1日最大で500枚を処理した場合でも業務に支障が無い性能を発揮できるか

Scansnap単体の性能は問題なかったので、今度は読み取った帳票を自動的に電子化する方法をトライアルユース版のOCRソフトで試してみる。

OCRソフトと一口に言っても価格も機能もピンからキリまであり、どれを導入すればよいのか掴みかねる状況である。今回は処理する伝票の粗利から見ると高額な製品や運用サポートを必要とする製品は導入できない。このため、比較的低価格のエプソン社「読んでココ」とパナソニック社「読取革命」を評価してみた。

サポート体制

両社共にトライアル版はフリーダウンロードであるが、今回使用する機能に関して質問を行ってみた。これは「本システムに耐えられる機能かどうか」を見極めるという目的の他に、どのような回答が送られてくるのかというサポート体制も見てみたいという目的も含んでいる。

結果については、1社は「機能説明と、トライアル版の制限」について回答を頂いたが、もう1社は「少々お待ちください」というメールの後、なしのつぶて。（トライアル版という制約もあるので社名公表は控えます）

機能評価

読んでココはオペレータレス（作業者が介入することなく）で、連続処理が可能になるような機能を保有している。で、実際にこれを試したものの、読み取った帳票が数ｍｍずれても正しく読み取れないようである。

帳票の行間に余裕があれば調整も可能なようだが、今回は取引先が作成した帳票で、

• 行間・文字間隔が狭い
• 小さい文字（６ポ程度）が含まれている

という制約があった。また、一部機能的な問題もあり、今回のケースでは利用するにいたらなかった。

読取革命は人間が介在することなく連続処理を行うこと自体が不可能である。処理速度は問題ないので、残念である。

両製品共に、「自動処理ではなく、人が介入して一つ一つの帳票に対して読み取り範囲を指定する」という方法であれば帳票の電子化も可能であった。

残念ながら、人件費が掛かりすぎるためこれらの製品導入は難しそうであるが、違うケースであればこのような低価格商品でも利用価値はありそうである。

と、いっても購入したわけではなく、PFUさんから借用したデモ機である。

scansnap

現在、業務要件の分析を行っている受注管理システムで、「伝票のOCR取り込みの可能性」を評価するために二週間ほど貸していただいた。

これから、SCANSNAPの能力評価、SCANSNAPと連携するOCRアプリケーションの機能評価等を行い、受注伝票の電子化の可否を判断する。

まずはイメージ作りの一環としてプロトタイプを作り、ここから要求分析に入ります。

今後の拡張性と導入費用を考えてMYSQLを使おうかと思っていたが、ACCESSでプロトタイプを作ったところ、微妙な容量。

「分散させれば2GBの壁を越えずに済みそう」という感じだが、エクスポート・インポートもあるし、経験的に危ないかなという気もする。（と、思うときは、得てして勘があたるもの）

きっちりした容量見積もりが出来れば迷わないのだが、これが出来ないから迷うんですよね～。