tchikuba's blog

クリエイティブが輝ける組織をエンジニアリングする

イベント「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言！～ 女性エンジニアとして長く働く秘訣 ～」に参加しました！

先日「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言！～ 女性エンジニアとして長く働く秘訣 ～」 というイベントに参加してきました。 私の妻も私と同じエンジニアでdots.女子部の一員として運営に関わっています。 妻からこのイベントを企画していることを事前に聞いており、参加を楽しみにしていました。

参加した当日はノートPCを持っていくのを忘れていたので、スマホからひたすらtwitterで実況中継していました（笑） 備忘録的な意味も込めて、当日のtweetをtogetterまとめっぽくお届けします。

※遠距離恋愛の参考にしたいというdots.女子部メンバーの話を受けて

夫婦共働きで子供がいるってどんな生活リズム？

家事の役割分担とかどうしてる？

子供にはお金がかかるけど、どうやって踏ん切りつけた？

夫婦でエンジニアって同業のメリット・デメリットは？

地方移住とか考えたりする？

※リモートワーク的な文脈での話。

2人目ができると更にカオスって聞くけどどう？

どれくらい産休・育休って取ったの？

今後の夢とかは？

終了後の懇親会

オサレなケータリング

竹馬 力さんの投稿 2016年3月24日

他の参加者の方の感想

やっぱりエンジニア夫婦って(・∀・)ｲｲﾈ!!

勉強会に参加して感じたことです。 同業だと問題もあるという話を聞いたりもしますが、ふたりともエンジニアである場合、メリットばかりが目についてデメリットってほとんど思いつかないです。 テクノロジーへの理解があるという点、非常に共感しました。新しい製品を買ったりするのに家庭内稟議は圧倒的に通りやすいんじゃないかとｗ

あと、今回登壇されたご夫婦2組とも、男性の優秀さもさることながら、女性の優秀さが凄いなと感じました。 なのでプログラマである私の妻にも、このご夫婦に見習って凄くなってもらおうと思います（笑）

エンジニア・チームのダイバーシティ向上を！

私は日頃から、ダイバーシティの観点から、あらゆる組織は男女比率がおよそ半々である方が良いと考えています。 しかしながら現時点では、特にエンジニアの世界では圧倒的に男性比率が高い状況があります。

たとえば、10代、20代の女性をターゲットにしたwebサービス開発エンジニアは全員男性で、女性が1人もいない、などのケースも比較的よく耳にします。 中長期的に続くことが前提のサービスにあって、手を動かすエンジニアがdog foodingできることは、成功する確率を高める最も大きな要因の1つだと思います。 その意味では、女性向けのwebサービスであれば女性エンジニアが手を動かした方が、より良いサービスを創ることができるのではないでしょうか。

今後もしエンジニアのチームを構成することがあるとすれば、できる限り男女比率を半々になるようにやっていきたいと改めて決意した次第です！

21世紀型のクリエイティブな働き方・思考・組織の新しいあたりまえ

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

私は現在IESHIL（イエシル）という中古マンション価格査定サイトのエンジニアやってます。 担当は雑用係です。 リブセンスに入社して約2年半ですがリブセンスでwebサービスの自社開発の文脈に身を置いて色々思うところがあるのでその辺をちょっと言語化してみます。

プロフィールとバックグラウンド

私はエンジニアになったのが2004年8月でした。 7年間フリーランスのエンジニアとしてお客さんのところに常駐して作業するという形で、所謂社畜フリーランスでした。 前半4年間は大手SIer、後半3年間はエンタメ系事業会社に常駐していました。

前半の4年間では小さいプロジェクトだったこともあり、ウォーターフォールで言うところの要件定義、基本設計、詳細設計、実装、テスト設計、 単体テスト、結合テスト、受入テスト、リリースなどソフトウェア開発の全工程を担当してエンジニアとしての基礎力を身に着けた時期でした。

後半の3年間では所謂「ステークホルダーと調整して設計書を書くSE」「ベンダーコントロールPM」的な立ち位置で 主に自分が手を動かさず人に手を動かしてもらう為の環境整備的なことをやっていました。 今思い返すと、この時期に所謂プロジェクトマネジメント的なところの基礎力を身に着けた時期だったと思います。

そうこうしているうちにより大きなやりがいと責任ある立場でやれる仕事をしたいと思い、新規事業のプレイングマネージャー的なポジションを探していたところ あの2011年3月11日が来て、人生短いんだからやりたいと思ったことをやるべきだと踏ん切りがついて前職となるPR会社の新規事業の開発マネージャーとして転職しました。 この時期に要求仕様の変化が激しい新規事業、所謂スタートアップ的な文脈ではウォーターフォール型の開発の行き詰まりを実感し、 アジャイルやリーンな開発(技術開発だけでなく事業開発含め)の手法を模索し貴重な経験をした時期でした。

開発マネージャーとして約2年間働いた後、現職のリブセンスに転職をして現在に至ります。 リブセンスでの強烈なエンジニア文化の中で、エンジニア含めた事業に関わる全ての人が効率の良さと気持ちの良さをどうやったら追求出来るかを最近良く考えます。

SIerから事業会社の文脈へシフトして感じたビジネスとエンジニアリングの関係性

自分のキャリアを振り返ってみると受託開発が主であるSIerから徐々に自社サービスを展開する事業会社へとシフトして行ったことになります。 私のキャリアの文脈が徐々にシフトしたのは単なる偶然な気がしますが、この経験があるからこそなのか、最近良く考えていることがあります。 それは、ビジネスとエンジニアリングは一体不可分であるということです。

ある意味これは最早当たり前の時代になってきたんだと思われますが、私が10年前にいたSIerの文脈だと実感として結構違っていました。 あくまでも受託開発では発注側のお客様がいて請負契約に基づいて予め定義したシステムを納品することが目的です。 出来上がったシステムがお客様が使ってみた結果、それがビジネス上価値を生み出すか否かは短期的には関係がありませんでした。

しかし事業が社内にあり内製出来るエンジニアチームを持っている文脈では事情が異なります。 当然ですが開発を行った結果ビジネス上無価値なものを作ってしまったとしたら基本的にその当事者が作り直す必要があります。 開発と運用が一体となっている文脈では、要件の変化に伴い柔軟にシステムを変更する必要がありまたそれに耐え得る品質を ソースコード上の保守性、DDD(ドメイン駆動設計)等を用いたビジネスドメイン設計、CI等で担保する必要があります。

これまでの私の経験上、感じていることをまとめると以下の様な図になる気がしています。

発注者と受託者という関係では、前者から後者へ金銭的な授受が行われる為、ビジネスパートナーといえど、構造上どうしても主従関係のような強弱がついてしまいます。 当然上手く行っている受託開発も存在しますが、経験上上手く行かないパターンを見ることが少なからずありました。

※ただ最近は一括請負契約の構造上の問題を解決する受託開発の手法の1つとして「納品のない受託開発」 を手掛けるソニックガーデンさんの事例は注目したいところです。

上記の図に表現した通り、時代の変遷と共にエンジニアリングの比重を相対的に大きくしていますが、これも実感としてあるところです。 昨今のビジネスにおいては「如何にビジネス上の営みをシステムに落とし込むか」という点の比重が徐々に拡大している気がします。 当然ながらビジネス上のシステム化とは、エンジニアリングの観点でのシステム化だけではなく、機械的に出来ることと出来ないことを選別した上で 人手でどこまで行うのか、人をどう配置するのか、関わる人に要求される職能は等、多岐にわたります。 しかしながらそれらの人が業務上関わる場所に全てシステムが介在することもまた事実であり、その範囲は時代を追うごとに拡大していると思うのです。

もっと言えばビジネスに近接する立場にある非エンジニアの日頃の業務にこそ、効率化の余地があることが多いとも感じます。 余談ですが最近日経の記事にコーディング・ブートキャンプの話がありました。

この記事から類推するに、非エンジニアが何らかのビジネス上の課題解決の為にコーディングを勉強する需要があるんじゃないかと思います。

いずれにしても現時点で痛感していることをまとめると、 ビジネス上1つのプロセスでしかなかったシステム化が、ビジネス上最も重要なプロセスの1つとなり、その後、ビジネスと一体化しつつある ということです。

これらのことは既に各方面の偉い人が唱えていることで、理論上は当たり前だと思うのですが、これを経験上私が感じれていることに スティーブ・ジョブズ曰くのconnecting the dotsを感じてちょっぴり嬉しいのです。 頭で理解したことと体験で会得したものでは実は雲泥の差だなと思いますので。

ゴール思考とシステム思考の融合

connecting the dotsのリンク先の記事に曰く、

点と点を繋げるということは、あらかじめ仕込むことは出来ないということです。 しかし、振り返ってみると「あの時のことが役立った」とか、「あそこで出会った人に、こんなタイミングで助けられた」といったことって意外とあるものなんですよね。

とあります。

私も自分の経験を振り返ってみて思うのですが、その通りだなと。 これ実はある意味「システム思考」だな、ということを最近しみじみ感じます。 少なくとも予め仕込むことは出来ないという点においては、ゴール思考とは遠い気がします。

私実は11年間エンジニアやる前、1年くらい超ブラック企業と言われた某営業会社で営業をしていた時期が(一応)ありました。 この企業が物凄い体育会系ノリだったのと超絶ゴール思考的で理系出身だった私には全く考え方が合わず辛い思いをした苦い経験でした。 既に亡くなった(笑)会社でもう時効だから書いちゃいますけど、当時の上司から2回辞表書けって言われて書いたりして(笑) 1回目の辞表なんて「まだ辞めたくないけど上司に辞表書けって言われたので辞表書きました」という内容の辞表だったりして(笑)

今でこそ笑い話ですが、この経験が実は比較的ネガティブな原体験として、極端なゴール思考では歪みが生まれて持続可能な発展でなくなる ということが自分の中に焼き付きました。その後も若干紆余曲折あったんですが、この体験が元になってエンジニアリングを1から勉強してエンジニアになろうと思えました。 当然ながらこの時はシステム思考なんて言葉も知る由もないんですが、振り返ってみれば、目の前の課題解決を積み重ねるアプローチを欲していたんだと思います。

また、実はゴール思考も適切な範囲であればモチベーションコントロールとして有効であることも体験していることも重要です。 システム思考だけだとビジネス上実現したいビジョン等から外れてしまっても暫く気付かないケースがあるように思います。 個人的にはゴール思考とシステム思考の融合を目指したいと考えています。私の体験上でもそれは理に適っていると思われるのです。

ヒエラルキーとホラクラシー

このような文脈にあってもう1つ私の中で良く考えることがあります。それはクリエイティブな組織の在り方についてです。 私はその1つの解としてホラクラシー型組織の構築があるのではないか？と考えています。 ホラクラシーとは、マネージャーの存在しないセルフ・マネジメント型組織のことで、ザッポスが導入したことで有名です。

最近のハーバード・ビジネス・レビューにホラクラシーに関する記事がありました。

この記事に曰く、

ホラクラシーの大部分は、優れたマネジメントによく見られる要素を単に体系化していると気づいた。 ホラクラシーの導入にまつわる細部にとらわれず、それが何に対処するためのものなのかを掘り下げて考えれば、見えてくることがある。 問題は、ヒエラルキーそのものがいかに正当性を失ったかではなく、速まっている世の中の動向に対してヒエラルキーでは動きが遅れることなのだ。

とあります。

確かにヒエラルキー型組織で優れたマネージャーは、出来るだけ現場に裁量を与えて信頼し、問題が発生した場合だけ出来るだけ迅速に対応し 問題の責任を取るタイプが多い気がします。極論、成功は部下の功績とし、失敗は上司(自分)の責任とするタイプですね。 まぁ体験的には大体ヒエラルキー型組織だと中間管理職層は人間が腐っていく例を良く見てきた気がしますが(笑) 私が開発マネージャーだった際にこういう優れたマネージャー像を目指して奮闘してましたが、理想像からは程遠い感じだったような気がします(汗)

いずれにしてもスピード感を持って変化に対して対応していく為には現場でコトに当たっている当人が誰かに判断を仰ぐことなく 自分の判断で臨機応変に行動することが出来てしかもその判断が正当であれば(結果がどうあれ)最も正しいと思います。 まぁ逆に振り返って判断が正当でないように第三者からは見えても、結果がマズい方向ではなく良い方向であればヨシとすることもあるかもしれません。

私は、クリエイティブな仕事に携わる人々が関わる組織が今のところ最も上手く行く方法論としてホラクラシーを捉えています。 逆に1ヶ月ほど前にバズってた、CIAのスパイマニュアルの記事がヒエラルキーの問題点を端的に表していると思いました。

曰く、

会社内での組織的位置付けにこだわる。 これからしようとすることが、本当にその組織の権限内なのか、より上層部の決断を仰がなくてよいのか、といった疑問点を常に指摘する

これとかまさに先ほど書いた現場の臨機応変な判断を阻害する真逆の論理で一見正当性が見えるので厄介なんですよね(苦笑)

「不二」という視座から垣間見る21世紀のスタンダード

ちょっとここまで書いた所で息切れしてきましたが(笑)そろそろ結論めいたことを書きたいと思います。 結局のところ私の体験という文脈の中でしか実感を持って判断出来ないと思っていまして、その意味では至極主観的極まりない話だということが前提ですが。 現時点での私の文脈(コンテキスト)では、これら一見相反するように見えるものが実は一体不可分である、ということです。

まず、ビジネス上使われる一部に過ぎなかったエンジニアリングが、経営の中心となりつつあります。 次に、極端なゴール思考の行き詰まりや矛盾から、持続可能な発展を考慮したゴール思考によるビジョンに基づいたシステム思考の重要性に気付きました。 最後に、ヒエラルキー型組織の矛盾の中でキラリと光るマネージャーを垣間見たり、理想像目指して奮闘したりするも、 マネージャーとなってコードを書かなくなったらエンジニアとして終わりなんじゃないかと自問自答して、 私自身の手でエンジニアのホラクラシー型組織を実現したいと夢見て現実と奮闘していたりします。

私の体験としては実は予期せず元いたコンテキストがあったからこそ、気付きを得たと言えますし、 対立しているように書いたことも実は存在意義が多分にあり一体不可分なのだと思えるのです。 これを代弁する考え方に仏教の用語で「不二(ふに)」という言葉があります。

曰く、

対立していて二元的に見える事柄も、絶対的な立場から見ると対立がなく一つのものであるということ。

前述のような見方が絶対的な立場か否かは分かりません。

ただ、ヒエラルキー型組織でウォーターフォール型開発を一通り経験出来たからこそ、その長短を体得することができたのだと思います。 ビジネスと遠いところで開発をしていたからこそ、ビジネスに近接するところで開発する際の違いを痛感し開発プロセスを多少なりとも改善してきました。 そもそもホラクラシー型組織を上手く回す為にはセルフ・マネジメントが出来る優秀なメンバーのみで組織を構成する必要がありそうです。 職能的にジュニアクラスのメンバーは一向に力を発揮出来ないことになりそうですが、敢えてヒエラルキー型組織で力を付けるという選択肢もあるかもしれません。

これらを踏まえた上で、私自身の経験に即して、これからの時代以下のような流れになっていくのかなと考えています。

  • 事業会社の内製化により下請けも含めたSIerは斜陽産業化する。
  • 事業会社がweb企業・インターネット企業となるのが当たり前になる。
  • 新しいビジネスを起こす人はエンジニアの素養のあることが当たり前になる。
  • エンジニアの素養のある人が起業するので、エンジニアの評価がよりまともになり、まともなエンジニアがよりHappyになる。
  • 非エンジニアの職種では徐々に人工知能や機械学習による自動化が進みよりクリエイティブな仕事をせざるを得ないようになる。
  • 日頃ルーチンワークが辛いと言って仕事がつまらない思いをしている人は少なくなっていく。(仕事自体がなくなるので)
  • プログラミング教育が官民共に爆発的に広まる。
  • エンジニアの仕事はコーディングによってビジネス上の価値を創造することが評価のポイントになる。
  • 世の中の複雑性は増していく一方で先が簡単に読めなくなり、反復型アプローチが問題解決の主流になる。
  • ある一定の人々に共感される極めて倫理的なビジョンを有するテックドリブンな企業が緩やかに受け入れられ世界を変えていく。
  • 急進的なスタートアップより、持続可能な発展を掲げるスモールビジネスが大量に浸透していく。
  • 副業やリモートワークがより普及して組織力は弱まり、クリエイティブな個人がクローズアップされる。
  • 自律した働き方の出来るクリエイティブな個人が集まり、プロジェクト単位でギルド的集団を形成し、質の高い仕事を成し遂げる。
  • 自律した働き方が出来るまでの職業訓練が比較的安価で受けられる教育的な仕組みが出来ていく。

私自身はこれまでの経験を踏まえてやりたいことが比較的明確になりつつあるのですが、 キーワードはITと新規事業と教育ということで一応一貫しているつもりなのでこの方向性は常に持ちつつ、 これまでのエンジニアとしての技術的な方向性から、更にビジネス・経営的な方向性で社会貢献出来る人材になろうと決意しています！

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

「ECMAScript6勉強会」HappyHalloween JS 祭！！に参加してきました！

2015年10月31日(土)に行われた「ECMAScript6勉強会」HappyHalloween JS 祭！！に参加してきました！ ハロウィンということで仮装して参加すると参加費が半額になるというちょっと変わったイベントでしたｗ

※リアルタイム更新してました！

『Good evening, ES6』byよしこ氏 @yoshiko_pg

  • 発表スライド
  • var –> constで変数の上書き禁止が可能に
  • Template Strings
  • 関数のDefault Parametersが使えるように
  • Rest Parametersで…argsで引数がarrayで取れるように
  • Spread operator(スプレッド演算子)でapplyメソッド使用せずに配列を展開出来るように
  • yoshiko氏の年齢がサンプルコードで暴露されてる（笑）
  • Destructuringで変数の入れ替えの為のtmp変数が不要に
  • Effective ES6(slideshareのスライドがオススメ)
  • ES6をES5に変換するBabelを使うとES6で書くことが出来る
  • Scratch JS(chrome拡張)入れるとES6をコンソール上で試せる
  • gulpfileをv3.9.0以上ならES6で書ける

『Promises』by矢倉 眞隆氏 @myakura

  • 発表の様子
  • 非同期処理について洗濯機とかお風呂とかの例
  • JSでの非同期処理だとコールバックヘルに陥りがち
  • thenで非同期処理を実行することが可能。メソッドチェーンで繋げることが出来る。
  • Async functionでコールバックパターンから開放される方針。try,catchで書ける。MS EdgeやFirefoxで実装される予定。

『Function and Class』by川田 寛氏 @_furoshiki

  • 発表の様子
  • Arrow Function
    • 朝起きたらクリックイベント書きたくなる（笑）CoffeeScriptであるやつ(–>, =>)
    • function,selfを書かなくて済むようになる
    • 引数は括弧を省略可能
  • ES6クラス
    • ES5まではclassなのにfunctionだしprototypeとか謎の宣言が必要だったがES6からclassが使えるように
    • extendsも使えるように

『ブラウザで今すぐES6を使おう』by林 優一氏 @frontainer

  • LIGのCTOやってる人
  • ES2015のブラウザ実装状況はIE10で10%,Chromeで65%程度
  • WebPack
    • Module Bundler require();したものの依存関係を解決してまとめる
    • webpackコマンドで1つのJSとして合体して出力してくれる
    • webpack.config.jsで設定を定義しておくとwebpackコマンドのみでいける
  • Browserify?
  • Loader
    • 読み込んだファイルに何かしらの処理をさせる
    • html-loader
    • babel-loader
  • babel-runtime
    • ファイルサイズに注意だが使った分だけ増える
  • frontplate
    • gulp + webpack + babelをまとめたやつを林さんが公開

『Years with JavaScript.Next』by dynamis氏 @dynamitter

  • 発表の様子
  • FF1.0の日本語担当で死んだ思い出
  • ECMAScript4はYahoo!とMSの猛烈な反対に合い陽の目を見ず
  • FirefoxOSでES6書こう
  • 佐藤徹平さん(@teppeis)イチオシ
  • FxDevCon キャンセル待ちだけど参加してね

QA

  • エディタ
    • vim, webstorm, atomとか。Visual Studio Codeも使いやすいかも
    • FirefoxのScratchpadが便利でオススメ
    • ES6に一番対応出来てるのはFirefoxじゃなくてEdge13(96%ぐらいES6対応が完了)
    • プラグインでESlintとか入れればどのエディタでも使える

「dots.2周年記念パーティ」に参加しました！

2015年10月30日(金)に行われたdotsの2周年記念パーティーに参加してきました！ rubyのパパことmatzの話が聞けるということで楽しみにしてたイベントでした。 またdotsは渋谷のイベント・コワーキングスペースを2015年8月から運営しており、運営に関わっている人が知人でもあり、ちょこちょこ利用させて貰ってます。

※リアルタイム更新してました！

まつもとゆきひろ氏

  • PHPで出来てるdotsにあまり関係ないruby開発者のまつもとゆきひろです（笑）
  • スライドタイトルにデザイナってつけたのは渋谷でお洒落感出したかったからむりくり。
  • ひろゆきの方が圧倒的に多い名前で2ch作った人ですよね？って間違えられた。
  • 同じように西村博之氏がruby作った人ですよね？って間違えられたことがあるらしい。
  • プログラミングなんて教育出来ないですよねーとか言って嫌がられる。
  • 昔のスパコンは今のiPhone5と同じCPUパワー。
  • 言語が進化することで脳の限界で出来なかったことを出来るようになった。
  • 本質を理解すればバズワードではなくなる。
  • C10K/C100K問題
  • 変わらないものが大事。数学・アルゴリズム・コンピュータ基礎・基本プロトコル・人間・インタフェースの原理
  • matzが尊敬するデイブ・トーマス
  • 中学の時にプログラミングやったらコンピュータが思う通りに動いて「カワイイ」と思ったのが原点
  • basic言語の辛みからプログラミング言語に関心を持った高校生時代。Pascalの本とか。
  • 未来はコンピュータと直接インタラクションするようになる。スタートレックのコンピュータみたいな。
  • reactとか面白い。

パネルディスカッション

  • エンジニアの働き方とか
  • ビットジャーニー代表井原さん：なんで呼ばれた感満載で技術分かんない
  • VASILYのCTO今村さん：かっこいい写真
  • クラウドワークスCTO大場さん：娘と一緒に登壇
  • クックパッドCTO舘野さん：本日のモデレーター

未来に必要な技術とは？

  • スティーブ・ジョブズ見たらクズだった。クズさが必要by大場さん
  • ベースになる技術が必要
  • 好きなモノを突き詰めてる人に任せたいと思う

未来に繋がる考え方は？

  • 何の為に学ぶかをしっかり持つ。信念が大事
  • 仕事してても好きな仕事を優先してたまつもとゆきひろさん。クズ感出てきましたねｂｙ大場さん
  • 人の能力の総量は桁が違うということはない。あとはパラメータの問題。なので何か1つのことに振る方が集中出来る。ｂｙまつもとさん

どう働くべきなのか？

  • エンジニアが得意なことを1つの会社が囲うのは勿体無い。会社もオープンソース化すべき。ｂｙ井原さん
  • 毎朝保育所に子供をデプロイ（笑）して出社するとか、全力出せる時間が少なくなる。生活も子供中心。労働のオープンソース化までやりたいｂｙ大場さん
  • 朝来ないからと言って全力を出せないとは思っていない信頼感がある。エンジニアはパフォーマンスを出せる時間に集中することｂｙ今村さん

今後のオープンソースの動向

  • 欲しいOSS
    • クラウド・ビッグデータ等のOSSは既にあるよね。hadoop,sparkとか。2世代目に凄いの来るかも。ｂｙまつもとさん
    • meteorとかactive value？コンセプト。リアルタイムでデータを出力し続ける。データバインディングに革新が起きればSPAが画期的に変わってくる可能性。ｂｙまつもとさん
    • 口に出すの恥ずかしいソシャゲを登壇中にやるまつもとゆきひろさん（笑）
    • TreasureData, Elasticsearchとか、更に運用を楽にしてくれるOSSがもっと出てくるかも。ｂｙ大場さん
    • hashicoop製品使い始めたところ。決定版はまだまだなので欲しい。マーケティングオートメーション的なOSSとか。意思決定を支えるOSS。サービスレイヤーに近いOSS。ｂｙ今村さん
    • kaizen platform的なものとかあるけどミドルウェアが違うので各社自社で実装している。ｂｙ舘野さん
    • 製品を半オープンソースにして製品のコードを使っている会社のエンジニアがプルリクエスト送ってくるみたいな。企業のありかた。レベニューシェアとか。ｂｙ井原さん
  • 注目される開発コミュニティ
    • 黎明期のOSSコミュニティは自身の影響度が大きいのでエンジニアとしてはやりがいがある。ｂｙ舘野さん
    • 日本人がいないコミュニティに入ると国際化対応とか日本人しか分からないところで貢献できるよねｂｙ大場さん
    • 開発コミュニティの敷居を下げるような活動とかOSSとかが必要。最初の一歩を手伝うような活動とかｂｙ今村さん
    • コードレビューすらしていない会社もたくさん。OSS以前の問題で底上げが必要かもｂｙ井原さん
    • 大体動くけど隙があるOSSは他の人がコミットしてくれる。OSSに必要なのは炎上力だ！ｂｙまつもとさん
    • DHHとか敢えて目立つ発言して炎上させてる節がある。あれもOSS運用力の一つかもｂｙ舘野さん
    • コミュニティへの帰属意識が変わってきている。github時代は様々なOSSにコミットするように変わってきているｂｙまつもとさん
  • 質問
    • 好きなことに全振りすれば良い。サポートにはサポートの、新技術を開発する人にはその人の意味があるｂｙまつもとさん
    • ダブルクリックというユーザーインターフェースが悪い（笑）ｂｙ今村さん
    • ハードウェア系もArduinoから始まるオープン化で組合せでやりたいことが出来るようになってきたｂｙ舘野さん
    • toC向けのハードウェアサービスレイヤのイノベーションはこれから起きるんじゃないか。mrubyとかも2020年とかにもっと爆発的に広まるんじゃないかｂｙ舘野さん
    • 新しいことが生まれる時は未知との遭遇から。ハードウェアエンジニアとウェブエンジニアだと摩擦が起きるけどそれを乗り越えたらイノベーションがｂｙまつもとさん
    • 時間の使い方や優先順位を伝えるのも重要だがノンバーバルな部分が伝わるのでちゃんと朝・晩は一緒に娘と飯を食うように自分にルールを課したｂｙまつもとさん

「Jubatusハッカソンwith読売新聞」に参加してきました！

先月8/23(土)、8/24(日)の2日間で歌舞伎座タワーのドワンゴ本社を会場として行われた Jubatusハッカソンwith読売新聞に参加してきました！ 読売新聞の記事の写真にバッチリ写ってましたｗ

ちょっと遅くなってしまいましたが参加レポートをば。

Jubatusは「ユバタス」と読み、Preferred Networksと NTTソフトウェアイノベーションセンタが開発した オンライン機械学習向け分散処理フレームワークです。 ※公式HPの受け売りですが(笑)

今回のハッカソンはピンで参加したのでその場で即興でチームビルディングしました。 以前から知人で選挙ドットコムCTOの佐藤さん 率いるチームで「2030年の日本の首相を予測する」というチャレンジング？(笑)なテーマに挑戦しました。 大枠やったことを書くと、1985年時点での各政治家の当選回数、世襲か否か、得票数、選挙区の都市などを説明変数として 2000年の閣僚経験数が一番多い政治家=首相を推定する 回帰モデルを5年毎に作って2015年時点から2030年を推定する、という感じです。 説明変数のデータは主にwebクロールしてきたものを利用しました。

私の担当は前回参加したハッカソン同様、この辺のクロール周りだったんですが やはり時間がかかって思ったより大変でした。(前処理大事) 収穫としてはDBpediaの存在を知ったことです。 SPARQLというSQLライクな言語でデータの関係性を含めてデータ取得出来ます。 例えば安倍晋三だとprop-ja:内閣を参照すると閣僚経験数が分かります。 ※SPARQLって難解で使いづらいんですがｗ

で、肝心の結果なんですがこれが面白かった(笑) 以下、首相に最も近い順の予測結果です。

  1. 亀井静香
  2. 甘利明
  3. 前原誠司
  4. 石破茂
  5. 岡田克也
  6. 枝野幸男
  7. 林芳正
  8. 安倍晋三
  9. 藤井比早之
  10. 大畠章宏

ホントはチームメンバーみんなで「小泉進次郎」とか期待してたんですが全くかすりもせず(笑) 1位の亀井静香は2030年には94歳だし(笑) ちょっと悔いが残ったのはJubatusのオンライン機械学習の良さを全く活かせてなかったりwebインタフェースがなかった辺りでした。 ただ今回のようにかなり具体的なデータで機械学習を応用すると話題としては面白いものが出来るなぁということが改めて実感出来たのは収穫でした。

以下は発表会の様子です。

発表会はどなたもかなりガチの内容で非常に刺激を受けました。 その中でも特に印象に残っていたのがドワンゴの小田桐さんの発表でした。 ニコニコ動画のコメントをChainerによるディープラーニングでカテゴライズや次のコメントを予測する、 みたいなことをやってそのモデルをtwitterに応用しても結構使えるよね、という内容でした。 スライドが公開されていないかググってみたんですがちょっと見当たらず残念ですが・・・

ちなみにこのChainerもJubatusを開発したPreferred Networksが開発したディープラーニングフレームワークです。

「Jubatusハッカソンwith読売新聞」参加レポート

Jubatusと自然言語処理

同じチームメンバーの方がまとめたQiita記事が分かりやすいです。 自然言語処理を行う際に避けて通れない前処理が機能としてJubatusに備わっているので便利ですね。

オンライン(機械)学習とは

オンライン機械学習はJubatusの最大の特徴とされています。「機械」を省略して「オンライン学習」とも呼ばれます。 オンライン学習について分かりやすい解説は以下のNTTデータの記事です。

以下の記述がオンライン学習について端的に言い表しています。

オンライン学習は機械学習モデルにおける学習アルゴリズムの1つであり、データを1つずつ読み込んでモデル更新を繰り返すことで学習を行う手法です。反対に、データを全て読み込んでから学習する手法をバッチ学習と呼びます。

バッチ学習のデメリットとオンライン学習のメリットについては以下の記述が分かりやすいです。

通常、機械学習で作成したモデルは運用していくうちに徐々に精度が低下するため、モデルの精度維持のためには定期的に新たなデータを加えたモデル更新が必要となります。この時、バッチ学習では過去のデータと新しいデータを合わせてモデルを1から作り直す必要があり、多くの計算時間が必要になります。オンライン学習を用いれば、新たなデータのみを既存のモデルに取り込む逐次更新が可能になるため、モデルの精度維持がわずかな時間で可能になります。これを推し進めて、発生したデータをその場でモデルに反映すれば、モデルの精度低下を意識する必要すらなくなります。

このオンライン学習が迷惑メール判定ロジックに利用されていることを考えるとオンラインであることのメリットが分かりやすいですね。 常に迷惑メールの対象は増えていくのでバッチ学習で学習したモデルを運用してもすぐにそのモデルは古いものになってしまって 新しい迷惑メールを判定出来ないことになってしまいますよね。 そういう意味で特に変化の早いビジネス上では、IoTの絡みも相まってオンライン学習は今後拡大していくだろうと思います。

機械学習周りの勉強法

私自身、機械学習周りのインプットをし始めたのはここ半年くらいです。 インプットを初めて痛感するのは、統計学、機械学習、人工知能などの情報をググっても断片的な知識ばかりであまり体系的にまとまっていないので 初学者が体系的に知識をカテゴライズすることの難易度が高いという点でした。 体系的に知識を学ぶにはネットで楽しないでちゃんと本読めよ、というのが王道ではあるのですが、、 そう言っては身も蓋もないので何か良い方法はないかなと。

そこで個人的に最近良くお世話になっている銀座で働くデータサイエンティストのブログを書かれている Takashi J. OZAKIさんの以下の記事がオススメです。

ここで出てくる「落下傘方式」とは

「必要になった時に必要な項目だけ学び、覚えたらとにかく実践してみる」

という定義だそうですが、この勉強法はwebエンジニアとの親和性が高いんじゃないかと思います。 ググッたらちょっと古い「Rubyのパパ」ことmatzの記事がヒットしました。OSSのコードを読む場合の戦略の一つとして紹介されてました。

特に私の場合は機械学習アルゴリズムそのものを研究する訳ではなく、既に確立された機械学習アルゴリズムを利用するユーザーの立場なので、 実際にJubatusを触ってみたりpythonの機械学習ライブラリのpandasやscikit-learnを 実データで利用してみた方が理解が進んでいる気がします。

pandasの参考になった入門記事

scikit-learnの参考になった入門記事

Chainerの参考になった入門記事

参考書籍

イベント「人工知能ハッカソン」に参加してきました！

最近、人工知能について非常に興味関心があります。 ロジスティック回帰による数値予測や機械学習、特にニューラルネットワーク・ディープラーニングへの興味関心が発展して最近では専ら人工知能についての話題に釘付けです。 そんな折に丁度タイミング良くサムライインキュベートさんからのメルマガで「人工知能ハッカソン」 が開催されることを知り、応募してみたところ見事参加抽選に当選したので過日(2015/5/23-24)参加してきました。

(当選時の喜びの声)


ハッカソン当日の模様

1日目前半にアイディアソンやって1日目後半、2日目に開発をやるというガチなハッカソン自体、 初参加でしたので良い経験になりました。今回のハッカソンでは基本ハスラー、ハッカー、デザイナの3つの役割の人が各チームに均等に割り振られるルールのようでした。 私がいたチームはハスラー2名、ハッカー3名(サーバサイドエンジニア2名、インフラエンジニア1名)な構成でした。 やはりデザイナかフロントエンドエンジニアがいないとプロダクトの見栄えが・・・な感じでした。。

ネタとしてはうちのチームでは「みんなのカイシャ(仮)」というタイトルで開発を行いました。 過去の判例の情報解析を手掛けるUBICさんが用意した自然言語処理系の人工知能APIを使って 選択肢に企業理念を候補として出力して選択していくと企業理念が似通った企業を推薦してくれるというものです。 クローラによるデータの収集や前処理に時間をかけすぎて肝心の人工知能APIバックエンドの実装が中途半端だったのが悔やまれました。

(2日目の成果発表の様子)

以下の通り、優勝したのはダイエット家庭教師等を手掛けるFiNCのインターンの方がいたチームでした。

ハッカソンに参加して感じたこと

参加して思ったのはハッカソンは(アイディア出しよりは)開発メインでテック寄りな方が良いかなという点です。 アイディア出しに注力するならハッカソンじゃなくてアイディアソンとして別枠でやった方が時間的な制約で中途半端にならずに良いかなと思います。 開催する側のメリットとしても2点あると思っていて、1点目はAPI提供側が開発時にストレスなく組み込めるか温度感を見る点、 2点目は提供したAPIが具体的な課題解決にどのように応用されるかアイディアの幅を見る点。 この2点の検証が盛り込まれた今回のハッカソンだったと思うのですが、提供されたAPIがシンプル過ぎてちょっと拍子抜けした参加者もいたようで 両方の検証がUBICさん的に十分に出来たのかはちょっと疑問が残る内容だったかもしれません。

ところで今回のハッカソンのメンターがトレタ増井雄一郎さんと 東京大学准教授の松尾豊さんだったのも参加理由の一つでした。 増井さんのお話を1年前のデブサミ2014で聞いたことがあり、 スタートアップ的な考え方からのツッコミが聞けそうだなと思っていたところ まさに想像通りのフィードバックがあってその視点が非常に参考になりました。

また、松尾豊さんは人工知能の専門家で 人工知能は人間を超えるか (角川ＥＰＵＢ選書) という有名な本の著者だということを知っており一度お会いしてみたかった方でした。 (この書籍は後日読んで興味深かったので次回のブログ記事のネタで書こうかと思います) ハッカソンの中間と発表時にチームへのフィードバックをいただいたのと、ハッカソン終了後にご挨拶して 日頃の興味関心事等について色々意見交換が出来たのは収穫でした。

ハッカソンで実際に何を作るのかという以上に、ハッカソンのテーマ(今回なら人工知能)に興味関心が近い人と繋がれる、 という意味でハッカソンに参加することは有意義だなと思いました。 初日にハスラー2名と私の3人で飲みに行って意見交換したんですが、参加者やメンターの方と直接会って意見交換するのは貴重な時間だと思います。 私は常日頃人が会うことで生じる「場のエネルギー」を信じているところがあり(別にオカルトという訳ではなく) 共通の指向性を持った人同士が出会う場としては相当良い場ですね。

人工知能ハッカソンの記事

参加者の方のレポート

td-clientを使ってHiveより早いPrestoクエリを実行する方法をrakeタスクで

最近、Hadoop(Tresure Data)と格闘してます。

td-clientを使ってTresureDataからデータを取得するrakeタスクを書いててHiveクエリだと遅いのでPresto使いたいなと思うことがありました。 td-clientのREADMEなど公式情報をざっと確認したところ見当たりませんでしたが、 td-client-rubyのソースコードを見たら案の定クエリタイプを指定するインタフェースがありました。

https://github.com/treasure-data/td-client-ruby/blob/master/lib/td/client.rb#L182

client.rb#L182付近gist
1
2
3
4
5
6
7
8
9
10
11
12
13
14

  # @param [String] db_name
  # @param [String] q
  # @param [String] result_url
  # @param [Fixnum] priority
  # @param [Fixnum] retry_limit
  # @param [Hash] opts
  # @return [Job]
  def query(db_name, q, result_url=nil, priority=nil, retry_limit=nil, opts={})
    # for compatibility, assume type is hive unless specifically specified
    type = opts[:type] || opts['type'] || :hive
    raise ArgumentError, "The specified query type is not supported: #{type}" unless [:hive, :pig, :impala, :presto].include?(type)
    job_id = @api.query(q, type, db_name, result_url, priority, retry_limit, opts)
    Job.new(self, job_id, type, q)
  end

上記の通りqueryメソッドの第5引数にoptsというハッシュで指定するオプションがあり、 type: :prestoな指定をするとHiveではなくPrestoでクエリが発行されます。

以下、rakeタスクでのサンプルコードです。

rakeタスクでのサンプルコード
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

namespace :execute do
  desc 'download treasure data by presto'
  task presto: :environment do
    apikey = 'your api key'
    db = 'your_db_name'
    query = 'select count(*) from your_table_name'
    client = TreasureData::Client.new apikey
    job = client.query db, query, nil, nil, nil, type: :presto
    until job.finished?
      sleep 2
      job.update_status!
    end
    job.update_status!
    p job.result if job.finished?
  end
end
実行
1

bin/rake execute:presto
結果
1

[[100]] # your_db_name.your_table_nameの件数

上記のように単純なクエリの場合、Hiveだとパフォーマンス的にwebアプリ等から動的に取得するのが 現実的に時間がかかりすぎたクエリでもPrestoであれば動的にデータ取得可能なので利用の幅が広がりますね。

合わせて読みたい

好きなことを仕事にするという論調を何故批判する向きが多いのかふと疑問に思った

私はちょっと前にこのブログ記事を読んで凄い共感しました。 記事のコメント欄を読むと比較的肯定的な意見が多いようです。 一方、はてブのコメントだとかなり批判的な意見が多いように思います。 コメントも合わせて読んで色々思うところがあったのでちょっと自分としての考えをブログにまとめておこうと思いました。

個人的には自分が正しいと思う価値観や信念に素直になって自分の仕事を選んで行こう。 何も規模や効率化だけを選ばなくても食べていける選択肢はある、って解釈しました。

この記事の方に対する嫉妬が邪魔するのか、単に価値観が違うのか、理解できない向きもあるようで、 それが個人的には不思議だったんですよね。一般的には好きなことを仕事に出来ていない人が想像より多いのかな？と。 そこでちょっと好きなことを仕事にするという切り口で色々な考え方を調べてみることにしました。



否定的な意見



肯定的な意見



中立的？な意見



その他



私見

上記の通り色々意見がありますが、職業を選択するときははなんだかんだ言って好きか、 好きになれそうかを基準にした方がこれからの時代にはマッチしていると改めて思いました。 で一度選択したら多少何があっても好きになれるまで修行だと思って踏ん張ってみて、 その仕事を好きになって自他共に認められるようになったら次のステージを検討しても良いのかなと。

あと学生を卒業したばかりの新社会人や第二新卒などのジュニアクラスの人は修行だと思って、 選択した仕事を好きになる為に一定の努力をするのは必要ってことでしょう。 といっても所謂ブラック企業でただひたむきに働き続けるのはブラック企業に加担することになってしまうので良くないので、 そういうケースに該当するかも？って思ったら経験豊富な人に相談した方が良いですけどね。

一番重要なのは、好きな仕事でどうやったら継続的に稼げる(少なくとも食っていける)ようになるかを 真剣に考えて行動していくということ。 そして個人的にはよりクリエイティブな仕事を選択すると好きな仕事で継続的に稼げる可能性が高いと思っています。 好きな仕事って1つじゃない可能性もあるので、もし色々好きになれそうで1つに絞れないって人は よりクリエイティブな仕事を選択すると幸せになれると思います。

金融イノベーションビジネスカンファレンス(FIBC)2015に参加しました

縁あって金融イノベーションビジネスカンファレンス(FIBC2015)に参加してきました。 普段参加するイベントはweb技術系かスタートアップ系のものがほとんどですが、 いつも参加するスタートアップ関連イベントに比べてスーツ率がかなり高いのが金融らしいなと思いましたｗ 同じ感想持った方がいましたねｗ

あと、いつも参加するイベントに比べて50-60代くらいのおじさまがいるのも新鮮でした。

オープニングスピーチ

  • ソーシャルトレーディング
  • ロボット取引
  • 英語であんまり聞き取れずキーワードのみメモ。。

finピッチ第1部

  • 7分で1ピッチ
  • 参加者も投票可能

クラウド給与計算ソフトfreee

  • 給与計算を半分くらいが社長がやってるのって理不尽な気がする
  • スモールビジネス向け

メリービズ

  • 自力で経費書類入力行うやつ
  • プレゼンがアナログでおもろい
  • 経費データを業界毎に解析して生ハム保険（笑）など新たなサービス開発も

Dr.Wallet

  • Drつけて人っぽいネーミング
  • レシートを写メってアプリ経由で送信、在宅ワーカーが入力
  • クーポンの仕組みも CLO(card linked offer: 見せないクーポン)
  • テンポの良いしゃべり方する人、赤メガネ
  • 生涯使えるお金管理サービス ＜ー キャチフレーズ
  • リブセンスがやってるお祝い金モデルに近い＜CLO
  • データ入力平均6時間後
  • CLO: 現在amazonポイントほぼ現金
  • 在宅ワーカーはクラウドワーカーで地方の主婦とか

Moneytree

  • CEOはオーストラリア出身
  • appleのbestアプリを2013,2014連続で受賞
  • お金だけじゃなくてポイントにも対応
  • 70万DL、リワード広告とペイドインストール一切使ってない！この数字にこだわらない法が良い（至言）
  • 未来から来たアプリ
  • セキュリティ頑張って結果大手とパートナーシップを締結
  • アカウントアグリゲーションは金融機関の顧客に不利益でなければOKとされている

coincheck for EC

  • ビットコイン決済
  • 送金に優れている
  • 怪しいイメージだが最近は大手がスタートアップに投資開始
  • ビットコインは自民党が支援
  • ビットコイン取引所 月間1億円取引
  • ビットコイン決済めちゃ便利！手数料1%!
  • デモでは日本を訪れる外国人向けにsimカードを売っているサイトで利用可能
  • 和田CEO 1990年生まれ！
  • 越境ECにビットコインは相性が良いと考えている
  • 自主規制団体作ったりしてる

Liquid

  • 生体認証システムの会社
  • カードでID一致させた後画像照合してるのが既存の指紋認証
  • 指紋そのものをキーとしているのが大きな違い
  • 100ホテルで利用開始予定
  • 国内800店舗で利用可能になる予定
  • 手数料に依存しないビジネスモデルも構築中
    • 面白そう
  • 10秒で登録可能
  • 指紋読み取りデバイスは10-200ドルくらいの幅がある

ここまでで1部完了

finピッチ第2部

スーパー乱数表

  • WBCの特集で取り上げられた
  • 色々凄い技術の特許とか持っている人らしい

Capy

  • 社長コレない
  • 元々画像をパズルで認証するやつで有名になったがパズル屋やめた
  • 有名になると撃破されるのでパズルやめても良いんじゃないか みつを
  • そこでリアルタイムブラックリスト
  • captchaから入ってくる攻撃者のIPリストを提供(現在無料)
  • アバターcaptcha: 人に帽子を被せて下さい
  • 画像解析だけでなく意味解析も合わせて行う
  • 1認証1円で提供

ETFラップ

  • 白髪のおじさん56歳での起業
  • ロボットによる投資アドバイザリーサービス
  • 時代が変わり円建てでの資産形成はリスクが大きい
  • 5000以上あるETFから50銘柄をピックアップしてグローバル分散投資
  • 諸々カスタマイズして提供する
  • www.money-design.com

アノマリーサーチ

  • ANOMARY: 市場の歪み=取引チャンス
  • 節分天井彼岸底(初めて聞いたｗ)
    • ジブリの法則もアノマリーの一種なのかな
  • 投資はどこまで人工知能で代替できるのか(というより支援できるのか)
  • シグナル配信＆他の人の戦略をコピー出来る
  • バックテストも実施可能
  • 人によって投資する対象は違うのでカスタマイズ可能に

ZUU SIGNALS

  • フィナンシャルメディアプラットフォーム
  • 月間150万UU 配信先含めると1000万超え
  • 30-40代の70%が運用未経験だがこの世代に団塊の世代の資産が移ってくる
  • 保有資産のシグナルを信号に見立てて青・黄・赤の3色で配信してくれるサービスを提供
  • 投資を分かりやすくするのがコンセプト。ちょっとみんかぶに似ているサービス
  • 初心者向けだと情報が多過ぎる程投資判断に迷うことがある
  • なのでメディアを作って段々投信判断が出来るように教育も兼ねている

FINATEXT

  • 最後のセッション
  • あすかぶ！という株アプリ(iOS&Android)
  • 初心者・若年層にターゲットを絞る
  • 思ったより経験者が多く
  • プレゼンうまい、情熱的
  • みんかぶと似たような仕組みで予想結果によるランキングとか企業の豆知識とか
  • 3ヶ月で作ったアプリ
  • 若者が熱くなるポイントは手軽さ

これで2部完了

FinPitch大企業枠

マネックス証券

  • answerという資産運用目標や保有銘柄を管理出来るアプリ
  • 一部の金融機関でアグリゲーションでデータ取り込み(スクレイピング)
  • 設定した目標にどの程度到達しているのかをスコアで評価する

リクルートライフスタイル

  • AirREGIの紹介
  • POSレジアプリ
  • 他社サービスとも連携している Squareとか

キーノートスピーチ

  • シンクタンク・ソフィアバンク藤沢久美氏。ダボス会議でヤングリーダー。7回程参加して感じるのは今、社会全体の転換期にあること
  • 貨幣経済から贈与経済へ。相手に心を使う。結婚式のご祝儀が貨幣経済。
  • 金融とはそもそも何か？非常に考えさせられる。富を再分配するプラットフォームが金融。現在の銀行や証券会社の限界を感じる。slow&nallow
  • グローバル化は多様化だ。IT革命やグローバル化が与えてくれるもの。1人1人の個人の力がエンパワーメントされること。権力が入れ替わる。革命の言葉そのもの
  • 個人が権力を行使するのは勇気がいる。それに必要なのが安心、仕組み。その仕組を提供するのが今日のピッチイベントで披露されていたサービスなど
  • ビジョンがあるものがワクワクする
  • 大阪で先物取り引きが生まれた
  • 大仏を作ったのも究極のクラウドファンディング=勧進 お金が出せない人は土や労働力を提供
  • なぜ投資したか？アンケートに儲けたいから10番目だった。共感したから、応援したいからが1,2番目だった。
  • 日本は不思議な国。全体的なレベルが高いのは日本の凄いところ
  • もっともっと大きな夢を持って失敗を恐れずチャレンジして欲しい

ピッチの表彰式

  • オーディエンス賞：メリービズ
  • ソニー銀行イノベーション賞：ZUU Signals
  • FIBC2015大賞：Capy
  • 審査員特別賞：Dr.Wallet
  • ISID特別賞：あすかぶ！

この後、ネットワーキングの時間がありました。 ピッチ登壇者がブースを出し、軽食をつまみまながら登壇者と参加者が交流するという形式でした。 個人的にも非常に刺激的な時間を過ごすことが出来て楽しかった！

Bufferにインスパイアされて、以前から私が書き溜めていた21世紀型ニュータイプ組織を晒してみました

CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ というHRナビの記事に興奮したのでこれは久しぶりにブログ記事を書しかない！と決意しました。 興奮したのは自分が起業したらこういう会社にしたいな、こういう組織が良いな、と思って以前から書き溜めていた内容と結構重複するところがあったからです。 この記事、タイトルが内容のごく一部というか表層的な部分しか表現出来ておらず、何かチープな印象すら受けるんですよね。。 給料を公開してる事実自体、実は物凄く小さいことで、もっと根源的な組織論みたいなものがテーマで、21世紀に新たに拡大していく有機的な組織の本質を 浮き彫りにしてくれていることが、この記事の核心なんです。なのでまだ読んでない方は是非熟読をオススメします。

まず本題に入る前にこの記事を読んだ人の感想をピックアップしてみます。

こういう捉え方はちょっと寂しいような気もしますが、私はむしろこの規模の企業の社長としては貰ってない方だなと率直に思いました。 と同時に従業員の平均給与はそこそこ良いのかなとも思います。 ビジネスは仕組み作りなので、Bufferはそれが着実に出来ているということなんじゃないでしょうか。

この意見は私もその通りだなと思いました。これからは資本主義で競争するのではなく人道主義で競争する時代になっているのだと確信します。 インターネットが普及したことで物事がオープンになり、資本主義の為に多少なりとも人道主義を犠牲にすることが出来ない程、衆人監視の目が光っているのだと思います。

ホントそうですよね！記事では自律分散型の組織運営としてフレデリック・ラルーの講演内容から引用して紹介していますね。 このフレデリック・ラルー(Frederic Laloux)という人、カタカナでググっても全然情報出てこないんですが、 Reinventing Organizationsという本の著者のようです。

直訳すると再発明組織ですね。まさにこのブログ記事のテーマ。

確かにBufferはグローバル企業で日本に閉じた場合に上手く行くかは必ず議論として出るところかと思うのですが、 ここはむしろ日本でも組織のイノベーションの波からは逃れられないと思います。実感値として。

投稿 by 須藤 憲司.

Kaizen PlatformのUSオフィスとBufferが同じビルってのはへぇ×２でしたｗ

このようにざっとSNSから声を市況かぶ全力2階建てばりに並べてみましたけど概ね好意的な意見が多かったように思います。 中には少数ながら給料公開とかダメでしょって見解の方もいましたが。 そしてやはり給料のことよりも組織論の部分に感じ入る方が多かったんじゃないかなと。

んで、このHRナビの記事読んで思い出したのが、私が常日頃書き溜めていた「もし自分が起業するなら」というタイトルのgoogleスプレッドシート。 かなりこっ恥ずかしいようなタイトルではあるんですが、今回の記事で紹介されていた事例のいくつかと共通する点が少なからずありました。 情報をオープンにした方がより良い方向に進むという実感があるので思い切って晒してみようと思います。

明朗会計

全社員が貰っている報酬を内外問わず公開する。

透明性

小声でヒソヒソ隠れて話をする必要のない会社にしたい。ヒソヒソ話が多い職場は気持ちが悪い。

アメーバ経営

会社の組織を10人前後で構成する小集団に分け、独立採算制を徹底させる「部門別採算制度」の仕組み。

小組織

10人前後のスペシャリスト同士が集まって高効率な組織を作る。報酬も会社の利益の山分け方式など。 この組織はスペシャリストだけがおり自身でマネージメントを兼務する為、マネージャーは必要ない。

評価制度

四半期毎など従来型のスパンでの目標管理シートではビジネス環境の変化による目標変更に柔軟に対応出来ない。 そこでよりアジャイルな評価制度を取り込む。

自社開発

技術を外部に委託せず自社で賄いこれを財産とする。

社会的意義

会社が社会に提供している価値に内外問わず誰もが共感してくれる。むしろ共感しない人がいない。

ノー残業

従業員の残業を原則禁止とする。家族や勉強会など社外のコミュニティを大事にすることを奨励する。

ここ1年くらいで書き溜めてきたものなんですが、読み返すとまだ抽象的過ぎるものもありますがベースラインは的を得ている気がしています。 Bufferのジョエル・ガスコインCEOもインタビューで言ってましたが、これまで既存の組織にいくつか所属していて感じた違和感をベースに、本来あるべき組織について、理想論じゃん無理無理的なことは全く考えずに書き溜めてきたものです。 個人的にはまだまだ網羅的にちゃんと考えきれていない点もあるかなと思っているので今後この記事をちょっとずつ更新していこうと思います。