官報掲載 統計センター 【ＡＩ技術を用いた文字認識サービスの提供業務】

私がシステム設計、提案した案件が官報に掲載されました。統計センター【ＡＩ技術を用いた文字認識サービスの提供業務】です。これは紙の統計調査票をAI-OCRという文字認識技術で自動読み取りしてデータの整備を行うというもので、AI技術の実使用として国内最大規模のものです。令和2年国勢調査を含む大規模調査の自動読み取りに5年間使用されます。

第3次AIブームも重要なマイルストーンを通過しました。

期待値だけでは技術の自然成長はあり得ません。実使用に耐え、経済価値をもたらすかがポイントです。同じAI、ニューラルネットでも音声認識はOCRほどお金になりません。官庁であれ民間であれ業務情報は書類として記録されており、オーディオで保存されている訳ではないからです。画像認識の応用として医療がありますが、医師抜きの画像診断に診療報酬をつけられる訳でもなく、お金になるのでしょうか？AI-OCRがちょうど実使用期に入った良いタイミングでこの入札がありました。書類を対象とするAIは今後も発展していくでしょう。

AIだけでは実用レベルのシステムは出来ません。他のIT技術を組み合わせた全体設計となって、ようやく使い物になります。要件分析、基礎設計、プロジェクト計画など全てを私が行いました。建築のような目に見えるデザイン、意匠はありませんが、システムにも筋のいい設計、悪い設計があります。基礎技術を使って費用対効果の高い、シンプルで安定したシステムを設計するのが私の得意です。1人称で書いていますが、本当に1人称です！入札提案は難易度の高い仕事ですが、落札提案がまさか1人の手によるものだったとは競合もあきれ返ることでしょう。

入札提案の実際はまた次の機会に

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)

失敗しない要件定義 その４ 〈議事録 テンプレート〉

失敗しない要件定義その４ は 議事録のテンプレート、書式です。ワードとPDFファイル版をアップしておきます。

シンプルですが、構成と大事なポイントは私がフューチャーアーキテクトにいた頃から20年以上変わっていないのでご安心を。

こちらです。議事録（MSワード、PDF）研修も以前ご紹介しました

あまりにシンプルなのでガッカリされたでしょうか？でも、シンプルなほうが書きやすいです。この書式を見ながら、要件検討会の運営も含め大事なことを列挙していきます（検討会は毎週開かれる前提とします）。

要件検討会で一番大事なことは重要な論点を効率良く、徹底的に議論、検討することです。システム設計プロジェクトの最初の段階、要件定義では検討結果、検討状況の確認ツールとして議事録があります。従って議事録の内容、品質、デリバリータイムが重要です。その分、体裁など他のことは端折ります。検討資料と議事録がしっかりしていれば要件定義書はできたも同然です。

失敗しない要件定義のポイント

• 要件定義フェーズのプロジェクト設計（仮説、重要論点出し、推進体制作り、検討会スケジュールの事前調整など）
• 検討会での意思疎通、コミュニケーション
• 検討資料と議事録作り（ドキュメンテーション）

1. 検討会の論点は２週前からアナウンスしておく。業務部門内での検討に２週かかるのが相場。その上で必要な資料準備や予習をしてきてもらう。１週前の検討会では進み具合を確認する。
2. 検討会の１週前には議論の材料となる資料を用意し、問題がないか予習してきてもらう（検討会資料、業務フロー、データ定義、画面構成・遷移図など）。
3. 検討会はスケジュール表で今日の位置付け、論点や、前回の振り返り、宿題状況の確認から入る。1週ぶりなので参加者の準備ができないと、いい議論に入れない。
4. 検討会では議論となる論点が絞られているので、各部門の立場で、大胆に見直す案、現状との親和性を維持する案、その間の妥協案、その案をとった場合の盲点などをじっくり議論できる。ただし積み残し、宿題が出るので２週など期限を設けてもちかえってもらう。重要な論点を要件定義前半にカバーしておく。それでも時間がきつくなることがあるので、毎回検討会スケジュールを見ながら善後策を考えていく（検討会スケジュールには問題がなかったことを納得してもらいながら）。
5. 検討会では議論の中で別の論点に言及することがあるが、議事録は論点別に再構成し、箇条書き形式とする。言葉を補い要件定義書のインプットになるレベルに仕立てる。確認が必要な言葉にはアンダーラインを引くか、目立つ記号★★を付けるなどして、参加者に議事確認をしてもらう。誰が言ったかよりも、ドキュメントが優先される。曖昧さ、考慮漏れを排除していく(MECEという言葉があったりします)。
6. 概ね時間順になるが、それにとらわれず構成の分かりやすさを重視する（論点の階層、議論の粒度など）。
7. 発言者の記載は必要に応じて。質問－回答は一文にまとめて構わない。細かい発言、同じ内容はカットする。本線に関わらないが記録に残したいものは、「その他」として最後にまとめておく。
8. 決定事項、未決宿題の確認を検討会の最後に行っておく。時間切れの場合、メールでの議事確認を必ず伝えておく。
9. 議事は必ずレビュワーがチェックする。書き始める前に重要ポイントをおさらい、確認しておくと早く正確に作ることが出来る。
10. 議事送付は当日か翌日までに行う。

ヘビーですよね。要件検討会２時間やるとヘトヘトなります。１日３コマやるとやせます。でも、要件定義しっかりしていれば、その後がうまくいきますからね。頑張りがいがあります。何事も備えあれば憂いなし、先手先手です。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その３ 〈要注意な言葉 アカウント〉

アカウント（Account）という言葉、あまりに意味が多過ぎて困ることありませんか？ただでさえ、業界、会社ごとの業務用語 “方言” があって、システム泣かせなのに、基本的な言葉の指す意味が複数あるのってどうなんでしょうか？

クイズです。それぞれアカウントはどういう意味で使われているでしょうか？

シーンその１ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「分かりました。財務でいいですよね？」

シーンその２ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「全支店分ですか？何のためですか、許可は取ってますか？」

シーンその３ 

システム屋：「現状のアカウントの一覧ご用意頂けますか」 

ユーザ部門：「国内なら今週用意できると思います。海外現法はちょっと聞いてみないと・・」

シーン１では勘定（科目）の意味です。財務会計の勘定科目ならあっという間に出せますよね。項目数でも1000ないくらいで意味のブレもそうそうありません。業種により多少違いはあっても経理さんに聞けば大丈夫です。（ただし補助勘定はローカル運用なのでご注意を）

シーン２は銀行口座の意味ですね。ペイオフ制度のため名寄せが進んだとはいえ、口座は支店別管理です。定期預金口座は普通預金口座と別になっています。なので振替で資金移動をします。同一名義の別支店口座も振替であり、振込ではありません。振替とか、繰越とか会計と同じニュアンスで使われていますね。（あまり遭遇しないと思いますが、医療機関も施設別患者管理です。患者情報の施設外持出は原則不可です）。

シーン３は得意先の意味で、銀行以外の業種でも得意先のことを口座といったりします。業務システムでは一般的な使われ方です。販売管理のキーとなるマスターですから、要件も盛りだくさんです。すぐ思いつくだけでも

・請求先か、届け先か、関連付けはどうしているか？

・与信（枠）管理はどの範囲で行っているか？
・仕入先は別管理か？
・グループ会社取引はどうフラグ付けしているか？
・国・地域、通貨、関税などとの関連付け・・・

新しく導入したシステムでは減ってきていると思いますが、コードが８から始まるものとか、必ず確認していました（ニヤッとされる方もいると思います）。

英語のミーティングでは Accounts of BS,PL, Bank account, Cusomer account と確認すれば良いかと思います。届け先は Address になります。

アカウントの話、ITっぽくありません。システムと全然関係ないようで、知らないと要件定義１回目からアウトです。コンシューマとビジネスで考え方が丸っきり違います。アカウント＝ユーザーではありません。以前、顧客コードを電話番号にしようとしていた人がいました。今なら E-mail でしょうか。絶対だめです。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その１

IT / システム部門の方とお話をするのですが、苦労が絶えないのは相変わらず要件定義のようです。開発になるとパソコンに向かうことが多くなるので技術者という感じですが、要件定義は対人業務です。ストレス解消法も良く話題になります・・

要件定義には、コミュニケーション能力とドキュメンテーション能力（とストレス耐性）が求められます。業務要件を言われた通りに丸写しすればいいというものではなく、システム化、シンプル化のインタラクティブな現場対応が必要です。コンピュータは賢くありません。だからといって闇雲に要望を切り捨てたら使えないシステムになります。実現性、工数などを勘案して、賢くないコンピュータを不便でない程度にブラッシュアップして、費用対効果に見合うようにするのですが、実は要件定義で大方結果が出てしまいます。*

設計フェーズで見直すという考え方もあるのですが、予算が決まっている以上、要件を膨らます訳にはいかないのです。要件精査でもたついたら設計フェーズの時間が削られてしまいますし、そもそも忙しい業務の合間をぬって検討会に参加してもらった業務部門のキーメンバーとの関係にひびが入るなど、デメリットばかりです。

すべては無理にしても要件検討会のその場その場で問題処理をしてしまわないと時間切れになります。データもあいまいでは困るので定義を明らかにしていきます。データ間の依存関係、上下関係も大事です。幹をクリアにしないと例外要件なんかまず出てきません。

プロジェクトは要件定義開始2週間が勝負です。最初の2週間でセッションをリードできれば要件定義をスケジュール通りに進めることが出来ます。失敗するプロジェクトは、要件定義が終わっていないのに時間切れで次のフェーズに進めている場合が多いです。設計フェーズで吸収しよう、ということですが、設計フェーズの方が投入工数は増えるので進捗の遅れのインパクトが大きくなります（工事進行基準廃止！）。要件定義が終了しているモジュールから五月雨式に設計に入ろう、としますが、データモデルを共有している以上、影響が伝播します。結局、設計修正、手戻りが発生し二重コストになります。データモデルが確立していない段階でのアジャイル開発が失敗するのはこの点にあります。MVC ( Model, View, Controler ) のModelについてはウォータフォールに利があります。データモデルを精査するためにはユースケース（システム利用、操作仕様）の理解が必要で、業務シーンではその重要なインプットの一つに業務フロー（業務フロー）があります。

業務フロー図にやり取りされるデータは定義されているでしょうか？失敗しない要件定義の分かりやすい Howto を一つアドバイスさせて頂くとしたら、

業務フロー上のデータを精査

することです。あまりうるさく言われていないようですが、成功のカギの一つです。
大変かもしれませんが、必ず報われる苦労ですので。是非一度レビューしてみて下さい。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

* 顧客サービスですから、ここをうまくお話ししないと仕事が終わってしまいます。状況をフェアに説明し理解を得て、妥協点に落ち着かせる交渉事でもあります。

失敗できないプロジェクト 〈成功の秘訣〉

システムプロジェクト成功のポイントは要件定義にあります。では要件定義の成功のポイントは？　プロジェクト開始前の事前ヒアリングです。規模の大小、期間の長短問わず、1,2回の事前ヒアリングの有無が、プロジェクトの運命を決めます。全体の費用対効果、QCDを大きく左右します。

“ 事前ヒアリング ” 、うちでもやっているよ、と思われるでしょう。それがプロジェクト成功のポイントになるのか？

事前ヒアリングの断片的な情報から、必要とされるもの・ことを具体的に想像して、仮説レベルの全体像をイメージ。要件定義の限られた時間で、検討すべき課題を具体化し、キーメンバーのアサインを決める。

これが、事前ヒアリングからのアウトプットです。

要件定義の重要検討テーマ、セッション・スケジュール、そして仮説レベルですがシステムの全体像、おおまかなデータモデルまでイメージします。要件定義はその仮説検証となります。一般的には要件定義フェーズの計画書ですが、この段階で高い品質を目指し、ゴールに近づいています。

成功しますよね。だから事前ヒアリングが重要です。仮説作りです。

プロジェクトリーダには業務知識、システム設計経験もですが、コミュニケーション能力、ドキュメンテーション能力が重要です。仮説作りは、インプットからロジカルにアウトプットするという思考法ではありません。課題解決型の非日常的な思考法です。プロジェクトの初期段階はお客様、ベンダー共にお互いのことが分かっていない、情報不足した状態ですから、仮説作りの思考法が効果的です。

事前ヒアリングもう一つの利点はベンダーの実力が、早い段階でお客様にはっきり分かることです。不幸にも実力のないベンダーを選んでしまったら、お客様側がそれに合わせるしかありません。
初めて要件定義をするリーダーがアサインされているかもしれません。業界、業務知識ゼロかもしれません。お金を払っているのはお客様。でも、ほとんどお客様がベンダーに仕事を教えて、チグハグなドキュメントをもらって、真っ赤になるほど赤入れをしているかもしれません（アジャイルとかスプリントがどうとか言って、ドキュメントを出さないベンダーもいるかもしれません）。事情はともかく、あいみつ（相見積もり）なり、コンペなりをして、事情了解の上で、契約、注文書を発行してしまったのですから、元には戻れません。

泣くのはお客様側、特に業務の現場のみなさんです。こうならないように、事前ヒアリングでベンダーの実力をみてください。コミュニケーション能力、ドキュメンテーション能力も伺い知ることができるでしょう。人柄、第一印象も重要です。そういう相談の仕方、提案依頼をしてみてください。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）