【読書メモ】エンジニアリング組織論への招待
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
年末にじっくり読もうと思ったらじっくり読みすぎて年が明けてしまい2019年最初の読書メモとなりました。近々発表のある ITエンジニアに読んでほしい！技術書・ビジネス書 大賞 2019 の参考本にもなっていますが、2018年に「エンジニアリングマネジメント」が話題になったのはこの書籍がきっかけと言えるのではないでしょうか。
マネジメントを目指すエンジニアはもちろん、技術を追求するエンジニアもビジネスにしっかり貢献したい意識を持っているなら読むべき書籍です。読み進めるにあたってのポイントとより理解を深めるための補足情報をまとめておきます。
エンジニアリング組織論とは
この本のテーマはタイトルよりも副題の「不確実性に向き合う思考と組織のリファクタリング」のほうがイメージしやすいかもしれません。冒頭の「はじめに」の中でも著者が次のように述べています。
「不確実性に向き合う」というたった1つの原則から、エンジニアリング問題の解決方法を体系的に捉える組織論です。
不確実性とは
本書ではエンジニアリングとは「不確実性の削減」であるとしています。不確実性には「未来」と「他人」に関するものがあり、それぞれを「環境不確実性」、「通信不確実性」と分類しています。環境不確実性はさらに「目的不確実性」と「方法不確実性」に分類されます。
- 未来：環境不確実性
- 目的不確実性
- 方法不確実性
- 他人：通信不確実性
これらの不確実性に対して、人、チーム、組織のそれぞれでどのようにアプローチしていくかというのが本書のテーマです。そのため、1章ではまず人の思考にスポットをあてて不確実性について考察します。2章ではその延長として個人にスポットをあてたメンタリングについて書かれています。ここまではマネジメントの要素は少なく、多くのエンジニアが読みやすい内容だと思います。例えば、先輩として後輩エンジニアと接していて「なんかうまく伝えられていないな」と感じたことがある人も、ぜひ読んでみると良いと思います。
3章と4章では範囲を広げてチームにおける不確実性の削減についてアジャイル開発の観点から論じています。そして最後の5章ではさらに範囲を広げて本のタイトルにもつながる組織における不確実性の削減について、アーキテクチャの観点で論じています。後半のアジャイルやアーキテクチャについてはマネジメントの視点が強く、アジャイルなプラクティスやアーキテクトのノウハウの話は出てきません。
思考と組織のリファクタリングとは
本書で述べられるリファクタリングとはソースコードをきれいにする事ではなく、人の思考や組織の構造をきれいにすることです。コードをリファクタリングするために様々な技術的知識が必要なように、人の思考や組織の構造をリファクタリングするためにも様々な知識が必要です。エンジニアとして理解しているつもりだった技術知識を他人に説明してみるとうまく説明できなくて理解不足を感じた経験は誰もがあると思いますが、これが人の思考や組織の構造に対してとなるとより大きな影響と責任を伴うことになります。この本の各章で様々な理論や手法がその背景とともに紹介されているのはそのためだと思います。理論や手法には必ず目的や背景があり、それらを正しく理解しておくことはマネジメントにおいても非常に重要なのです。そして、その対象がエンジニアやエンジニアの組織であれば理論や手法はエンジニアリングと関連付けて使うことになります。つまりエンジニアリングマネジメントにおけるエンジニアリングとマネジメントはそれぞれ別の手法でありながら両方切り離すことができない手法でもあります。
6章に入る構想だった組織とアーキテクチャの話
著者が Engineering Manager Advent Calendar 2018 - Qiita の投稿で書いている記事を読むとさらに本書の理解を深めることができます。
この記事に書いている以下の一文こそ、本書の最も重要なテーマだと思います。
ソフトウェアサービスとは、ある機能を提供しているのではなく、継続的にその目的を果たしつづける組織やチーム文化を提供しているビジネスと言い換えることができるのです。
経営・マネジメント用語の補足
5章ではエンジニアの書籍ではあまり使われないものの、経営やマネジメントの書籍では当たり前に使われる用語が出てきます。もしこれらの用語がピンとこなかった場合は、知識を補っておいたほうがより理解を深めることができるでしょう。いずれも用語の元となった書籍があります。ビジネス書としては古典的名著なので読んでおいても損はありません。
コア・コンピタンス／ケイパビリティ
ある企業の活動分野において「競合他社を圧倒的に上まわるレベルの能力」「競合他社に真似できない核となる能力」の事
ケイパビリティ
企業や組織が得意とする組織的能力
コア・コンピタンスはゲイリー・ハメルとプラハラードが書いた論文の中で使われ始めた言葉です。この2人が書いた「コア・コンピタンス経営」という書籍が出版されています。
コア・コンピタンス経営―未来への競争戦略 (日経ビジネス人文庫)
- 作者: ゲイリーハメル,Gary Hamel,C.K.プラハラード,C.K. Prahalad,一條和生
- 出版社/メーカー: 日本経済新聞社
- 発売日: 2001/01/01
- メディア: 文庫
- 購入: 8人 クリック: 273回
- この商品を含むブログ (16件) を見る
バリューチェーン
バリューチェーンは価値連鎖と邦訳され、マイケル・ポーターが著書の「競争優位の戦略」で使った言葉です。企業内部の活動の連鎖に目を向けてそれぞれの活動がどれくらい価値を生み出しているかを分析することで、競合他社との競争優位性を見出す差別化戦略を見出すためのフレームワークです。
原著は分厚く難解でハードルが高めですが解説書などの関連書籍もたくさん出版されています。
- 作者: M.E.ポーター,土岐坤
- 出版社/メーカー: ダイヤモンド社
- 発売日: 1985/12/01
- メディア: 単行本
- 購入: 3人 クリック: 25回
- この商品を含むブログ (18件) を見る
まとめ
個人的には3章4章を通じてスクラムは開発手法であると同時にマネジメント手法でもあるということを改めて認識することができたことが大きいです。エンジニアリングだけでなくマネジメントも不確実性を削減する手法だと思うので、その両方の手法を組み合わせたエンジニアリングマネジメントはIT技術を扱う企業において事業に貢献する重要なスキルであると思います。
2019年版プランニングのやりかたと今年やろうとしている事について
年が明けてだいぶ経ってしまいましたが、あけましておめでとうございます。今年もよろしくお願いします。
新年なので今年のプランニングについて書きます。と言っても私の新年の抱負や1年の計画をここにまとめるだけだと、ただの自己満足で終わってしまうので1年の計画のやりかたや、参考にした情報、注目しているテーマなどを紹介したいと思います。
プランニングのやりかた
2017年〜2018年で読んだPDCAノートの本2冊が知的生産の手法としてとても参考になっています。
- 作者: 岡村拓朗
- 出版社/メーカー: フォレスト出版
- 発売日: 2017/01/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
今年のプランニングは2018年に発売された2冊目の本に書いてある個人の目標のたてかたを参考にしました。
- 作者: 岡村拓朗
- 出版社/メーカー: フォレスト出版
- 発売日: 2018/01/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
本書の目標のたてかたは、設定したゴールを3つのポイントに分解し、さらにそれぞれのポイントを3つのステップに、それぞれのステップを3つのアクションに分解して日々実践する手法でGPSと名付けられています。昨年も少し実践してみましたが、やってみると目標のたてかたにもコツが必要だと感じます。ブログ記事にもまとめましたが、詳しくは本をしっかり読んで取り組むのが良いです。
もう少ししっかり実践してみたいと感じているので、Google Spreadsheetの「プロジェクトのタイムライン」のテンプレートを少しカスタマイズしてPDCAノートのテンプレートを作りました。興味を持たれたかたは本を読んだうえで使ってみてください。
ちなみにこのブログを執筆時点でPDCAノートは電子版が半額キャンペーン中です（1/7まで）。
今年やること
アジャイルの実践とコミュニティへの還元
2018年はチームで本格的にスクラムに取り組んだ1年間でした。その内容は会社のブログでアウトプットしていますが、今年も試行錯誤しつつ得られたものは積極的にアウトプットしていきたいと考えています。
個人的にも引き続き様々な書籍やコミュニティにお世話になりつつ、理解を深めていきたいと思います。
また、今年最初の大きなアクションがスクフェス2019への登壇です。
たった1年のスクラムの経験でこのような大きなイベントへの登壇にチャレンジするというのは自分でも大それたことだと今更ながら戦々恐々としていますが、最初の1年の経験というのは二度と訪れない貴重な知見でもあるので、お世話になったコミュニティにしっかり還元することで、今後の新たな学習サイクルに活かしていきたいと考えています。
エンジニアリングマネジメントの理解を深める
2018年はエンジニアリングマネジメントにとって希望の光が差し込んだ重要な年と言えるのではないでしょうか。「エンジニアリング組織論への招待」と「エンジニアのためのマネジメントキャリアパス」という2冊によって、それまで多くのエンジニアにとってネガティブなイメージの多い役職であったマネジメントとの距離が縮まったように感じています。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- 作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/09/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
勉強会のテーマで扱うことも増えてきており、EM.fmなどのPodcastも始まって理解を深める環境は整ってきています。
個人的にも2年前に会社の研修でマネジメントやリーダーシップ、企業経営などの本をたくさん読んで知識を得たものの、これらをエンジニアの現場でどう活かしていくか課題を感じながら取り組んでいる段階なので、世の中の動向が自分の課題ともリンクしてきて理解を深めるには良い一年になるのではないかと感じています。
技術テーマの選びかた
昨年末のエントリー でも書きましたが、技術的なテーマを1年のはじめに決めて取り組むのは無理があるので、選ぶのではなく選び方、つまり優先順位の決め方を考えてみます。
毎年恒例のガートナーによる「戦略的テクノロジートレンドのトップ10」は次のようになっています。
新しいものを生みだすよりはここ数年で登場した技術をブラッシュアップして実用性を上げていく段階に来ていると感じます。
同じくガートナー発表の「日本におけるテクノロジのハイプ・サイクル」によると、ここ数年登場した技術要素が軒並み幻滅期に突入しています。これを見てもこれらの技術が少し腰を据えて洗練していく段階に来ていることが覗えます。
https://www.gartner.co.jp/press/pdf/pr20181011-01.pdf
Technology Radarを見ても革新的なものというよりは、サーバサイド、フロントエンド、モバイルといったそれぞれの領域で技術をブラッシュアップしていくツールやフレームワークが登場しているように感じます。
こういうフェーズでエンジニアとして何に投資していくかのが良いか、いくつか選択肢があると思いますが、個人的には色々なものを少しずつつまみ食いするよりは、洗練されて出来上がってきたものを検証するようなアクションのほうが良いのではと感じています。また、特定の技術領域に腰を据えてみるのも良いタイミングかもしれません。
個人的には本業のWebであるサーバサイドやフロントエンドの技術を軸として、Webを拡張する目的でのモバイルやAI技術には引き続き注目したいと思っています。
以上のようなテーマで今年も活動していきます。関西のかたは勉強会等で見かけましたらぜひお声がけください。それでは今年もよろしくお願いします。
2018年のブログへのアウトプットをふりかえる
これを書いている時点で今年も残すところあと2日となりました。今年最後の投稿としてブログへのアウトプットをふりかえってみたいと思います。
88エントリー
この投稿を含めると1年間で88件エントリーしていました。
月ごとにみると5件〜10件で、平均すると週1〜2件程度の投稿です。内容の内訳は勉強会メモが64件、読書メモが18件でした。
勉強会メモが週1回、読書メモが月1.5冊ペース
個人的に、年初の目標でアウトプットの頻度と量をチェックしてペースを安定させることを挙げていました。
勉強会に関しては月平均5.3件で概ね週1回ペースでした。週1回以上というペースは個人的にはしっくりきています。
また、読書は月1.5件でした。読書数として月1.5冊というのは微妙な数ではありますが、実際にはその時の必要性に応じてさらっと読み飛ばしてしまった本や、読んでみたものの理解が不十分だったり、あまりにもテーマが個人的だったり、様々な理由でアウトプットしにくいものもあるので読書は概ね月2冊程度のペースだと思います。
勉強会を週1回以上、読書数月2冊というのは来年も目安にしたいと思います。
57カテゴリー
勉強会と読書以外の投稿カテゴリーは57種類ありました。WordCloudにしてみると以下のようになります。
投稿数が2件以上あったカテゴリだけに絞ると30種類です。
圧倒的に多いのがアジャイル系、次がビジネスやマネジメント、その次にAndroidとiOSなどのモバイル系になっています。本業はWeb系なんですけど…
年始に書いたエントリーでモバイルアプリ開発とScrumの体系的な学習については挙げているのでこの2つは計画通りでした。ビジネスやマネジメントについては今年の流行りと個人的な課題感を反映した結果と言えます。
そもそも技術的なテーマを1年のはじめに決めて取り組むというのがスピード感的に無理があるので、年始に書いた内容と違っていること自体に課題感はありませんが、あまり範囲を広げすぎてあれもこれも手を出すのもダメなので、ある程度テーマの絞り込みと優先順位付けは必要だな、と改めて感じています。
Action for 2019
これらを踏まえて、社内のふりかえりLTで2019年の改善アクションとして以下を発表しました。
- Tryしたい技術テーマをバックログ化
- 数日〜1ヶ月でアウトプットが出せる単位のストーリーに分解
ストーリーに分解したタスクは会社のビアバッシュで発表したGoogle Keepのタスクマネジメント方式で管理していくつもりです。
Google Keepには個人のタスクが混在しているので、技術テーマのバックログは別で管理したい気持ちもありますが個人のタスク管理はなるべくシンプルかつ単純にすることを重視しているので、自分に適したやりかたを来年模索していきたいと思います。
補足：ブログのデータ集め
ブログのふりかえりをするために、はてなブログのAPIを使ってPythonで集計をしました。来年も使えるはずなのでGithubに残しておきます。
それでは良いお年を。
参考サイト
【勉強会メモ】Docker Meetup Kansai #2
- 日時：2018/12/26(水) 19:00 〜 21:30
- 場所：さくらインターネット株式会社 大阪本社
2018年最後の勉強会。コンテナ技術は今年の個人的な注力勉強テーマにしていたのにあまり勉強できていなかったので年の最後に勉強会に参加できて良かったです。世間的にも注目されていて年末のこの時期なのに参加者が多く大盛況でした。
DeveloperからみたOpenFaaSの可能性
福山 健 @kenfdev さん
少し遅刻したのでメモはありません。発表内容はQiitaにもまとめられているようです。
Docker Compose & swarm mode オーケストレーション
前佛 雅人 @zembutsu さん
Cloud Native Computing Foundation
Trail Map
- 段階的にやっていきましょう
- まずコンテナ化しましょう
Docker Composeとは？
複数のコンテナで構成するアプリケーションの定義と実行するためのツール
- Composeはアプリケーションのサービスをファイルで定義
- Dockerコマンドと高い親和性があるので学習コストが低い
- Swarmモードにサービスをデプロイできるオーケストレーション機能
※参考 qiita.com
Mastodonのcomposeが参考になる
3つのDocker標準ネットワークモデル
- bridge
- host
- none
3分類のボリューム
Cloud Native参照アーキテクチャ
宣言型サービス・モデルのオーケストレーション
Swarm mode
- dockerにはサービスとタスクという概念がある
- デフォルトでマルチホストネットワークができる
コマンド
Japan Container Days v18.12 Report & Container Journey for SIer.
濱 真一 @track3jyo さん
Japan Container Days v18.12
発表資料まとめ
docker,k8sの本番運用
- マイクロサービス化は一見すると開発者的なメリットが多い
顧客側のデメリット
- 運用の煩雑化など
- そもそも顧客側に導入する体制がない
- SIerに任せたい
- 安定稼働しているプラットフォームを変える必要がない
顧客が導入する意欲がない
- 必要としない技術に投資しない
Microserviceは組織論
私の考えるContainer Journey
- 事例を持っていく（顧客は事例が大好き）
- 内製化したいという思いはどこもある
- 全部受けしない。顧客と一緒に作る
結果論としてdocker.k8sを入れる
『RancherでKubernetes』『KubeConシアトル参加レポート』
新藤 洋介 @shindoy さん
RancherでKubernetes
- 2.0からk8s構築が楽に
※事例
www.slideshare.net
www.slideshare.net
CNDO2019
鈴木 教之 @szkn27 さん
ここからLT
ChainerのエバにKubeflow使ってもらった
機械学習の開発環境
※メモ
SchedulerでGPUをよしなに割り振りたい⇒Kubeflow
※参考
BuildKit を使った Scala アプリケーションのテストと高速化
↓BuildKitについての参考資料
www.slideshare.net
Scalaのビルドとテストがめちゃ遅い
⇒CIの遅い問題を解決したい
- とにかくステージを分ける
- とにかくキャッシュする
どれくらい早くなったか
- 12⇒7分
- キャッシュがあればそこそこ早かった
一番うれしいこと
- docker buildにしたことでstagingのビルドキャッシュを使える
Compose on Kubernetesについて
デプロイ
【読書メモ】北海道日本ハムファイターズ流 一流の組織であり続ける3つの原則
北海道日本ハムファイターズ流 一流の組織であり続ける3つの原則
- 作者: 白井一幸
- 出版社/メーカー: アチーブメント出版
- 発売日: 2017/03/03
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
ITエンジニアとプロ野球選手は全く違った業種ですがプロに徹する仕事のスタイルは似ている部分が多いと思っています。例えば、自分の持っている技術を駆使してチームのためにパフォーマンスを発揮する点、パフォーマンスを発揮するためのスタイルが人それぞれで個人個人のやりかたを積み上げることでチームの成果につなげる点、職場以外での技術の磨きかたも（やる/やらないも含めて）個人のスタイルに委ねられている点などです。私が野球好きということもありますが、このような類似点から野球の理論や事例から学べることはたくさんあると思っています。今回もたまたまこの本を手にとって読んでみましたが非常に参考になるマネジメントの本でした。
著者の白井さんは、当時は万年最下位とまで言われていた日本ハムファイターズでコーチとして若手を育成しチームを立て直して44年ぶりの日本一に貢献した人物です。当時の日本のプロ野球界では事例が無い中でコーチング理論のような科学的手法を取り入れた組織づくりの手腕はビジネスの世界でも注目されています。
2017年のシーズンでコーチを退任され、現在はテレビやラジオの解説者として野球界に関わりながら、全国各地で企業研修や講演も行われています。
著者自身も冒頭の「はじめに」で次のように書かれており、これまで取り組んできたマネジメント理論が野球以外でも活用できることを示唆しています。
コーチという現場の、いわば中間管理職としてチームの改革に努めてきました。強いチームをつくるために、何を意識して、どのような関わりをしてきたのか、その考え方はどこからきているのかを伝えることで、スポーツ分野だけではなくリーダーとして組織を導く多くの人たちに役立てていただけることを願っています。
また、白井さんは現役時代、日本ハムファイターズの選手としても素晴らしい実績を残されているかたです。そういうバックグラウンドや人物像についても情報を補って読むとさらに理解を深めることができると思います。
一流の組織であり続ける3つの原則
冒頭に書いてある3つの原則を読めばこの本がマネジメントについて書かれていることがすぐわかると思います。
- 実力
- 正しい方向で、正しい方法で、正しく練習をすれば実力がつく
- チームワーク
- チームの目標を全員で共有して一人ひとりが役割を果たす
- メンバー全員がチームの目標を自分の目標に設定
- 運
- 「最後にツキまくっている」のが日本一になれるチーム
- 最後に運を呼び込むのは、意識してできることを愚直にやり続けている選手
この3つの原則を徹底するためにメンタリングやコーチングの手法を取り入れています。
メンタル・コーチング
エンジニアの世界も会社組織で仕事をしていくためには個人の技術力だけでなくチームプレーが必ず必要になるので、コーチングの手法の重要性を改めて感じることができます。
選手に考えさせる
目標は無理につくるものではなく、「なんとなくこれをやりたい」という願望から出てくるものです。
- さまざまな観点で願望が具体的になるような関わり、向上心や好奇心が芽生えるきっかけづくりをつづける
- 達成の方法を学ぶ前に、達成したときにどんな価値があるのかをありありと描いて、どんどん膨らませていく作業が大事
- 会社から求められることをいち早く終わらせれば、自分の好きなように過ごせると考えることもできます
コーチングは手段の1つにすぎません。選手を指導の型にはめるのではなく、方法はたくさんあっていいと思っています。時にはティーチングも、カウンセリングだって必要になります。状況に応じて最適な手段を使い分けていくのです。 押すしかないときには、よいタイミングで押してやらなければならないのです。
明らかなミスへの対処
- 具体的な改善方法を一緒に考える
- 言い訳は一切出さない
- 反省しているのも、何が問題かいちばんわかっているのも本人
具体的な指示
- 「思い切っていけ」ではなく、どうしたら思い切りが出るのか考えて、具体的に指示する
- 「なるようにしかならない」というのはあきらめ。「これさえやっていれば大丈夫」という確信のもとで「このプレーに徹する」と決めて、あとは結果を受け入れる
「自分さえよければいいんだ」と思って普段から練習している選手が急にチームの勝利という重荷を背負えば潰れてしまいます
マネジメント
「体育会系は苦手」という言葉をよく聞きますが、こうして読むとエンジニアの世界でも体育会系的な根性論や曖昧な指導をしてしまっている現場は多いのではないかと感じます。
意識してできることを最後まであきらめずに全力でおこなう
- 指導内容が選手に定着しないのであれば、選手ではなく指導する側に何らかの問題がある
- いつでも誰にでも言い続ける
- 言いづらい選手、言いづらい場面でも言う覚悟を決められるかどうかが指導者としていちばん大切
あきらめずに選手に関わり続ける
- 選手に必要かどうか
- 指導者としてできることは何か
- できることはやり続ける
- 最後は選手に決める権利がある
- でもあきらめずに関わり続ける
監督にもコーチにもよい成果が出せるように100パーセントのエネルギーを注ぐ
「あいつは自分の意見が通らないとパワーを発揮しない」と思われているコーチと、「どんなときでもおれの決めたことに100パーセント尽くしてくれる」と思われているコーチ。どちらの進言を監督は取り入れやすいでしょうか？
どういう指導者になればいいか？
答えは「自分が選手だったらどういう指導者から学びたいか」を考えれば見えてきます。 選手は間違いなく実績を残している人から学びたいのです。しかし、それ以上に学びたい人がいます。実績を残して、なおかつ学び続けている人です。
黙って結果を出すのが謙虚ではない
- 冷めている人が多いからこそ言い続けるのです。伝え方を変えて言い続けるしかありません。
- 有言実行しかダメだ。言ったもの勝ちだ。
- 始める前に謙虚で、結果が出たあと傲慢な人は山ほどいます。自信をもって始めるために、やるべきことをすべておこなって準備するのが、何かに臨むときのほんとうに謙虚な姿勢です。
一流の指導者とは？
- 最初に任せて、最後に責任を取ります
- 二流の指導者は最初に責任をとって、最後に責任をなすりつけます
- リスクの大きい決断をするときほどコーチ陣には相談しない
- 同意を求めたら責任を負わせてしまうからです
成果と結果が同時に出ないというのは誰でもわかっていることです。結果とは成果の積み上げです。結果を出すためには、成果を出し続けるしかありません。
技術を活かしてチームとして成果を上げるためには理論を裏付けとしたマネジメントを愚直に行うことが求められるのだと改めて感じました。
参考
