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

技術評論社の傳さんからご恵贈いただきました。中小企業で内製化や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)

 

Joy, Inc. 共訳で作業してます。

もうちょっとでいろいろ情報が出てくると思うんですけど、年内の発売予定で「Joy, Inc.」を仲間で訳した日本語版が出ます(申し訳ないことに私が訳したのはほんのちょっとなんですけど)。三年前くらいの Global Scrum Gathering で基調講演してた Richard Sheridan という人の本で、米国でアジャイルな受託開発を10年以上ずっとやってきた会社の話です。

顧客との関係を喜び溢れたものにする。従業員が会社にいくのが楽しみになるような喜び溢れた職場を作る。そのメソッドはアジャイルのプラクティスと、UCD(人間中心設計)。もちろん、その会社なりの工夫もあり。

ユーザーストーリーマッピングのジェフ・パットンにも「あの会社、もう観に行った？」って聞かれるくらい、注目されている「メンロ・イノベーションズ社」の努力と奇跡をぜひお読みください。... ってことで、もうちょっとお待ち下さい。

出版社さんは翔泳社さん。初期のスクラムギャザリング東京で大変お世話になって、デブサミでもたびたび登壇させていただいていてスクラムやアジャイルの話をさせていただいて、なにかと縁の深い出版社さんにこの本を担当していただけて、ありがたいです。

(11/18 追記) 日本語版の書誌情報いただきました。

(12/10 追記) 楽天ブックスの予約ができますのでリンクを掲載しました。12/19発売です。

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

■刊行日
2016年12月19日

■価格
1800円＋税

 

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

Joy, Inc.: How We Built a Workplace People Love

Regional Scrum Gathering Tokyo において、たくさんの落選セッションが出てしまってごめんなさい。

(この文章は昨夜Facebookに投下したものです)

Regional Scrum Gathering Tokyo において、たくさんの落選セッションが出てしまってごめんなさい。まさかこんなたくさん応募してくれるとは思ってなくて、相対的に自信があった人すら、残念に思う結果を受け取る結果になり、ショックを受けていることも想像しています。

実は会場を予約する時点で三日間開催という意見もありまして、仮予約までしたんですけど、運用がもたないだろうということで、二日間の開催を選択した経緯があります。それが間違っていたかもしれないし、やろうとしてやはり運用が破綻したかもしれず(2年前に三日間開催は経験ありますが、誰かに負荷が集中するという苦い経験もしました)、情報が足りないというのが現在のところです。

どれか特定のイベントを推すというのは控えたいですけど、せっかく書いたプロポーザルをどこかの場で実現するっていうのは、ぜひやっていただきたいです。受け皿を作っていただくこともぜひぜひ。

実行委員会が採択したセッションはそれなりに議論して決めたのですけど、所詮は限定的な記述を短い時間で読んでの決定に過ぎないので、誰かの観点でよりベターなプロポーザルが落ちてしまっているという可能性は高いと思います。

幸いにしてプロポーザルはオープンです。もし誰かにとって重要なセッションが落ちてしまっているなら、ぜひ、実現に向けてご協力下さい。コミュニティやカンファレンス、社内勉強会など、できるだけ幅広い機会に恵まれるとありがたいなと祈っております。

ジョナサン・ラスマセンのインセプションデッキ研修 : プロダクトオーナーにおすすめ

アジャイルサムライの著者、ジョナサン・ラスマセンさんのインセプションデッキ研修をお手伝いします。私は５年前に来日したときに受けました。

インセプションデッキ・トレーニング 同時通訳(1日間)

http://www.jp.agilergo.com/inceptiondeck-rasmusson-20161018

講師　ジョナサン・ラスマセン
日程　 2016年10/18(火)

アジャイル開発でどうやってプロダクトバックログを作っていくか、ステークホルダー(利害関係者)からどうやって要件を引き出すか、彼は10個の手法を選んで、デッキにしました。

ジョナサンはモノを作る側の技術プラクティスには精通しており、正しく作ることはうまくいくのですけど、それでもプロジェクトが失敗してしまうことがある。なぜかというと、要件が不明確、もしくは、間違っていたわけです。

そこで作ったのがこのインセプションデッキです。確認すべき要件のリストです。それぞれがテンプレートになっていることが重要です。

このテンプレートを埋められるようにステークホルダに質問してみて、答えてくれればそれでよいし、なければ自分で埋めてみて「こう理解しているのですけど、どうですか？」と聞いてみれば「いやいや、こうですよ」というふうに情報を引き出せる可能性が上がります。

ジョナサンのインセプションデッキは10枚のテンプレートで構成されます。もしこれと違うものが必要になったら、自分のデッキを作ればいい(作るべき)と言っていました。まずはジョナサンのインセプションデッキを参考にし、足りない所があれば作ってみたり、不要なところを省いたりしながら、自分のものを作り上げていくといいでしょう。守破離です。

もし、ご自身のインセプションデッキの工夫があれば、ぜひ研修に持ってきて、こんなのあるよ！と聞いてみましょう！

1. 私たちはなぜここにいるか？

2. エレベーターピッチ

3. ビジネスのビジョン

4. 目的とスコープ

5. 組織のコンテキスト

6. 論理的スコープ

7. 技術的ビジョン

8. リスクマネジメント

9. プロジェクト見積もり

10. トレードオフスライダー

テンプレートを角谷さん(@kakutani) が日本語化して公開してくれています。

support/blank-inception-deck at master · agile-samurai-ja/support · GitHub

ブログを移設中

Movable Typeで置いてもらっていた古い日記(ブログ)をWordpressに移行するということで、こちらはデータを引き取ってはてなブログに移行中です。ついでに、はてなダイアリーで書いていた新しい方の日記(ブログ)もこちらこちらに移行しました。

手書き風のデザインにしてみたのですがちょっと読みづらいのでどうするか悩むところ。 ( => 更新: 本文のフォントは通常のゴシックに変更しました。タイトルは手書き風フォントのまま。)

2004年のエントリーとかなかなか赤面モノなのですが、まあそれはそれでよい。

デブサミ2016 で発表しました : 実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう

デブサミ2016でお話しました。

• 【18-D-1】実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう
  • http://event.shoeisha.jp/devsumi/20160218/session/1004/

前年の話を下敷きにしつつユーザーストーリーマッピングと、カイゼンの先に新規ビジネス開発をしてこそ....というお話をしました。

Day1の朝イチにもかかわらず、おかげさまで満席のお客様に入っていただきまして、ありがたい限りです。壇上に上がってから、2008年のデブサミに初めて参加して、奇しくも同じくDay1の最初のセッションで関さんの「8年目のアジャイル」のセッションに参加して、アジャイルのはじめかたとして「信頼貯金」のアイデアとか、テストの話を聞きまして、ああ、できないと思っていたけど、とっくに始めている人はいて、自分の環境でも始めようと思えば始められるのかもな、と思ったのを記憶しています。ちょうどその1年後には、スクラムを始めるべく準備のスプリントをしてました。そんな話を冒頭で語ってしまったので後半のスライドは全く未消化かつ、大事なとちきテストの会議の宣伝もできませんでしたが、資料には入っておりますので、ご参照いただければ幸いです。

以下に、資料と動画をおいておきます。

資料のリンク

https://speakerdeck.com/kawaguti/jikkan-kudo

自撮り動画はこちら

https://youtu.be/W9vf18aY72k