UI/UXとは言うものの・・・

UI/UXとか“クリエイター”さん達はかっこいい言葉を使うのですが、業務システムの場合どうでしょう？

本音ではオフコン時代からのキーでパチパチ速打ち入力がいいと思っている方も多いのではないでしょうか？あまり見ませんがWebでもできます。PCの性能が高くなっている分、Webページにマスターを持たせることもでます。通信が発生しませんから速いです。

サンプルです。1,2,3を打ってください

1日1回 朝食後

1日1回 昼食後

1日1回 夕食後

1日2回 朝食後/夕食後

1日2回 朝食後/昼食後

1日2回 昼食後/夕食後

1日3回 毎食後

薬の用法を分服回数（1日1回、2回、3回）で候補選択する様子を背景色で表示しました。同じように頭数文字でマスター（10,000件以下）を絞り込むことができます。候補をサジェスト表示するのがWebっぽいUIですが業務系では頭３文字＋スペースキーで候補表示する方が使いいいです。またUIの紹介したいと思います。

永島志津夫

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

システム開発 〈見積・工数計算〉

システムの設計開発、工数計算をする側のお話です。”見積依頼” とか “提案依頼” の対応、なかなか手間を取ります。それでコンペだったり、価格交渉だったり、使った時間を回収できないこともあります。来ないと困るし、来たら大変だし。だからと言って、おろそかにできません。受注したら責任が発生します。納期、品質を守るにはそれなりのお金が必要で、工数計算間違えていたら大ごとです。その大事な工数計算、このAIの時代になっても進歩していません。逆に技術が細分化、ダイバースしたためトータルで工数を見積もれる人材が減っているのではないでしょうか？

設例）アクセサリーの卸販売を手掛ける企業から、受注業務のシステム化についての見積依頼があった。

出荷配送はサンプル品を除きすべて配送ベンダーに任せており、Webで出荷指示が可能である。ショップからの注文はメール、FAXおよび電話である。FAXが６割、メールが３割、電話が１割で取引先数は 2000件ほどである 

アイテム数はおよそ600、SKUとして3000程度だが、常時入れ変わりがある。オーダーは月平均2000件程度、多いときは5000件、担当者２、３名で平日の営業時間で対応している。 

情報はいったんこれだけだとして、明日までに概算見積が欲しいと言われています。システムの見積できるでしょうか？業界常識など書かれていない与件があるのですが、経験的にはこのシステム ￥５千万から７千万位になるかと思います。もちろん仕事では機能積上げ法の結果と突き合わせます。明日までに概算が欲しいと言われても、￥１千万の見積だしたら大変なことになります。また販売管理パッケージ提案したら物笑いになります。スクラッチです。
このシステム ￥５千万として費用対効果（投資対効果）は見合うでしょうか？２，３名でこなせる業務ですからそのままでは見合いません。同業者と共同利用のような形がとれるなら検討の価値ありです。発注側も見極めが大事です。

情報技術関係の資格試験も増えましたが、工数計算の問題がないのはなぜなのでしょう？工数計算ができないとエンジニアのキャリアも描けないですし、工数計算のできないプロジェクトマネージャーも困ります。直球の問題出してほしいです。細分化した知識試験を積み上げても工数計算も要件定義もできません。ということは知識の持ち腐れになります。
仕事仲間から聞いた話ですが、システムテストが開発工数の〇分の１、システム移行は見積なしという案件があったそうです。基幹系です。情報処理資格は一体何をクオリファイしたのでしょう？発注者のみなさん、お気を付けください。成功に必要なのはコンペよりもセカンドオピニオンです。

永島志津夫

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

使える AI 使えない AI

コロナの影響で派手な催しもできず AI / IT バブルがすっかり鳴りを潜めた感がありますが、本当のところはどうなんでしょうか？ IT なんて不要不急の代名詞かと思いきや AI 系は影響を受けていないようです。よっぽど医療関係のほうがダメージが大きいです。

わからないものです。医療のほうが不要不急だったとは。ただ区別しないといけません。医療は個人のニーズで、AI / IT は企業のニーズです。たまたま私はそのふたつを掛け持ちしているので比較してしまうのですが、企業活動は個人活動を凌ぐ力、強さがあるようです。

AI にお金払っている個人います？いませんね。パソコン相変わらず賢くありません。このブログも賢くないかな漢字変換で効率悪く作っています。お金出して ATOK 入れたほうがいいのは分かっていますが、人間がカバーして良しとしてしまいます。

ところが、企業は AI にお金払います。AI が全部できる訳ではないです。本当に限られたシーン、適切なユースケースだけです。ただボリュームが大きくなると人間の 1/10 以下のコストで業務をさばきます。24時間365日さばき続けます。10倍、1/10 というのは、パラダイムシフトが起きる目安で、以前のニューラルネットや AI ブームが終わってしまったのは、せいぜい 3倍、1/3 どまりだったからです。

さてタイトルの “ 使えるAI 使えないAI ” 決め手は認識率だけではないです。ユースケース設計もです。認識率が 仮に 80% でも、サンプリング調査であれば サンプル数を 25% 増やせば必要なデータは得られますね。ちょっと机上計算をしてみましょう。

・1 サンプル に10円かかる調査 で 1000サンプルなら 1万円、1250サンプルなら 12,500円
・1サンプルを人間がデータ化するのに 10円、AI だと 1円だとします。
　1000サンプルを人間がデータ化するには、1万円
　1250サンプルを AI がデータ化するには 1250円
結果、人間だと2万円、AI だと13,750円です。2万円と1万4千円ではインパクトないですが、2億円と1億4千万円だとしたら、 AI に切替ない経営陣は責任を問われます。

使える AI はユースケースに利があります。利があるユースケースをターゲットにして不要不急のコストをかけずに市場を拡大しています。AI  もまた資本主義の申し子、おそるべし資本主義！資本主義の辞書に自粛という言葉はないようです。

永島志津夫

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

オフィスエヌ ショートレビュー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 (#を@に変えてメールをお願い致します

失敗しない要件定義 その２ 〈コミュニケーション〉

コミュニケーションについてのエピソードをご紹介します。

あるお客様から課題要望事項をまとめた一覧表がEメールで届きました。課題と思われること、課題ではないが実現できればなお良いと思われる要望があれば、ご連絡くださいと、前回の打ち合わせで私がお話したことを受けて送っていただいたものです。 

ただ一覧表を見ると担当のスタッフは驚いてしまいました。そこにはとてもご契約期間内（1ヶ月）で完了できないほど多くの事項、初めて聞く内容などがあったからです。これを一つ一つ実使用に耐える品質で実現することなど到底できません。担当者は途方に暮れかけていました。少し時間をおいてから私もそのメールと課題要望事項の一覧表を確認しました。 “まずは電話で課題要望事項として挙げた背景、理由であるとか、是非とも必要なことなのか、きいてみてはどうだろう？” と担当スタッフに話しました。幸いすぐ電話で連絡がつきました。30分程お話した内容は以下のようなものでした。  

“社内から色々と要望、課題が出てきており、その量を認識、把握する意味合いもあり一旦全て表にまとめた。要望として挙げているものも、すぐ実現が必要という認識ではなく、これから数ヶ月の中での改善を考えていく上での検討材料という位置付けである。もちろん要望を実現できるに越したことはないが、なかには相矛盾する要件も存在している。要するに、表に挙げたような要望は現在もあるし今後も出てくるであろう、そのような状況にあることをまず共有、理解してもらいたかった。”  

また、課題とされているものも一つ一つに対応するというよりは、業務に与える影響、代替手段（人手で回避、工夫できないか）、そもそも課題として挙げていることの理由、妥当性などの検討を一緒にしたい。それから現実対応できるものを絞り込んで、順次対応していくプランを作ることができたら、と考えられていることが理解できました。 

いかがでしょうか？電話でのコミュニケーション。リアルタイム、インタラクティブですから効率がいいですね。テキストよりもはるかに情報量が多い分、相互理解に有利ですし、お互いの時間を共有したこと自体が価値になります。逆に、お客様から時間をとるに値しないと思われたら要件定義失敗です。電話が苦手なスタッフが増えていると聞きます。ボイスコミュニケーション、もっと活用して欲しいと思います。

永島志津夫

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

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

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

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

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

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

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

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

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

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

永島志津夫

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

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

システムの費用対効果 〈研修による能力向上、人材開発〉

忘れられがちですが、人材開発は最も効果的なQCD向上策です。適切な研修や職場教育(OJT)は費用対効果を何倍にも高めます。2年前の新卒者研修で行った内容をご紹介します。*

15名の新卒者を対象に初期導入教育を実施しました。昨年の反省を踏まえ今年は一人一人に集中力を求める強化プログラムに変更しました。メモをとらずに30分ヒアリングをする。人の話を頭に焼き付ける。そのために集中力を発揮する、昨年との違いは“集中力”、この一点です。

高専卒から大学院卒まで年齢は5歳くらいの幅がありましたが、結論から言えば、集中力、ヒアリング能力に年齢、理科・文科など専攻の影響は見受けられませんでした。採用プロセスで一定の基準をクリアしているからでしょうか。ただ意外なことがわかりました。今回はそのこともお話しします。

研修の内容は、模擬的に顧客へのヒアリングを実施し、問題分析、改善提案を行うというものです。ヒアリングでは私が一人二役で上司役と顧客役を演じ分けました。15名の新卒者はスタッフとして、個々に上司と顧客にヒアリングするという設定になっています。上司とスタッフのペアが15組あるかのようなイメージですね。また問題を分析、改善提案をスライドにまとめていく過程では私が上司役としてレビューを実施しました。

お客様はアパレル企業、人事部さんとの打ち合わせでヒアリングをするという設定です。副業採用を本格化するとのことで、既に導入済みの正社員採用の電子りん議を手直しするというものです（※フィクションです。念のため）。検討されている副業のあらまし、採用りん議として考慮すべきことなどをヒアリングします。実際のヒアリングは20分になりました。60分かけてヒアリング内容を議事録にします（実際の仕事でも慣れないうちは議事録作成にヒアリング時間の3倍かかるというのが相場です）。

副業を取り上げたのには理由があります。技術系、営業系と大きく配属先の目処はあるとはいえ総合職は辞令一つで明日から何屋さんにでもなるというものです。だからといって主体性を無くしては何屋、何者にもなれません。仕事（賃労働）とは自分の職務能力を売ることであり、会社に来て漫然と時間を過ごすことではない、そのことを意識する材料として、副業＝得意とする職務能力を売る、働き方を題材としました。

お話の内容です。

“販売員、デザイナー、EC系ITなど専門職について副業採用を考えている。販売員であれば週末の忙しいタイミングで働いてもらう。平日・週末の繁忙の波はもちろんだが、ファッション通の個人の力に期待する面もある。自分のブログでコーディネートを発信、街中での動画も活用し表現力豊か、プロ顔負けのものもある。固定ファンも持っている人も多いようだ。自社のブランド、自分の世代に閉じることなく、幅広く素養を得て、お客様との交流経験を積むことがこれからの販売スタッフには必要だ。正社員にも良い刺激になるはずである。デザインも仕事の波があり必要な時に仕事を出したい。クリエイターにとり仕事がないのに会社に来ることほど苦痛なことはないらしい。逆に自分がしたいと思っていたチャレンジングな仕事というのは、いくら忙しくてもイキイキしていられるらしい。もちろん、その方がデザイナーにも相当良い収入になる。EC系ITは他社での経験、ノウハウを期待している。例えば、おすすめ商品、いいねリスト、購買履歴など、表には出てこないところでレスポンスを高める設計上の工夫があるらしい。利便性とのトレードオフをクラウド基盤の特性を踏まえ実装、ECサイトを成功させている人材の手を間借りしたい。

もう一点、採用後2年間に掛ける育成コストを採用りん議の段階で想定しておきたい。人件費（給与、賞与、社会保険、福利厚生）、エージェント経由の場合のコミッションなどの直接費に、育成コスト加えたトータルで勘案したいという要望が経営から出されている。人手不足を背景に十分な能力を持たない人材を無理に採用しアンマッチが起きている。早期退職ではコミッション分も回収できていないので、育成コストという項目で現状の能力を意識させ、無理な採用に一定の抑止をかけたい。”

他、選考、採用りん議のプロセスに関連した内容が続くのですが、それは割愛します。

ヒアリングを前編と後編に分けて、計2回行う予定だったのですが、結果的に前編を1回追加し計3回実施しました。最初のヒアリングの出来があまりに悪かったからです。出来が悪かったというのは全員ではありません。出来た人と出来なかった人の差が甚だ大きく出ました。今回わかったことの一つは、このヒアリング能力と問題分析能力の相関です。問題分析、改善提案の最終的な出来はほぼ最初のヒアリングの出来に連動しました。同じヒアリングを2度実施し、提出してもらった議事録を見る限り個人間の差は縮まっていたのですが、結論から言えば前編を2回実施せずとも最終的な結果に差はありませんでした。これは怖い結果です。一見簡単なタスク、30分ほど人の話を聴くことが、問題分析、改善提案といった高度なアウトプットに連動するのです。出来の良い人ははただ聴いているだけではない、問題分析、改善提案につながる ”何か” が違うのです。そもそも、人の話を聴くというベーシックな知的好奇心があるか、ないか、その違いではないかと私は見ています。モチベーションなくして認知・行動はありませんから。



例えば採用試験にヒアリングを導入すれば良いスクリーニングになるでしょう。話の要点が議事にあるかチェックするだけです。難しい質問を用意する必要もありません、簡単なことです。また面接を何度もするくらいなら、ヒアリングに続き問題分析の宿題を出しても良いでしょう。あまり手間のかかる宿題を出せば他の企業に流れるかもしれませんが、問題解決に興味のない人間、問題分析を億劫がる人間を雇用し続けることになるくらいなら他に行ってもらった方が良いとも言えます。単純労働は早晩機械に取って代わられますから。

※求職者側の意見ですが、就職活動をしていた頃、形式的に続く部長面談、役員面談に辟易しました。何の意味があるのでしょう、同じような質問ばかりで。これはこれで求職者側の企業見極めになりましたが。



知識教養がないのも考えものです。あまりに論理性がないのも困ります。しかし仕事の現場に書かれた文章が用意されているでしょうか？顧客の要望、要件が文章として既に存在しているのでしょうか？ face to face のコミュニケーションで徐々に要望、要件が具体的になり、”である・ではない” という問い掛けから、あいまいさが排除され、よりクリアになっていく。“こんなケースはどうでしょうか？” という自分にはない相手の発想から、より発展されたアイデアが作られていく、そのような創造のプロセスにこそ機械に代替されない人間らしい労働の価値があります。



顧客とのコミュニケーションには甘えが許されません。重電メーカの総合研究所にいた時、NTT出身の所長がレビューや面談で “技術者の独善性” という言葉を何度も使っていたことを覚えています。当時、私はその言葉の実感がありませんでしたが、20代の最後、顧客相手の仕事に復帰した時、責任も重く、コミュニケーションに緊張しましたが、何よりも “技術者の独善性” を思い知ることができました。専門性を盾に社内では好きな事を言えます。言いっ放しができます。その気がなければ人の話に耳を傾ける必要もありません、あえて不都合、不愉快なフィードバックをする人もいないでしょう。そんなことは組織において損なことですから。しかし、顧客には筋の通らないことは言えません。言い訳もできません。“技術者の独善性” は顧客に接し、フィードバックを直接受け、“痛い目” にあうことで初めて気付くのです。

ですから、今ヒアリングの出来が悪かったとしても悲観することはありません。母国語の話を30分聴き取る、こんなことすら自分は出来ないということを入社した4月の段階で認識できたことは有益です。4、5年後の異動で気付いたとして、どうしろというのでしょう。

永島志津夫

* 当時別のブログにあげた記事を再掲しました

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

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

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

システムの費用対効果 〈 RFP 提案依頼 〉

RFP ( Request For Proposal ) 提案依頼 という 仕事の依頼の仕方があります。背景、前提、希望などを伝えたうえで、“良い提案をして下さい” というものです。システムやプロジェクトという無体物を相手に何と大胆なことでしょう。

この世界で仕事を始めた頃、そう思いました。安い予算ではないのです。大きな仕事程、この RFP を使います。RFI ( Request For Information ) 情報提供依頼というのもありますが、ほとんど同じようなものです。要件が定まる・定める前段階で、望ましいゴール、そのためのプロジェクトの概要をシステムベンダーに考えてと依頼を出すのですね。契約に基づく依頼ではないので応じる義務はありませんが、大きな仕事や、取れそうな仕事とみると、それなりに手間ひまかけて、提案書を作ったり、プロトタイプまで用意したりすることもあります。当て馬とみると簡単に済ませます。なので、あいみつ（相見積もり）と同じで、前提が揃いません。結局は予算に収まるとか、価格の安いところに出すという判断になります。無体物ですから、本当は値段以前に必要なもの、ことが足りているかが大事です。

もうお分かりだと思います。問題が露呈するのは最終段階、移行のところです。 “ それはお客様でやって頂きます。 ” 　これが決まり文句です。他社が導入しているからといって安心は禁物です。新システムへのログインのタイミングが少しずれただけで移行に失敗することもあります。ユーザーにアナウンスしたつもりでも、ちょっとした隙にトランザクションロス、マスターロスが入り込みます。今はもうないと思いますが、オンプレのADから365のADへの移行でエライ目に遭ったことがあります。移行は準備も含め、時間もお金もかかります。経験も必要です。ここを端折れば当然安くなります。

安易なRFP止めましょう。安いところ選ぶのお待ちください。移行に不安はありませんか？

永島志津夫

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

システムの投資対効果 〈 Python AI ニューラルネット 〉

Python 使いやすいです。この簡単さ、何かに似ていると思いました。そう、BASIC* です。インタープリタだし、宣言しなくていいし。それでいて配列計算をスカラーのように記述できます。SASもそうですが、データアナリストは1命令でデータセットの処理記述ができる言語が好みです。ビギナーからプロまで遊ぶように使える素晴らしい環境ですね。

面白くなって少し遊びました。おなじみ「ゼロから作るDeep Learning」  ( 教材はGithub )。 でもあえて Deep とは反対の事を試しました。二層のニューラルネットで手書き文字認識（ MNIST  0から9の数字 ） を学習させるのですが、中間層をどんどん落としていきます。タイトルの通り、費用対効果を見るというトライアルです。

結果です。
中間層　認識率（テストデータ）
　50 unit　94.6 %

　25 unit　94.1 %

　15 unit　93.3 %

　10 unit　92.1 %

　  7 unit　91.3 %

　  5 unit　87.3 %

中間層が 7 でも認識率が 90 %越えるのですよ。どうなっているのでしょうか？おそらく 0 から 9 のどれか 1つに分類するというタスクであれば、特徴量は 10 も必要ないということではないかと推察しました。7 程度の特徴量の組み合わせで まあまあの認識ができると。こんなことから CNN に発展したのかもしれませんね。
多ければいいというものではない、少ない程必要なものに迫っている、何だか要件定義と同じですね。機能やデータを絞って迷わず使いやすくするのがデザインのポイント、性能も上がりますし。だいたいロジカルじゃないことはシステム実装できませんから。思い切ってシンプルにそぎ落とすのが肝心です。

永島志津夫

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

* パソコンのコンピュータ言語といえば BASIC という時代がありました。1980年代です。

システムの費用対効果 〈 工数計算 〉

工数計算、見積を作る側のお話です。実はシステムエンジニアの実力が、数値としてはっきり表れるのが工数計算です。要は難しいということです。

難しさその１　実務経験が必要（設計開発、後工程の経験）
Windowsアプリでも、Webアプリ（フロントエンド）でも、サーバーサイド（データーベース、ビジネスロジック、フレームワーク、基盤構成・・・）でも、実務経験のないことは工数のイメージが湧きません。要素技術偏重の昨今だと全体を見通すことが難しいと思います。

難しさその２　仕様理解が必要（要件定義、前工程の経験）
何行程度なら何時間というものではないんですよね。あくまで業務要件とその実装というイメージで工数建てしていくので仕様理解が必要です。ファンクションポイント、積み上げ法も使いますが、細かく機能分解しても見積精度は上がりません。経験ベースで業務要件から工数建てしていく方が的確に出ることが多いです。なので積み上げ法の場合、過去事例、類似事例との比較で妥当性チェックもします。

特に重要なのは特殊性、例外要件の理解。
時々あるのですが、要件定義と設計開発が別のチームリーダーの場合。うまくいかないですね。ひどいのになると、前工程と後工程が別の会社という場合があって、前後でお互いの責任はありませんから、損をするのはお客さんです。
要件定義と設計開発を同じ会社にやってもらうのが一番です。時間単価が高くなるかもしれませんがトータルで納期、金額とも少なく済みます。それができない場合はお客さん側でしっかり仕様把握、設計レビュー、工数管理をすることになります。

昔はみんなこれでやっていたのですが要素技術の広がりとともにベンダー任せになってしまいました。要素技術を絞るのはシステムの費用対効果を上げる近道です。クラウド＆ウェッブサービスの組み合わせもいいのですが、費用対効果は発注者自身が見極めないといけません。悪気はないのですが、ベンダーは自分の得意なことは言っても、不得意なことは言いません（不得意なことの方が圧倒的に多い）。

システムの費用対効果、一度見直してみませんか？

永島志津夫

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

システムの費用対効果 〈 業務フロー 〉

みなさん業務フローの書き方って習いましたか？システムをやっている人間だったら名前を知らないことはないと思いますが、業務フローのいい参考書ってないんですよね。

移行もそうなのですが、システムプロジェクトの要衝部分って参考書がない。知識では太刀打ちできるものではなくて、仕事、実務経験を通じてしか上達できない。そういうものみたいです。業務フローなんて要は時間軸と人軸のマトリックスですから。書き方について教わることなんて少しだけ。

予算に収めるため、納期を短くするため、画面を簡素化しましょうとか、帳票を共通化しましょうとか、そんな努力（ユーザーにとっては妥協）がいっぺんに吹き飛んでしまうのが業務フローのミスなんですよね。一言でいうと要件漏れです。たいがい例外系で、“注文した商品がなかったら・・” とか、“住所が変わっていたら・・” とか、そういった場合のロジックがなかったり、データ項目が不足していたり、テーブル構造的に無理だったり。

で、犯人捜しが始まります。ベンダーは「言ってくれなかったから」、お客さんは「聞いてくれなかったから」です。お決まりの言った、言わない、です。だいたい、システムテストとか、受け入れテストで問題が判明します。アジャイルだろうと何だろう同じで、実際の業務想定でないと例外系のことなんて表面化しません。

使おうとしたら使えない。例外系であろうと、なければ移行できない。予算も使い切っているし、時間もない。ひどい場合は例外系だけ手業務でお願いしますなんてケースもあります。

じゃあどうすればいいのか？

業務フローのインプットって、業務ヒアリングですよね。あたりまえですが。

業務ヒアリングにはコツがあります。

議事録作りにもコツがあります。

要件レビューの進め方にもコツがあります。

※経験も必要です

業務ヒアリングはプロジェクトの初めのところですね。まだまた修正がききます。１、2週の調整なんて難しくありません。ところが受け入れテストの段階で１、２週の調整は難しい。実際はシステムの作り直しなので１、２週じゃすまなくて、システムテストもやり直すことになり月単位の遅れになるでしょう。こんな感じでシステムの費用対効果は悪化します。品質も性能も巻き添えにしながら。

永島志津夫

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