「サービス設計」を含む日記 RSS

はてなキーワード: サービス設計とは

2021-05-09

anond:20210508205527

新規投稿タイミングよく見つけてくれる人がいないとすぐに流れて消え去るんだよな。運要素が強い。

その対策で何度も同じ記事投稿してうざがられたりする。

トラバ場合、そのツリーのどれかの記事ブクマされたりトラバついたりするたびに、自分記事恩恵を受けて目に入る。

特に何かひとつテーマがすごく盛り上がっているときは、無理矢理でもトラバにした方が記事寿命が伸びてより多くの人に読んでもらえる。

投稿サービス設計上の穴とも言えるが、今更どうしようもなさそう。

2021-02-11

anond:20210211171955

きっとあなた責任感が強い人だ。

プロジェクトの失敗に責任を感じているからこそ、クラウドファウンディング方式を取らなければ良かったと後悔している。

ただ、同業で似たような環境クラウドファウンディングを使うべきでないかというと、それは難しいんじゃないだろか。

CF提供側も、プロジェクトの失敗の可能性を考慮してサービス設計してると思うし、出資者リスク理解して出資している。

問題CFを利用したことではなく、増田会社一定クオリティ作品を作ることが難しい状態にあることの方な気がするがどうだろう。(その状態にしているのが資金である、となればまーループちゃうけど)

2020-09-11

anond:20200911085806

何らかの原因で暗証番号を把握していたのか、リバースブルートフォースたまたまヒットしたのかも確定ではないよ

確定しているのはこれだけ

犯人システム脆弱性をついて、何らかの手段他人の口座を自分ドコモ払いにひもづけてお金を抜いたこ

・よくよく見たらサービス設計自体に重大な問題があり、リバースブルートフォースによる攻撃現実的に実現可能であったこ

2020-06-06

ローソンデザインの件は、デザインの良し悪しやUDかどうかということよりも、企業理念乖離したデザイン採用したこと企業としての問題点を感じた。企業理念デザイン、一対一の問題ではなく、商品開発にしてもサービス設計にしても出店計画にしてもすべて企業理念に則って実行されているはずで、たとえばインフラ役割を期待されて出店が可能になった場合、今回のデザイン採用のようなことは半公共立場立候補しておきながらあとから公共性を放棄する、ある種梯子外しともとれてしまうわけで、ローソン自体がそれだけ社会的責任のある立場という期待をされ自覚している企業であることを踏まえると、それをぶっちぎっても新しいデザイン採用して新しい価値観創造するというのは言ってることとやってること違うよね、ということになると思う。

2020-01-13

GIGAスクールネットワーク構想についての雑感

私はとある自治体教育委員会教育情報化担当をしています

この界隈は今、GIGAスクール対応で大混乱です。

GIGAスクールって何?って人は文科省サイト見てください。

GIGAスクール構想の実現について

https://www.mext.go.jp/a_menu/other/index_00001.htm

補正予算の締め切りまで残り一週間を切る中で、文科省からはまだ要綱も示されていません。こんなもん、間に合わないのではないかと、どこの自治体も強い危機感を持って、焦っています

一方で、今回の事業が持つ意味やその先のことについては、ほぼ考えられていないのが現実です。

担当部署でこうなのだから一般の人はもちろん学校現場でもまるで理解されていないことは容易に想像できます

以前から教育情報化積極的に推進する立場にある人たちは、大変盛り上がっていますが、地に足がついていないというか、勇み足になっているというか、前提が共有されていないのに難しいことを言い過ぎていて、その世界の外側との溝が深まっている気がします。

なので、当事者のひとりとして、一般の人や学校現場に伝えたいことをここに書いてみたいと思います

まず、今回のGIGAスクール事業において注目されている一人一台端末ですが、騒ぐようなことじゃないと個人的には思ってます

「何の役に立つのか」とか、「何に使うのか」とか、そういった面倒な議論になりがちですが、とても便利なものなんだから、「とりあえず役に立つに決まってるだろ」というのが本音です。

みんなスマホを一人一台持ってますよね?オフィスパソコンが共用しかないとか無いですよね?

同じことです。

さらに、みんなが一人一台持ってるのが当たり前になったら、それを前提としたサービスがどんどん生まれてきます

LINEやインスタの普及を考えたら分かりますよね。

家庭に一台だとLINEはここまで普及していません。

一人一台だから変わることがあって、全国でインフラ整備されると学校向けのサービス設計が根本的に変わります

今回の事業における国の狙いとしては、今後のためのインフラ整備という面が一番大きいと思われるので、現場必要以上にどういう教育に使おうかと頭を抱える必要はありません。

どう使えば便利か、先生自身が楽になるか、効率的に授業できるか、現場レベルではそういう発想で十分です。難しく考えて逃げられるのがいちばん困ります

従来の3クラスに1クラス分だと、どう使わせるべきか、こっちもかなり頭を悩ませてたんですが、一人一台だと気軽に使ってもらえばそれでいいので、ずいぶん楽です。

一斉授業からの脱却とか個別最適化された学習なんかは、仕組みを考える人仕事です。

そのうちサービスが出揃って嫌でも巻き込まれるので、それを待ってりゃ良いです。

本当は各家庭で端末買って持ち込むBYODができれば良かったんですが、こういうサービスが出揃って常識が変わってからでないとそれは難しいから、順番としては今回のやり方が正しいのでしょう。

もう少しスケジュールに余裕が欲しかったところですが。

多分、あと5年もすれば世の中の常識が大きく変わっているはずで、それができなければ文科省の大失態だと言うしかないです。

ともあれ、それは現場責任ではありません。

導入の担当者として、一人一台になるにあたり現場にやって欲しいこと、考えて欲しいこと、気をつけて欲しいことというのは他にありまして、それは、授業以外の場面で、可能な限り子どもたちの自由に使わせてあげて欲しいということです。

OECD学習到達度調査(PISA)で衝撃的な結果が出ました。

日本の子どもたちは加盟国中で一番チャットゲームICT活用するのに、学習に使うのは最も少ないという結果です。

ゲームチャットは1位で学習最下位日本の15歳のICT活用実態

https://www.google.co.jp/amp/s/s.resemom.jp/article/2020/01/09/54151.amp.html

これは間違いなく、学校教育意図的ICT活用を避けてきた結果です。

プライベートだけで、誰から教えられるでもなく、何の導きもなくICT使ってたら、ゲームLINEYouTubeだけになるのは、当然のことでしょう。

遊び以外にICTを使う目的やヒントを与え、見守り、助言する役割を担う大人必要です。

ゲームが好きなら、ただ消費するんじゃなくて自分で作る楽しみを教えてみるとか、YouTuberになりたいんならとりあえず動画作らせてみるとか、きっかけを作ってあげることはとても大切だと思います

それを親に期待できない場合は、誰ができるんでしょうか。

また、インターネットは昔の子どもたちが生きてきた世界(学校地域社会)とは違って、子ども子ども扱いしてくれません。

ひとりの消費者として、賢い大人たちが用意する色んなサービス商品と向き合わないといけないです。

そこは、少しの失敗が大きな危険に繋がりかねない世界です。

そこで生きていく術を、大人の目が届いて、ある程度の安全が確保されている範囲内で学ばせることが必要です。

これらは、間違いなく公教育役割です。

ヒントを与えて見守るというのは制限するより負担が大きいので、現場に嫌がられることは理解していますが、必要なことです。

個人的には、ICT活用した授業研究より、はるかに大切だと思ってます

なので、私はこれから一人一台端末を導入する際に、子どもたちに出来るだけ自由に触らせてあげて欲しいと、繰り返し現場にお願いし続けようと思ってます

もし、これを同業者学校現場の方が読まれたなら、今回整備される端末の用途を授業に限定して過度な制限をかけることはやめて欲しいと思います

職員室のパソコンが一人一台になって悪くなったことなんて何一つないのと同じように、子どもたち一人一台端末で悪くなることなんてないです。

手書きの良さがとか言う人がいますが、パソコン入っても手書きは無くなりません。もちろん習字の授業も無くなりません。

冗談だと思いますが、目が悪くなると言う人もいます視力に影響するほど授業に使ってもらえるなんて、考えられません。

単純に、今より少し便利になるだけで、そんな大袈裟に考える必要はありません。

教育を変革するような大きな話は、制度考える人サービス提供する人の仕事です。

私たち現場に近い人間は、子どもたちが遊び以外に上手くICT活用できるように、見守り、サポートすることを大切にしましょう。

時代が大きく変わる局面に携われるなんて、とても幸せことなので、みんなで頑張りましょう。

というのが、今、最前線現場にいて思うことでした。

では、補正予算要求資料作りに戻ります

2019-10-14

ウーバーイーツの紹介コード(友だち紹介インセンティブ)のヤミ?

最近、散々な評判なウーバーイーツ。

サービス設計に様々な指摘を受けている。

その中のひとつに、友だちや知人を紹介してウーバーイーツで働き始めると、紹介者がインセンティブを貰える仕組みがある。

元マスダにおいても、紹介によるインセンティブにまつわる言及がある。

紹介者からキックバックで2.7万

https://anond.hatelabo.jp/20191008185049


自分が調べた限り、ウーバーイーツの紹介コードを使った際のキャッシュバックは以下サイトで28500円だった(元マスダの登録である名古屋で最大のキャッシュバック率)。東京であれば8万円の紹介インセンティブに対し、キャッシュバックが76000円とかなりの高額だ(規定条件:30日以内に50回配達にてインセンティブ対象)。参考:https://toys-hop.com/uber-eats-regist/

理由は後述するが、キャッシュバック率はサイトによってかなりの差が生じている。

紹介料の支払いは紹介者のみに支払われる

ここにウーバーイーツが想定する仕掛けが存在する。

一般的によくみかける知人紹介キャンペーンは、

自分(紹介者) ⇔ サービス側 ⇔ 友人 であり、提供される金額の高に差はあれど、サービス側が双方に支払う。

例えば、ジムに友だちを紹介したら、自分と友だち双方に1000円のクオカードプレゼント、などである

自分(紹介者) ⇔ サービス側(双方に報酬を支払い) ⇔ 友人 

ウーバーイーツは紹介料が以下の流れになる。

サービス側 → 自分(紹介者) → 友人

極端に言えば、自分が知人に支払わなければ(支払う約束をしなければ)、全額紹介料を貰い受けることも可能である

様々なトラブル公平性を期すのであれば、ウーバーイーツ側が自分と友人の双方に半額ずつ割り振って入金すればいいだけだ。

当然、紹介された友人も規定回数の仕事した後にしかインセンティブを受け取れないため、ウーバーイーツ側は個人情報銀行口座情報も把握しているため、双方に支払う事自体により生ずるコストは大したものではない。

ウーバーイーツのインセンティブ設計に、一見合理性が無いように見える。

ここには、新規配達員の獲得に対する大きな意図と、彼らのメリット存在していることが見て取れる。

紹介コードインセンティブ分配(方法・率)は各個人に任されている

基本的に、紹介コードを介したインセンティブは、分配することを前提にしており、ウーバーイーツの社員も、友だちと折半するなどのアドバイスを行っている。

にもかかわらず、「サービス側 → 自分(紹介者) → 友人」というインセンティブの支払い形態採用している。

これは、インセンティブの分配を紹介者に任せることで、競争を生むことを意図していることが考えられる。

最大8万円と高額なインセンティブ人参に、紹介者に強いインセンティブを生じさせ、更には他の紹介者とキックバック率を競わせる目的があると考えるのが普通だ。

単純に4万円ずつを双方に支払うよりウーバーイーツにとっては間違いなくメリットがある。

この紹介インセンティブMLMなのだろうか?

つかこれって短期ネズミ講…もといMLMじゃね?紹介料キックバックの稼ぎが主なのだから

https://b.hatena.ne.jp/entry/4675531806527889730/comment/snare_micchan

MLMは親・子・孫・ひ孫と連鎖することがサービス設計に盛り込まれ継続報酬が発生する。

紹介インセンティブは、親子に1度だけ発生する報酬であり、ピラミッド状の上下関係はない点が大きく異る。

このような採用形態は、リファラリクルーティングと呼ばれ、近年、成功事例が増えつつある採用形態の一つだ(2017年記事に以下言及があり、ここ5年程度で浸透してきたと思われる)。

日本においてここ2年ぐらいで浸透してきた手法

https://hcm-jinjer.com/media/contents/b-contents-6103/


アルバイト求人コストは年々増加している

アルバイトパート採用にかかる平均コストは、2009年の約29,000円/名から、4年で1.7倍の約52,000円/名にまで上昇

https://kyodonewsprwire.jp/release/201401317959


情報源の信憑性はともかく近年の人件費の上昇をみるに、採用コストも上昇している可能性は大いにありえる。

これらから考えられることは、ウーバーイーツが採用しているリファラリクルーティングインセンティブ額(東京で8万円)は的を外れた金額ではないことが分かる。

ウーバーイーツはインセンティブ後の仕事継続してもらわねば成り立たない

東京でのインセンティブで8万円とそれなりに高額であり、ウーバーイーツ側も当然定着率などを含めたコストを算出しているはずだ。

インセンティブの支払対象配達回数は、現在は50回である

単純にこの紹介料だけを目的とした配達員だけが集まってしまっては、コストをまかないきれない。

ウーバーイーツの収益源は、注文金額の35%である

例えば、1回配達の平均単価が2000円と仮定すると700円がウーバーイーツの受取額だ。

配達員側の支払い計算方式と、お店側への請求計算式は異なるが、このうち30%程度がウーバーイーツの収益源(粗利である

700×0.3=210円

東京の紹介インセンティブの8万円÷50=1600円

どう考えてもウーバーイーツ側にとって割の合わない制度設計になってしまう。

当然、長続きする人もいるので、平均の配達回数見込みが1000回と仮定すると1回あたりに占めるインセンティブ額は80円となる。


リファラリクルーティングによる採用は定着率や帰属意識高まる

ウーバーイーツはその他の仕事比較して人間関係希薄だ。

人間関係希薄なウーバーイーツの仕事において、紹介料を貰い受けつつ、友人をサポートすることを期待しているとも捉えることができる。

リファラリクルーティングを取り入れている企業メリットとしても帰属意識高まることや採用コストの低減を目的としている。

この採用形態Evilなのだろうか?

ウーバーイーツ側にとって割とリスキー設計には感じるものの、合理的な仕組みなのではないだろうか。

当然、ウーバーイーツにとって配達員の生殺与奪権を有するので、約束したインセンティブを支払わないなどの際は、警告を出すことも考えられる。

この友達紹介インセンティブ設計以外にも、ウーバーイーツの制度設計Evilとの評判(主にブコメ)で散見された。

もちろん、マルチサイドプラットフォーム(BtoBtoC)の支配者・プラットフォーム提供者として至らない点はある。

だが、意図的にEvilになろうとしているよりも、仕組みの設計が未熟が故に、トラブルを拡大してしまっている根拠がいくつか存在している。

少なくとも、採用コストから見るに[配達員の使い捨て]は合理的でない。が、結果的使い捨てのようなしくみになっている部分もある。

その根拠を書こうと考えたものの、文字数の兼ね合いか割愛する。

もし興味があればブコメ言及してもらえれば検討したい。

2018-12-04

空き巣に入られたことについて語らせて

事件から幾らか時を経た。

空き巣で起こった体験談、そこから感じたこと、そして空き巣に万が一あった時の参考になればと思い、当エントリーを書くことにした。

状況としては帰宅した際に、ノートPCがなくなっていた。

そこからパスポート・通帳・印鑑などもないことを確認し、警察通報

電話からおおよそ1時間して刑事警察官が来て、聴取指紋確認などが実施された。

被害届を出し、パスポート等の再発行手続きをしているうち1か月ほど経ち、犯人逮捕されたため、押収品に私物がないか確認して欲しいと連絡があった。

そのあと、幾度か警察署に行ったのち、被害品の約8割程度が戻ってきた。

まず、平成29年東京都における空き巣侵入窃盗と呼ばれるらしい)は、

認知件数で5,237件、うち住宅は2,868件数のようだ。

東京都における世帯数は平成27年時点で6,692,089世帯だそうだから

簡易に計算すると空き巣にあう確率は「0.04%」である

ソース

平成29年中の侵入窃盗の傾向(警視庁

http://www.keishicho.metro.tokyo.jp/kurashi/higai/akisu/ppiking.html

平成27年国勢調査人口及び世帯数速報(東京都

http://www.metro.tokyo.jp/INET/CHOUSA/2016/02/60q2q100.htm

「運がなかった」「被害品が戻ってきたならまだよかったじゃない」といえばそれまでなのだが、

被害を未然に防げること、事後対応にはもっと改善余地があるのではないかと考えている。

犯罪手法

犯罪手法はというと、犯人テレビ放送された犯罪ドキュメントを見て、

「これなら自分もできるのでは」と考え、犯行におよんだというのだ。

報道内容の偏りや番組制作環境過去にないほど厳しい昨今だが、

少なくとも模倣可能性がある犯罪報道については制作サイドには特に気をつけて欲しいと感じた。

該当する放送局や番組名については知ることができなかったので、

もしこのエントリー報道関係者の目に触れるようであれば、十分留意されたいと切に願っている。

(更なる被害を防ぐため手法についての記載は控えますが、筆者も実現可能方法です)

逮捕

犯人逮捕職務質問から任意同行のうえ自供ということだった。

ネット上では冗談迷惑意味もないまぜになって言及されることが多いものの、

本当に職務質問犯人検挙できるのかと感心した。

被害

犯人は私の自宅だけでなく他の住居でも犯行を行っていた。

が、逮捕は私への被害犯行から間もなかったため、知らせを聞いた私はほぼ全ての被害品が戻るのだろうと思っていた。

しかしながら押収品を確認の案内は、逮捕から1-2か月程度経過していた。

そしてなんと驚いたことに確認した際の証拠品は、私の被害品は一切なかった

まりにも何もないので、犯人は私の住居に侵入した者とは同一ではないのではと疑ったほどであった。

そこで、「逮捕されたのは私の住居に入ってすぐであれば、押収品はある程度はまだ犯人が持っているのでは」と意見した。

そこから2か月程度経ったのち、再度警察から連絡があった。

被害から日数も経っていたし、被害品の代用品をあらかた揃え終えていたので、

今更、、という気もしないでもなかったのだが、はたしてそこには私の被害品が相当数出てきていたのである

「〇〇さん(私)のお話をうけてもう一度調べなおしたら出てきたんですよ」とのことである

この点については本当に呆れてものも言えないという気持ちになった。

警察犯罪を取り締まるプロであるはずだ。

同様のケースなどいくらでもあるだろうに、私が何も言わなければ再捜索もなく、被害品は全て回収されなかったのだろうか。

そして時期も非常に遅い。

パスポートも通帳も印鑑も全て作り直しており、こちらは保険等に該当しないので、自腹である

(なお、犯人への賠償請求に関しては、本人支払い能力不全を理由請求を控えるよう、私へ促す言葉があった。弁護士費用や手間と見合わないと感じたため、私も訴訟へは踏み出さなかった)

被害品(PC悪用による被害

前述したが被害品には私のPCも含まれていたのだが、これが最もやっかいだった。

というのも、PCからgmailアカウント侵入されてしまパスワード変更をかけられてしまった。

そのため、一切のウェブサービスの界隈についてアカウント情報を変えることになった。

自宅外に持ち出すこともほとんどなかったのでロックなどはしていなかったのだが、このことは大変悔やんだ。

恐ろしかったのは、PCLINEアプリインストールしており、犯行日翌日スマートフォンLINEアプリ上で、

被害にあった私のPCからログインの通知が来た時だった。

LINE機能上、アプリ上で使用するスマートフォン以外の端末のアクセスを一切許可しないメニューがあったので、即時対応し、

知人・友人に迷惑もかかることがなかったのは幸いだったかと思う。

余談だがLINEに対しても、PCログイン時におけるwifi等の通信環境リクエストをしたが、警察への開示も難しいとのことであった。

これが可能なら、犯人が自宅でPCを開いていれば逮捕への手がかりになるのではないかと思う。

話をもう少し続けると、iCloudgmailアカウント作成していたため、現在iCloudサービスを利用できていない。

なぜならiCloudアカウント情報の変更は、既存アカウントに対して認証確認があり、新アカウント情報に移行するからだ。

gmailパスワードが分からず、今こそ最も欲しい「iPhonemacを探す」機能が使えないのは非常に辛い。

Appleサポートに、空き巣の経緯も含めて対応リクエストしたが、サービス設計上対応できないとのことだった。

保険

入居していた住宅では火災保険への加入が必須だったのだが、そこに問い合わせたところ、

空き巣被害における物品の喪失保証内容に入っていた。

空き巣に限らず、盗難被害にあった際には一度加入している保険会社相談してみるのも良いかもしれない。

被害品のなかにPC以外にも高額なものがあったので助かった。

しかしながら、被害届警察に提出する際に申告内容に含めている必要性があったので、その点は留意されたい。


以上が、私が空き巣入られたことにおける簡単顛末と雑感である

ことにPC被害については、屋外でのPCスマートフォンタブレット等の盗難・紛失についても示唆深い内容になっているのではないかと思う。

冒頭に記載した通り、空き巣にあう確率は非常に低いものだが、

情報機器をなくしてしまう機会はままあるだろう。

そういった時も含め、本エントリーが役立つことを期待したい。

また、空き巣金銭的な被害だけでなく、時間精神ともにかなり負担が大きいことも認知していただけると幸いだ。

万が一周囲に被害にあった方がいれば、一助差し伸べて頂きたい。

最後に、本エントリーのサマリーを掲載する。

少しでも多くの人が辛い思いをしないよう、有効活用していただけると幸いである。

空き巣に入られたことについて語らせて(サマリー)》

メディアにおける犯罪事件報道について

犯罪事件を取り上げ、かつ犯罪手法を取り上げる際には、模倣可能性が高くないか十分に留意して報道いただきたい

警察捜査

国民から鬱陶しいという意見が多くあろうが、職務質問有用性を理解できたのでこれからも地道に続けていただきたい

犯罪押収品は全て網羅されているか、十二分に被害者に確認を取りながらすすめていただきたい

PC/スマートフォン/タブレット被害に関しては捜査の簡略化を目標に、通信会社連携して被害品の通信場所特定ができるようにしていただきたい

PC/スマートフォン/タブレットセキュリティ

・必ずパスワード/顔/指紋認証などのロックをかけておく

iPhoneを探す/macを探すを常にオンにしておく

保険

・何かの被害があった時にはひとまず契約している保険会社相談をしてみる

2018-10-22

anond:20181021222057

ついこないだ同じ経験して同じように思った。ユニクロなんかのおかげで、裾上げは一時間あればできるって知ってるお客さんが多いこと、洋服修理のお店たちは前提にしてサービス設計し直したほうがいいよね。

2018-06-24

ドミノピザアプリがめんどくさい

マジギレ寸前だからここに吐き出しま

いい加減にしろ

ドミノピザアプリからメールアドレス経由で会員登録を行うと、まれに404エラーになってしま

しかも使ったメールアドレスは「仮登録」として情報が保持されてしまうので、

PC等の他の手段で会員登録をしようとする場合、このメールアドレス24時間使えない

LINE経由でログインしようとすると「電話番号」ではなく「メールアドレス」を要求されて、LINEメールアドレス登録してない人は使えない

しかもこのLINEログインの画面から元の画面に戻れないので、一旦アプリを終了させなきゃならないのがストレス

そもそもピザの詳細を見れない

ドミノピザアプリを開くと

[ログイン][お客様登録]

[クイック注文]

[配達]

[お持ち帰り]

これしか表示されない

https://imgur.com/5NiDM9D.jpg

普通、注文する前にピザの詳細くらい見れるだろ

注文方法決めてからピザぶってどんなだよ

コレ作ったやつアホだろ

画面の移動がカクカクで気持ち悪い

一昔前のアプリみたいな、カクつく動きがストレス

腹減ってるときにこういう地味なストレスはきつい

会員登録できないストレスも相まってかなりきつい

過去はてな―もドミノ・ピザアプリに苛ついてる模様

ドミノピザUIがクソほど使い難い

まじで早く何とかして欲しい。マイページくらい簡単に行かせて欲しい。あとイベリコ豚復活して。

https://anond.hatelabo.jp/20180131114015

ドミノピザWEBシステムリニューアルされてからクソ使いにくくなってた。なんでピザ選ぶのに先にログインして届け先指定させるんだよ、と。サービス設計がまともに出来てなかったんだな。

http://b.hatena.ne.jp/entry/313704069/comment/ryun_ryun

2018-03-03

会社についてのメモ

いろいろ働いていて思ったことのメモ

まず職位名だが本国と出先では同じ職位名でも実際の機能結構違う。これは出先機関基本的本国の指示を実行することがまず求められるのと、大抵は営業拠点であるので売上・利益というゴールが最大の関心事になるためと思われる。

Assistant - 契約社員 / Associate - 新入りレベル / Senior - 新入りレベルではない人、または、何年かはいる人 / Lead - 現場リーダー / Manager - とりまとめ担当者、または係長課長 / Director - 課長部長 / Vice President - 部長本部長 / Executive Vice President - 本部長〜執行役員 / Senior Executive Vice President - 取締役(CXO) / President - 社長CEO

Specialist - 担当者専門家という意味特に含まない / Architect - 作業担当者設計という意味特に含まない / Engineer - 作業担当者。開発という意味特に含まない

Sales - 営業段階で動く人 / Services - 利用段階で動く人 / Engineering - 開発段階で動く人

なので、たとえばService Architectは「サービス設計をする人」ではなく「導入支援担当者」で、Engineering Architectは「開発物の設計をするアーキテクト」となる。

面倒なのがManagerで、一般名詞として使うときは「管理者」だが、Product ManagerなどXXX Managerと使うとき管理者ではなく「XXXまわりのとりまとめ担当者」といった意味役職になる。

これらは一例で、会社によってどういう修飾語を付けるかは結構違う。ただ言えるのは、日本会社に比べてインフレした名前をつけるというか、実際の役務以上にカッコイイ響きにしている感がある。「Senior Architect」とか言われたらおおっと思ってしまうが、「新入りではない作業担当者」と読み替えたら普通である

意思決定については、VP-Director-Managerのラインでは、VP意思決定を行い、Director部門間調整を行いながらManagerを支援し、Managerがスタッフ管理をする形になる。日本でも同じではと思うかもしれないが、中央集権度が違う。

Managerが一番現場上層部意思決定板ばさみとなっているのは洋の東西を問わないようで、しか中央集権度が高いため中間では判断できずメール転送リレーになってしまうこともしばしば。実務上の判断よりも、メッセージルーティングが最大の機能になる。これを「オープン組織コミュニケーションスタイル」と呼ぶのか「ヒラメ族による調整」というのかは地域によって違うようだ。

このあたりは本国出先機関かがおそらく影響しており、叩き上げが多かったりコミュニケーション密度が高くなる本国内であればManagerへも権限委譲やすいが、人の出入りが激しい出先機関では難しいと思われる。

また、これは組織構造に加えて組織の大きさが影響していると思われるが、数値での目標管理がしっかりしている。全く異なる地域文化社員管理比較しなくてはならないので、個別状況を勘案することは基本的に無理。したがって数量換算できる指標管理するのが原則となる。これは成果主義ではなく、数値主義と言える。例えばSalesであれば獲得顧客数・売上・利益、Serviceであれば売上稼働時間といった指標になる。

再び本国出先機関の違いに戻ると、出先機関基本的に在籍年数が少ない。いわゆる日本での典型的外資系イメージがこれであろう。これは出先機関はとにかく売上・利益本国にもたらすことが最優先なのが理由と見ている。先の数値管理に加えて現場での自由度の低さもあり、プレッシャーの大きさだけでなくストレスレベルも高い。

そしてそんな短期間で回転してゆく社員個別の非数値的状況を勘案しつつ管理することは難しいので、数値管理ますますなされてゆくという傾向がある。ここはかつて流行った数値的経営管理の影響も大きそうであるKPIをどんどん定義して、その数値によって判断するのが論理的に正しい、という傾向がある。

一応、数値だけではまずいということで、それを補うために数値外の評価制度がある。しかしこれも360評価が主流となり上長が指揮下のスタッフを自らの責任評価するものではなくなっているため、全員がある意味世間による評価」を意識する必要があり、これはこれで大変である日本の「空気」みたいなものだが、結局管理せずに管理したいと処理を分散していくと同じ様なものになるのが面白い

そんな状況のため出先機関では常時人が不足している。しかし育成機能はなく、本国要求は現地状況と関係なくどんどん出てくる。そうなると短期間でやめるにしても給与レベルは高いですよ、という形にして集めざるを得ない。備兵みたいなものであるしかしそうなると会社としても元は取らなくてはいけないので目標管理が更に厳しくなる。

この構造では商売軟調になると、社員ストレスばかり大きくなるので一気に離散する。また、社員としても元々長年居られると思っていないので、軟調以前に他社のでもより強い商材が登場すればそれに乗って転職してしまう。こうして転職が激しい構造が生まれ、維持される。

企業の興亡が激しいのもこういう人的資本の急激な集散が要因になっていると思うが、こういうダイナミックな状況で法人が滅ぶのはいいとしても個人死ぬわけにはいかないので大変である。この構造を「状況に適応し迅速に新しいバランスに至るよい仕組み」とみなすか「過敏に状況を揺らし個人社会不安定化させる仕組み」とみなすか、難しいところだ。「経済効率の追求が世界人類総体ではより豊かにした」vs「経済効率の追求が個人生活破壊した」みたいな話。

何が言いたいわけでもないが、結局どの組織も置かれた状況に適応しているだけで、どちらがいいというものでもない。地の利と時の運に恵まれ業績のいい企業産業地域では余裕があるため、その余裕が反映して「理想的なワークスタイル例」としてもてはやされるが、それが自社・自分に適しているか全然別の話になる。

2018-01-25

保守光と影

左派価値観(https://anond.hatelabo.jp/20180120234044)を書いたおっさん増田っす。ダラダラ長い補足をつけるのは何なので放置していたんだけど、いくつか気になるブコメをつけていただいたので、続きというわけではなく別記事で書いてみたいと思うよ。

なるべく教科書的なおおよそのところを書くつもりだけど、やはり人間なので私見は入る。明確に個人意見場合マーキングします。また左派右派って分類は今回の場合そぐわないので、革新保守と言う表記で書くよ。

右翼も現状否定では一致してるからな、左翼のそれとなにが違うんだろ』

革新保守の何が違うのか? どっちも「今の社会をより良い方向に一歩でもすすめる」という点では一致しているのにどこが違うの? っていう疑問はなかなか良い切り口だと思う。

教科書的な答えは「革新は(ある任意の)理想の状況や体勢に跳躍、急進しようとする」「保守は方向に進むにしても一歩ずつ漸進(ゆっくり進む)してゆく」なんだけど、まあ要するに違いは「アクセルの踏み方だけ」。もちろん現実的には進むべき理想の方向や、その方向に進むにしても進む方法の実現手段では様々に意見割れるんだけど、そんなもの革新と呼ばれる人の中でも保守と呼ばれる人の中でもバラバラなので、革新保守の違いは? といえばアクセルの踏み方くらい。

でも、「違いは速度感だけ」っていうと、凄く小さいことに聞こえるし、なんでそんなことで揉めてるかさっぱりわからないよね。

増田的にこの部分を説明してみると以下のようになる。

「長い歴史と非常に(っていうか非常識なまでに)ユーザーの多い複合型の巨大Webサービス存在する。日常的なメンテバックアップはあるのだけど、このサービスに対して現在ユーザー環境や競合サービスを鑑みて大規模改修を加えることになった。

なお、この大規模回収にあたってサービスの停止やユーザー不利益を与えることは許されないとする。また別サービスを立ち上げてのテストユーザーサービス間移動も許されない。

方針A:サービス機能ごとに切り分けて細かい部分を解析して、小さな改修を加えて、少しずつ改善していく。改善を繰り返す。

方針B:機能単位、あるいはサービス単位、あるいはそれらをより大きな範囲コードを新作してブロックごとまるっと入れ替える。」

方針Aが保守と呼ばれている思想で、方針Bが革新と言われている思想

こうしてみると「AとBってぜんぜん違うじゃんよ!?」ってなるとおもう。主に現場悲鳴的な意味で。

他の競合サービスへのキャッチアップや理想の快適サービスを目指すのであれば、たしかにBが良い。最近開発された新技術も突っ込めるし、技術負債の返済もできそう。だけど、Bでなんかトラブったとき災害ってAの比ではない……。でも競合サービスに勝つため、あるいは環境変化に追従するためにどうしてもBを選ばなきゃならんこともままあるわけで……。そもそもAではなくBでしかたどり着けないサービス設計方針転換だってある。

じゃあAの、つまり保守の言い分ってのは何なのか? と考えると「人間集団(および集団の作るもの)なんて絶対ろくでもないアホやアホミスが混じってるものなんだから、いきなりすごいことしようとしてもコケるんだよ。今現在サービスは稼働してるんだからゆっくり進んでいくしかないんだよ」というもの

例えておいてなんだけど国家というのはWebサービスと違って逃げ場がない。他サービス移住とか容易く出来ないし、サービスが停止あるいは混乱したらすごい大きな迷惑がかかる。死人とか出ちゃう。だからゆっくり行こうぜ。と。

保守のこの言い分は説得力がある。人間は数が増えれば増えるほどカオスになっていっちゃう生き物だからだ。

革新(この場合左派リベラルも)は「みんなから見て素晴らしいこの理想を見せれば、その素晴らしさを理解したみんなは協力してくれるから、この理想は実現するはずだ」という理想主義ともいえる無邪気な思いを持っている。それそのものはそこまで間違ってるわけじゃない。明るい未来ビジョンも見せずに人がついてくるかと言えばNoなので、理想を見せるというのはとても重要だ。

その一方で、理想に耽溺しちゃうと説得する手間を惜しむようになる。程度の低いリベラルは「正しい理想はこれなのになんであなたはそれが分からないの? バカなの? 死ねば?」みたいな態度になりがちだ(あえて例は挙げないけどみんな心当たりあると思う)。

そこへ行くと保守というのは「人間は全員バカなので正しい理屈他者に必ず認められるとは限らないし、ましてやそれが正しい設計や正しい実装として実現されるとも限らない。失敗前提でいくしかない」という、ある現実的な、ある意味非常に後ろ向きとも言える考えを持っている。

だが一方で、保守のその後ろ向きさは「俺はバカだしあんたも多分バカなので、今俺が考えてることを理解してもらうためには手間ひまかけて説得しなきゃならん(それでもうまくいくかどうかは賭けである)」という考えも内包している。つまり、説得したり協力したり、時には泥臭く妥協したり、薄々間違っていると思うことでも頭を下げたりすることを前提としているのだ。

私見だけど、自民党という政党歴史とか規模において他よりの一歩抜きん出た存在になったのは、まさにこの「説得の手間ひまを惜しまない文化意見細部は異なる他人同士が同じ舟に乗るというノウハウを持った」という理由によると思う。これがすなわち思想政治的な正しさ保証するわけではないけれど、多人数が話し合うという政治現場に対して技術力があるという言い方は出来るだろう。

今の日本は概ね保守な方向の国だと思うのだけど、じゃあ、この記事説明した保守という思想に弱点がないのか? といえばそんなこともない。

革新原理主義と相性が良くてダークサイド落ちしやすいように、保守も泣き所がある。それはおおざっぱにいえば「怠惰」だ。

「今現在サービスが稼働してて、変な改修をするとサービス悪化するかもしれない」という考えは、一歩間違えれば容易く「今動いてるんだからこのままでいいじゃんよ」になりうる。そんな風にメンテをサボったシステムリスクで膨れ上がる爆弾みたいなものだ。

また同じように「更新を停止して監視が緩んだシステム」は既得権益の温床になる。特定ユーザー利益を受けたり、地位に居座ったりすることが固定化されてしまう。

この怠惰は話し合いの場にも及ぶ。「アホ同士の話し合いなんてどうせ完全な合意や完全な正解はないんだから、話し合いの内容なんて適当に打ち切って地位が上の人の命令に従えよ」という怠惰は、本当に発生しやすい。妥協必要だっていうのは保守の言い分なのだけど、妥協し過ぎという怠惰には目も当てられない。

これらの怠惰保守思想は本当に相性が良い。世襲制や不顕性のつい良い地方農村的な自治体とか、血族経営企業とか。

しかし、左派がそうであるように「保守の綱紀を引き締めるのもやはり保守であるはずだ。

そもそも保守真骨頂は「たゆまぬ、あきらめぬ」ことにある。

社会をより良い方向に一歩でもすすめる」に関して、その理想の輝かしさは革新保守だ。実現の確度を度外視して「一番良い理想をくれ!」で動ける革新に、保守キラキラでは勝てるはずがないのだ。そういう革新の優位性にたいして保守ができる返答は「たゆまぬこと、あきらめぬこと」でしかない。

一歩一歩は小さくても、「ずっと歩き続ける」「不断改善を続ける」「さぼらない」ことが保守思想本質的な光だ。

その意味保守は「議論をつくす」と胸を張るべきだし、自分メンテするシステム監視を厳しくすべきだ。「相手自分とは全く思想の違う存在でも、ギリギリギリギリまで説得を続ける」という汗のかき方が保守美徳であるはずなので、保守的には「むしろ議論バッチコイ!」くらいが健康的だと思うよ。

2017-12-30

世の中アホの方が多いから、アホを相手にした商売をしないと成功しない←これ

俺のこれまでの人生の失敗の理由は結局のところ全部これな気がする

アホの思考がわからない

人がどこまで合理的でどこから非合理なのか、その線引きをいつも見誤ったサービス設計をする

参考にしようにも周りにアホもいない

アホを周りに置かなかった俺が悪いのか、無意識に賢い人ばかりと交流してしまった

2016-06-29

ソフトウェアエンジニア転職するときに気をつけること

いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。

自分はこんな感じのエンジニアです。

  1. 技術的には広く浅くタイプ
  2. デザインインフラは不得意
  3. マネージメントは不得意
  4. いままで所属していたのは上場企業が多かったが、スタートアップ経験済み
情報収集
IRを読め、短信だけでいいか

これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事

で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。

公開されているコードを読め

公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社評価という点では使えない。

GitHub会社アカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリコミットしているかもしれない。

面談
経営陣や部長クラス技術に対する考えを聞け

社長エンジニアを信頼しているかCTOがいる場合は、CTO社長信頼関係があるか。

技術手段に過ぎない、ビジネスへのビジョン大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。

これはできれば上層部と平社員両方の考えを聞こう。

使っている技術スタックや将来への展望を聞け

技術目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。

もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいかバージョン管理インフラなどの下回りを一新したい、既存社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。

この話は技術者ならば誰から聞いてもいい。もし面談過程技術者がでてこなければ、その会社は諦めよう。

デザインについてのどう考えているかを聞け

ここでいうデザインは「サービス設計」のことね。デザイナー出身マネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。

サービス開発手法については納得するまで聞け

企画デザインプロトタイピング、開発、リリース改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。

これは現役の技術者から聞こう。実際に自分体験することになる日常になるのだから

外注と内製の比率とどういうとき外注するのかを聞け

外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋エンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。

以上。

願わくば、次の転職がうまくいかんことを。

追記

"見出しエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。

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/

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

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

前掲のセキュリティ文書は、 Permalink | 記事への反応(3) | 12:44

2016-01-13

はてなという会社思想よくわかんないんだけど

サービス設計から何を目的としてるのか読み取れないんだけど

何のために増田はてブはてブロをこんな状態にしてるの?

2014-05-24

http://anond.hatelabo.jp/20140524130817

自分サービス設計してて、参考にしようと大手UIを見ると結構駄目なUIの例が見つかる。

それでも大手なっちゃってるって事は、UIなんて実はどうでもいいって事?

大手がやってる事から駄目な部分をひねり出したものなんだから大手に例が見つかるのは当然だよ?

以前、やっちゃいけないUIの例まとめページホッテントリされてたけど

自分サービス設計してて、参考にしようと大手UIを見ると結構駄目なUIの例が見つかる。

それでも大手なっちゃってるって事は、UIなんて実はどうでもいいって事?

2014-04-27

未熟じゃなけりゃ雇われやってないっつーの

「まだまだだな」

全然なってない」

「それじゃ他行っても厳しい」

もっと主体的に」

ビジネスのことも考えて」

あのさ、独立して人雇ってリードしてマネタイズしていけるモノを持ってないから雇われさせてもらってるわけ。

んで、あんたはプログラム書けないからSE雇ってるわけ。

「え、なんでこんな不整合のあるサービス設計してるんですか?論理的に考えましょうよ。経営者なのにそんなんじゃこまりますね」

とでも言いたい。誰も本気じゃないから情熱を足しあわせてなんとか生きていくの。

資金だけあっても、やりたいことが明確じゃないし、チームについて見識は浅いし、教養もない。

まず日本語ボキャブラリーの用法が不正確。

起業する人に俺、幻想を抱いていたみたい。

 
ログイン ユーザー登録
ようこそ ゲスト さん