「SAAS」を含む日記

■リモートワークと組織のあり方

「リモートワークでは生産性が上がらない」という話がホットなようなのでプログラマである自分の経験を書く。

まず「リモートワークでは生産性が上がらない」というのは嘘で、やり方が悪い。

リモートワークを導入するならスタートアップのようなチーム型のフラットな組織ではなく、従来のマネージャが上にいる組織にすべきである。

基本的にはマネージャが中心になってタスクを整理して、分解する。

リモートワークの人にはタスクを渡して次々こなしてもらうと生産性が劇的に上がる。

つまり「考える仕事」ではなく「作業」として仕事をしてもらうのである。

「雑談」や「帰属意識」なんてものは「作業」には不要である。

これをやるために重要なポイントは「*マネージャ*が何を作るか理解して、仕様を決めて、文書にして伝える」ということだ。

「マネージャ」を強調したのには理由がある。自分はプログラマとしていくつかスタートアップを回ったがこれができないマネージャが圧倒的に多い。

このマネージャという立場はプロダクトオーナーでも、テックリードでも、CEOでも誰でもいいが、製品を作るための決定権を持っている人を指している。

もし一人でこなせないなら分担して複数人でやってもよい。

これを伝えると「スタートアップではスピードが重要なのでそんなことできない」「文書化する時間がもったいない」など言われることがある。

そういう人達が何をやってるかというと、自分の考えをまとめることはせず無駄なミーティングを設定してふわっとした状態で人を集めて

資料もろくに用意せずホワイトボードに雑な絵を描きながら説明をして、仕様の矛盾を指摘するとそこまで深く考えてないので意志決定を先送りにしてとりあえずやってみようとなることがほとんどである。

こんなことをやっている人間に「生産性」の本質など理解できないのでさっさとお払い箱にしよう。

また、このタイプの人間の本音としては「自分の考えをまとめて文書化する面倒だからやりたくない」というのがほとんどである。

一方で、リモートワークが向かない仕事もある。

まだ何をやればいいかわからない「種」を育てていくような仕事だったり、顧客とのコミュニケーションが必要な仕事、会社の運営などである。

SaaS なんかも「何を作るか決める」ことについてはリモートより顔を突き合わせた方がいいだろう。一方で、「何を作るか決めた」状態であれば

あとはフルリモートのメンバーに任せれば十分。いくら開発サイクルが速いと言ったって、2週間ぐらいは開発に専念する必要があるはずだ。

もし「1日の中で仕様が変わる」ような会社であれば、それはただただ仕事が雑なだけであってそんなことが頻繁に発生するならさっさと退職すべきである。

件の記事ではリモートワークは「ケースバイケース」「バランス」などアホなことを書いているがそんなことはない。

リモートワークには「向いてる仕事」「向いてない仕事」があるだけで、企業の大小やメンバーの適性は関係ない。

会社全体でリモートワークを導入する、しない、を決めるのはナンセンスなのである。

Permalink | 記事への反応(1) | 15:54

ツイートシェア

■Web業界でエンジニアが転職するときにチェックしたほうがいい点のメモ

求人資料を見るだけじゃなくて、可能な限り、直接面接で聞いたり、中の人に聞いたほうがよい。

Developer Experienceてきなところっすね。

バックエンド系なので、フロントエンドのことはよくわからない。

（給料とかは当然見ると思うので省略）

Windows以外の開発PCを使えるか？

Windowsが悪いという話ではなく、WIndows以外の選択肢（Mac、Linux）を選べるというのが大事。

Windows縛りのところはだいたいろくでもない。

リモートワークができるか？

リモートワークが好きってわけではないんだけど、台風の日とか出社しなくてもいいのはありがたい。

あと、リモートワーク可な職場は、非同期コミュニケーションが発達していて、エンジニアとしての仕事がしやすい可能性が高い。

ASP/SaaSがどの程度使えるか？

例えば、Github Enterpriseじゃなくて、github.comが使える、とか。ASP/SaaSがどの程度使えるか、ってのは、セキュリティがめんどくさいかそうでないかの試金石として有用。

Oracle RACを使っていないか？

Oracle RACを使っているところは経験上、結構がちがちな開発スタイルの可能性が高い。

言語処理系のバージョン、ミドルウェアのバージョン

古いRubyとか、古いMySQLを使い続けている職場は、そもそもあまり技術に関心がない可能性が高い。

エンジニアブログ

エンジニアブログが無いのは論外（いい会社かもだけど、外からはわからん）、あと更新頻度、更新者のプロフィールをちゃんと出してるか、など。

更新者のプロフィールをちゃんと出している会社は、中の人間の対外発表をそれなりに推奨（黙認）していると想像できる。

その他

• kubernetes採用してるかーとか（ぼちぼち普及してるので、フィルタとして使えなくなりそう）
• 使ってる社内wikiで結構文化がわかる。
• 使ってるフレームワークでも文化がわかる。
• Slackは必須。

本気で転職考える時は、他にもみる観点あるけど、1次スクリーニング的なところだとこんな感じ。

Permalink | 記事への反応(0) | 19:51

ツイートシェア

■Microsoft のクラウドが AWS を抜いた記事を見て思うこと

日経のこの記事。

https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05452/

この記事の真偽はともかくとして、反応を見てると AWS のマーケティング戦略に見事にはまった信者の人たちが冷静な見解が出来なくなって炙り出されてきているのが面白い。

AWS にもO365と同じ様な SaaS サービスあるだろうに、シェアが低すぎて普段見えてない分意識できてないんだろう。

そもそもIaaSとかSaaSを意識せずにクラウドを使える様にする、というのは AWS の根本の思想じゃなかったっけ。

ユーザーへの価値提供を忘れて、IaaSだけで勝負しろとか言ってるとそのうち Azure 単体で抜かれるぞ。

Permalink | 記事への反応(0) | 11:05

ツイートシェア

■7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。

昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。

また、会見内で「セキュリティー審査を実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。

セキュリティー審査とは

その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。

「審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。

以後脆弱性診断と記載していきます。

「実施した」とはいっても、どういった内容を実施したかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。

通常、脆弱性診断というと、以下のような項目があげられると思います。

• Webサービス診断
  • 入力フォーム等のXSS
  • SQLインジェクション
  • セッションハイジャック
  • CSRF
  • 画面遷移時のデータ受け渡し
  • レスポンスヘッダ
  • コマンドインジェクション
  • 各CVEのPoC
  • ソースコード診断
• スマホアプリ診断
  • apk、ipaファイル自体の診断
  • ローカルに機密情報を保存するか
• プラットフォーム診断
  • ポートスキャン
  • サーバコンフィグ
  • 権限昇格

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。

ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます。

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。

また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。

規模と見積もり内容にもよりますが、100～200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。

これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。

Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。

ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。

サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。

Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。

パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。

別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。

特定のベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います。

使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。

また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。

・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。

グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。

会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・。

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。

ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題を認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。

そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足→力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているからセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。

貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

ツイートシェア

■技術者(もしくは技術者出身のマネージャー)の殺し方

いわずもなタイトルは釣りです。たぶん、過去に色んな技術者やメディア等で議論されてきたのではないかと思う。自身が今の職場で久しぶりに清々しいくらいに経験しているので、備忘録として状況をできるだけ冷静に書き記すものである。参考になりえるとしたら”現職の状況がヤバイんだけど、どうやって現状打破を目論見ながら最悪のシナリオを想定した逃げ道も確保するか”といったところの考え方くらいかもしれない。それ以上もそれ以下も意味はない。

背景

業界についてはあえてぼやかすが、歴史が長い業界だ。自身が参画したのははじめての業界だ。いろいろと勝手がわからないことはある。業界の歴史が長いからということではないと思うが、業務フローやプロセスが古臭い。逆に私達技術者の活躍の伸び代がまだまだある業界でもあると言える。自社事業（サービス）を持つベンチャーだ。

技術的なことを包括的に担当してほしいということだった。結果的に(他にマネージャがいるのに)ただの人月計算をするおじさんになっている。ベンチャーでそういった担当者がいないのでよくあることだ。

状況

いくつか状況を記載しておく。

状況1 : 期待値のコンテキスト不足、ナレッジマネージメントされていない

やり方はどうでもいいから

当初このように聞いていた。目的が達成されれば、もしくは課題が解決すれば、ということだと思っていた。しかし、そうではない。

この方法以外認めない

という含みがあり、フォーマリティが実はちゃんとある。しかし、そういった期待値のコンテキストが不足しているという状態。そしてすべての事柄について隠しフォーマットがあり、それに準拠しなければならない。なぜならこういった背景だから。というものがしっかりある。個人的にベンチャーやスタートアップでは抜けがちな”背景”がしっかりあるのは良いことがと思うが、後発で加入してきた人に対して明文化されていない状態もあり、自身の役割としてはそういった期待値の明文化をすることも含まれるのではないかと思った。（しかし、そこにそんなにコストかけんなバカってことにもなった）

Web系スタートアップ・ベンチャー界隈ではこういった課題に関しては社内Wiki的なSaaS型サービスで全員で知見を同期的に書き出して意見交換をすることでナレッジ化していくといった手法を取っているところが多い気がする。そしてその行為を”文化形成”などと表現しているところもある。しかし、業界的にはそういった文化にはないためすべてはファイルベースでの情報共有となっている。もちろん、そういった手法で十分なケースもあるのだが、一方的に送りつけておいて”これ読んでおいてください”などとして一切の背景を説明されていないのが現状な訳で、背景が不確実なまま自身の想像力と経験で行動してしまうと業界の常識等の地雷を踏んでしまうことが多々あるのでできるだけ不確実な要素をなくしていくといったことにコストをかけることになる。

前に言ったじゃないですか

となる地雷が沢山あるやつ。スタートアップ・ベンチャーに限定したあるあるみたいだと思われるのも問題なので、一応書いておくと大手でもある。しかし、大手は割としっかり明文化している。その代りそのフォーマットを厳守することを要求されるし、従業員はその制限の中でいかに最高のパフォーマンスを出せるか？というレースになっているという印象。

これは確実に消耗戦になるやつだ。殺しにかかっている。

状況2 : 課題管理

別にWeb系スタートアップ・ベンチャー界隈のやり方にこだわるつもりはないが、課題管理表を管理する工数を取る文化は色んな業界にまだ根強くあると思う。具体的な管理手法としては昨今では一般的なIssueベースなのに結局Excelでやることになる。ただのExcelではなくてWBSという形式で欲しがっているケースが多いのではないかと思う。WBSを引くということはアジャイル的な変動的なスケジュールを持つといった管理方法ではなく、割とFixされたウォーターフォール型に近い考え方がある場合にこういったことが起こりやすいのかもしれない。とは言え、何らかのプロジェクトマネージメントツールを使いたい。そしてこれも確実に消耗戦になるやつだ。殺しにかかっている。

状況3 : SPOF

とにかく割り込みタスクが全員から投げられる。(WBSで欲しがるのに)具体的な優先度や期日もない。下手すれば”何をしてほしい”といったコンテキストもない。すべては投げられた人のMy Wayで処理されることになり、ナレッジマネージメントもおざなりになっているような状況ではスーパー属人化する。こういった状況は”投げられる人が投げる相手がいないからPlaying Manager化していること”が原因でも起こる。人事計画次第では解決できる可能性のある問題ではある。しかし、そういった見通しがない場合はしんどい。これも確実に消耗戦になるやつだ。殺しにかかっている。

まとめ : 確実性と不確実性に切り分け

自身としては”確実性”のある部分については"可能な限り確実に"しておきたい。それは具体的にいうと"今見えてる課題で緊急度が高いもの"の対応だ。これは"確実に飛び越えられるハードル"という意味ではなく、"確実に解決しなければならない課題"という意味だ。もちろん、そういった課題がなぜ緊急性が高いのか？というコンテキストの説明についてはコストをかけて説明しなくてはならない。地道ではあるが方法はそれしかない。しかし、そういったことを経験しておくと”自分の言葉でわかりやすく説明する”といったスキルがつく。そういったスキルが欲しい方にはおすすめする。また、確実に処理したことでかつて不確実だったものの具体性があがることもある。もっと理想を言えば不確実なものの具体性を上げるためにどう確実化していくか？というスケジュールの引き方をしても良いと思う。

問題はメンバーそれぞれのスペシャリティ、経歴、興味、個性がまだわからないことを前提にした説明が必要で”相手が何からわからないのか？”がわからない状態だ、色んな補足情報をゼロから入れながら説明すると物凄いコストになる。かといってあまり上から目線でモノを言ってしまうと後のチームビルディングにおける心理的安全性にも影響するため、嫌がらずできるだけニコニコしながら説明するしかない。これは一種の”信頼貯金”に将来つながってくるものだと思う。

しかし、何事も限度はある。それを自身で見極めないと確実に消耗戦は始まる。殺しにかかってくるのだ。

今後

さて、正直困っている。というか疲れている。

ライフスタイルへの影響度

忙殺されてしまったりするとどうしても以前のライフスタイルや状況と比較することすらできずにいることがある。気をつけたい。ある人は独身かもしれないし、ある人は配偶者も子どもいて育児や家事などのタスクを抱えているかもしれない。自身は家庭の事情もあり家庭運用タスクももっているライフスタイルなので、ワークがライフに侵入してくると大きな問題として認識する。実際に今、そういった状況が起こっている。（もちろん、それなりの待遇の場合は家庭内で調整して検討しても良いとは思うがあくまで運用可能な状態であることは前提である）

そういった判断ができにくい状況にあるということを一度立ち止まって認識するということが大事だ。さもなくば遠慮なく消耗戦に持ち込まれ、殺しにかかってくるのだ。

定時内のパフォーマンスで測る

実際、定時外（邪魔の入らない時間）でのパフォーマンスに大きく依存する状況が続いている。死にたい。体調不良等でリモート勤務にしたときの捗り具合がヤバイ（笑）しかし、本来、定時内のパフォーマンスで自身の力量や限界を測るべきだ。そして無理なことは無理という勇気を持つことも大切だ（自戒）。

https://youtu.be/0sEM3UKuRw4?t=28

あれもこれも含めてオンボーディングコストと見れる可能性

完全に気力・体力との勝負ではあるという前提ではあるが、少し粘ることで状況が外的要因等により改善したりすることもある。内的要因であることが理想的ではあるのだが…そこは自身の気力・体力と相談して”いつまでこの船に乗るか？”を決めていくべきだろう。自身でその状況を変えたい！と思うモチベーティブな人間はその限りではないが、その状態でいられる状況とそうではない状況もあるということは言っておきたい。

代表と合わない

多くのベンチャーの場合、代表の哲学は経営方針や事業方針に深く影響しているというか、そのまんまそれが方針になっている。そして多くの求職者はその”綺麗な上澄みだけを抽出した部分"だけを読んで共感して入社することになる。しかし、入社してみると違うと感じることもある。感じるだけじゃなくて、実際に言っていることから違うこともあるだろう。しかし、それが会社だ。と最近思える程度に大人になった。

それって理念に反してませんか？

みたいなことを言えるなら良いと思うが、言えないならそれはすでに消耗戦の始まりであり、いつでも殺しにかかってこれるヤツだ。

自分が楽しめているか？

正常な判断が困難な場合、こういった指標で評価することにはなる。自身は仕事が好きな方ではあるので割と参考にする。そして、楽しめていない。もちろん、苦しいときもあることは承知の上だが、この状況を具体的に変えていくモチベーションも沸かないのでそれに輪をかけている。これは確実に殺しにかかっている。

まとめ

現実問題として不確実的で抽象度の高いタスクを集中砲火されてしまい、自分で優先順位を決めにくい状態が起こっている。自分の手に余る程度であれば良いが(多少の無理なら許容する)、確実にこのままでは消耗してしまうことは目に見えているので、年末年始や週末を利用して(週末は邪魔な割り込みが入らないから作業しやすいという悪循環にもなっている)自分なりの"働きやすさ"を作ろうと必死だ。しかし、それが自身の限界を超える前に構築できなかった場合、最悪倒れる。その前に転職も見据えた行動を取るべきだろう。ということで行動するしかないので行動している。

おかげさまで既に数社からリファラルで引き合いがある。しかし、こういった状態であることもご存知なため（笑）、あまり良い状況（良い印象を与えることができる状況）とは言えない。迎え入れる側も気力・体力が満たされた状態の人に来てほしいに決まっている。しかし、命辛辛逃げようとしている脱北者みたいな人たちにはそういった余裕がない。それとそういった状況において転職先を正常に判断できない可能性もある。また同じ状況になりやすい。気をつけたい。というか面談のときに”他に聞きたいことはありますか？”というところで聞く質問はそこだと思う。

全てはここに帰するのではないかと思う。

期待値を明文化しろ

さて、生き残れっかな（CV : 野沢雅子）

Permalink | 記事への反応(4) | 10:43

ツイートシェア

■プログラミングの本質はカプセル化・ブラックボックス化

コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。

（わかりづらい数字を人間が理解しやすい英単語に置き換えた）

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間の言語により近い高水準言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと

いったものができた。

（処理の流れをわかりやすくした、構造化、カプセル化）

複数のデータをひとまとめで扱うレコード型や構造体生まれた。

（カプセル化）

コードとデータをまとめて扱うクラスができた。

（カプセル化・抽象化）

アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた

（ブラックボックス化）

複数のクラスやコード、データをひとまとめにするにモジュールができた。

（カプセル化）

プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。

（リモートからの操作、ブラックボック化）

WebAPIでアーキテクチャーを超えての疎結合が進む

（さらなるブラックボックス化）

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

（ブラックボックス化）

CIツールでサーバ数台〜数百台を1人で扱えるようになった

（操作の簡略化）

Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。

（カプセル化、抽象化）

プログラミングとはわかりづらいマシン語を人間にわかりやすくするのが本質。

カプセル化・ブラックボックス化・操作の簡略化は正義。

Permalink | 記事への反応(1) | 11:16

ツイートシェア

■ タレントクラウド とかいう採用管理システム by 採用を考える僕

投稿者の僕は３０代、求職者、けど、現人事

タレントクラウドとかいう業者をご存知ですか？

http://talentcloud.jp/

一応、HR、採用関連の仕事をしている立場として、「胸糞」なので書くことにした。

正直、採用担当をしている僕でも英語は読めるし、「タレントプール」が何を指すのかは理解できる。

タレントクラウド社は、「タレントプール」を主張しているが、提供しているものは、正確には「採用管理システム」である。

無視できなくもない、どうでもいい規模の業者である。

ただ、彼らが「タレントプール」なる領域を主張し、競合が少ないために、第一人者面していることが胸糞である。

ぼくは、某HR領域において小さくはない企業の採用管理システムの利用者である。

それなりに満足しているし、特に月1で訪問してくれるセールスマンによるサポートには頭が上がらない。

もちろん、採用について考える身ゆえに、「タレントプール」というキーワードには飛びついたが、

タレントクラウド社が、提供しているサービスに失望した経験がある。残念ながら、問い合わせをする前にサービスの至らなさにに気づいてしまった。

それは、ただの「採用管理システム」であり、あたかも他採用管理システムとの差別化を図るためだけに「タレントプール」というワードを用いているからだ。

間違いなく、そこに本質性は感じないし、様々なメディアに露出しては、ただ「タレントプール」の概念を語るだけ。

僕も、利用している採用管理システムの提供社の人間と差異点を探してみたが、目新しい点はなかったように思える。

色々と発信されているが、多くが間違っている。

アメリカ人が見たら笑いにつながるレベルだ。

特に、この動画は失笑ものだろう。

動画では、マッチングサイトを主張している。

https://www.youtube.com/watch?v=OqOfEhVtusg

もはや、マッチングサイトなのか、採用管理システムなのか、よくわからない。

少なくとも、タレントプールではないのかなと思う。

これを取り上げるメディアもメディアだが、元はサービス側の問題。

是非とも、同じ立場の採用担当者は気をつけてほしい。

追記：talent cloudというのがマッチングサイトで、

talent cloud saasというのが採用管理システムみたいだ

どちらもタレントコミュニティでもなければ、タレントプールでもない。もはや詐欺、アホらしいことだ

Permalink | 記事への反応(1) | 13:33

ツイートシェア

■コインチェック事件はWebエンジニアとSIerの融合の幕開けかもしれない

　Webサイトと技術の高度化

Webでは単純にテキストサイトではない本当に色々なことができるようになってきた。

HTML5になって以降まさに飛ぶ鳥を落とす勢いだ。

ここ５年くらいでデスクトップアプリに負けないレベルのSaasも出てきた。

Slack、Youtubeや生放送、Googleドキュメント、Google mapをカーナビ代わりにしている人もいる。

Javascriptも相変わらず日進月歩でTypescriptやらNodejsやらReactやらVue.js Three.jsなど、もうテキストサイトの付属品ではないことは明らかだ。

個人的にはWebGLでアプレットを使わず3Dの描画ができるようになったのは衝撃的だった。

　コインチェックで露呈したWebエンジニアの弱点

そんなわけで、Webはどんどん急激に高度化し大規模化してきている。

ここまで大規模化していったシステムはセキュリティ的にもシステム的にもこれまでのような少数のチームがちまちま作るには手に負えない状況に来ているんじゃないかと思う。

それが表面化してしまった事件が今回のコインチェック事件ではないか。

コインチェックはおそらくWeb系のエンジニア主体でイケイケで開発したんだと思われる。

デザインはハイセンスでUXも洗練されてる感じがする。

ただセキュリティが甘かった、つまりシステムとしてセキュリティ（内面）に問題があった。

これはまさにWebエンジニアの弱いところを突かれたといっても過言ではない。

　WebエンジニアのSIer化

それに伴ってWeb企業もSIer化していくんじゃないかというのが私の持論。

全てとは言わないが、これまでのWeb系エンジニアの開発スタイルはどちらかというとイケイケドンドンでできたらいいや使えたらいいやの精神でやってきたんじゃないか。

これでは大規模なシステムになるとセキュリティも保守も難しくなってくるだろう。

大規模なシステムはきちんとオブジェクト指向で作ってテスト駆動でウォーターフォール式で開発するのが筋ってものだ。長期的な目で見れば理にかなっている。

今後高度化していくWebに対応するためにはそうやって作っていくべきだろうし、自然にそうなっていくだろう。

大規模なサービスに関わるWebエンジニアは自然にSIer的になっていくんじゃないか。

Googleスライドとかスプレッドシートはヤバいくらい複雑なシステムだと思うしハイクオリティだとおもうんだけど、どんな開発体制で作られたんだろうか気になる。

Permalink | 記事への反応(0) | 18:22

ツイートシェア

■anond:20180112155945

すごいね アソコが あんな風に そそり立つなんて SaaS

Permalink | 記事への反応(0) | 16:20

ツイートシェア

■働き方改革は労働者へのパターナリズム

2013年に安倍晋三が総理に就いた後、アベノミクスと呼ばれる大規模な金融緩和と機動的な財政出動によって、名目GDPは47兆円増加した。2017年第一四半期の経済成長は年率で2.2%と、潜在成長力の0.7%を大きく超えている。失業率も2.8%まで下がり、ほぼ完全雇用状態だ。20年間のデフレによる経済停滞で錆付いていたギアが徐々に回りつつある。ここ数年の日本の経済政策は成功を収めつつある。しかし、アベノミクス第2弾の中心にある働き方改革は成功しそうもない。

1.働き方が問題？

そもそも長期的な成長力を示す潜在成長力は、土地、労働力、資本ストック、生産性の上昇率からなる。日本は人口減少社会に突入しているので、土地、労働力、資本（人口減社会に投資が集まらない）は停滞かダウントレンドにある。つまり成長戦略には、生産性を軸にするのは極めて正しい。ここで、具体的な課題として取り上げられてるのは、以下の問題だ。

a.正規と非正規の処遇の差（同一労働同一賃金）

b.長時間労働

c.単線的なキャリアパス

お分りだろうか？働き方改革は、日本の生産性の低さを主にミクロな労働の現場に帰責している。例えば、人も金も突っ込んでいるのに儲からないのは、社員が身分制のように正社員とパートに分かれており、テキパキ働かず、無駄な残業をし、ずっと同じ会社に勤めているからだという話だ。スタートアップが「日本の生産性を上げたい」など言い、単なるSaaSを提供するのとノリは近い。

2.日本のテキパキ度と生産性

実は日本の労働時間は、「24時間働けますか？」と言っていたバブル時代と比べても20%ほど減少している。つまり20年間経済停滞したものの、単位時間あたりの付加価値は上がっている（テキパキ度上昇）。しかし、OECDの生産性ランキングは落ち続けている。生産性は購買力平価ベースのGDPを就労人口で割って出す。つまり分子の売上が一定なら、いくらテキパキ働いたところで全く影響がない。有名な話だが、日本の祝日は16日あり諸外国よりも多い。テキパキ働き、休みを取らせることを強制すると、使用者の労働コストが上昇するので、結果的に給与が減額されるのを恐れたサラリーマンは有給を取らないどころか、休日返上で働き出す（パソコンの電源を切って働く、退勤打刻をした後に働くなど）。結局、今の労働環境の延長線上にある光景ではないだろうか。※もちろん、労働法的な論点も重要だが、成長戦略とは別途取り扱うべきだ。

3.責任があるのは雇用者と産業政策

当たり前だが、高い生産性というのは、同じ労働力でも、より高い付加価値を生み出す。つまりビジネスモデルの問題で、ここで帰責されるべきは、個々の労働者ではなく、労働集約的なビジネスモデルを維持している雇用者と、うまく生産性で競争する環境やチャレンジを促進するセーフティネットを用意できない行政にある。マクロ的な（ケインズ的な意味ではなく）産業育成構造に問題があるのに、ミクロの労働者に責任を転嫁してきたのが、バブル崩壊以降の日本の現場だ。ワークライフバランスの議論は定期的に盛り上がり、クールビスだの、プレミアムフライデーだの国辱的な施策が残る。日本人ビジネマンは自分で着るものも、働く時間も自分で管理できない。そのような古い産業を残しているのは誰？

何故、このような労働者に帰責する生産性議論が延々と続くのかと言うと、政労使に、社会を変えるインセンティブがないからだ。

政治家:大企業との繋がりが深く、新興企業との競争を促進することが難しい。労働者に飴を与えれば票が入る。

労働者:企業の中にいるうちは、新たな競争に晒されることを望まない。労働時間短縮の飴がもらえる。

使用者:略

これでは、全く自浄作用が働かない。

興味のある方はこちらもどうぞ。

「不安な個人、立ちすくむ国家」違和感の正体

http://anond.hatelabo.jp/20170521174022

Permalink | 記事への反応(1) | 11:15

ツイートシェア

■コメ率の低いはてブエントリは英語とエロか?

http://anond.hatelabo.jp/20170305115905 を増田以外のホットエントリで見ると。

2017年2月コメント率の低いホットエントリ

Python、データベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。

2017年2月コメント率の高いホットエントリ

Permalink | 記事への反応(1) | 17:20

ツイートシェア

■http://anond.hatelabo.jp/20170127092557

俺はどんなクソジジイにも敬意は払うし、幼稚園児のお遊戯を頭ごなしに否定するような真似もしない。

• ウェブ・アプリを作ってファンやフォロワーを増やす。それから価値ある課金サービスを生み出す。
• ローカルビジネスを支援するウェブ・ビジネスを始める。
• プログラミングのノウハウと、元からあるSaaS APIの知識を組み合わせてニッチなコミュニティー向けのサーヴィスを作る。

これを読む限りプログラミングの守備範囲とか限界とかわかってないし、魔法か何かと勘違いしてるし、アイディアとしては特に面白くも無いし、明確なビジョンがあるわけでもなく、お堅く儲けられそうもない。

ワナビーがザッカーバーグとか見て陥りがちな夢物語というのもわかる。

でも老い先短いんだから、酒やたばこももう許すから、プログラミングも許してやる。

Permalink | 記事への反応(0) | 09:45

ツイートシェア

■[開発プロセス] ウォーターフォールのメリット

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。

各種記事

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。

日本でアジャイルが流行らない理由

http://ledsun.hatenablog.com/entry/2016/06/21/102501

「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。

ウォーターフォール型開発プロセスの有効性

http://ledsun.hatenablog.com/entry/2016/06/21/102501

タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。

最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。

ウォーターフォールとアジャイルを考える

http://arclamp.hatenablog.com/entry/2016/06/23/172941

冒頭，

まず、「ウォーターフォールは何のメリットも無い」は嘘です。何のメリットもないものが存在するわけないので。

とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。

ウォーターフォールのメリット

ではウォーターフォールのメリットは何なのか？

それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。

この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。

さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。

答は

「納期 and/or コストがぶれるリスクを小さくできる」

である。

すごく当たり前のことなのだが，これが書かれている記事が見当たらない。

そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。

やはりウォーターフォールにはメリットなどほとんどなかった

ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。

よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。

そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。

「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」

これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。

その結果，これまでどんなことが起きてきたか。

あくまで変更を行わなかった場合

開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。

「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。

禁を破って変更を行った場合

これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。

最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。

そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。

うまくいくのは非常に限られた条件が成立する場合のみ

スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。

もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。

アジャイルは銀の弾丸ではない

ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。

そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。

アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。

1. スコープの変化がありうることを前提としている

2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる

この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。

また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。

もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。

もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。

契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。

Permalink | 記事への反応(0) | 21:53

ツイートシェア

■anond:20160426145507 の続き

anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)

「普通の実装における」OAuth の代替品

適切な OAuth ベースの設計とはどのようなものか

ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

• ユーザが自分のアカウントに直接アクセストークンを生成できるようになっており、そのトークンを自分の統合したいソフトウェアに自分で施すことができるので、ばかげた要求や危険な転送やリダイレクトを回避できる。
• client_secret が、一般的なパスワードのように平文のまま渡されるデータとして機能するのではなく、それ自体では暗号学的な共通鍵であり、そこから認証コードを生成するようになっているシステムなので、ばかげた要求や危険な転送やリダイレクトを回避できる。この種のシステムでは一般的に、ユーザが自分の認証情報さえ持っておらず、SSO (シングル・サインオン) の仕組みを使うだけである。

とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。

Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。

ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。

JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。

これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

Permalink | 記事への反応(2) | 15:03

ツイートシェア

■anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイト・リクエスト・フォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。

OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。

章のまとめ

セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。

OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。

ユーザビリティ関連

(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)

(略: オープンソースにしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認

Permalink | 記事への反応(2) | 14:55

ツイートシェア

■さらばSIer、オレは逃げるぜ

さらばSIer

転職しました

数年前にこの日記と同じようなタイトルを書いた増田がいたなぁ

その人はソシャゲ業界に行っていたが元気かな？

それはおいといて、本来なら投稿を自分のブログやTwitterでかきたいところだが、キャリアポルノっぽいからモザイク付きでここで書くぜ。

そろそろ8年位いたSIerからおさらばする。

自分が入社した頃からSIer崩壊論は提唱されてきたけれども、今後業界が生き残るにしてもどっちでも有意義な業界にはならないだろう。

自分も腐っていくだろうし、だから辞めた。

数年前、社長がしたり顔で「これからはクラウド（時期によっては、ビッグデータ、SaaS、IoT、etc...）などの従来の開発にはない高付加価値を！！そのためには社員には技術力を今よりも更に磨いてほしい」みたいな話を会議でしていた。

受託開発でお客さんのいうとおりに作って保守しても身になりづらいし、複雑化して保守もお金がかかる。 お客も楽して僕らも楽してWINWIN!!クラウドサイコー

みたいな話を毎回似たようにするわけだ。

ありがたい言葉いただきました。

さぁ、その高付加価値ってのはなにをしたのか？

「これからは○○っていうパッケージ（フレームワーク、製品）を売って短い間に開発をして、サービス化していくぞ！」

どこぞの会社から買ってきたか提携を結んで、俺達は”設定”をするだけでシステムを売る。もしくは出来上がっているシステムを従量課金で貸す。そんな仕組みで儲けようと考えている。

ビッグデータも高名な大企業様の製品を”設定”して統計をすることで売っていこうとしている

技術力：それらの製品の設定力

なんだよ設定力ばっかり求めやがって！

モノを早く多く売って客を喜ばせるってのは分かる。

でも道をまちがっちゃーいませんか？

営業力に力を入れて技術者は外注任せにしようとして、じゃあ俺達は何屋なんだよ。 設定屋か？

そんなの技術じゃないし、

よく分かんないパッケージ買ってきては、社内で使ってみては社員は使いづれーって思っていて、売ろうとしてる奴使ったことあるの？これユーザー欲しがる？

関連会社に開発やってもらって、コアコンピタンスないじゃない。

なにが良いものか分からなくなっちゃうんじゃないの？

高付加価値高級料理店

ウェイターだけの高級レストランみたいなもんだ。

このレストランはウェイターだけだけど、お客さんの要望に素早く答えることができる。

ウェイターはメニューになにがあるか、膨大な量の項目を知っているんだ。

でも、そのレストランには料理人は居ない。

お客様の食べたいものをレンジでチンして出せるならそうする。

でも食べたいものを要望どおり出すのも標榜しているから、メニューをアレンジしたり新しく作ることも承る。

だが、「今日のこのワインに会う美味しい白身魚の料理がほしい」とかいうお話は出来ない。ウェイター味も料理も分からない。

だから「予算と、どれくらいで出して欲しいか、それからどういう材料が入って欲しいか決めてくれ」とお客さんに言っちゃうんだ。

しょうがないよねお客さん至上主義だから。

さて注文ができたら、別のレストランから料理人を借りるんだ。

シェフ、つまり厨房を統括するポジションはなぜかウェイターなんだよな。シェフ兼ウェイターなんだ。

料理できないけどシェフなんだ。

シェフは臨時の料理人を集めて料理を作る。

そして出す。

でも、ワインにあう美味しい白身魚とは程遠かった。

お客さんはグルメでも料理のプロじゃない。 要望はあっても要件は決められないんだ。

ウェイターシェフは料理の種類のプロでも、なぜか料理のプロじゃない。

要件は決められてもそれが美味しいか、作れるか、分からないんだな。

料理人は、料理を作れる。だけれどもシェフの要望通りにしか出せない。

そもそも安い賃金だし、そんなに頑張っても報われないし

その高級料理店はブランドのちからはあったけれど、安くするとピントのずれた料理しか来ないし、本当に美味しいものを客が食べるには相当な金と時間をかけなければならない。

ところが、料理人が直接安いけどそれなりに美味しい店を出すようになった。

グルメな客は、安いけど旨いしということでそっちに行くようになった。

そのうち、高級料理店の方はレンチン料理しかでないことになり、

料理人が出した店はお客さんの要望に100%合わせた豪華な時間のかかる料理は出せないけれど、

料理人のこだわりが出ていてそれはそれで美味しということで、お客が高付加価値高級料理店から離れて行きました。

Permalink | 記事への反応(0) | 00:31

ツイートシェア

■http://anond.hatelabo.jp/20140715183518

これまであまりコードレビューしてなくて、最近はコードレビュー頻繁にやるようになった。修正もさせてる、ちょっとづつよくなってるけど、まだ日々新しい発見してるとこ。

請負受託開発とかじゃなくて自社開発のB2B SaaS(オフショアへの開発委託だけど)だけど、教育しつつ長い目で見ればよいって思ってるけど、せっかく自社サービスなのにコードがかけないと思うと恨めしい。

うん。自社開発のサービスで俺プログラマーだとおもってるのに、コードかけないのが恨めしいんだよ。

Permalink | 記事への反応(2) | 19:24

ツイートシェア

■http://anond.hatelabo.jp/20140121224740

それの現実解がSaaSなんじゃねーの？

Permalink | 記事への反応(0) | 01:22

ツイートシェア

■もう婚活なんてしない

スペック

性別：男、年齢：30中盤、年収：中の上or上の下、見た目：中の上or上の下（たぶん）

周りの結婚ラッシュもとうに終わって、facebookに嫁と子供二人と仲良く家族サービスなんて写真がバンバン載るのに焦りを覚えて、友達に紹介してもらったり合コンしたりホームパーティに行ったり商業ベースの婚活サービスや出会い系パーティーにも首を突っ込んでみた。

でも、結局のところ、結婚する意義を見い出せない、ってかそんな意義をすっ飛ばしてくれる程にときめきがなかった。

結婚を前提に女の子を見てしまうと、どうしても減点法になりがちで、会って食事をしたりする最中でも、まるで採用面接みたいな妙な緊張感が走る。

それは向こうにとっても同じで、一見すると楽しい会話に見えるが、お互いがお互いを品定めしている感じがどうしても付きまとう。

そんな状況をすっ飛ばしてくれるのがときめきだと思っていたが、ここまで冷静に歳を重ねると、そりゃときめきのハードルも上がるというもの。

さて、振り返って何で自分は結婚したい、いやしなきゃと思ったのだろうか。

それを就活の自己分析のノリでやってみたら、結局行き着くのは・・・”他の人がしているから”

facebookに溢れる同世代の家庭生活の幸せな部分だけを毎日毎日見るたびに、ある種の洗脳状態になっていたのかもしれない。

試しにfacebookを見るのをやめたら、もともと職場はプライベートな領域に突っ込まない環境なので、結果としてその結婚に対する妙な焦りが少し和らいだ。

数年前の仕事に趣味に社会に友達に自己に、好きなものに対して純粋に向き合える自分を取り戻した気さえする。

そして、この他の人との横並び意識から来る結婚への焦りは、今後どんどん結婚する人が少なくなるにつれて、和らいでくるのではないかという期待がある。

結婚はみんながするものではなく、大部分はするけどしない人も一部はいる・・・ちょうど自動車の免許証の様な位置づけになっていくのではないか？

そうなると、独身者をターゲットにしたビジネスの多様性が生まれ、結婚したのと同じような幸せ感が得られるサービスも今後多く出てくることだろう。

帰って来たら「お帰りなさいアナタ！ご飯にする？お風呂にする？それともア・タ・シ？」といった訪問型家事支援＆風俗サービスや、休日に子役タレントのような子供を独身者に対して派遣して幸せな家族の一日を体験出来るサービス・・・そんな、ありとあらゆる独身者のコンプレックスを解消するサービスの出現が考えられる。

思えば、時代は持ち家から賃貸へ、ネットの世界も自前サーバを構築運用するSIから必要な時に必要なだけサービスを使うASP、SaaSの時代へ確実にシフトしているだけに、少なくとも30年以上は運用の義務が課せられる結婚というサービス形態は、今のSaaS時代にはそぐわないのではないか？

あと10年経って同世代が結婚生活の厳しい現実に直面している頃に、自分は仕事に疲れたら新婚サービスで若くてフレッシュな嫁と甘い夜を過ごし、お盆休みには子供レンタルサービスを活用してキャンプで幸せ家庭体験でもしているのだろう。

その時、世の中はどちらを幸せとジャッジするのだろうか・・・。

と、こんな腐りきった考え方に至ってしまった自分にときめきが訪れるか、もしくは弾丸論破されるか、どちらにせよ、もう婚活なんてしないなんて言わないよ絶対と言える日がまたやってくることを心の奥底では真に願っている。

Permalink | 記事への反応(6) | 21:17

ツイートシェア

■http://anond.hatelabo.jp/20120403180843

ITだ！　コンピュータだ！　SaaSだ！　クラウドだ！！

って声高に叫ぶくせに、本社は東京。大量の紙の書類。集まるだけの会議。

Permalink | 記事への反応(0) | 18:24

ツイートシェア

■クラウドは、語義の派生を追いながら理解するとわかりやすいと思う

http://anond.hatelabo.jp/20100518115813

「ネット上の超強力コンピュータを使いたいときだけちょっと貸してもらうサービス」

それは一般的にASP（≒SaaS）とかPaaSとかIaaSとか呼ばれるサービス形態で、クラウドの説明としてはちょっと違います。

だけど、クラウドコンピューティングの代表格としてそういう「ネット上の超強力コンピュータを使いたいときだけちょっと貸してもらうサービス」が流行しているので、たしかにそう思えなくもない。

多義的な感じになってしまった「クラウド」を理解するために、ルーツから追ってみましょう。

まず最初に、インターネットは2点間の通信をするための道具であることを思い起こしましょう。国際電話網と同じです。A地点から、B地点を指定して通信するもの。

Webサイトでサービスを受けるときには、ドメイン名をかぶせたURLを使うので実際のIPアドレスは意識しませんが、それでもA-B間の通信であるのは基本でした。

しかしGoogleだAmazonだといった超大規模サービスになると、もうどれだけ強力なサーバにどれだけ太い回線でもリクエストを裁ききれるわけありません。世界中にサーバを置き、同じ「google.com」でもたくさんある中の最寄りのサーバに導かれてそこでリクエスト受け付けてもらうのが当たり前になります。

すると、「google.comサーバと通信する」という意味は薄れます。どれでもいいからgoogle.comの用意しているサーバに要求を処理してもらう……どういう構成かは知らないけどgoogle.comというサービスに要求を処理してもらう、と言う状態になります。

こうなるともはやA-B地点の通信の意味はなくなり、A-（構成はよくわからない分散したサービス）という関係になりました。この「（構成はよくわからない分散したサービス）」が「雲（クラウド）」です。

その後、GoogleもAmazonも、自社で構築した分散サーバ群を外部に提供し始めました。これを利用すれば誰でも、世界中に分散したサーバでクラウドなWebアプリケーションを提供できるようになります。

GAEもAWSも、「クラウドなWebアプリケーションを実現するサーバ群を利用させてくれるサービス」で、これを極端に略して「クラウド」などと呼ぶことがあります（ニフティクラウドとか）。でもこれらサーバの時間貸しは最初に書いたとおり、あくまでIaaSやPaaSであるわけです。

Permalink | 記事への反応(1) | 12:45

ツイートシェア

■行政の「クラウド化」は成功するか？

更新：6月22日 10:10

ビジネス：最新ニュース

行政の「クラウド化」は成功するか？

　昨年来、日本のＩＴ業界ではクラウド・コンピューティングがブームになっている。最近は短縮して単に「クラウド」と呼ばれることも多いようだ。そして、この業界ではよくあることだが、クラウド・コンピューティングについて、コンセンサスのとれた定義はない。

クラウドの定義

　しかしそれでは議論が進まないので、まずはマッキンゼーが発表した"Clearing the air on cloud computing"という資料におけるクラウドの定義を引用するところから始めよう。大企業でのクラウド利用に懐疑的な見方を示したことで、話題になったリポートだ。

　これによれば、クラウドとは「以下の条件を満たす、情報処理（コンピューティング）、ネットワーク、記憶装置（ストレージ）を提供するハードウエアベースのサービス」である。

1. 利用者にとって、ハードウエアの取り扱い（管理）が、高度に抽象化されている

2. 利用者は、インフラのコストを経費として支払う

3. インフラに、非常に柔軟性がある（スケーラビリティーがある）

　クラウドと聞いて誰もが思い浮かべるのは、アマゾンが行っている、ネット経由でコンピューティング機能を提供する「ＥＣ２」や、同じくストレージを提供する「Ｓ３」といったサービス、あるいはウェブアプリケーション開発キットを提供する「Google App Engine」などだ。これらは上記の定義を満たしている。ユーザーは簡単に仮想サーバーや仮想ストレージをインターネット上に持つことができ、そのコストは使用量に応じて課金されるのが普通で、企業会計の中では経費として処理される。また、スケーラビリティーがあるので必要に応じてリソースを増やすことも減らすことも簡単かつスピーディーにできる。

クラウドの効用

　クラウドがこれだけ話題になるのは、やはり多様な効用があるからだ。

　まず、使いたい時にすぐに利用できる。ハードウエアやソフトウエアの調達は必要ない。ネットワークへの接続や各種環境設定などの作業も不要である。試験的なシステム構築も容易で、使えないと分かればすぐに止めることも可能。費用は、コンピューティング機能やストレージなどのリソースを使った量に応じて課金され、会計上は経費として処理でき、バランスシート上の資産が増えることがない。スケーラビリティーも高い。そもそもインターネットの“あちら側”にあるため、関係者でデータなどを共有することも容易である。

　さらに、運用業務から解放される。内部統制やコンプライアンス（法令順守）強化の流れを考えると、利用するサービスが十分信頼できるものであれば、これはメリットが大きい。

　特に中小、中堅企業にとっては、クラウドの持つ機能や信頼性、情報セキュリティーレベルは自社システムより優れていることが多い。信頼性や情報セキュリティーに対するユーザーの懸念は、クラウド普及の障害になると考える人が多いようだが、実際には追い風になるだろう。

　こうしてクラウドの効用を並べてみると、企業規模が小さい企業ほどメリットが大きいことがわかる。そこで登場するのが、「プライベート・クラウド」である。

プライベート・クラウド

　プライベート・クラウドとは、ＥＣ２やGoogle App Engineのような「パブリック・クラウド」とは異なり、一つの企業や組織の中に閉じたクラウドである。従って、そのコストはすべてその企業や組織が支払うことになる。

　たとえば、米国防総省の国防情報システム局（DISA）が保有する「RACE (Rapid Access Computing Environment)」は、国防総省内部向けのクラウドであり、関係者以外は利用できない。実際に構築したのはヒューレット・パッカードであるが、その構築費用も国防総省が負担している。

　したがってプライベート・クラウドは、最初に挙げたクラウドの定義のすべてを満たさない。つまり、条件の１と３（バーチャルなサーバーを簡単に構築でき、その規模を自由に変更できること）は満たすのだが、２の条件（コストを経費として支払うこと）を満たさない。

　最初に挙げたクラウドの定義を正しいとするならば、プライベート・クラウドはクラウドではないことになる。

　当然、クラウドのメリットであるはずの「使えないと分かればすぐに止めることも可能」「費用はリソースを使った量に応じて課金」「会計上は経費として処理でき、バランスシート上の資産が増えることがない」「リソースを増強することも縮小することも簡単にできる」というわけにはいかない。

　もちろん、その組織内の個人や一部局は、クラウドの持ついくつかのメリットは享受できる。使いたいときにすぐに使うことができるだろうし、スケーラビリティーも高い。しかし、組織全体で見た場合にはクラウドのメリットの多くの部分は消滅する。

　そう考えると、プライベート・クラウドは、仮想化技術を利用したサーバー統合だと考えた方がよいのではないだろうか。

霞が関クラウドと自治体クラウド

　さて、2009年度の補正予算には、電子行政クラウドの推進という項目がある。この中に、霞が関クラウドと自治体クラウドの構築が含まれている。これはそれぞれ、政府のプライベート・クラウド、地方自治体のプライベート・クラウドである。

　当然のことながら、パブリック・クラウドのように「使えないと分かればすぐ止めること」はできないし、「費用は使った分だけ支払う」わけにもいかない（自治体クラウドについては、各自治体に利用量に応じて課金する方法も考えられるが、利用率が低い場合には、徴収できる利用料が運用コストを下回ることになってしまう）。

　ただ電子行政クラウドにもメリットがないわけではない。分散されたサーバーを統合すれば、コンピューターリソースの利用効率を高めることが可能になるし、運用コストを削減できるだろう。また、自治体クラウドを利用して市町村や都道府県の業務システムをSaaS（ネット経由でソフトウエアを提供）化できれば、大幅なコスト削減も可能になる。

　「うちの自治体は隣の自治体と業務のやり方が違うので同じシステムでは処理できない」という話を地方自治体の関係者から聞くことが多いが、優れたSaaSはそれぞれの組織や業務プロセスに合わせてデータの構成はもちろん、ワークフロー、業務プロセスをカスタマイズできる。そうした仕組みを取り入れた自治体向けSaaSを開発すれば、間違いなく自治体の情報処理コストは大幅に削減できる。

　問題は、それを実現できるかにある。中央官庁のサーバー統合にしても、自治体向けSaaSにしても、机上の計算では、投資に見合う十分なコスト削減効果をはじき出すことはできるだろう。しかし、一歩誤れば稼働率が上がらず、税金の無駄遣いだと非難されることにもなりかねない。

民間による電子行政クラウド構築

　そこで提案なのだが、電子行政クラウド構築のリスクを民間企業に委ねてはどうだろう。政府が構築するのではなく、民間企業が霞が関クラウドや自治体クラウドを構築し、各府省、自治体にサービスを提供する。もちろん、利用者である各府省や自治体からは利用量に応じた料金を徴収する。当初の構築費用については補正予算を使ってもよいが、数年間で国庫に返納してもらう仕組みにする。

　利用料金は、ある一定の利用率で採算が取れるように設定する。つまり、利用率が予定以上になればその民間企業は大きな利益を得ることになるが、そうでないと損失を被ってしまう。

　つまり、政府や自治体のプライベート・クラウドにするのではなく、政府や自治体をユーザーとするパブリック・クラウドにするという発想である。こういう仕組みにすれば、構築を担当する企業は知恵を絞り、多くのユーザーを獲得しようと使い勝手のよい電子行政クラウドを構築するのではないだろうか。

このコラムは日経デジタルコアによって企画・編集されています。

ご意見・問い合わせは同事務局あてにお願いします。

[2009年6月22日]

Permalink | 記事への反応(0) | 16:23

ツイートシェア

■本格始動する霞が関・自治体クラウドの課題

本格始動する霞が関・自治体クラウドの課題

総務省が掲げる霞が関・自治体クラウドの計画が本格的に動き始めた。同省は2009年8月10日、「政府情報システムの整備の在り方に関する研究会」の中間取りまとめを公表した（資料はこちら）。これは、2015年の本格稼働をターゲットとして、府省の情報システムの将来像を描いたものだ。これによると、現在は府省ごとでバラバラに構築・運用している情報システムのうち、共用可能なものを霞が関WAN内のデータセンターに集約する。その際に、基盤となる「政府共通プラットフォーム」を開発。この上でアプリケーションをSaaS（ソフトウエア・アズ・ア・サービス）形式で利用する。政府共通プラットフォームには、府省間で共通利用するデータを連携する機能も含まれる（図1）。この政府版プライベート・クラウドが、霞が関クラウドの実態である。

府省横断の業務改革が不可欠に

この取り組みで重要なのは、どれだけアプリケーションを共用化できるかという点だろう。府省ごとに利用しているアプリケーションをそのままSaaS化するだけでは、単にWebアプリケーションのホスティングにすぎない。システムだけの統合・集約に終わらずに、業務プロセスの統合・集約、すなわちシェアード・サービス化にまでつながらなくては、大きなメリットを得ることはできない。

そのためには、府省を横断した業務の標準化が不可欠となる。中間取りまとめでも、業務の見直し（BPR）を課題として掲げている。しかし、その道筋は見えてこない。中間取りまとめの資料には、2009年度から2015年度までのスケジュール（予定）が掲載されているが、業務の見直しに関連するような工程は2010年度中の「要件定義」と「最適化計画策定」の2つだけだ。府省横断で業務を改革した上でシステム要件を定義するまでを、1年足らずの期間で完了できるのだろうか。

短期間での業務改革を実現するためには、強力なリーダーシップが必要だ。府省を横断して大なたを振るえるとしたら首相しか考えられないが、総選挙を間近に控えた今、実働部隊となるプロジェクトメンバーを選ぶことさえもままならないのではなかろうか。

自治体クラウドが実証実験へ

一方の自治体クラウドも実現へ向けて大きく動き始めている。総務省は2009年7月17日、「自治体クラウドに係る開発実証団体」の募集を開始。実証実験に参加する都道府県を募り始めた（資料はこちら）。都道府県CIOフォーラム（詳しくはこちら）の事務局を務めている日経BP ガバメントテクノロジーでは、8月のフォーラム開催に向けて事前アンケートを実施しているが、実際にいくつかの都道府県が実証実験に参加する予定だと回答している。

自治体クラウドは、自治体専用のWANである総合行政ネットワーク（LGWAN）内にあるデータセンター（3カ所の予定）に市町村のシステムを統合・集約する取り組みである。市町村レベルでのシェアード・サービス化ととらえることできる。市町村の場合は、それぞれが同じような住民サービスを提供しているため、シェアード・サービスに向いているといえる。

理想論でいえば、全国の自治体が利用するシステムを統一すれば、コスト面で大きなメリットを得られるし、ガバナンスを効かせやすいというメリットも生まれる。しかし、アプリケーション（あるいはSaaS事業者）の品質を維持できるのかが見えない、地域特性による個別のサービスが提供しにくい、あるいは地場のITベンダーが育成できないなどデメリットも少なくない。実際、総務省の実証実験では、ASPやSaaSは自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位のシェアード・サービス化ということになりそうだ。

ただし、都道府県単位でバラバラの仕様のシステムを作るわけではない。自治体クラウドの要件の中には、「自治体クラウド連携インターフェイス」というものがある。これは、アプリケーション間でデータを連携するためのインタフェースで、将来的には都道府県間の連携も見据えたものになっている。

とはいえ、都道府県を横断したアプリケーションの共用化は容易ではないだろう。都道府県をまたいで業務を標準化しなければならないからだ。自治体クラウドと霞が関クラウドの両方に共通することであるが、IT面での研究や実証・分析に偏らずに、業務の標準化にも力を入れていかなければ成功はおぼつかないだろう。というよりも、IT面の実装よりも、業務の改革・標準化のほうがハードルが高いのではないだろうか。

（吉川　和宏＝日経BP ガバメントテクノロジー） 　[2009/08/21]

http://itpro.nikkeibp.co.jp/article/Watcher/20090818/335667/

Permalink | 記事への反応(0) | 15:06

ツイートシェア

■企業向け製品ってJ-SOX無ければ死んでるよね。たぶん

タイトル通りのことを思う。

企業向け製品ってJ-SOX無ければ死んでるよね。たぶん。

WebのOSSな世界と、Windowsの閉じたネットワークの世界がくっついちゃって戸惑ってるんだろうね。クラウドなんて言い出したのもその辺の焦りが見受けられる。

だってメールクライアントなんて使ってるの社内だけでしょ？ねぇ？

一般ユーザーの大半はメールは携帯電話か、GmailなどWebメール。

もうね、答えでてるんじゃん。Web企業の一人勝ち。

クラウドがなぜ安いか、どこでも解説されてるじゃん。インフラ周りでWEB企業が最強って事でしょ。

クラウドを使いたいけど、事情があって「和製クラウド」を使うんだ。という話でしょ。

つまりIT内部統制とか大手同士の付き合いがなければ「舶来クラウド」に圧倒されてる。ってことでしょ

とあるWEB開発企業にいたんだけど、社長が企業向けSaaSにこだわるのよ。

絶対変だよね。クラウドもSaaSも「Web系企業」が一人勝ちしてる。その事実があるのに、企業向けなんかやっても未来がないよね。

エンタープライズシステムの会社がいくら焦っても遅いんじゃないかな。

Gmail使ってる世代が就職始めて、社内でそれなりの立場になる10年後考えてみたらいい。

「10年は泥のように」「無理です」

http://www.atmarkit.co.jp/news/200805/28/ipa.html

この考え方の違いは、10年後顕著に表れるだろうね。Gmail世代とメーラー世代。いまはメーラ使ってる世代が偉そうにITを土建屋みたいに言ってるけど。Gmail世代はWebAPIで従量課金とか使い放題とかインフラから切り離されて、土建みたいな事を言わなくなるんだよね。

もうWindowsアプリは売れないと思った方が良い。20年後見据えるなら諦めた方が良い。

Permalink | 記事への反応(0) | 02:06

ツイートシェア

■http://anond.hatelabo.jp/20090428153637

ＮＥＣ、７月からクラウドサービス　基幹業務、ネット経由で提供

4月24日8時16分配信 フジサンケイ　ビジネスアイ

　ＮＥＣは２２日、基幹業務システムをネット経由で提供するクラウドサービスを７月に始めると発表した。情報システムやソフトの機能をインターネット上に保有する「クラウドコンピューティング」の技術を活用した。顧客企業は経理や人事、販売管理といった経営管理システムを自前で構築しなくても安く利用できる。ＮＥＣが、企業経営を効率化するための基幹業務を、データセンターからネット経由でサービス提供するのは初めて。

　７月に始めるサービスの名称は、「クラウド指向サービスプラットホームソリューション」。システムの種類を３種類に分類。企業規模や利用形態に応じて、一般的な「ＳａａＳ型」、個別企業に特化した「個別対応型」、複数企業で共有できる「共同センター型」から、自社に最適なシステムを選べる仕組み。

　利用料金は個別見積もりとなる。中小・中堅企業から大企業まで幅広い業種の利用を見込み、「２、３年後に年間１０００億円を売り上げたい」（藤吉幸博執行役員常務）考えだ。

　開始に合わせ、システム構築を担当するＳＥ（システムエンジニア）を、提案から保守・運用まで一貫して担える「サービス要員」として育成する。２０１２年までに、グループ会社を含む１万人のＳＥをサービス要員に移行させ、企業向けの提案力を強化する。

　１万人のサービス要員のうち、２０００人は顧客に業務手順の改善を提案する「ビジネスコンサルタント」、残りは、システム構築から保守・管理の段階で提案する「プロジェクトマネジャー」とする。

　クラウドサービスはサーバーなどの機器やソフトを自前で保有しないことから、運用コストを大幅に削減できる。また、新システムへの移行が容易なことから、システム更新も簡単にできるメリットがあり、利用企業が増えつつある。ＮＥＣが基幹業務システムのクラウドサービスに乗り出すことで、ライバル企業も追随する動きが加速しそうだ。

最終更新:4月24日12時37分

http://headlines.yahoo.co.jp/hl?a=20090423-00000004-fsi-bus_all

たとえば、こんな記事なんだけど、具体的には何がいいたいのかぜんぜんわからん。

基幹業務システムをインターネット上で提供、とかいうのをクラウドっていってるけど、それは過去のASPであり、SaaSとかであり、名前があまりにバズワード化したので、こんな言葉を使っているわけだが、具体的に何がいいたいのかわからんので×。

Permalink | 記事への反応(1) | 21:37

ツイートシェア