人付き合いの話

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

 

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

 

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

 

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

 

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

 

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

 

....などなど。

 

 

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

 

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

 

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

 

徒然ですみません。

 

 

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

以前、ご紹介していた 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年にわたって、アジャイルとデザイン思考を通じて、ソフトウェア開発が必要な顧客に価値を与え続けてきました。

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

f:id:wayaguchi:20161217085309p:plain


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

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

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

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

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

f:id:wayaguchi:20161217095441p:plain

 

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

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

 

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

f:id:wayaguchi:20161216213453j:plain

f:id:wayaguchi:20161216212413j:plain

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

 

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

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

 

 

 

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

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

 

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

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

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

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

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

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

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

cbec-titech.connpass.com

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

社内で読書会したい

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

 

 

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

 

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

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

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

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

f:id:wayaguchi:20160120114243j:plain

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

 

 f:id:wayaguchi:20160120114227j:plain

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

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

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

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

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

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

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

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

■刊行日
2016年12月19日

■価格
1800円+税

 

 

 

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

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

 

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

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

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

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

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

 

 

 

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

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

 

インセプションデッキ・トレーニング 同時通訳(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

 

f:id:wayaguchi:20161005112933p:plain

f:id:wayaguchi:20161005113028p:plain

f:id:wayaguchi:20161005113041p:plain

 

f:id:wayaguchi:20161005113101p:plain

f:id:wayaguchi:20161005113114p:plain

f:id:wayaguchi:20161005113126p:plain