Agile2017 Day 2

昨日に引き続き Agile Conference の記録を日記にしとこうと思います。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5
 

High Performance via Psychological Safety (Joshua Kerievsky, Heidi Helfand) POPULAR

Modern Agile で再ブレイク中の皆さん大好きジョシュアですが、SFAgile という2011-13年くらいにやってたカンファレンスで２年連続でキーノートやってて、ベイエリアのアジャイルコミュニティではもともと人気者な気がする。

今回は Modern Agile から心理的安全のセッション。心理的安全を確保すると、生産性が上がるというのがタイトルなんですけど、その時点ですでに納得なわけです。逆に心理的安全がないといかに無駄な説明が増えたり足引っ張られたりして生産性が下がるのがよく分かるので。

で、デミングの言葉から。「安全を感じないところで、ベストなパフォーマンスを出せるやつなんかいねーんだよ。」

「企業にとって長期的に一番いいのは、修繕とオーバーホールのために生産を一時的にやめること。そうすれば私の日報のいらなくなるし、私も失業する。」

コンサルタントの仕事の重要なところは、自分が抜けても大丈夫にしとく(相手が自らやったような気になってもらう)ことだというのを聞いた気がします。 

職場にはびこる恐怖に対処する本はこれ。

信頼が欠如すると悪循環が起こっていくと。

よくない仮説 -> 自己保身に走る -> 見える形での攻撃的な行動 -> ... 

ワークショップ。「他の人から見て、無知/無能/ネガティブ/破壊的な人と取られないように、あなたの行動を変えたことはありますか？」

あ、これワークのとき意味取り違えてたな。隣りにいた高橋陽太郎さんと噛み合わなかったのはそういうことか...。ごめんなさい。シルク・ド・ソレイユのチケットに集中して話を聞いてなかった...。

MTTCR (平均紛争解決時間)

昨日思いついたって言ってたがまあ冗談でしょ。

修繕です。問題が起こったときに、どのように組織が反応できるかというのは、大きな指標ですね。心理的安全がないと、「問題には気づいているけど、どう直していいのかわからないので、黙っておく」という行動が多くなります。逆に言うと、つぎのジョセフ・グレニーの言葉「組織の健康状態は、あなたが感じたタイミングから、組織で議論されるタイミングまでの経過時間で計測される」ということです。思ったらすぐ言える関係性や余裕が非常に重要ということ。

マネージャーは部下の衝突を解決するためにどんなコーチングができるか？

共感のトライアングル。私、あなた、関係。(そのうち調べたい)

心理的安全があるミーティングの原則。

みんなの貢献を促す。他の人の話に耳を傾ける。話の内容を復唱する。支配や中断を避ける。気配り、好奇心、決めつけない。

ということで、おなじみGoogleの図です。まずは心理的安全ありき。

モブプログラミングについて質問攻めの会

お昼に、Hunter Industries のモブ軍団のマネージャーの Chris Lucian が通りかかったので、みんなで質問攻めにしました。今週一番価値ある会になったんじゃないかという気がする。

で、同じくHunter の William Larsen と母上の Diana Larsen (アジャイルレトロスペクティブズの人) とパシャリ

How to go from Zero to Sixty in 19 years - Accelerated learning on the path to Agile (Woody Zuill) Popular

午後は、Mob Programming の伝道師 Woody Zuill の話を聞きました。といってもモブの話ではなく、人生の話。巷では、業務時間に勉強するかどうかというエントリが流行ってますが、なにを言っているんだお前は、という気がします。

まあ、勉強だったり技術習得は投資なわけですが、じゃあどうやれば成功できるか？っていうと、ファンドマネージャとしての力量が問われるわけです。

しかし短期的には成績に差が出るものの、

つぎの期を取ると、所詮ランダム。賢くて勝ち続ける人なんていないんです。

確証バイアスにすぎないわけです。

 偶発性。思ってもみないことに出会うのが人生。

他の人の事例を聞いたって真似出来ないし、勇気をもらうことくらいしかできない。

意図的に失敗して、失敗から学ぶ。

小さなステップで、学びながら進む。学んだことで、目標も変わるかもしれない。

つぎの一歩を決めるときには、より可能性が広がる方へ。新しいドアを開く。

よいメンターを探す。でもみんながメンターなんだよ。

古い本だけど、これ知ってますか？いかに考えるか。

みんなでうまくやっていく方法を学ぼう。

これが Hunter Industries の最初のモブチームだそうです。初めての見学のお客さんを受けてみんなで撮った写真。

まとめ。色々話してました。

記念写真パシャリ 

２日目は以上。スーパーでビール買ってきて軽く飲みました。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Agile2017 Day 1

最近ほとんどSNSばかりでブログを書いておりませんが、今年も Agile Conference に参加しております。2009年からなのでもう８回も参加したらしいです。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

初日は基調講演から始まって90分の並行セッションが３つという構成です。

オーガナイザーからの説明とか。

リーダーシップに関する基調講演。潜水艦のマネジメントだった経験を踏まえて、マネジメント層の重要さとか、心理的安全とか自律性の話をしていました。

基調講演の後は、アジャイルコーチのスコアカードの話に参加。メトリクスを取ろうという話でした。

Productivity, Predictability, Responsiveness, Quality, Agile Maturity/Fluency, Business Outcome, Happiness という観点でメトリクスを出す。Rally(プロジェクト管理ツール)から取れるものと、アンケートやインタビューで。

Productivity(生産性)の例。緑がストーリー数、黒がバグ対応数、青が合計。

カンバンとスクラムを混合してるのでサイズ見積もりはなく件数だけとってる

この例ではより安定してきてる。

これはPredictability(予測性)の例。
下側の時は着手数の方が多い状態。上側は完了数が上回ってる状態。WIPを制御することで徐々に上になる。こうすることで、「タスクが山積みなんでいつ終わるかわかりません」状態を回避できるようになる。フローの効率化。

ここで会場から質問。「Weって言うけど誰？誰のためにデータ取ってるの？コーチやコンサルタントのため？チームのため？」

どっちのためでもある、というような回答だったと思います。（メトリクス系のとき、この点がいつも焦点になる気がします。マネジメントに管理しやすい数値を渡したいだけなら、それチームのためじゃないじゃん説。いやマネジメントが管理しやすければチームもやりやすいでしょ、という立場はあると思いますが、チームとの信頼関係次第かな。業務知識のないマネージャーさんに操作しやすい数字をあげても、いい方向には使えなかったりするでしょうし。）

このあと質問ラッシュになってました。

Agile Fluency / Maturity つまりアジャイルがどれくらい出来てるか、はインタビューでトルっぽいです。ダイアナ・ラーセンとかがやってる、Agile Fluencyのモデルを参考にしている模様。

Jonathan Rasmusson : 7 Sources of Waste

「アジャイルサムライ」の著者で今はSpotifyでエンジニアしているジョナサンのセッションに参加。Pragmatic Bookshelf から新しい本が出てます。

テスト自動化の７つのムダ ... ３つは技術面、４つは文化面。

#1 スローテスト
まず見つけるのが難しい
すべてのテストが暴動ではない 1000ms 100ms 1ms
スローテストは生産性キラー

#2 Flaky Test
100%の信頼性で動かないテスト。
つまりテストの結果が揺らぐのは辛いってこと。
これ1月にMicrosoft行ったときにBingのUIテスト自動化の人も同じことを言っていた。
なるべく各環境(ロケールとかブラウザとか)で揺らがないような書き方を探すんだそう。

Kent Beck はそんなテストは消せと言っている。

#3 Premature Hardening

バグを取りきる前にUIテスト(自動化)に入ってはいけない。

こっから文化

#4 Lack of Language and Framework
共通言語(結合テストがなにを意味するかとか)がないと辛い。テストのフレームワークが統一できてないと辛い

#5 Lack of Skills

必要なスキルがないと辛い

#6 Artificial Separation of concern

責任を変に分割してると辛い (開発者とQAとか)

一つの作戦はテスト中の列をタスクボードから削除。

#7 Lack of perspective

しかし観点は必要なのだ。

最後にSpotifyの話

ダッシュボード作って常に見えるようにしている。テストコケてないかとか、各種メトリクス。

チーム(Squad)によっては専任のテスト自動化のロールの人がいる。例えばクルマのメーカーとの共同プロジェクトですごい短い期間でクルマ(TeslaとかBMWって言ってた)でSpotifyの音楽を流せるようにしたんだけど、こういうテストは専門家がついた。

生産性向上のための専任チームがいる。これはプロセス改善するという意味ではなくて、技術的に解決する人たちという意味だと思う。DevOpsとかツール整備とかそういう感じだろう。

毎週リリース。これはきついけど守っている。ユーザーからフィードバックもらうためには必要なこと。毎週機能をリリースする。

テストエンジニアの社内認定試験を作った。(このへんは How Google test に近いな)

ということで、本を出したので読んでね。(日本語版は９月にオライリージャパンから出版予定だそうです。)

よいまとめであり、かつSpotifyの話が聞けてすごく勉強になりました。

昼ごはん食べたときに「タフクエスチョン用意しといてね」と言われたので質問。

「こういう話って、非エンジニアの偉い人に説明するの大変じゃん？どうしたら良いと思う？」

答え「わかんね。カナダのエネルギー系のプロジェクトのときは、お金に換算して説明してた。Spotifyはファウンダーがエンジニアで、もともと技術的解決をする仕事をしてて、その３つの柱の一つがSpotifyだった...」

まあ、そういう時代かなーと思う。 

最後に日本人とパシャリ

で、このつぎのセッションが David さんの非エンジニア向けにクリーンコードを説明する方法のセッションでした。熱く語っていた。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Joy, Inc. のジグソー法ワークショップ

Developers Summit 2017 でやった、Joy, Inc. のジグソー法ワークショップの資料を公開しました。Joy, Inc. は2000年代初めからアジャイル開発とデザイン思考を取り入れて顧客を巻き込んだ受託開発を行っている、メンローイノベーションズ社の取り組みについて、ファウンダーであり現職のCEOであるリチャード・シェリダン自らが描き下ろした本です。米国のアジャイルコーチの多くが見学ツアーに訪れる、活きた実例であるメンロー社の徹底した顧客志向の文化に触れることができます。

書籍の無料お試し版(電子版、固定レイアウトのみ Kindle  Kobo ほか)がありますので、購入前の方でもこのワークショップを行うことができます。イベントなどでワークショップを行うこともできますので、お声掛けいただければ幸いです。

ジグソー法の読書会への適用は教育心理学概論読書会で試みられ、知識構成型ジグソー法 | 東京大学 CoREF を参考にさせていただきました。この場を借りてお礼を申し上げます。

speakerdeck.com

無料お試し版で公開されている部分 

以下の４つの部分を無料版に入れていただいております。開発者、プロマネ、UX/要件定義担当にとって興味がありそうな部分を抜き出しました。ワークショップではこのうち３つを使いました。

1. 喜び？ご冗談でしょう  P.7-12 

2. 頭は二つ … コンピュータは一台 (ペアプログラミング)　P.62-69

3. プロジェクト計画折り紙　困難な選択をつきつける (プロジェクト計画)   P.98-103

4. そこにある断絶 (ユーザーエクスペリエンス/デザイン思考) P.138-146

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジグゾー法ワークショップの模様

100名超え、かつ、短時間のワークショップでしたが、みなさん楽しく議論ができたようです。無料お試し版は、ジグソー法型の読書会をやってみるのにも最適な分量を考えて作っていますので、ぜひ試してみてください。いろいろな本でジグソー法を使った読書会をやっていますが、どの本もどの回も満足度は高いです。

永瀬さんの実況解説付きビデオはこちらです。

Joy, Inc.Jigsaw Reading at Developers Summit 2017

Joy, Inc.Jigsaw Reading at Developers Summit 2017

Joy, Inc.Jigsaw Reading at Developers Summit 2017

ジョイ・インク 役職も部署もない全員主役のマネジメント [ リチャード・シェリダン ]

人付き合いの話

周りの目が必要以上に気になってしまう人がいます。たぶん生まれ持ってしまったか、家庭や社会の環境との付き合いで長い時間をかけて作られてきたそうした感覚なのだろうと思います。もし生存のために必要に迫られて獲得した能力だとすれば、急に変えるなんて難しいでしょうね。

私ももちろん相手が自分をどう思っているかは大変気になります。ものを教えたり、アドバイスするようなことを仕事にしてしまっているこの数年は特にそこは重要になりました。しかし相手の心なんてどうあってもコントロールできない。ストレスがある環境下でパフォーマンス出せるほど、人間がうまくできてないし...。どうするか....。

で、私なりにいくつか心がけていることを書いてみます。

なるべく攻撃してくる人や話が合わない人とは付き合わず、認めてくれる人とだけ付き合うようにしていけるといいなぁと思います。生きて行くために何人と付き合わなければならないかは、職業にもよると思うけど、実はそんなに多くない(かもしれない)。まあ、挨拶もするし、用があれば会話もするけど、仕事はしないと決めてしまうんです。すでに仕事を始めてしまっていたら、この仕事を最後にする。終わるまでは我慢する。早く終わらせる。

認めてくれてるけどある部分でいじってくる人は、単に気にしてることに気づいてないだけなんで、うるせーそこ気にしてんだよ、って言えばもう言わなくなることが多いかなと思います。

はっきり悪意を持ってる人は、意外とその人の状況も危うくて、嫉妬してたりするケースが多いので、距離をとっておいて憑き物が落ちるのを待つしかないかな。もう仕事に絡んでめぐりあうことはないでしょうけど。

....などなど。

相手の期待に"ある程度"応えていくことが、仕事というものの本質なので、「お前には期待しない」って思ってる人とは成立しないわけです。お金にならない。

一方、相手の期待に応えようとするだけでは期待を越えることができません。儲からない。

一緒にできる人は仲間として、そうでない人はお客様として、うまいこと付き合っていけるといいのかなと思います。(トヨタでは知識ある人は仲間にせよ、知識ない人は客にせよ、という言葉があると、以前黒岩先生に伺った気がします)

徒然ですみません。

ジョイ・インク 役職も部署もない全員主役のマネジメント

以前、ご紹介していた Joy, Inc. 日本語版が出版されます。邦題は「ジョイ・インク 役職も部署もない全員主役のマネジメント」です。 

ジョイ・インク 役職も部署もない全員主役のマネジメント [ リチャード・シェリダン ]

メンロー・イノベーションズ (Menlo Innovations) 社の創業から、社内の文化、どのように顧客とともにソフトウェア開発を行っているかについて、創業社長リチャード・シェリダン自身の手によって書かれた本です。

イントロダクション
1章　僕が喜び（Joy）にたどり着くまで
2章　スペースとノイズ
3章　自由に学ぶ
4章　会話・儀式・道具
5章　インタビュー・採用・立ち上げ
6章　観察のもつ力
7章　恐怖と戦い、変化を抱擁する
8章　ボスではなくリーダーを育てる
9章　カオスを終わらせ、曖昧さをなくす
10章　厳密、規律、品質
11章　持続可能性と柔軟性
12章　スケーラビリティ
13章　説明責任と結果
14章　アライメントー向きを揃える
15章　問題
16章　まとめ――喜びのなかへ
エピローグ――ひらめき
お勧めの先生たち
推薦者あとがき（川鍋一朗）
本書に寄せて（ケリー・パターソン）

著者のリチャードは、1999年ごろにアジャイル(ケント・ベックのXP)と、デザイン思考(IDEO)に出会います。それらのやり方を取り入れソフトウェア開発チームを目指します。

翌日になって僕はボブのところに行き、VP職を引き受けた。立場を利用して「めちゃくちゃイカしたソフトウェアチーム」を作るつもりだとも (P.23 )

ベックのWikiを読んで数週間後、今度はIDEOという会社がナイトラインというテレビ番組で取り入れられているのを見た。(中略) 三十分間の番組では、IDEOの仕事の様子を取り上げており、それはまさにベックがエクストリーム・プログラミングとして紹介しているやり方の実例だった。ベックの手法そのままではないとはいえ、IDEOは熱意のある会社であり、密接な協調によるチームワークと顧客との素晴らしい関係性を持ち、優れたデザイン思考を持っていた。(P.25)

僕はチームのメンバーを全員集めた。十四名のソフトウェアエンジニアだ。そしてエクストリームプログラミングの話を聞かせた。彼らにとっては全く新しい考え方だ。それまでの経験と蓄積とはまったく異なる手法で、ショッキングと言ってもいい。最後に僕は聞いた。「みんな、どう思う？」

だれも、一言も言わなかった。(P.28 )

ここ二年ほど、クレアはまた別の手法を導入してきたが、失敗に終わっていた。親しみを込めて「ソフトウェア開発ライフサイクル」(SDLC)と呼んでいたが、業界では一般的にウォーターフォールと呼ばれる手法だ。このプロセスでは、中央集権的な委員会、定められた会議体、経営陣の承認、フェーズごとの審査と継続判断、委員による中間成果物の数知れないレビュー、などなどが求められる。(P.29 )

 実験が始まって三週間ほどたったとき、クレアが僕を呼び止めた。そして、まだ給料を払うつもりかと質問した。

「どういう意味だ？」僕は聞き返した。

「すごく楽しいんです。働いているように感じないんですよ。その上給料までもらっていいものか、ちょっとわからなくなって」(P.31 )

ある日の朝、ジェームズが興奮した様子で現れた。彼が案内してくれたのは、インターフェイス社が以前プリンタを製造していた、古い工場だった。(中略) ひらけた空間だけで、壁も、オフィスも、パーティションも、ドアすらない。巨大でオープンな、共同作業のための空間だ。いけるかもしれない！僕たちはこの場所を乗っ取ることにした。(P.32 )

この取り組みは成功し、しばらくして、業績好調の会社は2000年にシリコンバレーの会社に買収されます。しかし、インターネットバブル崩壊。親会社は経営が傾き、リチャードたちの拠点を含め全国のリモートオフィスを閉鎖、リチャードたちもレイオフされます。そこですぐ四人で、会社を興こす決断をします。それが、現在のメンロー・イノベーションズ社。15年にわたって、アジャイルとデザイン思考を通じて、ソフトウェア開発が必要な顧客に価値を与え続けてきました。

この本ではメンローで行われている、アジャイルに親しんでいる私たちにもおなじみのやり方の数々が紹介されています。デイリースタンドアップ、見積もり、計画ゲーム、見える化、コミュニケーション、採用からチームづくり、リーダーシップとマネジメントのすべて。 

そして、 私たちがUX(ユーザエクスペリエンス)だとか、UCD(ユーザー中心設計)と呼んている要件定義手法も取り入れています。

メンローで世紀の大発見をひらめいたのは、殆どのソフトウェアチームが何か基本的なことを見失っているとわかったときだ。僕たちの喜ぶべきゴールがエンドユーザに喜んでもらうことなら、そのエンドユーザーにはずっと利用し続けてもらわなければいけないのだ。ハイテク企業に限らず、ほとんどの人たちがいまだにソフトウェアには苦痛を感じている。しかし、あなたの会社と同様、ソフトウェアを使わなければ何もできない。(P.138)

このような紙ベースかつ手描きのユーザーエクスペリエンスデザインのプロトタイプは、実際のユーザーが検証する。ハイテク人類学者たちは、プロトタイプを触ってくれるユーザーを集めてくる。そしてデザイン案についての意見を求める代わりに、プロトタイプを使って何らかの作業をしてもらい、その過程を観察する。(P.150)

そして、開発の計画は開発者も顧客も巻き込んで行っていきます。「計画おりがみ」と名付けられた手法です。

計画おりがみというテクニックを使い(7章で詳細に説明する)、プロジェクトマネージャーは顧客をガイドする。計画シートの上に、おりがみで作ったストーリーカードを乗せていくのだ。計画シートもストーリーカードも、物理的な大きさにより予算と時間を示す。ストーリーカードは開発する機能を示す。必要な時間は見積もりの儀式ですでに見積もってある。計画シートの大きさは、その週に使える時間を示している。(P.99)

私たちが様々な本で読み、多くの人の話で伝わってきて、自分たちでも試してきた手法や文化の多くが、ここに結実していると感じます。そしてこの会社は、天才たちが作った「イケてるハイテクソフトウェアベンチャー」ではないんです。シリコンバレーですらない。決して手の届かない技術を使っているわけでもないんです。道具はすでに私たち、何年もかけて、十分に学んできました。この本に書いてあることで、理解できないことはおそらく一つもないでしょう。

ところで、リチャードの役職名はCEO兼チーフストーリーテラー。社長であり、また社内で起こっていることを外に伝えることを責務にしているようです。この本をはじめ、講演、社内見学ツアーを通じて、幅広く活動を行っています。いつか見学に行きたいものです。

12月19日の発売ですが、すでに一部の書店さんには先行して置いていただいています(写真は池袋のジュンク堂さん)。おそらくビジネス書の経営の棚にあります。アジャイルやソフトウェアの棚にも置いていただいているかもしれません。

 仕事やコミュニティで関わってきた、いつもの仲間たちであり、最高の先生たちと一緒に訳しました。素晴らしいレビュアーの皆さんにも手伝っていただいて、出版社の皆様の手厚い支援にも恵まれ、いつもの方法で翻訳作業が進められ、届けることができます。本当にありがたい、喜び(Joy)に満ちた一冊になりました。読者の皆さんにも私たちが感じた興奮が共有できることを大変嬉しく思います。

ジョイ・インク 役職も部署もない全員主役のマネジメント

その「エンジニア採用」が不幸を生む

技術評論社の傳さんからご恵贈いただきました。中小企業で内製化やIT投資のためにはじめてエンジニアを採用する方を主に想定して書かれたエンジニア採用についての本です。「2万名近いエンジニアの職務経歴書を読み、エンジニア採用の責任者として年間700人以上の社員雇用の最終決裁を判断し、約500社の経営陣と面接してきた著者が...」と帯にある通り、豊富な実例(主に失敗例)を持つ著者の方が、ズバっとえぐってくる感じの内容になっています。知らなかったことがたくさん書いてある、という意味では HARD FACTS レベルでした。

その「エンジニア採用」が不幸を生む 〜良い人材を見つけ、活躍してもらうには何が必要か？【電子書籍】[ 正道寺雅信 ]

ということで、各章の気になった部分を抜書きしたり、雑に補足してみます。

第１章 経営課題をエンジニア採用で解決しようとする落とし穴

この章はまず企業の経営サイドで起こりがちな問題を列挙していきます。あるあるすぎてびっくりです。「ITリテラシーすらないのに、ITビジネスを始めるためにITエンジニアを採用してしまう」「際限ない変更でコストだけがかさんでいく状況」...あるあるですね。特にソフトウェア開発を専門としない一般企業で、ソフトウェア開発の経験者とそうでない方の間で軋轢や意識の違いがあってなかなか続かない(辞めちゃう)、というのはよく聞いた気がします。ソフトウェア開発者といっても、一人でどの程度まわりを巻き込んでできるかというのはかなりその人に依存しますし、もちろん技術力にも様々な側面がありますので、うまく見抜く目利き力とか、アドバイスを受ける力も大事になってくるかなと思います。

この章でびっくりしたのは外資ファンドからのアドバイスで、IT分野への投資額を高める...ためにエンジニアの数を揃える企業の例でした。さすがに大きな企業で、一般例でもないんじゃないかと思いますが...。世の中、すごいことが起こるものです。

第２章 エンジニアの募集要項が書けない人事

この章の最初の事例はなかなか衝撃的で、現場部門が書いたJD(募集要項)にある必要要件(Javaがどうとかそういうやつ)のうち、人事部門にとってわかりにくいものを勝手に削除して公開したという話でした。この例だと「LAMP」「Web・サービス系」という文字。うーん、そこ外しちゃまずいでしょ。

他に、とにかく現場で人が足りないので数を追ってしまうダメな採用担当の話、人材紹介会社に依存しすぎる危険性について語られています。こないだスタートアップの採用の話をを聞いてきたんですけど、「採用のコツは、なるべく採用しないこと」と言い切っていてすごいなと思いました。それほど人は重要だし、フィットする人を探すのは大変なので、きちんとやっていかないといけないなと思います。

cbec-titech.connpass.com

第３章 不幸になる原因はエンジニアサイドにもある

まず就職より就社したいエンジニア、つまり、ある会社に入りたい、業務はエンジニアならなんでもいい、というのが一般的な傾向だと指摘しています。確かに会社に入ってから何をするのか、という点が雑なケースって多いと思います。その会社のイメージや環境、同僚のスキルなんかに憧れて、入りたいと思うことって多いと思うんですよね。特に現在の職場であまりうまくいっていないというか、自分のイメージにあっていないと特に。

どうしてエンジニアとして就職/転職したいのか？という話が出てきます。このあたりはぼちぼちエンジニアが人あまりの状態になってきそうで、向いてない人がやっていくには厳しい業界になりつつある、ということを反映しているような気がします。技術の進歩が速い業界って大変ですね。

第４章 「どんなエンジニアが必要なのか？」「そもそも、エンジニアは必要なのか？」を判断する

ここの章の図は面白いなと思いました。エンジニアを２つに分けて考えます。

1. タイプA: 自由な開発環境
2. タイプB: ガバナンス最優先の開発環境

ここでタイプBの、ガバナンス優先の企業で育ったエンジニアは、プロジェクトマネージャーに向いている(そのための基本素養を身に着けている)可能性が高いそうです。そうかもしれませんね。逆に、失敗するかもしれない新規のビジネスを起こすような案件には向いていないかもしれません。

ここではアウトソースするための「発注力」を大きく取り上げています。内製システム部門を整備できるか、外注するのかについても触れられています。

同業他社との競争戦略上コストカットが重要であり、同業他社の追随を許さないシステムを導入できる企業であれば、システム部門を整備して、部門として独立させ、エンジニアが中長期に渡ってキャリアプランを描ける体制を作るべきでしょう。

コストカットのために外注に振れて結局失敗するケースを何度も聞いた気がしますので、このあたりは本当に根深い問題だなぁ、と思います。

第５章 よいエンジニアをみつけ、採用する方法

キャリア採用については、優れたエンジニアを取るための状況が変化しているそうです。経営者やCTOが採用の前面にたって、SNSなどを利用して情報を発信して、採用の最初のタッチポイントがエンジニア同士になるような時代ですよ、という話です。

SNSについては、「自社の採用向け公式SNSを開設する」という話ではありません。情報発信力のあるCTO、もしくはリーダークラスのエンジニアのSNSで情報発信し、興味のありそうなエンジニアとつながっていくのです。すぐに転職の話しにはなりませんが、エンジニア同士の人間関係を構築していくことで、信頼関係ができれば、転職の相談を受けることになります。

第６章 エンジニアを惹きつけ、働いてもらえる仕組みを作る

最後の章は根幹の部分、いかに人が来てくれる職場を作るかという話です。給与体系の見直し、残業など職場環境、評価システム、教育研修の見直しなどを幅広く取り扱っています。

様々なアイデアが語られていて、刺さる部分も多いのですが、ちょっとまとめるのにむいてないので、書籍を眺めていただければと思います。超重要なところですし。

社内で読書会したい

というわけで、なかなか得るものの多い本でしたし、社内のエンジニア採用担当の人も興味持ってくれているので、社内で読書会してみようと思います。そういうきっかけに成るとすれば、相当素晴らしい本なのではないかと思います。よかったらそのうちパブリックに勉強会しませんか？

その「エンジニア採用」が不幸を生む [ 正道寺雅信 ]

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?

ケン・ルービン 認定スクラムプロダクトオーナー (CSPO) - 2017年01/26(木) 〜 01/27(金)

2017年01/26(木) 〜 01/27(金) の日程で、Ken Rubin さんの認定スクラムプロダクトオーナーをお手伝いします。資料の翻訳もやります(これからだけど)。前回はスクラムマスターだったんですけど、今回はプロダクトオーナー向けということで、少し踏み込んだ内容を扱うことになると思います。エッセンシャルスクラムを読んだ方にはわかると思いますが、スクラムを使ったプロダクトマネジメントについてはかなりきっちりとした記述がされていますので、プロダクトマージャー一般におすすめの内容に成るのではないかと思います。

プロダクトプランニングとポートフォーリオプランニング
階層制アジャイルプランニング
近々リリースのためのフィーチャ優先順位付け方法
単独チームとスケールでのリリースプラン方法
定期的に増加するリリースの経済的ベネフィット
ユーザーストーリーを書くことにフォーカスしたアジャイル要件
プロダクトバックログを整える（改良する）ためのテクニック
進捗を追跡しレポートする方法

ジェフ・パットンが「魅力的なプロダクトをUCDを駆使して高速にどうやって考え、合意していくか」というデザイン思考の色が濃いCSPOだとすると、ケン・ルービンはよりスクラムに準拠した経営視点とフィットしやすい側面を扱う感じがしています。これはたぶん組織やシステムの性質によってどっちらのほうが向いている、というのがあると思っています。

彼はエッセンシャルスクラムにも使われている図をCreative Commonsで公開しているので、スクラムの基本コンセプトやプロダクト管理の進め方を上司などに伝える際にも重宝するかもしれません。

エッセンシャルスクラム [ ケネス・S．ラビン ]

エッセンシャル スクラム【電子書籍】[ Kenneth S. Rubin ]

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)