ソフトウェア・ファースト
あらゆるビジネスを一変させる最強戦略
https://gyazo.com/b0345fec7d2a544bc6cbef41de2e9404
hr.icon
読書メモ
ほとんどの内容は「わかる」というもので、するすると読めた
たぶん自分は対象読者のド真ん中からは外れている
ソフトウェアを事業のコアに据えた企業でキャリアを重ねてきたからね
「もっとソフトウェアを活用していきたい、でもどうすれば？」という人にはポンッと渡せる 1 冊
及川卓也さんの経歴はもともと知ってはいたけれど、あらためて「すごいなあ」と思わされる 1 章
Ｗｅｂ黎明期にブラウザの開発で一世を風靡したネットスケープ創業者のマーク・アンドリーセン氏は２０１１年、「Why Software is Eating the World」というレポートを米ウォールストリートジャーナルに寄稿して話題をさらいました。このレポートでは、映画業界から農業、国防までさまざまな業界がソフトウェア企業によってディスラプト（破壊）されていることを紹介し、いずれすべての企業はテクノロジー企業になっていくであろうと予測しています。ここで言うテクノロジーとは、主にソフトウェアを指すと彼は主張しています。 それから８年が経ち、彼の予測通り多くの産業がソフトウェアによってディスラプトされています。しかし、一方でソフトウェア開発の流儀だけでは通用しない領域も見えており、単純に「ソフトウェアが世界を制する」とは言えない状況が生まれています。
2 章
ソフトウェア開発を外注化する場合は、ここまで戦略的に判断しているでしょうか。自社にはできないということで、安易に外部に委託してしまっていることも多いのではないでしょうか。付き合いが長いというだけで、いつも同じＳＩｅｒやＩＴベンダーに委託してしまっていることはないでしょうか。製造業の調達や開発委託と同じ基準で考えるならば、ソフトウェア開発において安易に外注してしまうことがどれほどのリスクになるかがお分かりになるでしょう。
製造業と比較して論じるのはおもしろかった
3 章
新しい言葉を使うことで、何かすごいことをやっているように錯覚してしまうというのは、昔から日本で繰り返し起きていたことです。ＤＸがそうなってしまってはいけません。そこで筆者は、ＤＸをこう定義付けしたいと思います。
ＤＸの本質はＩＴ活用を「手の内化」すること
定義するの、えらい…！
評価とは、部下が成長していくための気付きを与える行為です。定期的な人事考課の季節を待つのではなく、常に適切なタイミングでフィードバックをしなければなりません。そのためには、部下の能力を理解して、その能力を活かしたパフォーマンスを発揮しているか把握しておくことが大切です。
いい「評価」の定義だなあ… これいい
ちなみに、マネジャーがコネクターの役割を効率的に果たすための仕掛けとして、自分自身の「取扱説明書」を作って公開するというやり方があります。チームワークは人と人とのつながりから生まれるものですが、人は感情の生き物なので、ちょっとした行き違いでそのつながりが阻害されてしまいます。マネジャーに悪気はなくても、あるメンバーにぶっきらぼうだと思われてしまったり、発言の真意が相手に伝わらないこともあるでしょう。そんな些細なことで、組織運営で余計な手間が増えてしまうこともあるのです。このような状況を避けるためにも、自分の「取扱説明書」を公開しておくのは良いアイデアです。
「どこでも働ける」人材が、能動的に所属する組織を選んで働いているという状況は、その組織を強くします。と同時に、その人材は常に「どこでも働き続けられる」だけの努力を怠りません。個人の強さが組織の強さとなります。一方で、組織は強くあり続け、強い個人を惹き付ける努力を怠らないようにしないと、社員は「どこでも働ける」のですぐに流出してしまいます。この個人と会社との良い緊張関係がお互いを強くするのです。
完全に同意です
ぼく自身が常に「どこでも働ける」状態でありたいと思っているし、社の全員にもそれを期待している
このオープンソースプロジェクトのやり方を、本来クローズドな会社組織にもあてはめてみようという考えが、インナーソース（InnerSource）というコンセプトです。オープンソース開発のベストプラクティスと文化を、企業内に根付かせる活動になります。
インナーソースはこの部署間の壁を壊し、業務担当外のプロジェクトに対してもプルリクで貢献する人を増やすための活動になります。アメリカン航空がやっていたように社内ハッカソンを行うなど、GitHubを使った社内のコミュニケーションを意図的に促進して初めて、協業が進んでいきます。
4 章
5 章
ちなみに、このコネクティング・ザ・ドッツの概念は、スタンフォード大学のジョン・Ｄ・クランボルツ教授が計画的偶発性理論として提唱している内容とほぼ同じです。この理論は「慎重に立てた計画以上に、予想外の出来事や偶然の出来事がキャリアに影響を与える」という考えに基づくものです。この偶発性を起こすには、その人に次のような特性が必要であると教授は論じています。
これをソフトウェアエンジニアのキャリアパスに置き換えると、多くの場合、「技術」「人・組織」「プロダクト・ビジネス」の３領域に落ち着くことになります。
2020 年 1 月時点でのペパボのエンジニアのキャリアパスも、だいたいこの 3 種で表現できる
グーグルという環境で働いたことから皆さんにできるアドバイスは、この本に書いてあることすべてです。技術の可能性、組織文化の重要性など、本書で行っているアドバイスの多くはグーグル在籍中に学んだことがベースとなっています。
「退職エントリが 1 冊の本になりました」いい話
筆者がグーグルを退職する時に、同僚に言われた言葉を今でも思い出します。 「グーグルを辞めて、同じように世界を変える仕事ができるのか」
神々の会話かよ〜と思っちゃったけど
程度の大小はあれど、ぼくだって道を選ぶときにはいつだってこういった観点を持った方がいいよな
筆者はあまり生存戦略という言葉が好きではありません。生存戦略よりも成長戦略。何歳になっても常に成長していくことを考えてみましょう。
これはよい視点をもらいました
「生存する」よりも「成長する」というつもりでぼくもやっていこう