2020年9月7日月曜日

コンペ提案 〈勝ち抜き〉


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


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

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

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

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

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

永島志津夫

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

2020年9月6日日曜日

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


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


エンジニアはだいたい固定給なので実際原価把握が容易なのに、なぜでしょう?どうも原因はプロジェクト管理にあるようです。プロジェクト管理と原価計算はもちろん別物ですが、一緒にやろうとすると実績原価(標準時間単価×実績時間)でプロジェクト管理して、原価差異を足し引きして財務上の原価を
出しますが、実際原価に戻ってきます(当たり前ですが)。標準原価法を使ったところでプロジェクトを推進するプラスアルファは何もありません。予定原価と実際原価がほぼ一致する業種ならいざ知らず、試験や移行の工数を漏らすレベルで標準原価法を使う意味はありません。プロジェクト計画のリアリティチェックをするだけなのですが、できていないですね・・
EVM(Earned Value Management)という進捗管理法があります。これは予定原価が信頼できる前提ですから、システムの世界ではダブルクエスチョンものです。そもそも信頼できる予定原価計算ができていればプロジェクトは成功を約束されたようなものです。すべて見通している訳ですから。形式的なプロジェクト管理も必要ないでしょう。待っていればQCDいずれも満足のいく結果が得られるます。前にも書きましたが見積、工数計算はシステム設計でも高い習熟度が求められる能力です(システム開発〈見積・工数計算〉)。 要は経験、能力が未達ということで、人材不足なのでしょう。新しい言葉、言語、開発フレームワーク、資源管理・・が出ては消え、出ては消えを繰り返して、本質に切り込めず、周りをまわっているだけのような印象です。予定原価に信頼性がない以上、システム開発の原価計算は実際原価で十分だと思います。

永島志津夫

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

2020年7月23日木曜日

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ですが業務系では頭3文字+スペースキーで候補表示する方が使いいいです。またUIの紹介したいと思います。
永島志津夫

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

2020年7月4日土曜日

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

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

設例)アクセサリーの卸販売を手掛ける企業から、受注業務のシステム化についての見積依頼があった。
出荷配送はサンプル品を除きすべて配送ベンダーに任せており、Webで出荷指示が可能である。ショップからの注文はメール、FAXおよび電話である。FAXが6割、メールが3割、電話が1割で取引先数は 2000件ほどである 
アイテム数はおよそ600、SKUとして3000程度だが、常時入れ変わりがある。オーダーは月平均2000件程度、多いときは5000件、担当者2、3名で平日の営業時間で対応している。 
情報はいったんこれだけだとして、明日までに概算見積が欲しいと言われています。システムの見積できるでしょうか?業界常識など書かれていない与件があるのですが、経験的にはこのシステム ¥5千万から7千万位になるかと思います。もちろん仕事では機能積上げ法の結果と突き合わせます。明日までに概算が欲しいと言われても、¥1千万の見積だしたら大変なことになります。また販売管理パッケージ提案したら物笑いになります。スクラッチです。
このシステム ¥5千万として費用対効果(投資対効果)は見合うでしょうか?2,3名でこなせる業務ですからそのままでは見合いません。同業者と共同利用のような形がとれるなら検討の価値ありです。発注側も見極めが大事です。

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

永島志津夫

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

2020年6月25日木曜日

セキュリティ対策 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 (#を@に変えてメールをお願い致します)

2020年6月21日日曜日

外部認証 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)、めでたくログインとなります。
1.サイトBページ→サイトA(バナー広告のクリック)
2.サイトAページ→サイトB(リダイレクション、認証要求、トークン発行)
3.サイトBページ→サイトA(リダイレクション、認証トークン検証、ログイン成立)
4.サイトAページ

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

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



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

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

永島志津夫

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

2020年6月1日月曜日

マルチホーミング

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


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

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

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

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

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

永島志津夫

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