「SaaS」を含む日記 RSS

はてなキーワード: SaaSとは

2019-11-06

実感としてSIerは無くならないと思う

日本ユーザーたちが自分たち業務システム作れるわけない。

SaaS業務が回るようにも出来やしない。

法律規制でもされない限り、非効率業務を続けて、非効率業務に合わせた業務システムが作られる。

2019-11-04

田舎企業に対するアプローチが悪すぎる

https://note.mu/iryo/n/nb8b7217879e3

https://note.mu/iryo/n/n7567a9e071a7

 

東京ITやってたけど、介護田舎に戻ってきてそれからずっと田舎で似たようなことしてるけど、この人圧倒的にやり方が悪い

都会に住んでいたか田舎民の圧倒的なITリテラシの低さと、「iPadOS更新も、音量調整ですら、地方企業にとっては”難しい”」なんて実情も、なんで今時FAXなの?!っていう葛藤

不満もぜーんぶわかる。わかるんだが。

 

それでイライラしてたら田舎仕事は勤まらない。

これに腹を立てる人は田舎仕事に向いてない。

筆者は田舎に住んでいて、都会に出てしまった時点で、頭が都会人になっちゃってるんだよ

 

田舎もんは確かに知識がない。そして知識がない自分をよくわかってて、恥ずかしいとも内心思ってる

そこに都会でばりばりやってました! って人がサポートして、リモートでよくやってるじゃん、とかこのくらい簡単ですよ! なんていったことが自分に出来なかった場合、彼らのプライドは傷つく

おまえがバカなだけだろ! と怒るのは分かる。だがちょっと待って欲しい。

そういう田舎者を「かわいい奴め」と思えないと、田舎者はすぐに見抜く。

「なんか都会から来たえらそうな若造が俺たちのいままでやってきたことをぼろぼろにしていく、俺たち頑張ってきたのにダメ出しする」となってしま

そういう自分たちの気持ち会社効率化よりも上回るし大事なので、筆者は文句言われるのだ。

 

再度言うけど、田舎者は、自分たちのITリテラシの低さは自覚している。

ちょっと恥ずかしいとも思ってる。

そこに「こういうのくらい簡単から使えますよね」と都会感覚で乗り込めば、使えない自分が嫌になり、「なんでこんなものもってきたんだよ!」と逆ギレする

面倒だよね、うん。面倒なんだよ。

でもそれって逆に義理人情が上回る世界でもあるので、信用さえ掴んでしまえば、なんでもほいほいと言うことを聞いてくれるようになる

リモート対応されるのって、義理人情世界では軽く見られてるように思われる。コストとかの理由から分かるけど田舎メソッドでは「どれだけ自分たちに親身になってくれるか=信頼」なので、顔も出してくれない奴は信用されない

コストとか、効率化とかはそれらの「義理人情」より下なのである

 

田舎はよくdisられるが、俺は田舎義理人情世界は嫌いじゃない

クズも多いが、そんなの都会でもいるし。

アホが多いんだよ。よく地方のじじばばが鑑定団に出て、借金の形にとか安い壺買わされてるじゃん。買うなよ、って思うけどそれが田舎なんだよ。

都会の場合は「こういうことすれば人件費も減り効率化されますよ!」を最優先にだして営業すればいいけど、田舎場合

「いやー忙しくて残業続きですか、わっかるわー、ちょっと僕とお話しさせてくださいよ、おお、お孫さんが今五つですか、かわいいですねえ。でもこのままのやりかただとお遊戯会も出られないじゃないですか、早く帰れるようにしましょうよ」

というノリを半年から一年はやる。

話してるだけでいい。なんもしなくていい。顔だけ出して帰るのを1年くらいやってると、「いつも来て貰って悪いからねえ」というノリになってくる。

ええ、そう。不効率ですよ、はい。金にならんよ、そりゃ。

から金だけ考えてるとこんな仕事は出来ないよ。

ただ一旦そういうSaaSを導入し始めると、ウォーター!とばかりにがらっと考えが変わって効率化が徹底されたりするようになるので、面白くもある

レベル50くらいの奴を60にするのが都会なら、レベル1を50にしなきゃいかんのが田舎だ。

がんばれ

2019-09-04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019-07-22

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

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

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

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

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

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

Windowsが悪いという話ではなく、WIndows以外の選択肢MacLinux)を選べるというのが大事

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

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

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

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

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

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

Oracle RACを使っていないか

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

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

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

エンジニアブログ

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

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

その他

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

2019-07-10

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

日経のこの記事

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

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

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

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

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

2019-07-06

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

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

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

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

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

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

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

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

セキュリティ審査とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Webサービス200万、スマホアプリ(iOSAndroid)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というサービス自動での定期診断が可能なようです。

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

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

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

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

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

脆弱性診断ツール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は社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

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

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

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

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

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

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

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

そもそもやってない

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

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

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

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

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

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

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

以上。

以下追記 2019-09-08

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

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

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

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

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

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

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

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

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

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2019-01-06

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

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

背景

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

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

状況

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

状況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 : 野沢雅子

2018-10-12

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

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

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

(わかりづらい数字人間理解やす英単語に置き換えた)

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

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

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

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

いったものができた。

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

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

カプセル化

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

カプセル化抽象化

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

ブラックボックス化)

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

カプセル化

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

リモートから操作ブラックボック化)

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

さらなるブラックボックス化)

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

ブラックボックス化)

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

操作の簡略化)

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

カプセル化抽象化

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

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

2018-07-10

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

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

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

http://talentcloud.jp/

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



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

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


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

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




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

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


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

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


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

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

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

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

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

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

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

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

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

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



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

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


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

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

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

2018-02-07

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

 Webサイト技術の高度化

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

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

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

SlackYoutube生放送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スライドとかスプレッドシートヤバいくらい複雑なシステムだと思うしハイクオリティだとおもうんだけど、どんな開発体制で作られたんだろうか気になる。

2018-01-12

anond:20180112155945

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

2017-05-31

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

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

2017-03-05

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

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

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

コメントタイトルコメント数/ブクマブクマページ
0.0%Python3.6 から追加された文法機能 - Qiita0/96b.hatena.ne.jp/entry/324476241
0.8%文章ベクトル化して類似文章の検索 - Qiita2/245b.hatena.ne.jp/entry/324662835
1.0%[wip] 会社サーバサイドエンジニアにReactとかReduxのことを説明する資料 - Qiit1/97b.hatena.ne.jp/entry/319535213
1.1%機械学習ディープラーニングの入門者向けコンテンツまとめ - Qiita1/94b.hatena.ne.jp/entry/321793279
1.9%Web制作時の概算費用と想定納品日を簡単に計算する票をつくってみた – のんびりデザインしているよう7/375b.hatena.ne.jp/entry/320010979
2.0%最近見かけるレイアウト・ナビゲーション・スライダーフォームなどがどうやって実装されているのかのまと7/344b.hatena.ne.jp/entry/322198623
2.2%フロントエンド知らない私のwebpack入門 その1 - Qiita4/186b.hatena.ne.jp/entry/319233247
2.3%フルマネージドのSaaSクラウドデータベースサービスdashDBの活用スタイルとは ~手間いら5/216b.hatena.ne.jp/entry/323891713
2.4%Pythonをやるときに参考になりそうな情報 - のんびりSEの議事録19/807b.hatena.ne.jp/entry/322300431
2.5%React基礎 · GitBook17/681b.hatena.ne.jp/entry/321494522
2.7%開発効率を上げるテスト設計 // Speaker Deck5/183b.hatena.ne.jp/entry/323584734
2.8%畳み込みニューラルネットワーク可視化 - 人工知能に関する断創録3/108b.hatena.ne.jp/entry/322431100
2.8%グランブルーファンタジーを支えるインフラ技術 // Speaker Deck10/359b.hatena.ne.jp/entry/324611754
2.9%仮想DOMの内部の動き | プログラミング | POSTD6/206b.hatena.ne.jp/entry/321289144
3.0%金融データPythonでの扱い方 - 今日も窓辺でプログラム16/527b.hatena.ne.jp/entry/322842311
3.1%Python Jupyter notebookでpandasを使いCSVを読み込みグラフを描画してp5/162b.hatena.ne.jp/entry/321556884
3.1%React Redux Real World Examples 〜先人から学ぶReact Redux9/290b.hatena.ne.jp/entry/323749846
3.2%Awesome Python:素晴らしい Python フレームワークライブラリソフトウェア・リ15/472b.hatena.ne.jp/entry/319013267
3.2%履歴書志望動機|最速で書く方法と受かる書き方14/433b.hatena.ne.jp/entry/279613157
3.4%今日からはじめるGitHub初心者がGitをインストールして、プルリクできるようになるまでを解38/1128b.hatena.ne.jp/entry/318690305
3.4%スケーラブル GCP アーキテクチャ6/178b.hatena.ne.jp/entry/322723492
3.5%アーキテクチャから新しい! 初めてのエディタには、21世紀生まれの「Atom」がおすすめ【続・若手エ11/311b.hatena.ne.jp/entry/322534650
3.5%フロントエンドの基礎知識 // Speaker Deck15/423b.hatena.ne.jp/entry/322749937
3.7%ロードバランサー再入門 | ツチノコブログ26/704b.hatena.ne.jp/entry/323163487
3.7%APIサーバを立てるためのCORS設定決定版 - Qiita5/134b.hatena.ne.jp/entry/321742626
3.8%画像】こんなのソフマップじゃないwwwwwwwwwwwwww|ラビット速報5/131b.hatena.ne.jp/entry/321219627
4.0%動画あり】人志松本のゾッとする話のあるある探検隊の話怖すぎwwwwww | 2ちゃんねるスレッド10/252b.hatena.ne.jp/entry/319507149
4.0%翻訳2017年展望: pandas, Arrow, Feather, Parquet, Spa7/176b.hatena.ne.jp/entry/324411617
4.2%【たまに行くよ!って人向け】いつもと少しちがう東京ディズニーシーデートにするための5つの方法 @ja3/72b.hatena.ne.jp/entry/321496344
4.3%高速なシステムを作る方法 // Speaker Deck9/211b.hatena.ne.jp/entry/283448858
4.3%処分・廃棄にお金は要らない!?パソコン無料引取してくれる業者一覧7/162b.hatena.ne.jp/entry/320803373
4.3%タデサプリを支えるデータ分析基盤 ~設計の勘所と利活用事例~3/69b.hatena.ne.jp/entry/322583838
4.4%「Front-End Developer Handbook 2017」がGitBookで無償公開。フ24/542b.hatena.ne.jp/entry/318947145
4.6%デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの7/152b.hatena.ne.jp/entry/322562611
4.6%大量の要素を高速に表示するためのバーチャルレンダリング入門 / Virtual Rendering 6/130b.hatena.ne.jp/entry/323604383
4.7%MySQLアンチパターン22/473b.hatena.ne.jp/entry/319218778
4.7%5年間コードを書き続けたエンジニアが、新人に読んでもらいたい11冊+αを紹介する - エンジニアHu47/1006b.hatena.ne.jp/entry/313934939
4.7%グーグル社員も長友選手も行う集中力を高める方法 - 自分で学ぶ心理学20/427b.hatena.ne.jp/entry/322090614
4.8%例の機械学習コースが良いらしいと知りながらも2年間スルーし続けたがやはり良かったという話 - Qii68/1418b.hatena.ne.jp/entry/321403591
4.9%NoSQL を使用する場合と SQL を使用する場合Microsoft Docs28/577b.hatena.ne.jp/entry/322834020
4.9%Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita5/102b.hatena.ne.jp/entry/321629987
4.9%誰でもできる、プレゼンが劇的にうまくなる基本テクニック - 科学非科学迷宮77/1557b.hatena.ne.jp/entry/318913434
5.0%脆弱性発見者が注目する近年のWeb技術 // Speaker Deck24/481b.hatena.ne.jp/entry/319516657
5.1%たった3つのコトで仕事が楽になる!「できる上司の会議」がマジで真似したい | CuRAZY [クレイ7/138b.hatena.ne.jp/entry/322534334
5.1%日経電子版を支える基盤API // Speaker Deck13/256b.hatena.ne.jp/entry/319592914
5.1%30歳から始める数学 - Shoyan blog50/982b.hatena.ne.jp/entry/323617832
5.1%インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - VOYAGE GRO20/392b.hatena.ne.jp/entry/323171376
5.1%『How to Get Startup Ideas』 - いかスタートアップアイデアを得るか -17/333b.hatena.ne.jp/entry/324384439
5.1%無料ウェブサイトブログに使える写真を検索可能な28サービスまとめ - GIGAZINE18/350b.hatena.ne.jp/entry/323600897
5.2%内向的な人のための面接ガイド - GIGAZINE14/271b.hatena.ne.jp/entry/322036523

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

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

コメントタイトルコメント数/ブクマブクマページ
74.5%はてブ要望「返信出来るようにして欲しい」 - interact114/153b.hatena.ne.jp/entry/319990286
73.5%あなた朱雀とか白虎とか四神を覚えたキッカケは何?」という質問に対し世代がバレそうになる人々→「幽319/434b.hatena.ne.jp/entry/322198765
67.8%内海 聡さんのツイート: "あなた甲殻類アレルギーだった場合あなたの心は殻に閉じこもっている可449/662b.hatena.ne.jp/entry/318821783
67.4%日米首脳会談 首相は「ドラえもん」のスネ夫になった!民進党野田幹事長が批判 (産経新聞) - Ya95/141b.hatena.ne.jp/entry/321930776
65.7%いい記事書けばブクマつくとか嘘っぱち!こんな嘘がまかり通るはてな界に物申すっ! - ゆるくいきていく260/396b.hatena.ne.jp/entry/323206934
65.5%痛いニュース(ノ∀`) : 梅沢富美男(66)、老害判定に怒り 「日本は俺達が作ったんだぞ!」 - 190/290b.hatena.ne.jp/entry/322785094
65.5%茶碗に米粒を残した状態で「完食」する人は完全悪ではないけど相容れられない、という話に意見続々 - T413/631b.hatena.ne.jp/entry/321479096
64.6%けものフレンズを視聴1分30秒で挫折。 - 自由ネコ122/189b.hatena.ne.jp/entry/321589678
63.7%けものフレンズコスプレ批判に対する異論まとめ - Togetterまとめ228/358b.hatena.ne.jp/entry/323622485
63.6%レジでバレる!二流の人の超ヤバい3欠点』という東洋経済記事を読んで。クレジットカードイメージ119/187b.hatena.ne.jp/entry/323599229
63.5%痛いニュース(ノ∀`) : 日本在住のイスラム教徒の子どもがハラール対応給食に苦慮→学校側に配慮290/457b.hatena.ne.jp/entry/321128745
63.0%あざなわさんの炎上はてな村権威のなさ - メロンダウト133/211b.hatena.ne.jp/entry/323813866
62.7%プレミアムフライデーって何でこんなに叩かれてるんだろう? - シャイニングマンの「勇気を君に」126/201b.hatena.ne.jp/entry/324113658
62.5%飯田譲治さんのツイート: "日本が悪い日本が悪いって、民間人は殺さないってルール破って、原爆落として65/104b.hatena.ne.jp/entry/321434534
62.4%偏差値40の大学日本必要なのか?子供を焼き殺す大学補助金は不要 - カキカエブログ166/266b.hatena.ne.jp/entry/318786744
62.2%坂上忍 清水富美加の月給5万円は正当「僕らの時もそうだった」 (デイリースポーツ) - Yahoo!237/381b.hatena.ne.jp/entry/321888913
61.9%清水富美加17日著書出版「全部、言っちゃうね。」 - 芸能 : 日刊スポーツ73/118b.hatena.ne.jp/entry/322431771
61.5%警視庁捜査1課長が竹刀で23歳美人記者ボコボコ (文春オンライン) - Yahoo!ニュース415/675b.hatena.ne.jp/entry/322218394
60.7%ゴルフに興じる首相、誇れない」民進・蓮舫氏:朝日新聞デジタル136/224b.hatena.ne.jp/entry/321608217
60.6%金があるのに、理屈をつけてコンテンツに金を落とさない」連中について - うらがみらいぶらり243/401b.hatena.ne.jp/entry/321324226
60.6%痛いニュース(ノ∀`) : 中学校で「やばい」という言葉を使用禁止に 若い世代意味多様化 - ラ132/218b.hatena.ne.jp/entry/324642052
60.3%受動喫煙対策東京だけでやれ」 自民党内で反対論噴出:朝日新聞デジタル241/400b.hatena.ne.jp/entry/321316384
60.1%娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ92/153b.hatena.ne.jp/entry/321299915
60.1%「洗剤いらず」スポンジで教頭などが児童の体こすりけがNHKニュース215/358b.hatena.ne.jp/entry/322584234
60.0%松井一郎さんのツイート: "長谷川さんが、ブログで伝えたかったのは、健康であるための自己管理重要201/335b.hatena.ne.jp/entry/320414066

2017-01-27

http://anond.hatelabo.jp/20170127092557

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

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

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

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

2016-06-25

[] ウォーターフォールメリット

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等でも取り組みがあるようだが,いずれにせよ契約を行うのは発注者と受注者であり,受注者側だけでどうこうできる問題でもないので,発注者側の意識の変化を期待するしかいかもしれない。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond: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 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

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

他の選択肢

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

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

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

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

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

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

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

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

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイル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/

anond:20160426124418 続き

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

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、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 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ 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 のような場合は期限切れがあってはならないので、パスワード等を預かる

2015-12-05

さらSIer、オレは逃げるぜ

さらSIer

転職しました

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

付加価値高級料理

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

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

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

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

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

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

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

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

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

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

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

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

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

そして出す。

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

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

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

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

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

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

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

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

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

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

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

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

2014-07-15

http://anond.hatelabo.jp/20140715183518

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

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

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

2013-09-07

もう婚活なんてしない

スペック

性別:男、年齢:30中盤、年収:中の上or上の下、見た目:中の上or上の下(たぶん)

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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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


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

2012-04-03

http://anond.hatelabo.jp/20120403180843

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

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

2010-05-18

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

http://anond.hatelabo.jp/20100518115813

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

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

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

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

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

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

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

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

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

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

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

2009-10-16

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

更新6月22日 10:10

ビジネス:最新ニュース


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

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

クラウド定義

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

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

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

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

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

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

クラウド効用

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

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

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

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

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

プライベートクラウド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[2009年6月22日]

2009-10-14

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

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

総務省が掲げる霞が関自治体クラウドの計画が本格的に動き始めた。同省は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ベンダーが育成できないなどデメリットも少なくない。実際、総務省実証実験では、ASPSaaS自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位シェアード・サービス化ということになりそうだ。

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

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

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

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

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん