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

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

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

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

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

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

「優良顧客だけにダイレクトメール(以下、DM）を送りたい。売上実績も顧客住所も分かっているのだが、優良顧客だけの宛名印刷をすることが出来ない」とのことでした。
社内にデータ（売上実績や顧客住所）はあるものの、必要なものだけ（優良顧客の住所）をピックアップすることが出来ないという状態です。

顧客数が少ないのならば手作業でも探せますが、数百人規模になると手作業では時間がかかってしまいます。

決して売上は多くないが、小口の顧客をたくさん抱える業者さんでは同じような悩みがあるのではないでしょうか。

┏━━┓━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃疑問┃優良顧客だけにDMを出すには？
┗━━┛━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

こちらの会社は以前から顧客向けDMを送っていたものの、レスポンスが余りよくないとのことでした。
よくよく分析したところ、よく購入してくれる顧客はDMへのレスポンスも良いそうです。
そこで、費用対効果の観点から「売上実績が上位20%の顧客を優良顧客とみなし、この顧客だけにDMを送りたい」ということです。

売上実績、顧客名簿共にパソコン上で管理されているそうです。
ここまでは良かったのですが、販売管理ソフトでは顧客名は管理しているものの顧客住所までは管理していません。
また、顧客住所は宛名印刷ソフトで管理しているものの、これは宅配業者さんが提供したソフトウェアで、会計ソフトとは連携できないという状態でした。

欲しい情報（売上データ）は揃っているものの、データ間の繋がりがないというのが現状です。

「会計ソフトで住所も管理させる」ことを考えたそうです。
しかし、会計ソフトの会社に確認したところ、「そのような機能を追加するには数百万円の開発料金が必要」といわれて、どうしたものかと悩んでおりました。

┏━━┓━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃回答┃自作のデータベースでデータを連携させます
┗━━┛━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

データは存在するものの、そのデータ同士が連携出来ないのが悩みのタネです。

ということで、「連携できないなら、自力で連携してやれ！」ということになりました。
では、どうやって連携させるかというと、ここで活用したのがデータベースです。

データベースとはエクセルのシートと同じようなものです（エクセルをデータベース代わりに使用している会社さんもいらっしゃいます）。
が、エクセルと大きく違う点は、エクセルのシートのようなものをいくつも連携させることが出来るという点です。

今回は、販売管理ソフトが管理している『売上実績』、宛名印刷ソフトが管理している『顧客住所』をデータベースに登録しました。

これによって２つのデータを関連付けることが可能になり、「売上実績が上位20%の顧客を選び出す」という作業と、「その顧客の住所を印刷する」ということが１つのボタン操作で可能になりました。

データベースというと大掛かりな操作のように思えますが、ここで発生した費用はソフトウェア費用と開発費用も含めて数十万単位です。

IT活用においてデータベースという言葉はよく聞きますが、実際に活用されるケースは少ないように思います。
社内に同じようなデータがいくつもあり二度手間になっている、データはあるものの連携できないという悩みがあるならば、データベースの活用を検討してはいかがでしょうか。

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

scansnap

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

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

こういうものを使っていると、子供が集まりだして．．．．

デュエルマスターズの箱のJANコードを読み取るまでは良いとしても．．．

大怪獣バトルウルトラモンスターズのコードまで読み取り始めたりする。

JANコードとCODE39の読み取り設定しか入れていないので当然ながら読めないのだが、「これを分析すると、コンボ発動も出来るのか？？」などと考え出すので、親子揃って脱線。

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

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

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

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

業界の人ならば誰でも知っており、この工程がシステムの品質を大きく左右する重要なものです。

要件定義ではユーザのヒアリングや作業状況を観察するだけでなく、代替案の提示、解決策のディスカッションなど、様々な手段を用いて顧客要件をまとめてゆきます。

が、IT企業から離れてみて分かったことは、単なるインタビューを要件定義と勘違いしている人が多いといこと。特に、ITに疎いコンサルさん。

「ITベンダーと協力し、互いの強みを活かし、補完しあいながら．．．」という論理も間違ってはいませんが、何が不足している部分で、どこを補完しあうのかはっきりしないといけません。

要件定義で難しいのは技術（IT）ではなく、業務内容やビジネスモデル、経営戦略等のあるべき姿と、それを実現する方式をマッチングさせる点にあります。

単に「要望に一番近い技術」を探すのではなく、実現性や費用対コストの観点からビジネスモデルを見直したり、当初の要望とは異なった技術に解を求めることもあります。

つまり、技術と事業のバランスを取りながら最適解を探ることがキモになるわけです。

しかし、「インタビューが得意な人」と、「モノ（システム）づくりが得意な人」の組み合わせでは、キモの部分を担当する人がいないというわけです。

もし、複数のプレーヤーでチームを構成せざるを得ないなら、「業務もITの飛びぬけて詳しくないけど、別業態・別業務等で両者を融合させた経験のある人」が必要不可欠です。

これに、、「インタビューが得意な人」と、「モノ（システム）づくりが得意な人」を組み合わせられるなら、それぞれで補完するということは可能だと思います。

ただ、現実的にはそこまでの体制になっていないのが現実のようです。

「ユーザの要求に問題がある」という話も聞きますが、こういう現場を見ると、「そもそも要件定義をしていない」って感じることが多いですね。

　そこで気になっていることのひとつに開発言語の選定があります。「次のシステム開発ではＪａｖａを使いこと」とＲＦＰにも明記していることが非常に多いです。では、「なぜ、Ｊａｖａを指定したんですか？」とたずねると、「生産性が高く、保守効率も良い。だから、開発費用も削減できるから」と．．．

　確かに、「開発費用を削減したいから、開発言語も生産性の高いもの」というのは正論です。従来の「開発はベンダー任せ」という姿勢から比べると、好ましい傾向です。

　確かに、ものの本によれば「オブジェクト指向は生産性が高い」「保守効率が良い」とあるのですが、実際にプログラミングした経験からすると、そうともいえないこともあります。
　たとえば、「カプセル化によって、保守効率が向上」とはよく言われます。しかし、正しくは「カプセル化」が保守効率を向上させるのではなく、「部品化の設計がしっかり出来ていること」が保守効率を向上させます。確かに、Ｊａｖａの特性として再利用に向いていることは否定しませんが、モジュールの親子関係もなく作られたシステムは、きっちり設計されたアセンブラよりも保守効率が低かったりします。

　教科書的に言えば、「オブジェクト指向は生産性・保守性が向上する」のですが、実際には設計者のスキルが大きくものを言います。
　プログラミング言語はあくまでも道具のひとつです。道具をひとつ変えただけで誰もが「生産性・保守性向上」の恩恵を受けられるわけではありません。