ykmc09 blog

Podcast: https://omoiyari.fm

2019年の記録

振り返りというほどでもなく、2019年をログに残しておきます。

2018年の記録はこちらです。

仕事

いまの会社に入って2年目の年でした。

年初は、メインのアジャイルコーチングの仕事の傍、何件か社内プロジェクトの立ち上げや、社内プロダクトのプロダクト設計などに一時的に関わっていました。 限られた時間でしたが、久しぶりにプロダクトチームの一員として働く感覚はとても楽しかった記憶があります。

並行して年初にアジャイルコーチングの組織を正式にチーム化し、夏頃にはプロジェクトマネジメントの組織と統合した組織を作ったりと、そういった形になれるほどにはやってきたことに対して社内での認知を一定得られたのかなと思う年でした。 同時にプレイヤーとマネージャーの両立に苦しんだ(でいる)年でもありました。

この組織での仕事については LINE DevDay 2019 でお話しし、ログミーでの書き起こしもしていただいたのでご興味ある方はぜひ。(お仲間募集中・・・!)

logmi.jp logmi.jp

また、社内でスポットで支援したワークショップも記事化していただいたりもしたので、こちらもご興味あれば。楽しい仕事でした。

line-hr.jp

仕事(副業)

今年は年初から、人生初めての副業もしました。かなり限定的な時間での支援でしたが、以前よりいつか関わりたいと思っていた「大企業、エンタープライズシステムでのアジャイル」に関わることができました。

私からは詳しくはお話しできませんが、いつか彼らがどこかで登壇して発表してくれるのではと思っています。

私の支援は12月で予定通りいったん終了したので、来年の副業については、やるのかやらないのか、やるならどういうことをやるのか、もやもやと悩んでいるところです。

登壇、メディア掲載

パブリックな場での登壇は以下5件でした。

印象深いのは、 Agile Summit 2019 (Taiwan) です。 初めての海外登壇でしたし、Taiwan のコミュニティの方々とも関われたのはとても楽しい体験でした。また、Taiwan のイベントに出れるといいなぁと思います。

engineering.linecorp.com

ykmc09.hateblo.jp

flexy さんにもお声がけいただき、インタビュー記事を掲載いただきました。

flxy.jp

カンファレンス、コミュニティ貢献

Regional Scrum Gathering Tokyo 2019 実行委員

年初の RSGT 2019 に今回は実行委員として運営に携わりました。実行委員の練度が非常に高かったので、何か欠かせない貢献ができたわけではないのですが、Coaches Clinic を担当させていただき、盛況に終得られたので少しホッとしていました。過去いくつかの海外カンファレンスで見てきた Coaches Clinic のノウハウを色々とパクら真似させてもらいました。

RSGT 2020 も楽しみですね。

アジャイルリーダーシップサミット 2019 実行委員

7月には、川口さんやエンタープライズアジャイル勉強会の藤井さんと一緒に、キーノート+OST というイベント「アジャイルリーダーシップサミット 2019」の実行員をやらせていただきました。

RSGT で OST 慣れしている方々にも多く来場くださったお陰か、とても盛況の中終えられたと思います。 個人的には前述の副業先のチームが、チーム全員で参加してくれて、多くの影響を受けていたのが嬉しかったです。

プロダクトマネージャーカンファレンス 2019 実行委員長

今年で4年目なのですが、今年は来場者数を2倍以上に引き上げ、マルチトラック、スポンサーブース設置、など変数がたくさんある年としてチャレンジしました。

結果的には 1,200名以上の方に来場いただき、大きな事故などはなく盛況の中終えることができました。関わったすべての方々、ありがとうございました。

また今年は実行委員長という立場で携わっていたのですが、まぁ実行委員、運営メンバーがみなさん優秀ですので、楽させていただいたなと言う気持ちです。一般社団法人化に際しても設立時代表理事となり、名前だけ感は否めないのですが、いい経験をさせていただきました。 いまのところ来年も開催を予定していますので、ぜひお越しいただければと思います。

ちなみに開催の翌週が LINE DevDay の登壇で、怒涛の半月だった記憶があります。(思い出したくないw)

その他

Agile Japan 2019 の Coaches Clinic を手伝ったりもしていました。

去年から引き続き、 Scrum Masters Night! の運営にも関わっていました。

海外カンファレンス

今年は会社の予算から Global Scrum Gathering Vienna 2019 に行かせていただきました。川口さんに巻き込んでいただき OST ホストも体験できました。

休暇として寄らせてもらったドゥブロブニク、いい街だったなあ。

Podcast

#omoiyarifm 今年は 11エピソード公開したようです。 今年も色々なゲストとお話しできるのは楽しい時間でした。 個人的には、 #0 で話をした平鍋さんをついにお迎えできたのは、節目感のある出来事でした。

lean-agile.fm

まとめ

今年は、「慌ただしくなんとか1年を乗り越えていった」という感があります。 一つ一つのことに丁寧に集中して向き合ったか、と自問すると、少し反省するような気持ちになります。 いろんな貴重な機会をちゃんと楽しめたんだっけな、面白がれたんだっけな、という気持ちもあります。

2018 年は以上として、 2019 年は
- オープンマインドと謙虚、そして良い姿勢(物理)
- 集中と十分なゆとり
をモットーに、なんやら頑張っていければと思います。

去年のまとめでこのようなことを書いたのですが、後者に関しては真逆を行ってしまったかもと感じるほどです。その分、せめて誰かの役に立てていればいいんだけどな、と思います。
今年はどう生きて行こうかな。まだよくわかりません。そんなことも今は特に考えすぎず、休暇はガキ使をお供にゆっくり過ごそうと思います。

みなさんも良いお年を!

プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)

TL;DR : ひとことでいうと

  • 決定事項になる前に早めに巻き込もう
  • 巻き込むときは、
    • その意図や相手に期待することを伝えよう
    • 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう

たまに遭遇するシーン

ソフトウェアプロダクトの企画(プロダクトデザイン、プロダクト設計)を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。

「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は(程度の大小はあれど)起こってしまう と思っていて、今回はそういったケースを想定しています。

特に、以下のような思いがあるからそうしている、というケースを話題に上げたいと思っています。

  1. エンジニアに企画を説明すると、 多くの指摘(マサカリ)が入ることが多いので、なるべくちゃん作り込みたい
  2. エンジニアを 邪魔してはいけないという考えがある (または、嫌がられる)

ちなみに私は、エンジニア→プロダクトオーナーを経て、今は社内で横断的にチームの何がしかを支援する仕事をしています。エンジニアとプロダクトオーナー(≒ 企画職)両方を経験したので、ある程度どちらの立場もわかるなぁという気持ちです。

こういったケースで起こること

ちなみに、要件や仕様をかっちりと固めてからエンジニアに渡した場合、エンジニアの視点から見て以下が起こります。

  1. 解決したい課題、やりたい事に対する How が、 技術的に不可能、難しい、または最適でない
  2. 納得感が醸成されず、やらされ感のある モチベーションが低い開発になってしまう(上記と相まってのケースが多い)

a. については、企画を行う人にエンジニアリングの知識が少ない場合に起こりうることは想像に難くないと思います。 b. については、「自身が意思決定に関わっていないものは動機づけされづらい」という心理的な作用があると思います。(自己決定理論)

なぜ「かっちり決めないといけない」と思ってしまったか

再掲ですが、冒頭にあげたとおり、以下の理由を見聞きします。

  1. エンジニアに企画を説明すると、多くの指摘(マサカリ)が入ることが多いので、なるべくちゃんとしたい
  2. エンジニアを邪魔してはいけないという考えがある(または嫌がられる)

1. に関しては、「指摘される」=「自身の企画や、ひいては自分の努力が否定された用に感じる」「サンクコスト(これまで投資した時間、労力)を考えると指摘を素直に受け入れづらい」と感じることもあり、この反応がより防御的な行動、つまり「建設的な議論にならない」「次は、よりかっちり固めるように時間を使う」につながることがあります。

もちろんお気づきかと思いますが、完璧なものなど作れない前提において、時間をかけすぎることはリードタイムの不要な増加を起こす、負のスパイラルになってしまいます。

2. については、良かれと思ってやっている場合は「地獄への道は善意で舗装されている」の例だと感じますし、嫌がられるから、というケースは信頼関係が十分に構築できていないのだろうなと思います。(どちらかが悪いという話ではなく)

どうすればいいか

身もふたもないですが、「やっぱり早めに巻き込んでおくこと」です。

タイミングとしては、少なくとも、 やるということが決定する前 です。 先の「b. モチベーションが低い開発になってしまう」に関しては、やることが決定してからの巻き込みでは、人間の感情面でなかなか取り返しは付きません。

巻き込みの方法はなにか特別なものである必要はなく、通常のミーティングスタイルでも良いでしょうし、自席でのカジュアルな話、場合によってはチャットでもいいかもしれません。

「そうは言うけど嫌がられるんですけど」と思うと思います。

嫌がられないために念頭に置いておくと良いことがあり、その中でも特に重要なものは、

  • 目的と期待を伝える
  • エンジニアの仕事の特性に対する知識と共有認識づくり

だと思っています。

目的と期待を伝える

そのミーティングの意図や、相手に期待することをお互いで揃え、 その時間を使う目的、効果をあらかじめ明確にしておく、ということです。

エンジニアはミーティングを嫌う傾向があると思うかもしれませんが、すべてのミーティングが嫌いなわけではなく、「効率、効果が低いミーティング」を嫌っています。 特に良くないケースが、「効果が低い」かどうかも判断できないような、とりあえず設定されたようなミーティングや、過剰な定例ミーティングです。

だめな例のひとつは、「すみません、とりあえず時間抑えさせてもらいました」というものだと思います。 もちろんこれらすべて、別にエンジニアに限らず嫌ですよね。

ちょっと余談ですが、チャットの第一声で「〇〇さん、お疲れ様です」だけ送ってくる、みたいなコミュニケーションってもやっとしませんか?(重要度や緊急度が判断できないうちに、反応を強制される気がして、僕は嫌なのでやらないようにしています)

意図や期待することについては、難しく考える必要はなく、たとえば以下のようなものだけでもよいと思います。

  • 手戻りを減らすために、技術的に不可能なことがないか早めに確認しておきたい
  • もっと簡単にできる方法はないかアドバイスがほしい
  • 記載内容に不足がないか、レビューを手伝ってほしい
  • 先に技術検証しておいたほうがいいことなどがないか相談したい
  • 同じプロダクトメンバーとしてシンプルに早めに知っておいてほしい
  • 同じプロダクトメンバーとしての意見を聞きたい
  • やる/やらない、優先順位を決めるための超ざっくりな見積もりしりたい(数日レベル?数ヶ月レベル?)

合わせて「こういう場ではない」ということも伝えておいたほうが良いと思います。

  • やることが決定したという事務連絡ではない
  • 「約束になる見積もり」をしてほしいわけではない
  • 売上の試算はこの後するので、そういったツッコミは一旦なしにしてほしい
  • 仕様のイレギュラーパターンはこの後検討するので、そういったツッコミ(略

目的が達成されたら、ささっと解散してしまいましょう。

もちろんエンジニア側も、設定された打ち合わせの目的が曖昧であればちゃんと事前に確認するのが良いでしょう。 ただ「何が目的ですか?」のように高圧的に感じさせうるワードではなく、「確認の目的って、技術的に不可能じゃないか確認するため、とかでいいですかー?」のように、おもいやりを持って歩み寄ったコミュニケーションをぜひしましょう。

そして、目的に沿って意見を言うようにするのがいいでしょう。たとえば、ざっくりとした要件を検討しているフェーズでは重箱の隅になるようなことは言わない、などです。 また、自分が期待するものと程遠かったとしても、それは協調してい作り上げ、ともに成長して行けば良いものだと思います。期待が何かフィードバックしましょう。

※ RSGT2019 で、歩み寄って「どういった要求・仕様がいいのか」を一緒に作り上げていたチームの事例がありました

今後「マサカリが怖い」と不用意に思わせて、結果的にプロダクトや組織に悪影響をあたえるようにならないよう、ほんの少しの思いやりが必要です。 なにかがうまくいっていないとき、ほとんどのケースでは双方に何らかの問題があります。でもそれは逆に言うと、双方にできることがあるということです。

エンジニアの仕事の特性に対する知識と共有認識づくり

確かにエンジニアの「集中の妨げ」というのは生産性に影響すると感じます。

どういったことが「集中の妨げ」になるのか、ある程度知っておき、あらかじめ対話しておくのが良いと思います。

多いケースは、集中している時にいきなり直接声かけて割り込まれるのはきつい(近いイメージは、「数学の問題をといているときに声かけられるときつい」など)というものです。

なので、

  • 最初の一声は、チャットなどの非同期コミュニケーションを使う
  • 集中している時間帯をお互いわかるようにしておく、共有しておく

などもできるかと思います。

ちなみにエンジニアリングマネージャーは割り込みをいとわないケースもありますし、エンジニアでもまったく気にしない人もいるので、その人の特性を対話の中で確認しておくと良いかと思います。

エンジニアも集中が妨げられたとしても、説明なくつっぱねることはせず「今集中して○○の開発していて、今離れると効率が悪いので、夕方でもいいですか?」「次からは一旦チャットで、相談内容含めて連絡くれると嬉しいです。チャットでも解決できるかもですし」といった説明を、面倒がらずにするのが良いと思います。

こういった相談などに使う時間量の目安を、あらかじめ定めておく

少し補足的ですが、想定していなかった割り込み作業は、見積もりにも影響するので、あらかじめ時間の目安を取り決めておくのもよいかもしれません。

ガチガチのルールにはせず、あくまでも双方の目安としての認識合わせをしておくイメージです(10%くらいの時間、とか)

また、あまり五月雨にして集中できるまとまった時間を減らさないように、一日のある時間帯にまとまった時間として確保しておくのも良いと思います。

さいごに

プロダクト企画者とエンジニアの対立構造のように書いてしまいましたが、職種によるものではない話だと思いますし、どちらか一方が良い/悪い、偉い/偉くないというつもりではありませんのでご承知おきください。

なんとなくエンジニアが特権階級なような書き方に感じたかもしれませんが、まったくそんなことは思っておらず、プロダクトをより良く作るフラットな関係性として、お互いに敬意を持ち、相手を思いやって歩み寄ることが大切だと思います。

ちなみにスクラムだと、プロダクトバックログのリファインメントがこれに当たると思います。

そういう意味だと、こういったように多く説明しないといけないことを「プロダクトバックログリファインメント」と一言で表現できるのは、フレームワークを採用するメリットともいえますね。

ちょっとまとまらないままつらつらと書いてしまいましたので、ご意見ぜひください

嫌われるのが怖い人間からの「『嫌われない』を諦めない」 #devlovex 登壇記

DevLOVE X「嫌われない」を諦めない というタイトルで登壇してきました。

伝えたかったこと

伝えたかったことの中で、今回メインに据えたのは

  • ものごとを推し進めるために、「嫌われる要素」を取り除く努力もしよう

ということでした。

このテーマの動機(個人的な部分をメインに)

「嫌われるのを怖がる」という弱み

僕は「嫌われるのを怖がる」タイプです。 「全員に好かれるなんて無理なんだから、嫌われちゃってもいいじゃん」という励ましを受けるやつです。HSP (Highly Sensitive Person) の数値も高めの人間です。

なので、「相手を伺いながら、大きな衝突が起きないように進める」というアプローチを取りがちで、「嫌われることをいとわずに物事を大きく進める」というのはかなり意識しないとできません。克服しようと努めている弱みのひとつです。

前職でメンターをしていただいていた方に「その、周りを見て調整する能力が強みであり最大の弱みだ」とフィードバックをもらったこともあり、今でも胸にとどめています。

「嫌われるのを怖がる」という強み

でも逆に、「嫌われるのを怖がる」という弱みに感じることも、裏返せば強みになりうると言うことだとも思います。

僕と同じように「嫌われるのを怖がる」ことを弱みだと思っている人に、それもうまく活かせば物事をうまく進める要素になるんじゃない?という投げかけをしたかったというのがこのプレゼンテーションの動機です。(もちろん自分への投げかけでもあります)

また同様に、つい「嫌われるのをいとわずに進める」ことが多い人に、ちょっと立ち止まってこういうことを考えてみてもいいんじゃない?という投げかけをしたかったという動機もあります。

「『嫌われない』を諦めない」ことの矛盾

ちなみに僕がスライドに書いたような「嫌われないようにする」行為は、時として「あざとい」「腹黒い」ように映ることがあり、それが結果的に「嫌われる」につながるという矛盾があります。

つまりは完全に嫌われないことなんて不可能で、「全員に好かれるなんて無理なんだから」というのは真理ですね。

ただ、その中でも「無用に嫌われる必要はない」(と同時に「無用に媚びる必要もない」)というのが言いたかったことになります。

どちらのアプローチも一長一短で、どちらのタイプの方も、自分が自然に振る舞えるやり方をベースにしながらも、他方の要素も取り入れることで、成果を強化できるのではと考えています。

まぁ当然のことなんですが、関係者が楽しく成果でるのであれば、アプローチは結果論でしかない話だと思います。

「そのための準備」のスライド

スライド内の「アプローチ編」の各節の最後の「そのための準備」というスライドを入れています。

さらっとシンプルな問いの形で書いていますが、ここに答えていくのはそれなりに大変なことだと私も思っています。 「自分の広めたいこと」を深く理解して、何をどういったアプローチで解決してゆくのか。これをができていると自信を持っているでしょうか?

もちろん自信がないと始めてはいけないというわけではありませんが、これを楽しみながら続けていく必要があると思っています。今回のようなコミュニティは、まさにそのためにもあると思っています。

公演中に余談したこと

「自分の広めたいこと」を、自分が毀損していないか

僕は現場の支援から離れるときに、冗談で「アジャイルのことを嫌いになっても、横道のことは嫌いにならないでください」ということがあります。「逆だろ!」のツッコミ待ちですね(恥)

これはもちろん冗談なのですが、真面目な要素も含んでいると思っています。

人は、「誰が言ったか」でその良し悪しを決めてしまうことがあります。 これは「色眼鏡」な面が大きく、聞き手としては可能な限り避ける努力をすべきことであると思いますが、実際そういった判断が行われることは多いと思います。

つまり「自分の広めたいこと」を、「自分というフィルター」が毀損してしまうようなことは避けたいと思っています。(e.g.「あの人が言ってるから、あれはなんか嫌いだ」)

ykmc09.hateblo.jp

その他もろもろ

舞台裏

私の DevLOVE 初登壇は2013年3月でした。 このあとの私のキャリア選択の大きな転機の一つだったと思います。

devlove.doorkeeper.jp

このとき企画協力してくださった @TAKAKING22 が、今日は裏番組。 そして、このときに共同登壇した当時の会社の同僚が、セッションを見に来てくれていました。 さすが長い歴史を持つ、コミュニティ。私にとってもドラマを提供してくれました。

Peter Senge の名言

人は変化に抵抗するのではなく、変えられようとすることに抵抗する

この言葉は以前 @hiranabe に教えてもらった言葉で、とても気に入っている言葉です。こちらの対談の中で教えてもらったので、ぜひよければ記事もご覧ください。

next.rikunabi.com

スライド内の記事

スライド内で紹介した、「アジャイルをどう紹介しているか」は以下の記事からご覧ください。

flxy.jp

また、同僚の事例スライドは以下です。

さいごに

DevLOVE X 本当に楽しい素晴らしい場でした。 こんなに豪華な登壇者の中にまぜてもらったことを光栄に思います。

運営のみなさん、この規模のイベント運営、本当に大変だったと思います。 お疲れ様でした&ありがとうございました!

人望が集まる人の考え方

人望が集まる人の考え方

flexy に取材いただき、アジャイルの話をしました

取材依頼をいただきまして、話してきました。

言いたかったこと

記事が、ちょっと偉そうな感じのトーンになってしまったかもです・・・。

言いたかったことは、

  • なんでもいいから良くすることを始めてみよう。別にルールなんてないよ。
  • とどまることなく、世界に誇れるくらいまで邁進しなきゃな
  • 経営層、マネジメント層はちゃんと理解して、チーム支援したげてね

という感じです。

嬉しかったこと

取材いただいた担当の方から、

今回の取材を通してアジャイルがすごくクリアにわかるようになりました。そして横道さんに教えていただいたように振り返りを早速実践しています。

というメッセージを後日頂いて、これだけで取材受けた甲斐があったな、と思いました。