valid,invalid

関心を持てる事柄について

社員は「会社のために」「いつまでも」働くという欺瞞を葬る本『ALLIANCE 人と企業が信頼で結ばれる新しい雇用』

同僚から「"退職"に関する本ですよ…(暗黒微笑)」とスッと渡された本、『ALLIANCE 人と企業が信頼で結ばれる新しい雇用』を読んだ。

ALLIANCE アライアンス

ALLIANCE アライアンス

著者の一人リード・ホフマンは、リンクトインの創業者であり、ベンチャーキャピタリストとして様々なスタートアップを支援しており、「シリコンバレーヨーダ」の異名を取る重鎮的な存在です。 (Amazon レビューより引用)

とのことで、随意雇用*1が慣例のアメリカ、その中でもシリコンバレーを前提にした議論が展開されている。特に環境変化・事業の栄枯盛衰・人材流動が激しいとされるシリコンバレーで成功企業が多く生まれる要因の一つとして、企業と個人は信頼関係で結ばれるべきという考え方が浸透していることを本書は指摘する。

『ALLIANCE』を読んで「よーし弊社でもシリコンバレー式を完全再現しちゃうぞー」というのは法も雇用慣習も異なる日本では難しいかもしれない。また、企業と社員間のありかたは一人の思い込みで変えられるものではなくトップダウンで示さなければいけないと本書にはある。そうしたハードルが現実には存在するものの、企業と個人がどう繋がっていくべきかを考える材料・指針としては良い題材だと思う。

以下の3点は印象深かった点。

社員はいつまでもいてくれるわけではないと思え

個人的にはこの主張が最も気に入っている。"存在しない終身雇用を信じているふり"という欺瞞を葬れるかどうかが会社と個人の信頼関係を作る上で決定的な要因だからだ。

同書が提案する「コミットメント期間」という考えに基づけば、社員はコミットメントしたミッションをこなす一定期間を終えたら次のステップに進む、その前提で採用すべきということになる。

従業員の次の数年のステップが自社の可能性も勿論あるのでそうなるよう信頼関係を築かなければならない。しかし多くの会社は「優れた社員にいつまでもいてほしい」と思いつつ、その結果の囲い込みが信頼関係を壊している

就職活動をしているときによく見たのが「自分の成長ばかり考えていて」「応募動機に自分のことばかり」という企業本位の意見たち。成長意欲がありキャリア形成を真剣に考える応募者に対して見合う仕事・ミッションを交渉の中で提案できるかは会社の責任だ。

信頼関係がないから社員は転職活動を秘密にする

社員のキャリアを正直に話し合える信頼関係があるなら、自社と他社どっちがいいですかね〜という相談もできる。むしろキャリアを考えればこそ他社を推薦することもある。

「採用して研修して育ったと思ったらすぐ転職してしまう(#^ω^)」という不満もまた企業側の怠慢に思える。転職を止められないのも同様に、次のステップとして自社がふさわしくないと判断されていることを真摯に受け止めないといけない。

ネットワークに価値を置く

社員のネットワークは会社の事業にとっても採用にとっても価値となるということを示すべき。

  • 会社は信頼関係に基づく「卒業生」ネットワークを構築しよう
  • リファラル採用は現職員だけでなく卒業生からも見込める
  • 消費者でなく従業員目線での会社のブランドが存在する。これを高めよう

社内だけで問題を解決しようとするといずれ頭打ちになる。社内の合理性は社会の非合理ということはよくある。


以下、読書メモ。

「アライアンス」とは?

会社と個人の間のフラットで互恵的な信頼に基づくパートナーシップを指す。

互恵的というところが重要で、両者が相互に投資し合うことで事業の変革と個人の成長が同時に達成でき、会社も社員も満足度が高まる。

多くの会社の現状

  • 終身雇用は終わった
  • 個人に対して永遠に雇用を保障しようという誠実さを持った会社はほとんどいない
  • 社員を大事にするとか言っていても会社の本音は「優れた人だけに」「いつまでも」いてほしい
  • このあいまいな態度こそが信頼関係を壊す。社員側に忠誠を求めながら会社は何も約束しない
  • 社員もこのことを知っているからリスクヘッジをする。忠誠を疑われないように影で転職活動をする。チャンスがあればとびつく。転職したら現職との関係は終わり

処方箋

会社と個人は信頼関係に基づく「アライアンス」関係におく。

  • 個人は能力を提供し、会社は機会を提供する。自立したプレーヤー同士が互いにメリットを得るために結ぶ期間限定の提携関係。
  • 従業員が永久的に働くことを前提としていない、かつそれを両者が合意している。すなわち会社に閉じたキャリアプランやスキルを伸ばすことを強いられることもなければ、個人の市場価値を高めるための活動に制限や背徳がない。むしろ会社はそうした機会を提供する
  • 「ある程度長くいてくれるんですよね」「え、ああ、はい(^-^)」みたいな欺瞞がないからこそ個々人の「やりたいこと・やりたくないこと・なりたい姿・なりたくない姿」について忌憚なく意見を交わせる。誠実さは信頼関係をつくる

限定のこの期間を「コミットメント期間」と呼ぶ。

コミットメント期間

コミットメント期間には以下の3型が存在しする。期間の終了に伴い別の型へと移行する、またはキャリアの転向(転職)が発生する。

  1. ローテーション型:比較的代替可能なジョブに適用。会社との相性を見極めるのが目的。新卒の研修・OJTもここに含む。この期間終了後、変革型へ移行するのが通例だが、ミスマッチ解消のために転職してもまったく問題ない。
  2. 変革型:会社にとっては事業の、社員にとってはキャリアの変革をもたらすことが期待される。ミッションを完了する前に次のコミットメント期間のあり方を会社と相談する。まとまらなければ転職する。
  3. 基盤型:3種の中では特殊。個人のキャリアや人生と会社が密接に結びついているケースなので通常、期間は定められない。創業者、10年選手の経営層が代表的だが、組織の末端(CSリーダー、インフラ担当)でもありえる。

ミッションに応じて給与や具体的な職務内容が決まるので「マネージャーにならないと給料があがらない」はありえないし、高い給与に値するミッションを提供できないのは会社の責任となる。

ネットワーク情報収集力

社員が持つネットワークは会社に大きな力をもたらす。なぜなら社外には社内に存在するより遥かに多くの優れた頭脳が存在するからだ。

ペイパルはなぜビルポイントに圧勝したか

ペイパルは競合だったイーベイ+ビルポイント陣営に勝利できたのはこのためだと考えられている。ペイパルは営業からエンジニアに至るまで多くの社員のネットワーク情報収集力を最大限に用いたが、ビルポイントはこうした活動を行わなかったため顧客が本当に欲しかったものを見抜くことができなかった。彼らはそれが「銀行との提携による不正防止と安心感」だと考えていたがそれは衛生要因*2でしかなく、イーベイのプラットフォームを利用する企業とエンドユーザーはEメールでの簡易なやりとりといったUI/UXを重視していた。

ネットワーク情報収集力を強化する4つの手段

信頼関係を築けている社員はこれを最大限に活用してくれる。この能力を活性化・最大化させるには以下のような手段がある。

  1. ソーシャルメディアの活用を会社は社員に進めよう
  2. 業務中のTwitterを諌めない
  3. 無理に強要するとすぐばれる。社員が結託して「弊社に遊びに来ませんか?」などと一時に言い始めると「そういうのを強要される会社なのか」と怪しまれる
  4. ネットワーキング予算を設ける
  5. 社外の面白い人とランチをする場合は会社が費用負担する。ただしレポート必須
  6. 社員による講演会を設ける
  7. 自社オフィスでイベントを開催する

これらはいずれも有効だが活用されなければ意味がない。マネージャーたちが積極的にこの制度を活用するとともに、面談を通じて社員に重要性を説く必要がある。「この活動はあなたのキャリアにとっても非常に有益なものですよ」と。

「卒業生」ネットワークに投資すべき4つの理由

生涯続くアライアンス関係を作る。LinkedIn, Tesla, YouTube, Yammer, Yep, Space X…これらは皆ペイパルの「卒業生」が設立した。

残念がら辞めた社員との関係構築に注目している企業は驚くほど少ない。対称的に辞めた社員も過去の勤務先がどれほど自分のキャリアに影響しうるかをわかっていない。調査によれば64%の卒業生グループは自主的に結成され、卒業生同士での人脈づくりに使われる。これは会社にとってはメリットがほとんどないのだが、一歩はたらきかけるだけでとてつもないROIを生み出す。

  1. 人材獲得に有益。卒業生は社内のルールや文化を熟知しつつも社外の眼で会社を評価できる

    • 出戻り社員になる。卒業生の次のコミットメント期間は一度離れた会社で過ごすべきかもしれない
    • 採用候補者を紹介してくれる。文化に合う人間を卒業生が見極めてくれる
    • 紹介してくれた卒業生には謝礼を支払う
  2. 有力な情報を得られる

    • 同業他社に転職した元従業員からは業界のトレンドやニュースのみならず人材情報を得られる。
    • 卒業生を対象にしたアンケートを定期的に行うのもよい
    • 自社製品に対する批評をお願いするのもよい。社内の人間だと身内びいきのバイアスがかかってしまうが卒業生からは忌憚ない意見がもらえることがある
  3. 顧客を紹介してくれる

  4. ブランド・アンバサダーになってくれる

    • ブランドイメージを企業が完全にコントロールするのは不可能になっている。「あの会社はブラック企業だ」と一度名指しされればなかなか汚名は晴らせない
    • 反対に褒めてもらうことがあれば、いち消費者でなく従業員目線での会社のブランドを高まる

卒業生ネットワークにを活かすには「紹介ボーナス」「卒業生優待・割引」「自社開催イベントへの招待」「定期的な情報交換(メールでもよい)」などが挙げられる。

卒業生との信頼関係は在職中に作られるが、決定的となるのは退職時の面談だ。これを活かさない企業はダメ。

直近だとgrooves社の話が好例かもしれない。

*1:期間の定めのない雇用契約は雇用者・被用者のどちらからでも・いつでも・いかなる理由でも・理由がなくても自由に解約できるという原則のこと

*2:無いと不満だがあってもプラスにはならない要素

Bower は deprecated なので Yarn へ移行した

一度もまともに使ったことなかったけど bower って死んでたんだね…。正確にいうと "maintained, but deprecated" か。

github.com

snyk.io

自分には関係ない話かと思っていた…が、普段まったく触らないがひっそりと稼働を続けるレポジトリに2014年来の bower が残っているのを見つけてしまったので葬った。

構成

こんな感じの bower.json に依存性がガーッと書いてあって

# bower.json
{
  "dependencies": {
    "jquery": "~2.1.1",
    "backbone": "~1.1.2", # そう、backbone です…
    "marionette": "~2.0.2",
    "backbone.stickit": "~0.8.0",
    ...
  },
  "overrides": {
    "backbone.stickit": {
      "main": "backbone.stickit.js"
    },
    ...
  },
  "devDependencies": {
    ...
  }
}

dependencies のライブラリ群をまとめて concat して特定のパスに出力していた。

# gulpfile.coffee
gulp       = require 'gulp'
concat     = require 'gulp-concat'
bowerFiles = require "main-bower-files"

gulp.task 'vendor', ->
  gulp
    .src bowerFiles()
    .pipe concat('vendor.js')
    .pipe gulp.dest('./app/assets/javascripts/vendor')

migration

依存性管理を yarn へ

まず依存性管理を yarn に移す。

bower.jsondependenciesdevDependencies を package.json に移動する。一個一個 yarn add してもいいのだが、version はなるべくキープしたかったのでそのまま。

bower.json は削除する。

# package.json
{
  "dependencies": {
    "jquery": "~2.1.1",
    "backbone": "~1.1.2",
    "backbone.marionette": "~2.0.2",
    "backbone.stickit": "~0.8.0",
    ...
  },
  },
  "devDependencies": {
    ...
  }
}

単にコピーした状態で yarn install を走らせると失敗した。主に以下の理由による。

  1. パッケージ名が bower と npm で異なる
    • npm で調べて置換する
    • importrequire を使っていたらそのパッケージ名も要編集
  2. 指定の version が存在しない
    • version 差異を少なくするため、最低の version を選んでおいた

ビルド周りの整理

gulpfile を修正する。

まず main-bower-files のような packege は yarn remove する。

gulp の src として、dependencies に含まれるライブラリのパスをちまちま書いていく。package.json 中の dependencies をうまく引っ張ってくるとか、もっと冴えたやり方がありそうだけど一旦これで。

# gulpfile.coffee
gulp       = require 'gulp'
concat     = require 'gulp-concat'

gulp.task 'vendor', ->
  libs = [
    "node_modules/jquery/dist/jquery.min.js"
    "node_modules/backbone/backbone-min.js "
    "node_modules/backbone.marionette/lib/backbone.marionette.min.js"
    "node_modules/backbone.stickit/backbone.stickit.js"
    ...
  ]

  gulp
    .src libs
    .pipe concat('vendor.js')
    .pipe gulp.dest('./app/assets/javascripts/vendor')

他にも "bower_components/..." 配下を参照しているパスがある箇所は全部 "node_modules/..." を参照するように置換した。

ビルド

この状態で gulp を走らせる。

アプリケーションは dest ('./app/assets/javascripts/vendor') の中身を読んでいるだけなので特に変更は必要なかった。

ここまでで CI に push したらテストも通った 😇 ということで即マージしてもらえた。

余談

終わった後に気付いたが yarn を使いつつ "bower_components./" を使い続けるソフトマイグレーションもできるようだ。

How to migrate away from Bower? · Bower blog

# 
{
  "dependencies": {
    "@bower_components/almond" : "jrburke/almond#~0.2.9",
    "@bower_components/angular" : "angular/bower-angular#^1.0.8",
    "@bower_components/d3" : "mbostock-bower/d3-bower#~3.3.10"
  }
}

可能ならまとめて葬った方が良いと思うが…。


しかしながら、bower ってなんで必要だったんだろうか…。2014年頃 npm にはフロントエンド周りのアセットがあんまり揃っていなかった、ということなんだろうか?

OSSに貢献してお金を得る

OSSに貢献して¥6,000ぐらい貰えたのでその話をする。OSSがお金になった話 · Dとはちょっと違う。

tip4commit

Tip4Commit — Contribute to Open Source というサイトがある。 このサイトに登録しているOSSプロジェクトそれぞれのビットコインアドレスに応援という名目で寄付 (donation) ができる。

これだけだといわゆる"投げ銭"サイトなのだが、面白いことに、OSSへの contributor に対して蓄積されたコインの一部が報酬として支払われるのだ。

支払われる額は積まれた投げ銭残高のN%。この割合はOSSの管理者が決定できる。例えば bitcoin-ruby*1 を見てみる。

f:id:ohbarye:20180114181055p:plain

現在の残高は 0.10365790 Ƀ、 支払った総額は 0.32204210 Ƀ、次回に支払われる額は 0.00103658 Ƀ とのことだ。

同サイトは4,5年前からあるらしく、2013年頃に数十円の気持ちで投げられたコインたちが今になっては何倍もの価値になり、報酬として支払われると思うと夢がある。しかし少し見渡してもそこまで高額の報酬を設定しているプロジェクトはなさそうなのでお小遣い稼ぎぐらいの気持ちでやるのがよさそう。

実際に報酬を得た話

まずこのサイトに sign up し、自分の bitcoin アドレスを登録した。

tip4commit 本体もこのサイトに登録していて報酬もまずまずだったのでバグか何かないかサイトを巡回していたが特にめぼしい物は見つからなかった。なので開発上の課題や直近の修正からチャンスを得るべく GitHub ページ https://github.com/tip4commit/tip4commit/pulls を見てみると、最近になって Korean, Spanish, Indonesian ロケール対応をしており localization を歓迎している雰囲気があった。

余談だが、localization は最もとっつきやすいOSSコントリビューションチャンスだと思う。日本語・英語ともに多少の言語力が求められるものの高い技術力や対象プロジェクトのコンテキストへの深い理解が要求されることはあまりないからだ。

tip4commit は日本では全く話題にならなかったのだろうか、日本語対応がされていなかったので en.yml を見ながらガーッと翻訳を書きなぐって pull request を送ってみた。

github.com

これが27 days*2を経てようやくマージされ 0.00357757 Ƀ がマイページの残高として現れた!!!

f:id:ohbarye:20180114182459p:plain


雑感

どこであったか忘れたが、OSSへのコントリビューションに報酬が必要だろうか?という提言を思い出した。記憶が曖昧だが、「OSSは善意で回ってるんや〜」的観念、内発的動機づけ至上主義の立場からすると報酬は常に支払うべきでないという意見だった。ロウソク問題よろしく報酬に目がくらんだ低質な pull request が大量に飛びかい、結果としてOSS総体が悪い方向に向かうという危惧もわかる*3

このサイトの作者の真意は不明だが、上述のように報酬がバッドノウハウとして働くのを危惧するなら使わなければ良いし、選択機会を提供しているだけでも尊いと思う。報酬がなければ見向きもメンテナンスもされなかったプロジェクトが蘇るとか、OSSメンテナとしてコントリビュータに感謝ができるとか、そういう綺麗な話がもっと出てきて欲しい。

*1:bitcoin utils and protocol in ruby.

*2:OSS fatigue だろうか…

*3:実際、tip4commit に登録されたもののメンテナからのクレームで掲載落ちしたOSSプロジェクトもあるようだ。

『高い城の男』

もしドイツと日本が戦争に勝っていたら世界はこうなっていただろうか…という思考実験、平行世界もの。序盤を読み進める中で、第二次世界大戦前後の歴史に関する基礎的な知識がないと楽しみが半減してしまうと思って少しおさらいしてから読み始めた。

「もしも連合国が枢軸国に勝利していたら*1という歴史改変小説『イナゴ身重く横たわる』の著者、高い城の男に会いに行く」という終焉に向けて収束するメインストーリーはあるものの、無関係に言える登場人物が多く登場する群像劇になっている。人物の内面描写は多めだが行動原理や規範がずいぶんかけ離れた人ばかりで感情移入しにくく、幾分読みづらかった。物事がうまく進んでいそうなのになんだか結局ダメになってしまう…みたいな不能感の描写がバッドトリップぽくてそのあたりにそこはかとないSF感を見出すとやや楽しくなってくる。

Amazon Prime のドラマ版)も見てみようかな。

主題

本作の主題は"本物と偽物"、"選択と結果"というところにあると思った。「なんだか結局ダメになってしまう」とか「選択を間違えた」というようなネガティブマインドはこれと大きく関わっているし、展開される各々のストーリーに共通している。選択をするのにいちいち易経に頼る人物たち、自分の人生が自分のものではない、または世界が偽物であるような違和感…メタフィクションの感覚(ジュリアナは最後には易経を通して『イナゴ身重く横たわる』に描かれた世界こそが真実の世界だと知るわけだが)。

戦争観

『高い城の男』を読んで「やっぱり連合国が戦争に負けてよかったね〜〜〜」みたいな感想も見るがそれは違う気がするんだよな…。日本はそれほどひどくないものの、たしかに作中のドイツも扱いは結構ひどい。反ナチ派は粛清されているし、ナチズムが広がった世界はある種のディストピアだ。とはいえ必ずしもこうなりえただろうか?「勝たなければこうなっていたんだ」と現状肯定するのは戦勝国側の論理であって、敗戦やそれに伴う艱難辛苦の正当化や納得にはならないのでは。(まぁそこは主題ではなさそうなので読中はあまり気にならなかったがそういう感想を見かけたので)

ハイライト

あまりない


われわれの人生という、この恐ろしいジレンマ。なにが起こるにしても、それは比類のない悪にちがいない。では、なぜじたばたあがく? なぜ選択する? もし、どの道を選んでも、結果はおなじだとすれば……。

Read more at location 5606


どこか別の世界では、たぶん様子がちがっているだろう。もっとましだろう。善と悪の選択の道がはっきりしているはずだ。こんな曖昧な灰色の混合物ではないはずだ。しかも、もつれあった要素をほぐそうとしても、まともな道具さえない。

Read more at location 5613

*1:すなわち我々の現実世界

『僕がアップルで学んだこと 環境を整えれば人が変わる、組織が変わる』

一時はその存続が危ぶまれたアップルという会社が、回復に向けてどのような環境を構築し、人材を集め、優れた製品やサービスを生み出すに至ったのか。本書はその一部始終を経験した著者が語る指南書。スティーブ・ジョブズが用いた手法とそこから著者が学んだノウハウには、これからの社会を生きていくうえでのヒントが数多く含まれている。 (Amazon より引用)

ハイライトした箇所


このころのアップルというのは、完全に「船頭のいない船」と化していました。会社の方針を知っている人など誰もおらず、めいめいが好き勝手なプロジェクトを作って実行していました。もしかしたら何らかの方針が存在したのかもしれませんが、私は聞いた覚えがありません。次から次へとさまざまなプロジェクトが脈絡なく起きては消えていきました。

Read more at location 103


アメリオは、まだ計画中のものも含む350ものプロジェクトを50にまで減らしました(

Read more at location 171


この製品の表は非常に分かりやすかったため、どんなミッション・ステートメント(会社の根本原則や方針を明文化したもの)よりも社員の力をひとつの方向にフォーカスさせることに役立ちました。新しいモデルが発表になるごとに売り上げが倍増し、会社が勢いを取り戻すのを肌で感じられました。

Read more at location 293


アップルをアップルたらしめている最も強力な仕組み、それは「シンプル志向」です。無駄が多い組織、必要以上に複雑な組織というのは、まるでメタボリック・シンドロームに悩む中年男性のようなものです。この「シンプル志向」には会社の「脂肪分」に当たる無駄を取り除き、会社のビジョンを明確にし、多くの従業員を結束させる働きがあります。

Read more at location 319


ます。普通アップルほどの規模の企業になれば、国内だけでも数十もの関連企業があるものです。例えばアップルがずっと目標にしてきたソニーは、日本国内だけでも関連企業40以上を有しています(注23)。ところがアップルは米国内には本社のほかにもう1社しか持っていません(注24)。また参入事業もソニーは20以上もあり、それもコンピューターや電子機器のほかに映画や音楽制作から損害保険、生命保険、そして銀行業と多岐にわたります(注25)。対するアップルは、コンピューター事業、コンシューマー電子機器事業、ソフトウエア販売、ダウンロード販売事業、それからクラウド事業と、たった5つの事業にしか参入していません。この5つの事業も非常に密接に関連し合っており、ソニーの電子機器事業と生命保険事業のようにまるっきり別のことをしているわけではありません。また製品のモデル数を数えても、2012年1月9日の時点でアップルは世界中でも12しかない(注26)のに対して、ソニーは日本国内だけで120ほどもあります(注27)。  このようにアップル

Read more at location 326


組織というのはある程度の規模を超えると、どうしてもそれ自体が意思を持ってしまうようなところがありますから、複雑な組織を作るとてんでバラバラの方向を向いてしまう傾向が強くなります。また組織の階層が増えると責任の範囲が曖昧になりがちですし、意思決定や情報が流れるスピードが遅くなります。こうした事態を防ぐためにも組織の構造がシンプルであることは非常に重要です。

Read more at location 358


やること」と「やらないこと」を決めるのは、自分たちの得意な分野と不得意な分野を正しく理解し、得意な分野に特化するということです。またこれは、他社との差別化をどうやって図るのかを決めることにほかなりません。

Read more at location 418


まずいちばん最初に明快な製品のコンセプトを定義し、その定義に沿ってデザインを練っていきます。もしも製品のコンセプトやデザインが誤ったものであったなら、その後でどんなに開発や製造、品質保証部門が頑張ってもよい製品が出荷されることはありません。

Read more at location 467


優れたコンセプトやデザインが立ち上がったら、その形を劣化させずに製品化させることが大切です。製造部門や開発部門が「これはできない」「あれはできない」と言って最初のコンセプトやデザインを劣化させたり、営業部門などが「あの機能もこの機能も足してくれ」と言って最初のコンセプトを破壊したりしないように細心の注意を払う必要があります。

Read more at location 470


優れた製品やサービスは、どれも極めて分かりやすいコンセプトの上に築かれています。そのコンセプトが売る側の願望ではなく、顧客側のメリットを簡潔に言い表したものでないと売れる製品は作れません。また「他社が作っているから我が社も作ろう」などというのは製品コンセプトとは呼べませんし、そのようなやり方ではモデルにした製品を超えることも、有効な差別化を図ることもできません。すると競争力のある製品は生まれませんから、価格競争の消耗戦に突入するしかなくなってしまいます。

Read more at location 477


製品のコンセプトは「世界一クールなパソコン」と、明快なことは明快でした。しかし「クールなパソコン」では顧客のメリットを何も説明していません。開発中、私は部下や同僚たちと「これが発売になったら買おう!」とずっと言っていたのに、予定価格を知った途端に気持ちが萎えてしまったのをよく覚えています。

Read more at location 496


2007年3月に発売されたアップルTV(注30)は、「家庭のリビングルームに入り込む」ことが目的とされました。しかし顧客にどんなメリットを提供してリビングに入り込むのか、といういちばん大切な部分についてコンセンサスがないままに開発が始まったのです。

Read more at location 503


これから何が流行るか」を考えるのではなく、自社が顧客に対してどんなメリットを提供できるかを考え、そこから製品やサービスのコンセプトを定義していくのが大事な点です。

Read more at location 548


た。  1つ目の問題点は、どうしても最初に作った計画に縛られがちなことです。変化が激しい時代ですから開発途中に市場の動向が変わったり、あるいは途中でより優れた実装方法などが考案され、計画の変更をした方が理にかなう状況が発生したりします。しかし最初に計画ありきの「登山感覚」の開発はこうした変化に柔軟に対応しづらいのです。また最初に設定した現実的ではないゴールにとらわれて、やめるにやめられず開発コストがズルズルと上がっていき、見直すタイミングを失ってしまうこともあります。

Read more at location 661


2つ目の問題点は、なまじチェックポイントが決まっているが故に、開発状況を頻繁にチェックしようという意識が薄れてしまうことです。そしてチェックポイントが来たときに初めて問題に気付き、バタバタと慌てるハメになります。その結果スケジュールが延びてしまったり、品質が妥協されたままズルズルと出荷に至ってしまったりということが起こりがちです。そして一度そういう前例ができてしまうと「どうせスケジュールが延びるだろう」「この程度の品質でいいだろう」と誰もが高をくくるようになり、ますます品質が低下していきます。

Read more at location 667


アップルは「団体責任」のような責任の問い方をせず、個人個人の社員に責任を帰しています。この個人個人の責任を追及するやり方が、それぞれの社員の力を発揮させるうえで非常に重要な役割を果たしています。

Read more at location 762


創造性を豊かにするには自由をたくさん与えて伸び伸びさせることが大切である、というような「神話」があります。しかし私の経験では自由を与えるとむしろ創造性が下がります。創造性を引き出すのに必要なのは自由ではなく、むしろ適切な制約です。

Read more at location 1141


社会的手抜き(注46)」(social loafing)という現象をご存じでしょうか? 社会的手抜きとは、集団で共同作業をすると、人数の増加に伴い一人ひとりが徐々に手抜きをするという現象です。

Read more at location 1215


集団をうまく作用させると、一人で働くときよりもアウトプットを高めることもできるのです。これは「社会的促進(注48)」(social facilitation)と呼ばれ、他者の存在によって、個人の作業が肯定的な影響を受ける現象です。例えば観客がたくさんいる方が実力を発揮できるスポーツ選手や歌手、あるいは一人で走るよりも数人で一緒に走った方が速く走れる、なども社会的促進の一例です。

Read more at location 1226


実際どんな人を雇うのでしょうか? ひと言で言えば即戦力になる人を雇います。「そんな人いるもんか!」と思う人もいるでしょう。しかしシリコンバレーには雇ったその日から役立つ人が実際にゴロゴロいます。シリコンバレーの会社ではどこも仕事の進め方は似たり寄ったりですし、どの人も開発なら開発、マーケティングならマーケティングとずっと同じ畑で自分のキャリアを育ててきた人が大半なので、新しい会社で右も左も分からない、などということはあまり起きないのです。転職5回などというのはごく普通ですので、採用される側も慣れたものです。

Read more at location 1407


私が採用時に気を付けていたことにはさまざまな点がありますが、特に重要視していたのは技術力が高い人を採る、社会性に欠ける人は採用しない──の2点です。どんなに技術力が高くてもあまりに社会性に欠ける人ではやはり仕事になりませんし、逆にどんな人当たりのいい人でも、技術力がないと仕事にならないからです。

Read more at location 1419


面接は自分や部下5人程度で行っていました。5人がバラバラに面接し、あとで全員の意見を聞いて採用を決めました。自分が面接に必要な専門知識が足りない場合には、他部署から信頼できるエンジニアを借りてきて面接を手伝ってもらうこともあります。5人ぐらいで面接して話を聞いてみると、候補者の話していることの矛盾を洗い出すことができます。

Read more at location 1423


米国流の人事評価方法に興味がある方は、模範的な評価の書き方などもネットにたくさんありますので、ネットで「Performance Appraisal examples」などと入力して検索してみてください。

Read more at location 1491


日本は日本語の壁や人材流動性の低さにより職が守られており、一度就職すると基本的にはなかなか転職することもありませんが、私は遠からぬ将来、日本もシリコンバレーもあまり変わらなくなるのではないかと思っています。

Read more at location 1501


人間はちょっとだけ難しいことにチャレンジしているときがいちばんやる気が出る(

Read more at location 2058

2017年の振り返り -意志とエゴ-

2016年の振り返り -罪と罰- - valid,invalid

2017年の目標 -1年の目標を立てるのをやめる- - valid,invalidに書いたように、2017年は通年の目標を持つのを止めてみた。代わりに各月に何かしらに注力するという制約を付け、以下の活動に取り組んだ。月数が合わないのは、この取り組みに飽きてサボった月があるからにほかならない。


1月: 英語学習

2017年の2月から非日本語話者が東京オフィスに入社するということでようやく重い腰をあげて学習を始めた。かなり集中して英語力の底上げを測っていて、毎日欠かさずオンライン英会話をやったが3ヶ月で燃え尽きた。

最近はもうダメ。

2月: 健康

なんと2017年には一度も風邪を引かなかった。2016年までは年に4,5回は病院に行っていた記憶がある。

ジム通いは引越し以降やめてしまったが、自宅でできるトレーニングや健康に対するほどほどの意識の高さを保てているのはこのときに"基礎"を作ったからだと思う。

3月: 無

"無"です。

4月: ゲーム

毎日ゲームをやることを自分に許した。ニーアオートマタしかできなかったがめっちゃ良かった…。

5月以降はまったくゲームをしなかったので心が老いてしまったのかもしれない。

5月: 物件探し

頑張って物件探した様を書いた記事がなぜかバズった。みんな不動産屋きらいなんだね…。

ohbarye.hatenablog.jp

6月: Clojure

Clojure をちょっと勉強してた。けど手に"馴染む"前に手放してしまった。

7月: 無

"無"、です。この月の唯一の功績はドラム式洗濯機を買ったこと。

8月: OSS

buildersconに参加して"何か"をやりたい思いが強くなり、OSS活動を少し頑張った。年間で出したPRは23本

自作のものでは kpt-bot が podcast で紹介されたreview-waiting-list-bot が今までで最もスターを集めたけど目標の20には届かなくてやや無念。

その他にも幾つか gem を作った。8月の話ではないが、話題になった dev.to に記事も書いたりしてみた。記事を書いた後にスターがいくつか増えていて優しい世界だった。

Masato Ohba - DEV

9月: 無

"無"、なんだよなぁ…。転職から2年経った振り返りを書いていたようだ。

10月: お金周り

グズグズだったお金周りを整理したので安心して投資ができる。

ふるさと納税で貰った魚と肉が美味い。

11月: HIPHOPダンス

週一のペースで通い続けているものの、未だに Up/down をひたすら繰り返している。

12月: 暗号通貨

120万ほどの含み益が出た。前年の所得が確定したところでそろそろ利確しようかなぁ。


総括

やはり通年の、それも個人的な目標を掲げて達成に向けた行動をし続けるのは俺には向いていないとつくづく思った。たった30日という縛りの中ですら簡単に興味関心が移ろってしまう。また、熱いうちに何かの行動に移せなければ抱いたはずの情熱も一瞬で霧散する。

意志の弱さを克服するというアプローチも有りだと思うのだが乗り気でない。その時やりたいと思ったことを深めたり実行することが最も自分の心を大きく動かすと知っているからだ。

とはいえ今年は嫌々ながら何らかの"ちから"で自分の意見をあえて表明せずに収めるいわゆる"大人"の場も多くあった。2018年はもっとエゴイストになろうと思う。「人は感動するために生きている」*1のだから…。

*1:『宮本から君へ』参照

gulp-util の問題、deprecation warning と migration path について

2017年12月28日に The Problem with gulp-util という記事が公開された。

medium.com

gulp をウォッチしていたわけではないのだが、たまたま残された gulp 資産を触っている時に deprecation warning がコンソールに出力され、そのメッセージ中にこの記事へのリンクがあった。

warning gulp > gulp-util@3.0.8: gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5

記事の内容を要約すると以下のようになる。

TL;DR

  • gulp v4 リリースにあたり gulp-util はもう deprecation です
  • gulp-util はただの便利関数群なので使用している機能に応じて個別のライブラリに置き換えてください
  • 6752個ものライブラリが依存している… migration を手伝いましょう

同記事を抄訳したり加筆したりしつつ、もう少し詳細を見ていく。


A little postmortem

先週 GitHub で公開した gulp v4.0.0-alpha.3、これが破壊的変更を含むとは知っていたがどれほど広範囲に影響が及ぶかは想像していなかった。これは gulp-util に依存する6,752個のモジュールのためだ。だいたいは古くなった Vinyl を使用している*1

Why deprecation now?

gulp-util はただのモジュールの集まりなので2014年以来ずっと廃止するつもりでいた。ロギングのためだけになぜその他の無駄なモジュール、たとえば beeper もダウンロードしなければいけないのだろうか?プラグインのダウンロードサイズを大幅に増やすだけだ。皆がそれぞれ必要とする個々のモジュールを使うよう期待していたが、みな現状維持を選んでしまったらしい。

移行パスはそう複雑でないと踏んでいたが、先週の変更でこれは予想以上の大きな問題だとわかった。 古い Vinyl には互換性がないにも関わらずいまだ多くのプラグインで使用されている。 しかし Vinyl v2 は glup-util 付きではリリースされない。これは、我々がプラグインの作者たちに個々のモジュールへ移行してもらいたいからだ。

結果、gulp-util で警告を出すことにした。これは私たちが望んでいたエレガントな移行ではないのだが…。もしあなたが使用するプラグインが gulp-util に依存している場合、インストール時に deprecation 予定が通知される。修正を行うまではどのプラグインが警告を引き起こしているのかは分からない。

もし gulp-util に依存したプラグインが gutil.File API を使用していないのなら、そのプラグインは壊れていないかもしれない。 その場合は緊急ではないが、それでも gulp-util から離れるべきだ。

Help us fix the ecosystem

これらの手順でプラグイン作成者の gulp-util からの移行を助けよう。

  1. npm ls gulp-util を実行して、依存するプラグインのリストを取得する
  2. それぞれのプラグインに対して npm issue {PLUGIN NAME} を実行し、issue tracker をブラウザで開く
  3. issue をオープンするか、以下の API を置き換えて gulp-util を削除するようにした pull request を作る

※ コードの例は自分が実際に置換するときに使った方法(随時追記する、かも)

const gutil = require('gulp-util')
new gutil.File()

# should be

const Vinyl = require('vinyl')
new Vinyl()
const gutil = require('gulp-util')
gutil.replaceExtension(path, newExtention)

# should be

const replaceExt = require('replace-ext')
replaceExt(path, newExtention)
const gutil = require('gulp-util')
gutil.colors.red(message)

# should be

# Node 4 以降
const fancyLog = require('chalk')
chalk.red(message)

# Node 0.10 のような古いバージョンをサポートする場合
const colors = require('ansi-colors')
colors.red(message)
const gutil = require('gulp-util')
gutil.log(message)

# should be

const fancyLog = require('fancy-log')
fancyLog(message)
const gutil = require('gulp-util')
gutil.template(tmpl, data)

# should be

const template = require('lodash.template')
template(tmpl)(data)
const gutil = require('gulp-util')
gutil.env.production

# should be

const parseArgs = require('minimist')
const env = parseArgs(process.argv.slice(2))
env.production
const gutil = require('gulp-util')
gutil.noop()

# should be

const through = require('through2')
through.obj()
const gutil = require('gulp-util')
new gutil.PluginError()

# should be

const PluginError = require('plugin-error')
new PluginError()

(抄訳終わり)


現状

gulp-util, gulp のメンテナを中心に以下の issue でエコシステム全体のマイグレーションを進めている。

github.com

6,000個以上もあるので全てをまかなうのは無理そうだが、多く利用されているものから順次対応していくそうだ。

言い換えればコントリビューションチャンスなので自分も幾つか Pull Request を出してみた。メンテナがかなり精力的に色んなライブラリを直しているようなので、作業がバッティングしないよう issue や PR をちゃんとチェックするか、マイナーなライブラリから始めるとよさそう。まぁ、gulp 周りは死んでいるライブラリも多いのでマイナーなものだと永遠にマージされない可能性もあるが…。

github.com

github.com

*1:Vinyl は仮想ファイルオブジェクトを扱うライブラリ。ビニールと書くと聞き馴染みがある