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

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

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

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

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

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

永島志津夫

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

コンペ提案 〈勝ち抜き〉

RFPとか競争入札の提案活動のお話です。私はベンチャーが性にあっているので、だいたいチャレンジャーサイドでした。競合は大手、有名どころばかり、そんな不利な立場からの勝ち抜き、仕事の醍醐味です。

この8月（2020年）まるまる、某AIコンペに費やしました。夏を制する者は受験を制す、と言いますが8月までに下期の案件が決まるのでシステムの仕事でも8月は重要です。RFP対応とかコンペはこれまでもこなしてきていますが、これだけどっぷりというのは初めての経験です。

コンペは最後にだいたい2社の争いになります。チャンピオンサイド（大手有名どころ、既存ベンダー）対チャレンジャー（ベンチャー、新顔）になることが多いです。チャレンジャーがコストに勝るからで、大手の似たような提案は途中で絞り込まれることが多いです。コンペは、コンペをして発注先を決めたという手続き自体に意味があることも多く、はじめから当て馬というケースも多々あります。そうでなくともチャレンジャーサイドは負けること多く、光る技術、製品があっても、トータルで大手企業の求める品質基準についていけず、落とされます。会社の名前が品質を表すものではありませんが、名前で選ばれるのが現実です。

勝率は高くはありませんが、チャレンジャーが勝ち抜ける例があるのも事実です。なぜか？と問うよりも、実力勝負、興味ありませんか？ ” ここがロドスだ、ここで飛べ！ ” 

高校受験とか大学受験はみんな実力勝負でしよね。仕事でもその道何十年という経験を積んだ以上、自分の力で勝負したくありませんか？そんな機会を多く経験してきた私は幸せなのだと思います。システム大手では専門分野毎に、アプリ、基盤、プロジェクト管理・・と分担します。そもそも組織、部署が分かれていますから、担当分野以外のことに手を出せないようになっています。チャレンジャーサイドに分があるとしたら、一人の意思の全体設計で大手ではできないようなQCDを実現することにあります。顧客が見落としている大事なポイントがあれば、勝算は上がります。チャレンジャーの描くストーリーが評価基準になるからです。競合関係にない相手の場合、能力として自分より下の人間よりも上の人間を選ぶ傾向があります。 ”何でもやります” という提案よりも、 ”こうしなさい” という提案が選ばれます。名前で有名どころを選ぶのも同じ理由です。チャレンジャーはストーリーでそれ以上のことします。提案担当ができることと言えばそれくらいです。

競争ですから、案件の中身、要求仕様もさることながら、案件の状況を知ることが大切です。見極めの一番のポイントは、なぜ依頼をしたかの理由、経緯そして今後の段取りです。段取りがあいまいな相手に付き合う必要はありません。相手を立てれば案件が取れる訳でも、事業や自分が成長する訳でもありません。発注者に思い違いがないようこちらの出来ること、立場を知ってもらうことが大事です。コンピュータは人間ほど利口ではないし、簡単ではないし、開発には時間もお金かかるということです。私は最初にはっきりそれを言います。勝算のない案件に時間を使うことよりも実需に合わせた製品コア機能の拡充に時間を使うべきです。

ところで初めから勝算のない当て馬案件、見分けは簡単なのですが営業の立場だとなかなか捨てられません。ノルマがあるからですが、結局期末に悲しい結果を迎えます。当て馬ばかりというのは、営業の問題ではなくて製品、事業が当て馬レベルでしかないということです。そういう会社からは早く離れた方がいいです。ITの場合、営業で製品の不足を補うことは難しいです。いい仕事をするためには、いい環境に身を置きましょう。自己中心的、わがままでいいと思います。会社や上司も、みなさんの先のキャリアを考えている訳ではありません。その時々で役に立つ人間が欲しいだけです。自分のキャリアは自分で作る、そういう心構えがなければ、意思の通った全体設計なんてできないと思いますが、いかがでしょう。

永島志津夫

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

システム開発と原価計算 プロジェクト管理に実際原価がそぐわない？

製造業の原価計算システムを設計開発することもあります。前工程から実際原価を算出し後工程に反映していきます（転がし計算）。これを連結ベースで計算することもあります。そんな高度なことしつつも、灯台下暗しで、システム開発会社で実際原価計算をしているところは滅多に見かけません（私が知るのは過去1社だけです）。

エンジニアはだいたい固定給なので実際原価把握が容易なのに、なぜでしょう？どうも原因はプロジェクト管理にあるようです。プロジェクト管理と原価計算はもちろん別物ですが、一緒にやろうとすると実績原価（標準時間単価×実績時間）でプロジェクト管理して、原価差異を足し引きして財務上の原価を出しますが、実際原価に戻ってきます（当たり前ですが）。標準原価法を使ったところでプロジェクトを推進するプラスアルファは何もありません。予定原価と実際原価がほぼ一致する業種ならいざ知らず、試験や移行の工数を漏らすレベルで標準原価法を使う意味はありません。プロジェクト計画のリアリティチェックをするだけなのですが、できていないですね・・

EVM（Earned Value Management）という進捗管理法があります。これは予定原価が信頼できる前提ですから、システムの世界ではダブルクエスチョンものです。そもそも信頼できる予定原価計算ができていればプロジェクトは成功を約束されたようなものです。すべて見通している訳ですから。形式的なプロジェクト管理も必要ないでしょう。待っていればQCDいずれも満足のいく結果が得られるます。前にも書きましたが見積、工数計算はシステム設計でも高い習熟度が求められる能力です（システム開発〈見積・工数計算〉）。　要は経験、能力が未達ということで、人材不足なのでしょう。新しい言葉、言語、開発フレームワーク、資源管理・・が出ては消え、出ては消えを繰り返して、本質に切り込めず、周りをまわっているだけのような印象です。予定原価に信頼性がない以上、システム開発の原価計算は実際原価で十分だと思います。

永島志津夫

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

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 (#を@に変えてメールをお願い致します)

セキュリティ対策 XSS, CSRF, ポップアップブロック そして・・

サードパーティークッキー・ブロック！

Webサーバーがコンテンツをブラウザーにレスポンスする際、ヘッダー情報にクッキー ( cookie ) というセッション識別情報を付加することがあります。HTTPプロトコルはブラウザーからのリクエストに対してサーバーがコンテンツをレスポンスして終了です。1ページで終わらないようなアプリケーションの場合、継続しているセッションを知る必要があります。HTMLに識別情報を埋め込んでもよいのですが、コンテンツとは別にヘッダー部にセッション識別情報を組み入れたのが cookie です。

その cookie 、長年の問題がありました。ユーザーが意図していないタイミングで受け取ったり、送ったりしてしまうのです。
例えばニュースサイトをみて通販商品のコンテンツがあったとします。そのコンテンツは別のサイトのものだったとします。ユーザーはニュースサイトを見ているつもりですが、通販サイトはユーザーがニュースサイトのどのページをいつ見たかを記録します（できます）。通販サイトへのリンクをたどらずとも記録されます。ニュースサイトに通販コンテンツがあることを事前にユーザーはわかりません。また一度クリックすると別サイトでも同じ商品の広告が出てくるのはサイトを越えてクッキーの使い回しができるからです（事前にユーザーはわかりません）。このリンクが書き換え、悪用されてもそれっきりです。

この例のようなセキュリティの問題をはらむクッキーをサードパーティクッキーといいます。実はブラウザーの設定でサードパーティークッキーの受け取りを拒否することができます。高い、不便、遅くなるで不評のセキュリティ対策としては、例外的にただ、簡単、遅くならない、しかも強力なものです。ただブラウザーのクッキー設定を変更しているユーザーは少ないのではないでしょうか？会社のPCどうですか。

しかし朗報です。Appleは2020年3月に Webブラウザ Safari の初期設定を “サードパーティークッキーの受け取り拒否” としました。サードパーティークッキーの主たる用途は広告宣伝なのです。セキュリティもですが追っかけ広告も鬱陶しいですよね。サードパーティークッキーの濫用というか、そもそもネットマナー、エチケットとしてどうなのかと思っていました。広告宣伝行為として後ろめたさありますよね。会社のマーケティング部門に勤めている知人も個人的にはやりたくないし、自宅のPCはサードパーティクッキーをブロックしているそうです（私もです）。Apple やりますね。マイクロソフト、Google も諦めて欲しいものです。

ブラウザーの設定画面のキャプチャーを貼りました。設定した後は、過去のクッキーをクリアしましょう。クッキー・ブロックは受信拒否であり送信拒否ではありません。過去の設定でブラウザーに保存されているクッキーは有効期限まで送信され続けます。

Chromeの設定

Edgeの設定

サイト運営者、Webエンジニアのみなさま、自主的にクッキーポリシー SameSite=Lax  を明示しましょう。Apache であれば mod_header で append SameSite=Lax とするだけです。 php でも jsp でも HTTPヘッダーに反映されます。簡単です。Apache 知っていると得することまたご紹介します。枯れた技術に宝ありですね。

永島志津夫

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

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

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

外部認証 OAuth2 業務サービスのクラウドでは？

外部認証、身近なものでは “Facebookでログイン” とか “Googleでログイン” のことです。ユーザ登録は面倒ですし、パスワードも覚えていられないのであれば使われている方も多いかと思います。OAuth2 なのですがコンシューマ向けと業務サービスでは構成、シーケンスに違いがあります。なぜか？というお話です。

最初に業務サービスのの場合の認証シーケンスの例をご紹介しましょう。

ユーザーは認証サイトBにログインし業務サービスを利用していますが、あるオプション機能はサイトAのものだとします。まだサイトAにログインしていないので、オプションメニューをクリックすると、認証トークンが埋め込まれたサイトAへのログインページがサイトBから返されます。ここがポイントで、サイトAへのログインページをサイトAのセッションで返されると、認証トークンをサイトBから得るセッションがブロックされます。なのでサイトAにログインするページはサイトBから返してもらう必要があります。サイトBは有効なセッションをもつユーザー（ブラウザー）に対してサイトAの認証を代行します。認証OKの場合はトークンを返します。トークンはサイトAから提供された秘密台帳による署名付きです。

ログインページはブラウザーのリダイレクション機能を使って直ちにサイトAにアクセスします。認証トークンはサイトAの秘密台帳で検証されログインが成立、ユーザーはサイトAの提供するオプション機能を利用できるようになります。

さて同じことをコンシューマ向けサービスで出来るでしょうか？サイトBを Facebook 、サイトA を転職情報サイトとでもしましょう。Facebookにログインしているユーザーが転職情報サイトのバナー広告をみてクリックします。しかしここで引っ掛かります。サイトAへのログインページです。Facebookに自由にWebページを配置することはできません。このようなシーケンスになります。

いったん、ただのアンカーリンクでサイトAのページを表示します（ページ要求）。そのページはサイトB（ Facebook ）にリダイレクし認証トークンを受け取ります（ 認証要求(1) ）。ブラウザーは再度リダイレクしサイトAに認証要求(2)、めでたくログインとなります。
１．サイトBページ→サイトA（バナー広告のクリック）
２．サイトAページ→サイトB（リダイレクション、認証要求、トークン発行）
３．サイトBページ→サイトA（リダイレクション、認証トークン検証、ログイン成立）
４．サイトAページ

これが本来のOAuthの流れなのですが、業務系の場合は１と２をセットで行い、３へ行くことができます。被認証サイトへのログインページを認証サイトに配置できるとシーケンスを簡略化、認証処理の開発、テストも簡素化できます。高品質、安定稼働で安上がりです。業務サービス、企業向けクラウドの場合はこれが可能です。ちょっとしたことなのですが一考の価値ありです。

もう一つ。これはどうでしょう？

先に結論を言うとクロスサイトスクリプティングなので、そのままでは動きません（動いてはいけません）。サイトAのセッションの間にあるサイトBとのセッション（Javascriptで張られたセッション）が、サイトA以外にトークンを渡しうるからです。サイトCもしくは別のユーザーからこのトークンで認証要求されてもサイトAにはわかりません。なりすましでサイトAにログインできます。

postMessage による制限つきの処理も可能ではあるのですが、リダイレクションのような安全かつ一般的な手法を採用しない理由を説明できません。一見構成も簡単なのですが postMessage は特殊なケースに限定されると思います。
ITの世界は流行り、廃りが速いので変化にロバストであるよう、一般的な要素でシステムを構成、簡素化するよう心がけています。寿命の長いシステムはエンジニアの誇りです。ユースケースに応じた簡素な設計、費用対効果の高いシステムほど長持ちです。

永島志津夫

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

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

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

マルチホーミング

マルチホーミング、わかります？ITの世界でマルチホーミングといえば物理的なネットワークの冗長化です。最近とんと聞かなくなりましたが、可用性確保で案外落とし穴かもしれません。クラウド流行りでエンジニアも希少化しているのではないでしょうか。インフラ担当としてアサインされたら焦りますよね。。

クラウドへのアクセスはアプリケーションプロバイダーの責任範囲から外れるのまずネットワークの冗長化要件が来ることはないのですが、以前は自前でマシンを設置してアクセス回線を手配していたので、冗長化も仕事の範囲でした。

最初に確認することは、NTT以外の幹線が建屋の近くの（道路の下）に来ているかで、来ていれば建屋への引き込みを依頼します。大技で有線回線と無線回線を併用するなんてのもありました。冗長化の趣旨からするとできるだけ異なる特性のものを組み合わせたほうが良いので悪くないアイデアです。

さて難しいのは、なじみの薄いL1,L2レイヤーを意識しないといけない点ですが、現在はフルIPなのでまだましですね。それでもルーターを用意してBGPの設定となると、なかなか手ごわいですね。できればパスしたいです。できるのでしょうか？
ことと場合によると出来ます。負荷分散としても割りと悪くない方式だと思います。概略を紹介します。

フロントウェッブは一般的なクラウドサービスに配置し、アプリケーションサービスを別のサービスサイトから提供することとします。マルチホーミングの対象はサービスサイトのみです。
ネームサーバーに www.***.com （フロント）, svc1.***.com （サービス１）, svc2.***.com （サービス２）の3ホストを登録します。フロントはサービス１、サービス２をタイムアウト付きでコールする javascript を組み込んだページを返します。
もうお分かりですね。サービス１が障害されていれば、タイムアウトしてサービス２にアクセスするという簡単なものです。サービス１のホストが回線A経由で、サービス２のホストが回線B経由でアクセスされます。２つのホストが同一DC内であれば疑似マルチホームで、別々のDCであればDC可用性確保になります。
* サービス１、サービス２のIPアドレスがクラスター共有されていれば元々の定義のマルチホーミングらしくなりますが、やるかどうかはユーザーメリット次第ですね。

何も難しいことはありませんし安上がりですぐに適用できますね。というか、DC可用性確保は基本しておいた方がいいです。有名なクラウドサービスもダウン前提ですから（フロントも複数のホストに配置し、ネームサーバーに登録ですよ）。
タイトルと書きだしを否定するようですが、ルーターでマルチホーミングなんて割りが合いません。ajax のおかげで手軽にサービスレベルを上げることができます。
システム設計は、ユースケース、アーキテクチュア、インフラトータルで見ましょう。

永島志津夫

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

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

システム開発 原価計算・資産計上

以前取り上げた 工事進行基準廃止！ 2021年4月から強制適用の影響いかがでしょうか？分割検収が一つの手ですね。要件定義と設計開発が同時に進むようなアジャイルでは分割検収できないのでウォータフォールに逆戻りしている案件もあるのではないでしょうか。その検収ですが異質なのがAI領域ですね。納品時点では認識率が目標値に達していないことがあります。使い続ければユースケースに最適化されていくことは分かるのですが数値保証はされません。“資産計上していいのか？” 経理部さんを悩ませます。

AI技術を搭載した業務システムが導入され、自社業務・自社データで受入試験開始します。1日目で気付くと思います。“カタログスペックまず出ません”。コンピュータって賢くないです。AIだろうと電卓だろうと同じ、しょせん足し算と条件分岐の組み合わせです。コンピュータにはコンピュータに向いた仕事を定義して、単純ロジックに整理してあげないとエラーが多くて使い物になりません。それがユースケースです。ユースケースを整理できるAIはまだありません。一番面倒なところは人間仕事です。

いったん適切なユースケースが与えられれば、AIシステムは処理データ量・使用時間とともに精度が向上していきます。かな漢字変換（ATOKとか）もそうですが、使うほどにユースケースに最適化されていきます。かな漢字変換も入力効率が上がっていきます。大規模なAIシステムだと経済効果が大きなものになります。当初想定した投資対効果を上回り、めでたしとなるのですが、システムの資産価値はどうでしょうか？ソフトウェアなら5年の減価償却が基本ですね。減価償却ということは費用処理できる訳ですが、使うほどに生産性の向上するソフトで利益圧縮ができるなんて経営側から見れば打ち出の小づちです。本来なら、販管費から一部、資産に振替えていかなければならない気がします。類似するのは製造原価計算の副産物の原価控除でしょうか。

大手鉄鋼メーカーの経理部の方にお聞きしたことがあるのですが、現在の製造原価計算法は鉄鋼製造に由来しているところが少なくないそうです。AIソフトの普及、進展とともに減価償却の逆で資産が年々増える会計処理が制度化されるかもしれません。その際は単純な計上基準であってほしいですね。

ところAIソフトですが、最初からカタログスペックに近い値が出るのは不吉なサインです。自社業務のユースケースを学習させる余地がないからです。他社業務のユースケースで学習飽和したニューラルネットを再学習させるのは難しく、学習量の少ない未熟なニューラルネットを強化する方が容易です。

永島志津夫

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

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

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

湿度75% が 飛沫感染の予防目標か？

時節柄、今回も予防衛生の話題からです。感染という言葉を聞かない日がないくらいですが、ウィルス感染の前段階に “吸着” というプロセスがあります。吸着とは宿主細胞表面にウィルスが安定的に密着した状態です。ウィルスは宿主細胞に自力でたどり着くすべがないので、宿主細胞表面に密着できるかどうかは偶然です。健康な粘膜表面は粘液で覆われているので、ウィルススケールでは三次元の障壁となります。粘膜・粘液保護の弱い部位にウィルスが付着することが吸着を有利にします。吸着できなければ細胞内への 侵入（≒感染）プロセスには進めません。タイトルの通り、湿度75%以上が飛沫感染の予防目標ではないか、というお話（仮説です）。

生まれてから死ぬまでの全ての間、生物は常に微生物、病原体にさらされていますが、免疫システムがバランスを取りながら病原体から身を守っています。免疫システムの複雑さは神経系に例えられるほどで、人間が90年前後生きられるのはこの免疫システムに負うところが大です。過労・睡眠不足は要注意ですが、普段の健康状態に問題がなければ、心配することはないでしょう。心配の精神ストレスの方が考えものです。

予防衛生の一つ、飛沫感染対策です。「インフルエンザってそんなに怖いの？」？の38ページをごらんください。鼻、のど、気管支、肺への付着率と粒子径の関係を調べたものです。大きな飛沫は鼻には付着しますが、肺にはほとんど届きません。粒子が小さくなる程、肺への付着率が上がります。また肺の場合は鼻（鼻腔）よりもはるかに少ないウィルス数で感染が成立するとみられています。肺胞組織の健全性が損なわれている場合はさらに感染率が上がります。コロナに限らず、肺への感染は急速に症状が進みます。注意すべきはこの点です。肺に到達するような微粒子をどう防止するかです。

0.1mmオーダーの飛沫粒子は飛散中の乾燥でマイクロメートルサイズの微粒子になります。乾燥を左右するのは主に湿度で、室温 15-25℃ では、75% 以上の湿度があれば微粒子化までに5秒程かかります。なので飛沫を吸い込んだとしても、微粒子状態ではないので鼻腔で留まるだろうというものです。もちろん鼻呼吸していればですよ。湿度75%というのは東京では6月から10月頃の気候です。体感的には季節風が南風に変わるゴールデンウィークあたりから変化が表われるのではないかとみています。またアンブロキソールという薬が肺・気管支粘膜保護に役立ちます。高齢の方は医師にご相談下さい「生体防御因子群の分泌を促進する塩酸アンブロキソールの 抗インフルエンザ効果」。

飛沫乾燥時間見積（湿度75%、飛散速度3m/s）

縦軸：時間(秒）、横軸：気温（℃）

 飛沫乾燥時間見積（気温20℃、飛散速度3m/s）

縦軸：時間(秒）、横軸：湿度（％）

今年の夏は、換気対策で部屋の空気を入れ替えながらのエアコン使用でしょうか。換気とともに亜熱帯の湿気が部屋に入ってきますが、ドライ運転はしない方がいいですね。蒸し蒸ししたオフィスにいるくらいなら自宅で快適にしていたい訳で、テレワークが定着してしまいそうです。

テレワークは組織を疎結合化し瞬発力発揮に弱くなります。事情はどこも同じで慣れてきたのか、鈍くても文句あまり言われません。一方、自律的で集中力を持続させやすいというメリットは大きいです。こんな騒ぎの最中でもシステムの仕事は減りませんし、生産性も下がっていないようです。テレワーク向きの仕事だったということもあるのでしょうが、AI系は加速している感じもします。システムは人の仕事を機械に置き換えることを目標とするものなので、この勢いで進んだらコロナ騒ぎが落ち着いた後も一部雇用は永久に戻らないでしょう。
機動性、瞬発力を取柄とした人・組織は相対的に順位を下げ、鈍だが、その人・その組織にしかアウトプットできない仕事がニッチを広げていきそうです。
図らずも、社会進化の真っただ中に居合わせてしまったようです。

永島志津夫

追記
　風疹患者数、川崎病患者数が半分程度に減っているようです。予防衛生習慣が広くこのまま定着してくれたら、まさにティールです。

テレワーク 〈コミュニケーション/コラボレーション〉

残念ながら新型コロナウィルス感染まだ落ち着きませんね。2月から3月にかけて気温は上昇しましたが関連性は薄いようでした。感染予防の在宅、テレワークという働き方が広がりつつあり、これを契機に仕事上のコミュニケーション、コラボレーションのあり方も変わっていきそうです。

都内の最新感染動向 （東京都の新型コロナウィルス感染症対策サイト）によると 3/26の

検査陽性者数は50人前後です。普通の風邪症状で終わってしまう人は検査にかからないので東京都トータルでの感染者数、感染率はわかりません。検査は2182人に行われており陽性率は12% 、 8人に1人です（8人に7人は予防的検査か、症状はあるものの別のウィルス・細菌感染の可能性）。検査陽性者の状況をみると累計259人中、死亡5人となっており死亡率は 約 2% となるのですが、そもそも市中肺炎で入院した場合の死亡率は 9% 前後と高いものです。肺炎は日本の死因の第4位で年間約12万人が肺炎で死亡します（東京都健康安全研究センター年報 69巻 ）。重症者15人＋死亡者5人との割合で、死亡率は  5 / (15+5) = 25% ですが、重症の市中肺炎の死亡率が 22% 前後なので特別な数字でありません（市中肺炎患者死亡率ー全日本民医連）。感染率、重症化率が謎のまま不安が広がっています。肺炎について高齢者と喫煙者は要注意ということで、これは新型コロナに限りません。私は幸い気管支炎までで済みましたが、かって子供にとって肺炎は死の病でした。

今回の新型コロナは試練ですが、救いは乳児・小児の症例が少ないことです。もしもインフルエンザのようにも乳児・小児にも重症例をもたらすものであったら、騒ぎは想像を絶するものであったと思います。世間の騒ぎの割には医療現場は静かなもので、この時期にしては内科・小児科の患者さんが非常に少ないのです。インフルエンザの早期終息により日本全体で今シーズン500人以上の命が救われました（前回の投稿）。全国的な予防衛生対策の副次的な成果として小児疾患の川崎病と赤ちゃんに影響を及ぼす風疹が減少することを願っています。

人口1400万人の東京で新型コロナ肺炎の死亡者は現時点で5人です。これを、常態化している通勤過密等から既に高いレベルにあった衛生マナーが一層高められた結果と考えることは楽観的過ぎるでしょうか。あと１ヶ月が勝負のようです。過労厳禁、人混みでは口を閉じていましょう。あと手洗いを忘れずに。接触感染防止に手袋を。

話は変わりますが、テレワークご多分に漏れず私も経験しました。通勤および職場での新型コロナ感染予防を目的としたものですが、通勤がなくなった途端、仕事場として会社は副で、自宅が主という感覚になります。不便を感じつつもこれはこれでいけるとなると、この流れ元に戻せないかもしれません。

不便というのはコミュニケーションです。テレワークは仕事のコミュニケーション、コラボレーションのスタイルを疎結合スタイルに変えますね。いくらツールを使っても同じ職場で近い距離に同僚がいることと同じにはなりませんし、あえて同じようにしなくても良いかと思いました。メリットとデメリットを踏まえスタイルを変えていけば良いと思います。

（テレワークが成立する前提）

・職務能力を持ち社会で自律している人

・人に頼らずこなすことができるタスク

（メリット）

・人の目や雑音、つきあいたくもない雑談もない。人間関係のストレスが減る。

　チャットができるといっても仕事ですからハードルができます。リアルタイムに応じる必要もありません。

・休憩やちょっとした家事をはさむみことで仕事に対する集中力が回復する。

　集中とリラックス、頭を使うことと体を使うことを織り交ぜるのが集中力持続のポイントだといわれます。結果的にテレワークはバランスのとれた時間の使い方ができます。

　個人中心、他人は他人という感じです。

（デメリット）

・自律できないと無為に時間が過ぎるだけになる（人の目がないのでさぼりやすい）

　他人依存的な人には不向きです。

・ライバルや手本となる人を見ることが出来ない。組織ならではの成長圧力がない

　先輩が様子をみて助けることができません。指導には限界があります。
　自律前提＝他律不向きです。またチーム一体で瞬発力発揮も難しいかもしれません。

仕事にもよると思いますが、ITプロジェクトでテレワーク、疎結合型組織で働けるようにようになるのは30代からでしょうか。社会人としてある程度成熟し、専門能力をもち、それを裏付ける経験を語れるレベルでないと難しいと感じました。新型コロナ対策を契機に過密社会の是正に加えて、自律した個人が能力を発揮しやすい世界、他律組織から自律組織への変化が進めばと思います。ティール組織というのでしたっけ？

永島志津夫

データ解析 〈2020年インフルエンザ流行終息！新型コロナはいつ？〉

新型コロナウィルスに関心が集中する一方で、インフルエンザの流行は終息しようとしています。年明け以降、患者数が急激に減少しシーズントータルで例年の半分程度となりそうです。およそ500万人がインフルエンザに罹らず済む見込みです。日本におけるインフルエンザ発症者の死亡率は約1万分の１なので500人の命が救われたに等しいことです。

こちらの患者数推移のグラフをご覧ください。東京都感染症情報センター インフルエンザの流行状況
今シーズンは例年より早く11月頃からインフルエンザの流行が始まりました。しかも、2009年に大流行した新型インフルエンザ AH1N1pdm09 の再流行で、患者数も急激に増加しました。
年末までは感染拡大が心配されていたのですが、年明け以降は急速に患者数が減少したのです。今シーズンの患者数推移が特異であることは、過去の推移との比較でも良くわかるかと思います。
一方、北米では2月時点で2600万人以上が罹患という状況です。AH1N1pdm09の怖さを物語るものです。ではなぜ日本で感染を抑え込むことができたのでしょう？コロナを契機とした予防対策でしょうか？人混みを避けることはインフルエンザに対する確実な予防策です。でもそれだけでしょうか？

暖冬傾向にあったことにも理由を求めることができるかもしれません。空気の乾燥は上気道粘膜を乾燥させ、ウィルス感染の初期フェーズ “細胞への吸着” の可能性を高めます。低温は体力を奪い、感染から発症までの可能性を高めます。

東京のコロナウィルス患者数が人口比で少ないことは気象条件が感染を左右していることを表しているのかもしれません。そうならばこの先の見通しを立てることもできます。もっとも患者が疎らな状況で結論を導くことは難しいです。3月初め現在の都道府県別患者数で、検定にかけられるような無作為抽出性を主張できそうにはありません。報道されているように偶発的な事象が患者発生の原因になっていると考えるほうが自然です（たまたま、あるイベントがあったために○○県では患者が発生したなど）。
予防対策の勝利なのか、天の恵みのおかげなのか、どうも判然としません。例えば次の情報から仮説を立てることはできるでしょうか？
都道府県別情報　インフルエンザ　新型コロナ
インフルエンザと新型コロナの流行に地域的な重なりを見ることはできますが・・難しいですね。

ひょっとしたら来週手掛かりが訪れるかもしれません。
3/9-14の週は千代田区の最低気温は10度を上回る高温予報です(3/4時点の10日予報)。
予報通り高温で推移したとして、東京都のインフルエンザ、新型コロナの新規患者発生数
がどうなるか？貴重なデータが収集できるかもしれません。

時流のテーマを題材に歯切れの悪いデータサイエンス、サイエンスにもなっていないお話しをしてしまいました。ただ実際、データサイエンティストが扱うテーマもこんな感じです。データに走る前に状況、基本理解に努めます。感染症の流行と終息要因の仮説として気温に注目している段階です。機械的に割り振りができるものは既にシステムに組み込まれています。結論を急がない、人間領域ではあえて機械と違う心構えでよいのではないでしょうか。
※週末は薬剤師業務をしており小児科、内科の患者さんと接しております。現場感からこのような投稿を上げた次第です。

永島志津夫

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

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

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

失敗できないプロジェクト 〈急所〉

プロジェクトの “急所” 、一つ挙げるとしたらどこでしょうか？　プロジェクト計画、要件定義、設計、開発、テスト

どれも大切ですが、問題が表に出てくるのは “テスト” ですよね。結合テスト、システムテストでこんな問題が起きることがあります。

１．テストに入れない（プログラム がない！、ファイル、テーブル がない）

２．テストに入れない（テスト仕様書がない！）

３．テストに入れない（環境がない！、時間枠がない）

１番目のケース、まさかそんな！と思われますよね。でも開発の遅れで一部プログラムが揃っていないということは経験があると思います。影響のないところからテストをはじめます。またテストを始めた途端、仕様の取り違えが判明しテストにならない、ということもあるでしょう。結合テスト段階で単体テストのバグが出るというケースです。そもそも取りこぼしでプログラムを作っていなかった、リリース期日の間違え、もあるでしょう。

規模が大きくなる程、この手の初歩的なミスが増えます。

プログラムができるまでは、ドキュメントベースで確認するしかありません。要件定義書、設計書など何百ページもあるドキュメントを目検していく訳なので、ベテランであっても一定割合で、ある、なしレベルのミスが発生します。

発生割合ですが、さすがに全体の10%ということはありませんが、0.1%ということもありません。感覚的に１%はありますね。２%前後はあってもおかしくないと考えておくのが相場です。

結合テストからシステムテストと進むにつれ、ある、なし レベルのミスは全体の足を引っ張ります。影響のおよぶ範囲のテストを止めてしまいます。ミスは避けられません。早い段階で露見させるのが賢い対策です。PM（プロジェクトマネージャ）、PMOの真価は課題対策にあります。

“仮組み”

そこで開発中であっても、週の最後に、出来ている分だけ、ある分だけのプログラムを集め、中途半端なデータベースにつないでしまうのですね。私はよくやりました。ポイントは集めるにあります。

ビルドエラーも出ます。マスターのコード定義もありません。初めは動きません。それでも無いものが分かるので

「来週これは作る予定だよね？」

と確認できます。そこでドキッとします。

「忘れるところでした（本当は、忘れていました）」

というふうに。

アジャイルだと、頻繁にビルドをしているので、ある、なしレベルのミスは防止できますね。限られた時間と集中力を設計開発に回せるのは利点です。

“仮組み” はウォータフォール開発や基幹系システムでもおすすめです。「忘れている」というと、担当者に対する落ち度の指摘です。指摘された方は気分のいいものではありません。指摘する側も、言いたくて言っている訳ではありません（言いづらいです）。人間同士お互いの負の感情はコミュニケーションを阻害します。できれば避けたいものです。

 “仮組み” は「ある」「なし」を見えるようにしています。担当者が「忘れていた」ことに違いはありませんが、指摘は、仮組み環境を経由した間接的なものになります。同じことでも人から直接指摘された時のような負の感情は生じないか弱いものになります。

「見える化」とか「可視化」は問題発見の効率化と合わせて、担当者の前向きな行動や、グループのコミュニケーションを維持する効用があるのではないでしょうか。

“仮組み” 試してみてはいかがでしょうか。

永島志津夫

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