tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

#RSGT2020 を楽しむために

カンファレンス Regional Scrum Gathering Tokyo

f:id:tune:20200105174712p:plain

はじめに

いよいよ1/8(水)からRegional Scrum Gathering Tokyo 2020が始まります。 私も去年が初参加でしたが、今年も参加できることを楽しみにしています。

今年から会場が変わり、参加者数も増え、初めて参加される方も多いのだろうと予想しています。 自分も今年より楽しむために、去年知っていたらよかったなーと思ったことを思い出したので下記に紹介させていただきます。

アドバイス

タイムテーブルは印刷して持っていく

詳細スケジュールがConfengineで管理されていますが、スマホではタイムテーブルがうまく表示されず苦労しました。 昨年は会場にもタイムテーブルが印刷されていなかったので紙に印刷して持参すると何をみようか考えるときに役立つと思います。

大きめのカバンを持っていく

ストラップ付きの参加証に加え、記念品(昨年はビールグラスでした)、水・お茶、本、ブースでもらえるノベルティなどいろいろな配布物がありました。 ジャストサイズのカバンで行くと持ち帰りに苦労することになるので余裕を持っていくと良いと思います。

参加者に積極的に話しかける

初日の最後にネットワーキングパーティーがあります。 「初日に仲良くなってイベント盛り上がろうね」な位置付けだと思うのですが、初めて参加する人にとっては初日は仲良くなるきっかけが少なく、「旧知の人や同じ職場からきた人たちが集まってが飲み食いする場」になりがち(見えがち?)です。 一方通行で話を聞いて終わりのカンファレンスではなく、双方向に意見を交わしてよりよいやり方を模索するカンファレンスなので、普段の勉強会では他人と話さず帰宅してしまうあなたも、ぜひ積極的に話しかけてみてください。

また講演は発表時間ギリギリでQ&Aの時間が取れないものが多かった印象です。 なので疑問に思ったことは発表を終えて会場をうろうろしている講演者を捕まえて直接話しかけると良いです。 よくよく聞いてみると発表者の多くもフィードバックを期待しているそうです。

セッションに参加しなくてもよい

タイムテーブルをみてどれを選ぼうか考えてしまいがちですが、ピンとくるものがなければ講演を聞かず廊下にいる誰かと話を しても良いカンファレンスです。

講演者の言っていることが正解とは限らない。素直な気持ちで疑問をぶつけてみよう。

プロダクト開発は一つとして同じ事例がなく、唯一の正しいやり方があるものではないので講演者が言っていることが必ずしも正しいということはありません。 去年は基調講演でChris Lucian氏が「no estimates(見積もりしない)」を提唱していましたが、それに疑問を持った参加者が3日目の議論の場で「見積もりの良い点を議論しよう」と言っていました。それを受けてChris Lucian氏も「no estimateを参加者と話したい」と議題を挙げていました。誰かの発表を受けて議論があちこちで始まるそんなライブ感のあるカンファレンスです。

今年は大崎ではなく御茶ノ水です！

うっかり大崎に行かないようにしましょう。

ジョブボードを活用しよう(追記)

アジャイルな職場を探している人・アジャイルな人材を探している人向けにジョブボードがあります。 実際に転職に繋がる事例もあるので是非活用しましょう。

See also

去年の参加振り返り記事

他の方が書いたRSGTの楽しみ方

Engineering ManagerはManagerでしょ

この記事はEngineering Manager Advent Calendar 2019 20日目の記事です。

qiita.com

はじめに

他のEngineering Managerの方とお話しすると「技術」「プロセス」「組織」「育成」といった様々な悩みを聞きます。 ですが名前に"Manager"と入っている以上、組織の中間管理職の1つのはずです。 マネージャーとしての振る舞いが議論の俎上に上がることが少ない気がしたので、普段自分が気をつけていることを3つほど紹介します。

〇〇申請忘れられがち

勤怠承認・経費申請・利用申請などなど、ヒト・モノ・カネを預かるマネージャーには何かと承認作業が求められがちです。 溜めがち・サボりがち・忘れがちなのはエンジニアに限らない傾向なのかもしれませんが、ただ諦めていませんか? メンバーに何度も催促することは基本ですが、他にも工夫する余地はありませんか?

例えば「○○さんがリモート退勤1分後に勤怠時刻修正を送ってきてくれました 最高！」といったことを、皆が見えるSlackチャンネルに投稿したところ、リモーワーク時の勤怠申請をまめに送るメンバーが増えました。

また先月末の勤怠承認締め日前にはこんなメッセージをSlackに投稿したりしました。手を変え、品を変え、協力を促す努力はするべきだと思います。

f:id:tune:20191214174955p:plain
一番多く押されているスタンプは「なんてこった」です

ルールを文章化し、守って欲しいことを伝える

メンバーにはチームを組んで開発に取り組んでもらっていますが、中にはリモートで稼働する人もいます。 リモートワークでの業務効率を高めるため、「全員リモートワークを経験し、課題を議論しよう」という取り組みを、メンバーが自主的に始めてくれたことがありました。

マネージャーの自分抜きで改善を始めてくれたことは大変嬉しかったものの。会社としてはリモートワークは上長の許可の元行うルールになっており、リモートワークを積極的に推進している訳でもなかったのでルールと目的を改めて明示しておく必要があるなと感じ、下記のメッセージをSlackに投稿しました。

f:id:tune:20191215103102p:plain

ルールや考えは口頭でつたえるだけでなく、都度皆が見える場で共有することが大事だし、自由な取り組みをしてもらうにもここだけは守って欲しいという境界を明確にしておくことは重要だと考えています。

見本となる動きをする

できていない人に注意・助言されても聞かないと思っています。 なので自分がやって欲しいなと思っていることは率先して取り組んでいます。

  • 時間を守る
    • 遅刻しそうなら早めに連絡する。
    • 会議は時間になったら始めて、遅れる人を待たない。
  • 日頃からインプットする
    • 本を買う、本を読む
    • 役に立つ情報を共有する。
  • 日頃からアウトプットする
    • ブログを書く。
    • 登壇しにいく。

おわりに

「エンジニア相手だから」という先入観を捨て、マネージャーとしての当たり前の振る舞いを積み上げた先に「いいEngineering Managerのあり方」があるのではないでしょうか。

Scaled Agile with Jim Coplien に行ってきました

勉強会 マネジメント アジャイル

f:id:tune:20191208125056j:plain

はじめに

TACO(Tokyo Agile COmmunity)主催の勉強会に行ってきました。

taco.connpass.com

すでにまとめてくださった方もいますが、自分の言葉でまとめ直しておくことが大事かと思い、当日のメモを整理してみました。

Coplien氏の講演内容

"Scaled Agile"の勉強会なので、最初に参加者の取り組み状況を挙手で聞いていました。

  • 1チームスクラム：会場の1/3〜1/2ぐらい→20〜30人ぐらいかな?
  • LeSS：私を入れて2名だったはず。CopeはLeSS嫌いだったがLeSS考案者に"convinced"されたと言っていました。
  • SAFe：何人か手を挙げていたのかも。Cope曰く"SAFeはアジャイルでない"
  • Scrum@Scale：10人位か、ここ最近醸し出している「オフィシャル感」から広まっている印象。

次にCopeは「なぜスケール」を考えなければならないかについて疑問を投げかけました。 「作りたいものがたくさんあるから」というのは良く聞く理由の一つですが、人々は大きなプロダクトになるほどその使い方を知りません。 作った機能の大半が使われていないというのはソフトウェアエンジニアであれば一度は聞いたことがある話だと思います。 また開発員が増えるとプロダクトはその分良くなるのでしょうか? Coplien氏はSkypeを例に挙げていましたが、増えたエンジニアの数に見合う価値が上がったかと言うと疑問に思う方が多いでしょう。 ソフトウェア開発は1人のエンジニアがレバレッジを効かせてアウトプットを出すことができる業種です。 それなのに何故カイゼンを続けたり、スケールを考える必要があるのでしょうか?

スケールさせるとコミュニケーションコストが生じることは明らかです。 「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う理屈もあるかもしれません。 しかしある調査結果では組織のアウトプットは構成員の人数に比例していたそうです。 したがって「組織の構成員が増えたからコミュニケーションコストを抑えて生産性を上げなければならない」と言う課題は実は存在しないことになります。

ジェフ・サザーランドはScrum@Scaleをフラクタルに設計しましたが、チームの代表者を介してコミュニケーションを行うやり方は軍隊のやり方に似ています。 5名チームのScrum@Scaleを4階層で組むと625人が参加することになり、チーム同士が会話するのに必要なコミュニケーションパスは平均7.6人となるそうです。 世界中の人と6人介すれば繋がることができる六次の隔たりという理論もあるのに、組織内で7.6人を介するコミュニケーション設計はどこかおかしいのではないでしょうか。

ではこのような環境で人はどう問題を解決するかと言うと、ハブを作り特定の誰か・専門家を介して短く繋がります。 Spotifyモデルだとギルド、LeSSだとコミュニティがこれに当たると思います。

ハブがあることでコミュニケーションが最適化できます。 限られた人がたくさんの人と繋がり、ハブとなっている構成をスケールフリーネットワークと呼びます。 Coplien氏はスケーフリーネットワークの例として学術論文を挙げていました。確かに多くの論文が限られた数の論文を引用しており、その形はスケーフルリーネットワークと言えます。 ハブがあることでコミュニケーションがやりやすくなり、フィードバックをすぐにもらえることからアジャイルに物事を進められるようになります。 マネージャーやアーキテクトといった役割は組織の自然なハブになります。 しかしアジャイルな開発を目指し、上記の役割を人から取り上げてしまうとハブが消え、フィードバックを得る機会が失われてしまいます。

やり方をカイゼンしていくには自らの常識に従うことが重要です。 「Scrum@Scaleでこう決められているから」、「集まるのは大変だからハブをツール化(例えばConfluence)しよう」としてはいけません。

Coplien氏は講演の最後をこの言葉で締め括りました。

Small is beautiful

おわりに

終わってからも色々と考えさせられる講演でした。 「スケールは基本的に良くないこと」という前提に対し、プロダクトが大きいからチームを大きくしなければならないと質問した人方がいましたが、Coplien氏はこれに「リリースしたらユーザーをよく観察しろ」と回答していました。短絡的に人員を増やして対応するのではなく、ユーザーを良く観察し、何が価値を提供するのかを良く見極め、そしてそこに注力する。小さく開発を続けることにいつか限界が来ると思うのですが、それでも自らの常識に照らし合わせて考え、シンプルなやり方を追求していく必要がある。私にはそんなメッセージに受け取れました。

レガシー感謝の日2019で「おくりびと」を話してきました

勉強会 リファクタリング

はじめに

「レガシー感謝の日」という勉強会のタイトルに惹かれて参加 & 発表してきました。 弊社のレガシー、「Retty本体」を紹介できて大変満足しております。

askul.connpass.com

Twitterでいただいたコメント抜粋

#レガシー感謝の日で参照できます。あるある話なのか自社も同じようなことがあるという声が多いのだと感じました。

その他

ハンズラボさんのユニケージ開発手法がいろいろな意味で面白かったです。

www.usp-lab.com

びっくりポイント

Ques #14で「顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み」を話してきました

勉強会 アジャイル

はじめに

QA界隈のエンジニアが集まる老舗イベントQues #14で登壇する機会をいただき話してきました。「Agile Testの今」というお題に対し、「アジャイルな開発」を実現するためのRettyにおける文化の変革について事例を交えて紹介しています。素敵なオフィスでの満員の会場に、事前のインタビューでの集客と、Quesの運営スタッフの皆様には大変感謝しております。

f:id:tune:20191118095512j:plain

quesqa.com

Twitterのハッシュタグ付き投稿をみるにそれなりに参考になる発表ができたのではないかと思います。以下、いただいたコメントについて簡単にフォローします。

Twitterでいただいたコメント

投稿内容のチェック、ハッシュタグなどの解析、表示する順番などなど面白要素がたくさんあると思います。

こちらをどうぞ → 【2019年最新！】新宿の合コンで今年人気のおすすめ30店 - Rettyまとめ

QAは無くならないし、弊社もQA見てくれる人がいるなら大変心強いです。 QA組織が必要(そしてリリースのブロッカーとなっている)、テスト自動化だけをやるエンジニアがいる、手動テストだけをやるエンジニアがいる・・・というのはだんだん変わっていくかもしれませんが。

プロダクトオーナーの判断に委ねています。重要度と優先度を元に考えることが多いと思いますが、最後は誰かが決めないといけないので。

ABテストは結構やっています。

名前を付け替えてスクラムイベントを形式的に取り入れるとわりかしありますよ。 - 責任者→プロダクトオーナー - プロジェクトマネージャー→スクラムマスター - 進捗定例→スプリントレビュー

xUnit系テストは十分にないです。あればもっと改善早く進むのですが。

創業者が書いたコードの大半は書き直されていると思いますが、どこかに残っていると思います。

システム思考はこのブログも参考にしてください→ LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会 - tuneの日記

型は表面的に守られているけど、なぜやるのかの目的を腹落ちしないまま続けていた感じです。

それも含めてプロダクトオーナーが決めるものですが、やりやすいものばかり手掛けていると「へろへろバックログ」になってしまいます→ Agile Product Management - Speaker Deck

開発期間をストーリーポイントという単位に換算していた、大きくても分割しなかったというのがそもそもの問題です。

正しくは"stg-natsuka"という検証環境ですが、名前の由来は間違い無いかと。創業者によるQAとかではないです。

なかなか定着しなくて・・・→ アジャイル開発に使う文房具の使い方・選び方 - tuneの日記

大変です。これは私が入社してからの半年ではなく、入社前から1年ぐらい時間をかけてやったことです。やり切ってくれたメンバーには感謝しかありません。

対象が小さい方がテストはやりやすい。ただしマイクロサービスは相互の依存があるからそこを含めたテストは難しいというお気持ちです。

ビジネスロジックを整理するには型ありが向いているのかなと最近感じています。

開発メンバーが愚直に書いてくれました m(_ _ )m

マイクロサービス化の準備は私の入社前から1年ほどやっていて、現在もテスト展開中の状況です。

QAチームはあるに越したことはないけど、ビジネスロジックが不明瞭という一番重要な問題に対してQAチームを作ることはその直接的な解決になっていないということです。

ユーザー観点のテスト項目出しなので他社のQAエンジニア/テストエンジニアが作るテスト項目よりもずっと洗い粒度です。作る工数はかかりますが、プロダクト全体視点で仕様の漏れがないかを考えるメリットがまさっている状態です。

ある程度溜まったら整理して次の段階にいくんだと思います。今はテスト項目を洗い出すのも辛い状態なので観点の集積から始めたというお話です。

ドメイン知識を蓄積する→仕様を押さえたい→仕様の前に観点がよくわかってない の状態でした。ドメイン知識を蓄積するための前段階ぐらいです m(_ _ )m

一緒い働いているメンバーがイケていることは否定しませんが、「きれいなウォーターフォール」をやっているときと同じメンバーなので人の問題ではないと思っています。変わっていくことに不安を感じるメンバーがいるのはどの環境でも起きうるので時間をかけて少しずつ変えていきます。

信頼貯金が無い状態からのスタートなので、少しずつ少しずつ変え続けるしか無いですね。

指摘されて気がつきました。確かにそうですね！

そんなことはないと思います。ただ開発プロセスの末端にいてゲートキーパーをしているのではなく、全体に関与しプロセスで品質を高めるように関与する方が活躍している印象を受けます。

マイクロサービスを導入する話をするとサービスごとにチームを作りがちですが、1チームが複数のサービスにまたがって手を入れることができればドメイン知識が散在する問題は起きないのかなと思っています。

XP祭り2019で「カンバンに求めたもの(LT)」を話してきました

勉強会 アジャイル カンバン

はじめに

XP祭りでLT登壇申し込みをしていたので、会社で改善を続けているカンバンについて話してきました。

xpjug.connpass.com

Twitterでいただいたコメント

物理カンバンをカスタマイズして磨いていこう

ツールから入るとツールの使いこなしに頭がもっていかれるので物理から始めるのオススメです。

物理カンバンファンの声

私も物理カンバン派です。 とはいえそこで思考停止しているともっと良い可能性も潰しているんじゃないかなとも最近思っています。

電子カンバンが求められる背景

リモートよりも「書けない」が真剣に悩むようになったきっかけですね。 リモートだけが原因なら写真にとって共有するというやり方も選べるので。

おすすめの電子カンバンツール

情報ありがとうございます！

その他

スクラムイベントやワークショップの写真は積極的に残しています。こういう時に便利ですよー

トヨタ生産方式

トヨタ トヨタ生産方式 リーン 書籍

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

自分が生まれる前に出版された本ですが、内容はちっとも色あせておらず、アジャイルやリーンに繋がる重要な考え方が余すところなく説明されていました。多くの人がオススメしている有名な本ですがもっと早くに読んでおくべきでした。

トヨタ生産方式の基本思想

「徹底した無駄の排除」とそれを貫く2本の柱がある。

1. ジャスト・イン・タイム

ジャストインタイムとは組み付けに必要な部品が必要な時にその都度、必要な数だけ生産ラインの脇に到着する状態を指す。 自動車の生産は部品数が膨大であり、また生産計画も刻々と変化する。そのため中央に情報を集め全体を管理するようなやり方ではジャストインタイムの実現はできない。

ジャスト・イン・タイムを実現するには、物の運搬順序を逆にして考える。前工程が後工程へ物品を渡すのではなく、後工程から前工程へ必要な物品を引き取りに行く。前工程は引き取られた分だけ生産を行う。こうすれば一番最後の工程の生産計画に紐づいて生産の流れが同期され、ジャストインタイムが実現できるようになる。

2. 自働化

「機械に生産の良し悪しの判断をさせる装置」を付加することで、不良品の生産を止めるようにする。 すると正常時に人を機械のそばに張り付けておく必要がなくなり、異常時のみサポートすればよくなる。1人が複数の機械を見ることができるようになり、少人化が実現できる。

トヨタ生産の目的

「原価の低減」を実現するためである。

生産数や生産効率を目標にしていると、見かけの能率アップで満足してしまうことがある。例えば1日の生産数を上げたり、大型機械を導入して自動で作れるようにすることがこれに当たる。必要以上の生産を行うと倉庫や倉庫番が必要になり、大型機械を導入しても人が張り付いていなければ人件費は変わらない。かえって倉庫の費用、機械購入費、人件費が増え、原価は上がってしまっている。

生産目標数は顧客の購買活動によって決定し、企業が自主的に決めるものではない。そのため増産だけでなく減産にも耐えられるシステムでなければならない。

生産の流れを作る

ジャスト・イン・タイムを実現するための生産指示として「カンバン」を用いるが、利用の前提条件として「生産工程ができるだけ流れるようにする」ことが不可欠である。

そのためにまずは生産を平準化する。仕事の「標準作業」を定義し、生産ロットを小さくしても流れるようにする。 一人の作業者が複数工程を担当できるようにし、多能工を育てる。