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

システムの設計開発、工数計算をする側のお話です。”見積依頼” とか “提案依頼” の対応、なかなか手間を取ります。それでコンペだったり、価格交渉だったり、使った時間を回収できないこともあります。来ないと困るし、来たら大変だし。だからと言って、おろそかにできません。受注したら責任が発生します。納期、品質を守るにはそれなりのお金が必要で、工数計算間違えていたら大ごとです。その大事な工数計算、この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 (#を@に変えてメールをお願い致します）

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

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

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

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

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

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

永島志津夫

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

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

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

工事進行基準廃止！

“ 2021年4月以降開始の会計年度から工事進行基準廃止（強制適用） ” 大規模なシステムを請負開発している会社（の経理部）さん大変です。いまからソフトランディングできるよう調整かけていると思います。今回はシステム開発、プロジェクト管理を会計、原価管理面から触れたいと思います。

そもそもですがシステム開発の進捗って、計量可能でしょうかね？計量可能だとしたら尺度、単位は何でしょうか？禅問答のようですが、これがシステム開発の進捗把握を困難にしている要因の一つです。答えは工数なのですが、その工数が曲者で、意味ある仕事をした時間、生産的にソフトウェアを生産（設計、開発）した時間です。その中には顧客打ち合わせ、設計書などの資料作成も含まれます。これらが原価計算でいうところの直接労務費になります。他の業界では間接費にあたるものが、ソフトウェアの場合、直接費であり原価のほぼすべてを占めます。ベテランと新人では生産性は桁違いです（もちろん仕事の質、役割の違いもあります）。ベテランといえどもお客様やチームメンバーとのコミュニケーションに難があるとパフォーマンスが落ちます。要員をアサインしていれば工数は日に日に増えていきますが、その通りに進捗している訳ではありません。予定工数（予定原価）と実績工数（実際原価）の乖離が広がるだけです。予定工数の信頼性が失われた時点で、もはや工数は進捗計量の用をなさなくなります。いわゆる炎上です。

経理部の人が聞いたら驚かれるかもしれませんが、経験あるリーダー（プログラマーからのたたき上げ）は、投入工数をあてにしていません。毎週のソースレビューや小規模な動作試験の結果で完成度をざっくり評価しています。機能単位・難易度別に未着手(0%)、着手(10%)、仕掛中(20-60%)、完成検査待ち(70-80%)、検査終了(90%)のようなステータスを置いています。あたかも建物のような構造物のごとく、システムの仕上り具合を目視しています。感覚的に評価することもありますが、メンバーの顔を見ながら話しをしているので、そんなに外れません。ソースレビューはメンバーの実力や弱点が良くわかります。支援のポイントもわかります。その点でもプロジェクトを推進するのにプラスです。
ただし手間がかかりますし、たたき上げのリーダーでなければこのスタイルはとれません。リーダーの仕事、それだけではないですからね、大変です。ですがシステムの品質は確実に向上します。

スクラッチ開発からパッケージソフト導入に時代は変わりました。手間のかけどころも変わったと思います。工事進行基準は廃止していいと思います。こんなことまでやれというのは酷です。完成基準で、受入検査合格、不合格でいいのではないでしょうか。

ただ事業の命運を握るようなシステムは工数で進捗把握をしないでください。目利きをいれて実際の進捗把握を行いつつ、高い品質のシステムを作ってください。

永島志津夫

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

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

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

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

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

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

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

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

永島志津夫

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

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

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

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

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

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

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

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

永島志津夫

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

システムの費用対効果 〈 見積 〉

”見積” ！ みなさん、見積書を見るとき、ドキドキしませんか？ 一体幾らかと。で、恐る恐る見てみる。”え、こんなにかかるの！？” 、となりますよね、だいたい。逆に安過ぎる場合、何かが抜けています。それも非常に重要な何かが。移行とか設定とか、モノだけポンと置かれて後はどうぞです。

複数の会社に見積をお願いして安いところを選ぶ、いわゆる、あいみつ（相見積もり）をすることもあるかと思います。その場合は条件を揃えないといけないので、安直には最初の見積書を他社に見せたりします、名前や金額伏せて。それでも条件ずれます。各社得意なことは入れますが、不得意なことは入れないので。なので、ちゃんとした相見積もりをするには、自分で見積仕様を 文書として書いたほうがいいです。後日、トラブルになったときの証拠にもなりますから。

はじめてだと、どう書いていいかわからない。そもそも何を書けばいいかわからない、自分がわかっていないことが何かもわからない。当然です。職場に教えてくれるひとがいればいいのですが、一人だけだととても無理です。システムの大事なことって参考書ないですから。で、大失敗してしまう。小さな失敗なら繰り返してキャリアの糧になるのですが、大失敗だとキャリア終わってしまいます。
経験値ですが、消費税程度は保険代と考えてアドバイスを受けてください。
出来の悪いシステムに毎年支払う保守費・運用費を考えれば、費用対効果は悪いものではありません。そもそもいい会社紹介できますから。

永島志津夫

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