Wazanova Newsの読者の皆様へ、

この度、Wazanova Newsを卒業することになりました。1年半に渡り応援していただきまして、誠にありがとうございました。

特に、Gittipを通じて継続的に寄付いただいた皆様にお礼申し上げます。3月頭に寄付の受付を終了するとともに、応援していただいた趣旨に鑑み、お預かりしたお金は全額Gittipのサイトの運営側に寄付するかたちに切り替えました。これを通じて、エンジニアコミュニティのために活動する誰かのお役に立てればと思います。

Wazanova News上で執筆を続けていたコンテンツは、人気のものを中心に400本ほどをピックアップし、個人のブログサイト( http://jay7blog.tumblr.com/ )に移行しました。テクノロジーが世の中をどのように変えていけるのかという観点で、今後も時間の許す範囲で書いていこうと考えています。

@WazanovaNewsのTwitterアカウントは私の方で引き継ぎます(アカウントの名称は近々変更します。)ので、フォローしていただければ新しいブログをアップした際には、お知らせさせていただきます。

それでは今後ともよろしくお願いいたします。

Jshiike

Stack Oveflowではサイトの各機能の精度をあげるために、「webエンジニア」「Javaテクノロジー」など、ユーザごとの属性ラベルを付与しています。ユーザは、そのデータをダウンロード、もしくはクエリされないように無効化することも可能です。この仕組みを構築したProvidenceプロジェクトを、同社のエンジニアであるKevin MontroseとJason Punyonが紹介しています。

1) 機械学習における最適なモデルの模索

まず把握したかったポイントは、

  • エンジニアのタイプにはどのようなものがあるか?
  • エンジニアは一つのタイプに特化しているものなのか?
  • タイプごとにサイトの利用形態は変わるのか?

Stack Oveflow Careersにある大量だが曖昧な表現の履歴書と求人データを眺めて、

  • フルスタックwebエンジニア
  • フロントエンドwebエンジニア
  • バックエンドwebエンジニア
  • Androidエンジニア
  • iOSエンジニア
  • DBアドミン

など、11種類のエンジニアタイプを定義した。

次に社内のエンジニアが手分けして、Stack Overflow Careersに登録しているユーザからランダムに抽出された1,237名に対して、手動でエンジニアタイプを当てはめた。その結果、エンジニアタイプにはある種の階層構造がざっくりと存在することがわかった。(階層とエンジニアタイプの概念図)メジャーなエンジニアタイプ階層は、web / モバイル / その他にわけることができる。それを考慮すると、最初にメジャーなエンジニアタイプの階層を検証し、それからマイナーな階層に進む仕組みとした。Stack Overflowのタグの閲覧データ(ユーザに閲覧された質問に付加されているタグを集計したデータ)を元に分析するので、階層別のタグの内訳を下記の通りにまとめてみた。

  • メジャーなエンジニアタイプ階層
    • Webプログラミング言語(java, c#, javascript, php等)
    • モバイルプログラミング言語(java, objective-c等)
    • 非WEB / 非モバイルプログラミング言語
    • iOSデバイス
    • Webテクノロジー(html, css等)
  • モバイルエンジニアタイプ階層
    • iOSデバイス関連(ios, objective-c等)
    • Android関連(android, listview等)
    • Windowsフォン関連
  • その他のエンジニアタイプ階層
    • Stack Overflow使われるTop 100のタグ
    • Top 100ののペアとなるタグ
    • SQL関連(sql, tsql等)
    • DB関連(mysql, postgressql等)
    • Linux/Unix関連(shell, bash等)
    • 数学関連(matlab, numpy等)

タグ閲覧データは総計ではなく、平均を算出してそこからの偏差を使うことが多い。機能によっては、 例えば、Webプログラミング言語のタグ閲覧データを、Webプログラミング言語、モバイルプログラミング言語、非WEB / 非モバイルプログラミング言語それぞれとの偏差を利用するケースもある。

次に、Stack Oveflow Careerの求人データから抽出し、

  • PHP
  • Ruby on Rails
  • Microsoft関連(ASP.NET, IIS等)
  • Node.js
  • Python関連(Django, Flask等)
  • Java関連(JSP, Struts等)
  • WordPress
  • クラウド関連(Azure, EC2等)
  • MySQL

など15種類のテクノロジーのラベルを定義した。iOSとAndroidが含まれていないのは、モバイルの場合は、エンジニアタイプが決まれば利用するテクノロジーもほぼ自明なので、抽出されなかったと考えられる。

特定のテクノロジーに紐づくタグや複数のテクノロジーにある比率で関連するタグが存在するという仮説を実証するために、まずは、「php / php-* / zend-frameworkはPHP」「ruby-on-rails / ruby-on-rails-* / active-recordはRuby On Rails」などの基本パターンを用意してから、機械学習で精度をあげた。

ノイズを取り除くために、テクノロジー毎のタグを500個に制限し、Stack Overflowの質問において使用数が0.05%以下のタグは排除した。

2) 求人バナーのクリックスルー率(CTR)での検証

各ユーザがStack Oveflow Careersに掲載されている求人内容にどれだけフィットするかを、各求人ポジションとユーザの相関値で計測する。

ユーザごとに、11個のエンジニアタイプの%ラベル、15個のテクノロジーの%ラベル、それらのラベルを設定するのに利用したタグの閲覧データの三つが存在する。

また求人ポジションごとに、望ましいエンジニアタイプとテクノロジーのリスト、関連するタグが設定されている。

求人内容が幅広すぎたり(例えば、「どのプラットフォームでもよいのでWebエンジニア」)とか、狭すぎたり(例えば、「この地域でASP.NET / MVC2 / EE4 / F#の経験のある人」)することを極力避ける。

一つのラベルの影響力が大きくなりすぎないようにし、その場合に選択されるべき別のラベルは何かを決めるアルゴリズムについては、リアルタイムで実行できるようにする必要がある。

  • 求人ポジションにない、そのユーザのエンジニアタイプとテクノロジーのラベルは考慮しないようにする。(Androidエンジニアが該当しない求人ポジションは、そのユーザのAndroidエンジニアのラベルを無視する。)
  • 残りのエンジニアタイプラベルのパーセントを足し合わせる
  • 残りのテクノロジーラベルのパーセントを足し合わせる。
  • ユーザにとって最もactiveで、かつ求人ポジションにも該当するタグを見つけ、それがタグのactivity全体の何%になるか計算する。
  • 上記三つのパーセントに対しそれぞれ、事前に用意した比重(パターン別の計算を繰り返して最適値を算出済: エンジニアタイプが1、テクノロジーが2、マッチしたタグが3)を反映させ、その結果を足し合わせる。
  • 結果の値を、ありえる最大値で割ることで相関値を計算する。つまり、完璧にフィットするユーザ像を定義し、そのユーザがどれだけその値に近いかを計算する仕組み。

ユーザの情報がない(オプトアウトしている。)もしくは求人ポジションの情報がない(入力内容が極端すぎたり、不備など)場合も、ランダムにサンプリングしたユーザのマッチの平均で30%-50%にあたる標準偏差に調整したものを利用している。

ユーザに求人広告バナーを掲載したときのCTRで検証している。

  • まず、エンジニアタイプ(メジャー/マイナー)ラベル、テクノロジーラベル、タグを個別にテスト。それから、相関値を地域別の出し分けも考慮してたうえで、A/Bテストする。
  • バグの影響を下げるため、ユーザへの露出率は段階的にアップ。
  • 特定の求人ポジションでのCTR改善が、別のポジションに極端な悪影響がでないことも確認。
  • 全体で27%の改善。

3) 日次の集計作業

HAProxyから取得した、時間 / リクエストURI / クエリstring / 各種のタイミング情報から構成されるログデータを日別に集計。過去6週間の範囲から計算した予測モデルを日次で更新している。

  • ProvinceクッキーGUID(非ログインユーザは、ランダムなGUIDに対して、無効になる期限をかなり先に設定したProvinceクッキーをセットしている。)とユーザログインIDのタイミングデータから、非ログインとログインユーザのアカウントの紐付けを実施。
  • タグ閲覧データ: ユーザ別に、閲覧した質問にあるタグを集計し、最新更新タイミングとともに、Redisインスタンスに保存。
  • タグ閲覧データが更新されたユーザのみ、予測モデルを再計算し、その結果をRedisに取り込む。New YorkのRedisインスタンスから、Oregonのインスタンスへのバックアップも実施。

4) 反省点

最初に仮で、1年間ユーザデータを保存し、15分ごとに予測モデルを再計算すると決めたが、その結果、Cassandraや未知のWindowsサーバアーキテクチャを採用することになった。その新しいテクノロジーが組み合わさった結果、既存の運営/検知ノウハウが活用できず、データセンタ全体の電源障害につながるバグを事前に察知できなかった。

[その他参照サイト]

http://kevinmontrose.com/2015/01/29/providence-what-technologies-do-you-know/

http://kevinmontrose.com/2015/02/04/providence-matching-people-to-jobs/

http://jasonpunyon.com/blog/2015/02/05/providence-testing-and-results/

http://jasonpunyon.com/blog/2015/02/10/providence-architecture-and-performance/

http://jasonpunyon.com/blog/2015/02/12/providence-failure-is-always-an-option/


2014 Topアクセスランキング


サイトが成長していくとすると、ユーザに表示すべきリストのアルゴリズムもそれに伴い調整しないと違和感がでてきます。事例として、Stack Overflowにアクセスすると表示されるTop Questionsリストの時系列での変化をまとめてみました。


1) 当初のアルゴリズム

最新のactivity date(activityの定義は、新しい質問、回答もしくは修正)順にソート

2) 2010年11月

問題点

質問数の急増により回答のペースが追いつかず、50%の質問が未回答の状態になり、Top Questionsリストも未回答が占める状態になる。

実験

calculateWeightファンクションでソートのアルゴリズムの各パラメータをユーザがフロント側で設定/保存できる機能を実験的に提供 [1] し、本件に関心の強いユーザからのフィードバックを募集。(実験を完了した後の最終的なアルゴリズムの反映はサーバ側)

変更後のアルゴリズム [2]

ユーザごとにカスタマイズされた表示をするために、直近のactive質問3000件に対し、

  • Ignoreタグ(興味がない項目をタグで明示できる仕組み)を含む質問を排除。
  • クローズされた質問を再オープンにする評判スコアが足りないユーザに対しては、クローズされた質問を排除。

そして、残った各質問に対して下記の内容で設定したソートのスコアを適用。

  • Interestingタグ(興味がある項目をタグで明示できる仕組み): タグ当たり+1,500、最大で合計+2,000
  • そのユーザのタグ上位40件(Ignore/Interestingで設定したタグではなく、各質問にはタグが最大5個設定されていて、対応したユーザにタグごとのスコアが貯まる仕組み。): タグ当たり最大+1,000(スコアに合わせて調整)、合計で最大+2,000
  • 質問スコア: +200 x スコア、合計で最大+1,000
  • 回答スコア計: -200 x スコア、合計で最大-1,000
  • 回答数: -200 x 回答数、合計で最大-1,000
  • 閲覧数: -15 x 閲覧数、合計で最大-1,000
  • 直近のactivity date: -1 x (秒数/15)

上位90件が採用されるが、更にその3,000件の中からログインユーザに対しては10%、非ログインユーザに対しては20%をランダムに混ぜてから表示する。


3) 2013年5月 [3]

問題点

ユーザとして直感的に感じるのは、利用したタグは全て同じロジックで評価されるべきだとは限らない。利用の動機は様々。また、特定のタグの利用は、それ単体だけでなく他のタグとも絡んだ文脈で使われるケースもある。

本当に知りたいのは未来のこと。既にある情報ではなく、この先どのような質問に回答したいのか。その二つは確実に関連しているが、必ずしも同じものではない。具体的に言うと、ユーザとサイト上でのそれまでのactivityの情報があれば、各タグに対して、そのユーザの将来の回答の何%がそのタグ含む質問になるのかを知りたかった。この場合少し事情を複雑にするのは、各質問に最大5個のタグが設定できるので、パーセントを合計しても意味はない。

検証結果

ユーザが将来回答する質問に付与されているタグを予想するのに、変更前のページと変更後のページに対して、それぞれA/Bテストで検証した結果わかったのは、

  • サイト上で40回以上使われるまでは、そのタグは考慮に入れるにあたいしない。
  • 3回以上回答するまでは、そのユーザの回答はタグの意味合いを把握するロジックの参考にできない。(たまたま出くわした質問に回答しただけで、興味とは関係ないかもしれない。)
  • テクノロジーがこれほどのスピードで変化していても、直近の履歴からサイト全体の平均を計算するよりも、今までの全ての履歴から計算した方が結果の精度が高かった。
  • サイト全体の平均が世の中のプログラマーの回答行動を示す指標になるので、まずサイト平均のタグを抽出し、それにユーザごとのactivityを反映させるのがよい。但し、あるタグが9回以上そのユーザの回答に該当すれば、サイト平均よりもそのユーザの履歴を反映させるほうがよい。3回から9回の間はリニアに変化していくとするのがよい。
  • 新しいユーザは、既存の似たようなユーザと同じ傾向の回答分野を選択するようになるという仮説のもと、既存のユーザの最初のn件の回答を参考し、新しいユーザがどのクラスタにあてはまるようになるか予想。ユークリッド空間の最小距離を計測すると、最初の60個のタグ(= ほぼ回答30件)で440のグループに分けることができた。
  • 「htmlとcss」「javascriptとjquery」「iosとobjective-c」のように、相関関係の強いタグの存在はある。一定量のデータがないと証明できないが、Stack Overflow上では12,000タグが該当した。基本の予想アルゴリズムによるデータを、主成分分析を使って相関関係を計算した結果で少しだけ調整するのがよいとわかった。

Stack OveflowのエンジニアであるKevin Montrose曰く [3] 、

モデリングのプロセスで大きく占めるのは、何のデータを見るのか。網を広く掛けすぎると、検証ボリュームは膨大になる。狭過ぎると、成果を逃すリスクがあがる。

全てお任せの機械学習を盲目的に使った鵜呑みにしないこと。何にでも適用できる手法が可能なケースももちろんありえるが、調査するドメインをよく理解したうえでの自分の感覚を活かしたほうが効果は大きい。

仮説をたてて検証することで、事実を確認するとともに、誤った思い込みを排除するプロセスは本当に重要ですが、闇雲に仮説を立てると、終わりのない果てしない、かつ光の見えない辛く苦しい戦いになります。深く考えて仮説をたてる。つまり、自分なりに落ち着いて考えて、確かそうだと強く思える仮説かどうか、というのが大切ですね。やる人によって、センスの差もでてくるスキルだと思います。


[1] http://meta.stackexchange.com/questions/69571/help-us-choose-a-sort-order-for-the-stack-overflow-homepage

[2] http://blog.stackoverflow.com/2010/11/stack-overflow-homepage-changes/

[3] http://kevinmontrose.com/2013/05/22/your-future-on-stack-overflow/


2014 Topアクセスランキング


今や飛ぶ鳥を落とす勢いのSlackのCEOであるStewart ButterfieldがSarah Lacyのインタビューに答えて、40代のエンジニアを積極的に採用して、夕方6時半にはオフィスが閑散としていると語ってます。記事のとおり、父親母親になった世代の働く環境を重視し、サステナブルな企業をつくりあげることを目指しいている面もあるかもしれません。しかし実際には、20代に極端に偏っているベイエリアのスタートアップの熾烈なエンジニア採用競争に対して、優秀な人材確保のためにリモートワークを戦略的に選択する企業のように、能力の高いベテランを活用する工夫をして、相対的に人材競争力のアップを狙っているのかなと思いました。

ベテランの採用を躊躇する理由は、物事を決めつけたり、フィードバックに耳を傾けなくなったり、新しいことに挑戦しなくなったり、要は、変わりゆく環境に適応できなそうで、伸びしろがなさそうということかと思います。自分の知る範囲でも、確かに一般的にその傾向はあるかと。

しかし、発想を変えてみると違った風景が見えます。今のように環境の変化がものすごく早くなるとどうなるか。フロントまわりのテクノロジーのように毎年トレンドが変わって、ツールが進化していくと、過去の経験のあるなしのハンデがかなり減り、数年で一人前もしくはエキスパートになれる可能性があります。これはベテランにとっても、新しいことを学ぶことに踏み出す勇気さえあれば、環境に適応できるチャンスが高まったということです。但し、環境の激しい変化はチャンスが増すだけでなく、過去の経験という資産が効きづらくなる側面もあります。使い物にならなくなる危険性が高まるゆえに、新しいことに挑戦しないリスクも高まると言い換えることもできます。

こうなると企業の採用においても、本当に優秀な人を確保する競争に勝つためには、候補者の世代ごとのステレオタイプな対応を改める必要性がでてきます。

今までは、社会人経験の短い人に対しては、元気があるかとか、少ない手がかりをもとに、伸びそうかどうかをほぼ勘で決める。経験のある人については、職務経歴書から類推する。ベテランになると、おそらく伸びしろはなくて環境に変化できないだろうという偏見で一律に断るというパターンが典型的だったかと。

まずは、このような時代になると、仕事をした経験は1年であろうが、20年であろうが、自分がどういう人であるのかは、100文字内でまとめるようになると想像してます。経験のない人は、自分のポテンシャルを、読み手の気持ちに刺さるような意味のある100文字にできるか。経験のたくさんある人は、「10年の経験とは、1年間同じことをやって、それを単に10回繰り返しただけ。」と揶揄させることもありますので、要は自分は何者であるのかをシンプルにまとめることができるか。LinkedInのように経歴書を蓄積したサイトの価値は下がり、AngelListの自己紹介のようにコンパクトに何者であるのか効果的に伝えることができる方が役立つ情報になっていくかと。

採用面接は、何ができそうかを判断する場であることは昔も今も将来も同じですが、変化する条件にあわせて新規のプロジェクトをどうつくりあげていくか、既存プロジェクトをどう組み立て直すのかなどのチャレンジを積極的にこなし、かつ達成できる人物かどうかを見極めることの相対的な重要性がもっとあがっていくと思います。


2014 Topアクセスランキング


ものごとが進化すると、利用するユーザの満足度はあがるので、それを用意する作業量はツールの改善に従って最終的には減っていくのか?

スマホが登場して、アプリ上でのスワイプなどの直感的にできる操作や表現の幅が広がり、またディスプレイも改善。では、プロダクトをつくる側がそれに慣れてくると、作業量が減るのか?いや、現実は逆。同じことを実現する作業量は減っても、トータルでは減らない。ブラウザとアプリにまたがって、双方のメリットを取り込もうと、もっとレベルの高いUIを目指した競争が続いています。

David BellonaがTwitter Universityでの講演で紹介してくれているジェボンズの法則にまつわる話を聞くと、同じような矛盾については、昔も今も変わらないものだと理解できます。

最初に触れているのは、現代のエピソード。Googleの元CEOのEric Schmidtが、「我々は、初期の文明から2003年に至るまでの情報量と同じボリュームを、今や二日ごとにつくりだしている。」と言ったように、今やリアルのイベントが開催されると、大量の自撮りの写真がアップロードされます。これがSan Franciscoだと、日本ほど携帯のネットワークがしっかりしてないので、やがて帯域が一杯になって、アプリからのアップロードがしづらくなります。しかし、将来インフラが改善されると、更にコンテンツをアップする需要は増えるのが見込まれるでしょう。テクノロジーの向上が需要を喚起し、次のテクノロジーの改善の道筋がはっきりし、それが必然的に起きます。

そして同じようなことを、産業革命のころにジェボンズが気づいていました。工場に置いた蒸気機関を利用した機械において、石炭を燃焼させる効率をあげることができれば、石炭の消費は減るはずと思いきや、結果は逆。工場の生産能力が上がり、プロダクトの価格が下がると、消費者の需要があがり、かえって石炭をもっと使って生産が拡大していきました。

以上のDavidの話を聞いて思ったのは、最近のUIの競争の際限ない激化も、表現できるテクノロジーの進化に人々が気づくと自然に起きてしまう必然的なものだということ。


Flipboardが今回オープンソース化したReact Canvasは、facebookチームがReact Nativeを発表した際に「Reactは当初から、特定の環境のローレベルの構築ブロックをライブラリレベルで抽象化している。React Nativeは、DOMレンダラーをnativeレンダラーに置き換える..」と説明しているReactの特性を、進化の余地だと気づいていたので、それをCanvasに応用したということかと。

モバイルブラウザにおける無限スクロールのパフォーマンスを向上させたいが、DOMでは60fpsを実現するのは厳しい。DOMのような保持モードAPIは、描画するオブジェクトの階層を維持する、つまり情報をキープすることで追加のメモリが必要となり、画面を更新するのが遅くなる。一方、Canvasであれば、描画のコマンドがGPUに直接送られることで、即対応できるメリットがある。しかし、例えば画像の上にテキストを表示するケースなど、エレメントを重ねて描画するのにリソースが非同期で読込まれると難易度があがる。HTMLがエレメントの順番を簡単に操作できたり、CSSがz-indexで対応できるように、Canvasを利用する場合は、高レベルの抽象化を用意してあげる必要がある。

その概要は、

  • JavaScriptでスクロールを実装。
  • スクロールのモーメンタムの計算は、オープンソースで提供されているZynga Scrollerを利用。
  • 単一のCanvasエレメントで実現。タッチイベント毎に、スクロールのオフセット値を元にノードを解釈し、レンダーツリーが更新される。そして新しいフレーム座標にあわせて、全体のレンダーツリーが再描画される。スピードが遅くなるように聞こえるかもしれないが、描画操作の結果はオフスクリーンのCanvasにキャッシュできるので、それを利用してレイヤを後ほど再描画することで、最適化できる。画像にもテキストにも使えるし、一度レイヤを描画すれば、オフスクリーンを利用した再描画はすばやくできる。
  • Reactで宣言型APIを用意。レンダー構造を直感的に表現できるようになった。
  • スクロールにおいて、その瞬間のスクリーンで見えるアイテムのみをレンダリングする際、Reactのdiffアルゴリズムが相当早いのが役にたっている。

注意点としては、

  • React Canvasは、DOMを完全にリプレースすることを目指したソリューションではない。パフォーマンスの用件がクリティカルでないところは、DOMの方がよいかもしれない。Flipboardのモバイルweb版は、ネイティブとweb技術のハイブリッドではなく、DOMベースのUIとCanvasレンダリングを組み合わせ、全てwebコンテンツで構成されている。

2014 Topアクセスランキング


マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。

1) 非同期 & 可視化が進む

  • GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。

2) マネージャの役割が変わる

  • 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。
  • プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向上 / メンター / キャリア相談 / チーム編成 & 異動 / 採用 / (米国だと) 解雇など、多岐にわたっていたマネージャの役割は、今後は分散化していく。分散化しない決断をした組織においても、少なくとも役割の質は変わっていく。
    • Spotifyのエンジニア組織には、プロダクトをデリバーする責任をもつProduct Owner、チームメンバの目標設定 & マネッジしプロダクトのアーキテクチャを担保するTeam Lead、チーム内の協調/エンジニアの成長につながるような環境づくりをするAgile Coachがいる。[1]
    • Mediumでは、Domain Leadにアサインされたシニアなメンバが、メンターとなり、メンバへのフィードバックを行うが、採用と解雇の権限も持つ。プロジェクト / タスクではなく、人に責任を持つという役割。[2]
    • GitHub上の各レポジトリでの開発の進捗をリードしている人が、組織のマネージャだとは限らないのは、多くの会社で既によくあるケースだと思われる。

3) マネージャという生き物は絶滅しない

  • Googleのように、マネージャ制を撤廃した後に元に戻した事例があるように、組織がある限りは何らかの役割について取りまとめる人が必要になる。[3] それが全権をもったマネージャでなく、役割が変わり、かつ分散化し、数が減り、適さない人がその役割を担うケースが減り、そしてしばしば名称が変更になることがあるが、絶滅はしない。
  • 1) の効果として階級構造が減る傾向にはなるが、本当にフラットな組織にはならない。フラットに近づくだけである。もしくは、フラットではないが、フラットになったつもりで皆が高い意識での責任感を持とうという心の持ちかたの話である。
  • 競争力のある会社は、メンバの自主性を活かし、モチベーションの高い組織を運営している。自主性がパフォーマンスをあげるという考え方は更に浸透していく。とはいえ、自主性を活かせる範囲が広がっても、全社の方針などでの調整が必要なケースはでてきて、その役割をマネージャが担うことになる。
    • TreeHouseは社員によるタスクの提案 & 投票 & 自分で担当を決めるという、完全に自主的な仕事を進め方を目指したが、「経営陣から共有される経営方針に沿って」という前提があるし、「必要だけど誰も手をあげないタスクを誰かにアサインする」ということはしている。[4]
    • Valveは、高収益かつフラットで自主的な仕事ぶりで有名ですが、必要なチェック & バランスが働かない副作用はあるとの発言もある。 [5]
    • Netflixも、「仕事はかけた時間でなく成果であるので時間管理はしない、年休の管理もしない。」「会社経費の使用はルールで縛るのではなく、最悪自腹を切ってでも仕事に必要だと思うかとという質問に自分で答えて判断する。」[6] としても、大人として振舞う常識の範囲を超えるとなれば、指導はされる。[7]

4) 進化が遅いのではなく、全員一律が時代にそぐわない

もっと自主的に仕事したいという不満と、ダメな上司にあたってしまった不幸を恨む力にも後押しされて、マネージャ不要論とまではいかなくても、マネージャのスリム化 & 分散化はそこそこ進んでいくでしょう。また、1) の傾向であれば、リモートワークが増えていくことも期待したくなります。しかし、右肩上がりにどんどん進化していく気もしません。

抵抗勢力がいるからか?それもそうですが、それよりも、世の中の関心は人それぞれ様々で、1) のような仕事の進め方やコミュニケーションの進化で管理コストが全体で減るならば、その工数を、もっと個別のメンバの期待に応えることが求められてるのかもしれません。個々人の関心が違えば、全体の変化の傾向は単に総計したデータの結果であり、それがフラットになってきているとか、リモートワークが進んでいるとか評価するのはあまり意味がなく、大切なのは、一人一人が自分のあるべき方向に近づいているか実感できるかというところだと思います。

MediumのJason Stirmanは自らの経験から、

マネージャとして、何がそのメンバのモチベーションを高めるのかを見極める。チームを見回して、「みんな相当頑張ってるから、昇給しなくてはいけないな。」というマネージャもいるが、それが各人にとってベストなインセンティブだとは限らない。」

と語っています。彼が参考にしている、”Your Brain at Work”のSCARF分類例は、

  • ステータス重視のタイプ: 自身の肩書きや、重要なプロジェクトに名前が載るかが重要。
  • 確実さ重視のタイプ: 自分のタスクが全体にとって大切であり、うまく進んでいると太鼓判を押してもらうと安心できる。
  • 自主性重視のタイプ: リモートワークや、仕事中にヘッドフォンをつけて集中してよいかという自主性を重んじる。
  • 関係性重視のタイプ: 飲み会や皆んなでのスポーツなど、メンバとつながっていることを実感できる機会にモチベーションがあがる。
  • 公平性重視のタイプ: 仕事の環境や条件は皆公平で、誰もごまかされたりしていないかが重要。かつ、それをしばしば確認したくなる。

マネージャは、情報操作ハブから早く脱し、メンバの個別のモチベーションをサポートする役割にもっと進化するのが求められている時代。「人をよく理解する」というのは昔から重要ですが、組織運営の中では、全員一律論、右に倣え的な雰囲気の中で、霞んでいたのも否めません。「キャリアの点と線」でも触れた、メンバの「なりたい自分像」を把握する試みも、これからはあるべきという意味で、同じ個別サポートの延長線上の話かと。

[1] http://wazanova.jp/post/62296563955/devops-spotify

[2] http://firstround.com/article/how-medium-is-building-a-new-kind-of-company-with-no-managers

[3] https://news.ycombinator.com/item?id=9000328

[4] http://wazanova.jp/post/66337466350/treehouse

[5] http://www.gamasutra.com/view/news/195786/ExValve_hardware_expert_shares_uncommon_look_inside_the_company.php

[6] http://wazanova.jp/post/63021846567/netflix-culture-freedom-responsibility-1

[7] どこかで読んだのですが出典を忘れました。すみません。。


2014 Topアクセスランキング


フレームワークやツールが進化することで、そこそこのスキルがあれば比較的短い期間でもそれなりのプロダクトをつくれるようになるという恩恵を世の中全体が享受できますが、一方で才能のある人たちは、その便利になった道具を利用して、更に先に進みます。そしてUIの競争は際限なく続きます。

一つの目のパターンは、意外なところまで気遣いをしているので、それを発見したときにポジティブな喜び、驚きを感じるところ。

Slackを使っていると、

  • 登録済のパスワードの入力を求められる画面で、スマホキーボードでのパスワード入力を面倒に思う人、もしくはパスワードが長い人に配慮して、「パスワードを入力する替わりに、リンクをメールに送って、クリックするだけにしますか?」という選択肢が示される。
  • 衝動的に複数人にメッセージを送ろうとしたときに、時差があるところにいるメンバが含まれていたら、「このメッセージを受け取る人が4つのタイムゾーンに分かれてますが、(寝てる人もいるかもしれないのに)本当に送りますか?」と確認のダイアログが表示される。

などは、本当にそこまで仕様として必要かという好みは分かれるかと思いますが、「こうすればユーザはもっと使いやすいはずだ。」と徹底的に考えている人がいて、即実装している結果かと。

二つの目は、ものすごく自然にスムーズで使いやすいのだけれども、どうしてかと言われると説明してもらって初めて気づくようなユーザ体験を実現するために、裏側で相当な気遣いと努力が払われているケース。

そいう意味で、Twitter Videoを担当したPaul Stamatiouが、その取り組みをまとめた長いブログのエントリーはとても参考になります。

Paulは以前、「Provide meaning with motion」というエントリーで、Androidのマテリアルデザインの発表をうけて、「Googleが暗黙的にアナウンスしたのは、これからのデザイナーにとっては、アニメーションや遷移など、モーションをデザインするスキルが重要になるということ。」と発言しています。そして彼自身の日々の仕事のスタイルも、Framer.js & Framer Studioをヘビーに使ったプロトタイプ駆動型です。

プロトタイプのおかげで数千回の会議が不要になる。

但し、

プロトタイプづくりには相当な時間がかかるし、本質でない技術的なチャレンジを解決しなくてはいけなくなることもあるので、「どんな使いごごちになるんだろう。」という大きな問題を解決したくなったときだけ取り組むようにしている。

さて、Twitter Videoに話しを戻します。Paulは、Google Venturesが短いサイクル(Google Venturesでは一週間単位)でアイデアを具現化していくspringメソッドにおいて唱えている「Understand, Diverge, Decide, Prototype and Validate(目標/問題点を理解し、アイデアを膨らませて様々な角度から検証し、方向性を決め、プロトタイプをつくり、ユーザのフィードバックをもらう)」の考えに沿って、750枚を超えるSketchモックアップと54個のFramerプロトタイプを経て作り込んでいます。

最初は、録画のページと再生 / 編集画面のページに分かれた構成にはじまり、

  • 全体を一つの画面にまとめつつ、編集したいユーザはスムーズにできるが、録画から即投稿したいユーザのアクションを妨げないという用件を両立させる。
  • ユーザのアクションに対する明確なフィードバックを与える。録画したビデオの自動再生機能などアプリ側が行うアクションも、その進捗がビジュアル的にわかりやすくユーザに伝わるように工夫をする。
  • 録画中に残り時間を示す進捗バーを工夫なしに表示すると、時間が長く感じるし、ユーザが無駄に最大時間(30秒)録画してしまう
  • ユーザは録画すべきタイミングより前に録画ボタンを押す傾向がある。よって、画像編集画面においては、クリッピングするデフォルト箇所の起算はビデオの頭からでなく、後ろから数えた秒数の範囲が選択されるようにしている。またクリッピングのデフォルト範囲を20秒にすることで、ユーザが最大の30秒を不必要に選ばないようにして、短めのコンテンツの投稿を促している。

などいくつかの問題をステップごとに解決していった様子が、各デモビデオで紹介されてますし、ユーザテストの様子も載ってますので、是非原文をチェックしてみてください。

また、プロトタイプを実際にiOSとAndroidのコードに落とし込んでいくプロセスについても触れています。プロトタイプで設定した値をそのまま適用できなくて、OSごとのノウハウが必要なこと。Paul自身がアプリの実装をするエンジニアとペアプログラミングすることでコードの構成を把握し、プロトタイプをアプリ上に着実に反映させるための指摘力を上げていったこと。

デザインとプログラミングにまたがる人材を育成することの重要性はどんどん上がってきますね。

“The details are not the details. They make the design” - Charles Eames (詳細にこだわるというのは細かいことではなく、それがデザインをつくりあげるということである。)


2014 Topアクセスランキング


Benjamin Supnik曰く、高いパフォーマンスをだせるソフトウェアは、高いパフォーマンスを目指したデザインプロセスが大切。「本当にひどい状態になったら、プロファイラで調べて直すから。」といっても色々積み重なると簡単には直せなくなると指摘しています。そして、ゲーム開発において遅いコードを生み出すパターンを挙げてくれてます。

1. 無駄なことをする

  • テーブルを再描画する際、ユーザが見える部分だけでなく、テーブル全体のデータを取得していないか?
  • 同じ値が計算されて何度も使われるケースで、都度計算し直していないか?
  • 必要とするのが現状のステートであるのに、描画の度にOpenGLのステートを更新していないか?
  • エディタプログラムを使ってドキュメントで大量のアイテムを編集するケースで、アイテムごとにUIを更新していないか?最後にまとめて更新すればよい。
  • 非効率なアルゴリズムの選択。
  • terrainをシェードするのにGPUを使うか?それとも、事前にシェードして、ディスクに保存するか?ほとんどのケースで事前に処理する方がよい。
  • レーシングゲームで、建物はどのレベルにも配置する必要があるか?それとも、ドライバーが見える範囲だけに収めるか。どこにでも配置すると、ディスクから読み込み、cullして、レンダリングする作業が余計にかかる。

2. 定数時間の非効率を放置する

  • 静的に保存できるのにmallocで動的にデータをアロケートする。
  • std::vectorでよいのにstd::mapを使う。mapはmallocを大量に呼び出してしまう。
  • スタティック関数やインライン関数でよいのに仮想関数を使う。
  • static_castでよいのにdynamic_castを使う。
  • キャッシュの局所性が弱いメモリ構造を採用する。

この影響が大きくなっている背景として、

  • CPUとメモリパフォーマンスのギャップが拡大している。L1キャッシュが3サイクルであるのにメインメモリへのキャッシュミスが300サイクルかかると、定数時間の係数部分の局所性が100倍になる。
  • デスクトップではそれほどではない(遅延を隠すために超高性能チップがかなりアグレッシブに働いてくれる。)定数時間の係数が、コンソールでは依然として相当悪い。モバイルでも同様。Mac Proではそこそこ動いてくれるヒドいコードは、iPhone 4Sでは悲惨な結果となる。
  • コードのほとんどで同じツールを使う傾向にある。よって、遅い定数時間のテクニックを採用するとコード全体に影響を与える。該当箇所を直すのではなく、全体を書き直す羽目に陥る可能性がある。

3. 余計な抽象化の影響

  • 個別の課題の解決に、一般的なソリューションを適用してしまう。
  • 簡単な問題を更に計算能力を必要する解決策で対処してしまう。
  • プログラム間に、シンプルな、だがパフォーマンスコストの高い抽象化を適用することで、特定の問題に直接対応する機会を失ってしまう。

具体的に起こりうるのは、

  • AABB(軸に平行な直方体)に対してトライアングルをクリップしたいだけなのに、アルゴリズムが、ホールのある二つの任意のポリゴンの交差をとってしまう。
  • drawingファンクションが、ユニバーサルトライアングル(色、テクスチャ、ポジションを伴うトライアングル)を描画し、アプリの全てのパーツにその形式での呼び出しを強制してしまう。
  • WorldEditorが必要な箇所でなく全体を再描画してしまう。

2014 Topアクセスランキング


Reactは当初、「Huge step backwards(これではメンテできなくて、かえって大きく後退してしまっている。)」「Rethink established best practices(皆が積み上げてきたベストプラクティスを変えようとしている。)」と揶揄されたりもしましたが、最近は他のJavaScriptフレームワークにもその思想の一部が反映されるようになって、メインストリームに近づきつつあるようです。

さて今回Facebookが、React Nativeを発表 & オープンソースとして公開するとして話題になっていますが、Tom Occhinoは React.js Conf 2015のキーノートスピーチで、「一度書けば、どのプラットフォームでもうまく動作する。」ではなく、「一度覚えれば、どのプラットフォーム向けにも書けるようになる。」ものであることを強調しています。

同社の開発メンバの声を拾うことで、その全容を探ってみました

  • まずは、iOSとAndroidがターゲットプラットフォーム。
  • JavaScriptエンジンがバックグランドで実行される。
  • メインスレッドで実行されるネイティブサーバと、バッチ形式の非同期なメッセージプロトコルでやり取りする。(基本的に、create_view( ), update_view( ), destroy_view( ), on_event( )など)Reactのためにそのプロトコルを使えるプラグインという立ち位置。
  • Reactは当初から、特定の環境のローレベルの構築ブロックをライブラリレベルで抽象化している。React Nativeは、DOMレンダラーをnativeレンダラーに置き換えることで、<div> / <span>の替わりに、プラットフォームの<View> / <ScrollView> / <NativeWhatever>をレンダリングできるようにしている。それ以外は、既存のReact APIと同じ。
  • React Nativeの真の価値は、学ぶのが簡単なReactを使って、エンジニアが相当な努力をせずに優れたUXのアプリをつくれるようになるということ。
  • 標準のテキストコンポーネントやクロスプラットフォーム向けのflexboxレイアウトシステムなど、クロスプラットフォームでの開発を多少手助けしてくれるツールが用意されている。
  • ネイティブプラットフォームのviewを活用できるように設計されており、Java Swingのようにはならない。
  • CSSのサブセットもポーティングされている、nativeアプリをCSSでスタイリングすることも可能。
  • Facebook GroupsのiOS版は、React Nativeをベースに開発されている。

パフォーマンスについて説明する背景として、React Nativeが他と異なるアプローチを採用している理由は、

  • 「エンジニア自らの開発のフィロソフィーや習慣を変えなくても自動的に素晴らしいモバイル体験をつくれるようになる。」とは言っていない。モバイルの開発をしていれば、UXについて気にかけるし、パフォーマンスにも注意を払うので、コードがやり取りするニュアンスを大切にしなくてはいけない。素晴らしいUXを実現している作品の背後には、必ずそこに注力する人がいる。しかし、React Nativeであれば、そのレベルに至る工数を削減できると考えている。
  • React NativeはDOMをまったく利用していない。Reactは、ブラウザーにおいて想定外のプログラミングに起因するパフォーマンスの問題の多くを、うまく対処してくれる。そしてReact Nativeは、ブラウザでできることを超えて次のレベルまで進んでいる。Reat Nativeが示したのは、一般的に支持されている「バーチャルDOM」よりも、「ゼロDOM」をReactJSが志向しているということ。
  • Web開発のベストなところをアプリに適用できるのが、React Nativeの特徴。ネイティブviewのパフォーマンスやリソースコントロールをキープするためには、webでのよいところを捨てなくてはいけないわけではない。React Nativeだと、FlexBoxでネイティブのviewをレイアウトできるし、その他のよく使っているスタイル属性も利用できる。しかも、致命的なCSSのリフローも避けられる。ライブラリのコードが同じなので、既存のReactアプリと同じイベントシステムが動作する。勝手のわかるwebスタイルとレイアウトを使って、ネイティブアプリの実装を素早くできるようになる。まったく新しいツール群を学びなおさなくてはいけない他のアプローチと比較すると、この方が当然良いと思っている。
  • React Nativeの差別化のポイントは、クオリティの高いアプリをJavaScriptで書けるということ。ブラウザだと限界に突き当たる。プラットフォームのコンポーネント(physics/mapの特定のスクロールビューなど)にアクセスできないか、実装しているやり取りがイメージでコーディングに邪魔されてどうしようもなくなるとか。React Nativeだと、以前はJavaScriptでは実装(mapなど)できなかったネイティブのプラットフォームのviewを使ってアプリをつくれる。高いパフォーマンス粒度の構築ブロック(マルチスレッドでデコードされた<Image />や、DOMをまったく使わない<View/>ブロックなど)を使うこともできる。このおかげで、プラットフォームごとの特徴に合わせたクオリティの高いものをつくりだせる。
  • 基本的には、AndroidとiOSでなるべくコードをシェアすることはやってもらいたいものの、「一度書けば、どのプラットフォームでも動作する」ものではないことを留意してほしい。例えば同じiOSにおいても、iPhone6+のスクリーンに対する最適化などへの考慮は重要。なので、個別の環境に合わせた実装は常に必要になってくる。

ここで約束されているネイティブらしいUXを本当にうまく実現できる手法なのか。やや懐疑的な声もありますし、一方で、FacebookのChristopher Chedeauは「既存の素晴らしいネイティブコンポーネントをつくり直そうとして失敗したアプローチがこれまでは多かったが、React Nativeはそれをうまく利用する。」と説明してくれています。その成否は、今後色々情報がでてくるかと思います。

[参考資料]

https://www.youtube.com/watch?v=7rDsRXj9-cU

https://news.ycombinator.com/item?id=8961551

https://news.ycombinator.com/item?id=8963710


2014 Topアクセスランキング


Minecraft的なものをGo言語で試してみた経験をまとめたブログのエントリー。専用のツール / ライブラリ / エンジンなどはまだ充実はしてない中で、Goがゲームづくりにどこまで使えそうかと考えるうえでの参考になればと思います。

採用のポイントとしては、

  • アウトプットスピードがCと同じでなくても、近づきつつある。
  • Cとのインターフェースが簡単。
  • メモリレイアウトの操作のしやすさ。
  • ガベッジコレクションにおいて、メモリモデルを利用してガベージを安易に増やさない工夫ができる。
  • 概ね安全に書ける。
  • コンパイルが早い。
  • オーバーヘッドがほぼかからないGLのバインディング。
  • ビットバンギングにも向いている。
  • 優れた並行処理primitive & network。

注意点としては、

  • 気の利いたデバッガーがまだない。サーバ側の開発では、リクエスト/レスポンスのログメッセージを見ながらデバッグすることが多いので許容できるが、複雑なレンダリングのアルゴリズムや、かなりステートフルなクライアントコードに対処するには辛い。
  • デスクトップ、Android (NDK)は問題なし。iOSサポートはまだ途上の様子。

その他、具体的な感想としては、

Goコンパイラは単一の静的にリンクされたバイナリを生成する。わずかなランタイムはあるが、それ以外は邪魔にならず、システムコールとのやりとりにおいて無駄なハードルはない。とすると、大きなランタイムやVMの話ではなくて、ツールチェーンの問題になるので、コンソールのプラットーフォームをカバーするのも可能ではないかと思った。

GoのstructとポインタはCに似ていて、違いはポインタ arithmeticが不正だということ。つまり、フラットなメモリレイアウトでstructを実装できる。例えば、64ビットのプラットフォームに、正確に 4 (unit32) + 64 (16 float32s) + 8 (64ビット ポインタ)バイトをセットできる。いくつかのarrayやsliceに適用すると、ヒープ上で、境界を挟んだ一つのブロックがつくれる。メモリのレイアウトのコントロールがしやすい。

Cでは安全にstructやarrayの間にポインタを向けることができる。この仕組みは、Goにおいて最適化に応用できる。キャッシュの一貫性だけではなく、独自のpoolアロケータをつくれる。たくさんの同じstructをアロケートしなくてはいけないがガベッジを減らしたいときに、ヒープのアロケーションが一つで済むので有効。

60 fpsを達成するためには、フレーム間の予算は16msになる。そこでガベージコレクタが入ってストップすると悪夢。なので、メモリの安全性を担保したまま、ガベージを減らせるのは大変ありがたい。

OpenGLとのインターフェースには go-glを利用。GLの無数のhandleの型を忘れたことによるエラーが防げたり、他の言語のようなラッパーオブジェクトでないのでランタイムで消えてくれるケースがあることで、機能を気にしなくてもよいというメリットも享受できた。

ハイレベル言語によるゲーム開発でよく陷いるのは、ローレベルに対処したとき、例えばリソースの読み込みの実装が不適切な際に、急速にメモリを消費してしまうケース。Cだとシンプルにリソースファイルをmmmap()などでメモリにマップして、structでvert/index arrayポインタを使って、マップされたファイルに直接向けることができる。Goの場合は、mmap-goが提供してくれるクロスプラットフォーム mmapの抽象化機能で、問題の半分を解決してくれる。その後で、[ ]byteをどうやって[ ]float32にするかなどを考えるとよい。このあたりの工夫をガベージコレクタが気づかないことのリスクはあるが、C++でやるよりは安全で早い。


2014 Topアクセスランキング


Prometheusは、SoundCloudが中心となって開発を進めているオープンソースのプロジェクト。Dockerの社内でもメインのモニタリングシステムとして利用されているようです。

各社のブログのエントリーから、その特徴をまとめると。

  • 多元データモデルとそれを活かす柔軟なクエリ言語
    • 全てのデータにタイムスタンプのある、OpenTSDBに準じたデータモデル。
    • http_response_500_totalhttp_response_403_totalなどHTTPレスポンスのステータスごとに用意しなくても、ラベルで分類できる。api_http_requests_total{method="GET", endpoint="/api/tracks", status="200"}
    • コンテナの分析の例として、「同じ名称のコンテナのデータをまとめたいが、特定のイメージだけを選別する。」「本番マシンのデプロイと本番内の一部ユーザだけに露出するカナリア版を比較する。」「時間軸 / 正規表現でのフィルタリング、ホスト / 環境 / ゾーン別の分析」など、柔軟な切り口での分析をサポート。データをまとめることに関してはGraphiteよりも良い。
    • インスタンスごとにメモリ消費 / メモリ上限 / CPU消費 / アウトオブメモリエラー / インスタンスの再起動などを確認する際に、さらにアプリごと / プロセスタイプ / Gitの修正履歴 / 環境 / インスタンスIDなどで分類できる。直近5分のCPU利用上位をアプリごと、プロセスタイプごとに集計したり。デバッグや、設定ミスの発見がたやすくなる。また、分析に時間がかかるものは、バックグランドで事前に計算もできる。
  • ダッシュボード
    • 柔軟なクエリ言語が活きる。
    • GUIベースのダッシュボードビルダー + SQLバックエンド。設定が容易。HTTP API経由で複数のPrometeusサーバとやりとりが可能。Graphiteのグラフの組み込みも可能。
    • コンソールテンプレでシンプルにつくることもできる。
    • 複数モードでのビジュアル化やダッシュボードをサポート。
  • アラート通知
    • クエリ言語を活かし粒度を柔軟に設定。
    • Alertmanagerを介して通知とその取りまとめを行う。Prometheusの他の機能と比較すると、完成度という意味でまだ改善の余地あり。
    • Nagiosのプラグインあり。
  • システム関連情報
    • Prometheusスタイルのモニタリングはコードをダイレクトに操作する。これは、「モニタリングされるアプリは、プラグインか、独自の言語でやりとりするエージェントを介しているので、モニタリングシステムのことを知らない。」というアプローチとは異なる。
    • Go / Java / Ruby向けのクライアントライブラリが用意されている。HTTPを介するプルモデルで、フォーマットは基本はprotocol bufferだが、シンプルなテキストフォーマットも利用でき、ライブラリいらず、つまりシェルスクリプトからも対応できる。
    • 従来のモニタリングのアプローチにも対応できるように、HAProxyやNodeのエクスポーターも用意している。AWS Cloudwatch連携あり。
    • 中間のゲートウェイを利用してタイムシリーズのプッシュもサポート。cronjobのような短命でスクレイプに間に合わないものには、データをプッシュするPushgateway機能がある。
    • 分散ストレージへの依存なし。単一のサーバnodeが自立している。
    • 何でも分散化という流れがあるが、実際問題はメンテは大変。毎秒、数百万のタイムシリーズと数万のサンプルを一つのサーバのローカルディスクで処理できるようにしている。機能ごとにサーバをシャードして、シャードを複数レプリしたものを実行することにより冗長性を担保。サーバ間のクエリはできないが、階層的なスキームをつくり、上位のPrometheusサーバが下位のサーバから特定のデータを集める仕組みができる。ローカルのタイムシリーズDBは、インデックスと実際のサンプル値とタイムスタンプの保管にはLevelDBを採用。PrometheusのエコシステムをOpenTSDBのコレクションマシーナリーに変えることで、永続的なストレージとして集めたサンプルをOpenTSDBにストリーミングする仕組みを実験的につくっている。将来的にはPrometheusからのクエリでOpenTSDBからデータを読み込めるようにして、ラウンドトリップを実現したい。他のタイムシリーズDBのサポートの可能性もあるが、データモデルの違いがけっこうチャレンジである。
    • サービスディスカバリもしくは静的な設定でターゲットを見つけられる。
    • 分散ストレージバックエンドや再設定の手間なし、モニタリングサーバを必要なところ(ローカルのワークステーションでも)で立ち上げられる簡単さ。
    • スケーラブルで分散アーキテクチャ、別のチームが独自のモニタリングシステムを立ち上げることも可能。
  • パフォーマンス
  • ランニングコストの低さ
    • Boxever社のケースでは、タイムシリーズのスクレイプは、Amazon m1.largeは毎分50万件程度までスケールでき、6ヶ月保管するとして、タイムシリーズあたりのコストは月間$0.001程度。

[参考]

http://www.boxever.com/tag/monitoring

http://5pi.de/2015/01/26/monitor-docker-containers-with-prometheus/


2014 Topアクセスランキング


CSS-Tricksのエントリー。Chris Coyierが、「相手を思いやること、相手の立場にたって考えることが一番大切なスキルの一つ。」と語っています。

相手の立場にたつと、自分がつくったプロダクトをユーザがどのように使うのか理解でき、そのおかげでUXスキルを磨くことができる。サポートメールを書くときも文面を工夫できるようになる。ミーティングも意味のあるものにできる。コミュニケーションを受け取る相手がどう感じるかを考えれば、明確に相手に伝えることができるようになる。

それを実践するために、

相手への感謝を忘れないこと。相手にとって、自分が嫌なヤツになりかけたとしても、自分でそれを阻止することはできる。怒りは怒りを引き起こし。やさしい気持ちはやさしい気持ちを生み出す。

キツイ表現でなく、正直にフィードバックすることも大切。Web開発において、バグを伝えないことは思いやりではない。バグレポートを書くことで、相手の立場にたっていることを示すこと。

大切なスキルだというのは誰もが賛成すると思いますが、それでも努力が足りないと日々反省させられるのは、「一番」であるという心がけが足りないのかもしれません。

また、自分は様々な状況の中で揺れ動いて日々を過ごしているのに、他人のことは、無意識のうちに型にはめて判断しがちだということもあるかも。

Ben Casnochaが、PayPal / LinkedInのFounderであるReid Hoffmanについて書いた「10,000 Hours with Reid Hoffman: What I Learned」において、

人はしばしば他人の強みや性格を白黒で分けようとする。「あの人は素晴らしい」とか、「やつはアホだ。」とか。「倫理観の王子のようだ。」とか、「勝利が全てだと都合が悪いことは見て見ぬ振りをするハスラーだ。」とか。それは残念な傾向で、人の強みは常に流れの中の関連性で決まる。オスカーワイルド曰く、「聖人は皆、過去があり、罪人には皆、未来がある。」人間というのは複雑なものである。

必要なのは、長い文脈の中で理解すること。また、「思いやろうとしても理解できない。」でなく、「ものごとには両面があることを理解し、相手の強みを活かすかたちで思いやること。」かと。

相手が過ちを犯しても、弱点が露呈されても、長い期間で育むお互いの豊かな関係において、たった一つのデータポイントに過ぎない。Reidは、一度の失敗や一つの欠点で相手に対する評価が曇ることがほぼない。だから友人は皆、彼に対して忠実なのである。

多くの弱点には対となる強みがある。Reidはものごとを整理するのがあまり得意でないが、その無秩序が彼のクリエイティビティの源である。弱点は強みに変えればよい。実績がなくて信頼を得られないことを心配するのではなく、既存のものに縛られないで新しい観点で実行できるとアピールできる。頭の回転がものすごく早いわけでなければ、逆に思慮深くディテールにこだわり仕事を進めればよい。

ちなみに、「10,000 Hours with Reid Hoffman: What I Learned」は長文ですが、他に「ビジョンの副作用」などReid Hoffmanの含蓄のある考え方がまとまっているので、一読をお勧めします。


2014 Topアクセスランキング