tuneの日記

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

レガシー感謝の日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日の生産数を上げたり、大型機械を導入して自動で作れるようにすることがこれに当たる。必要以上の生産を行うと倉庫や倉庫番が必要になり、大型機械を導入しても人が張り付いていなければ人件費は変わらない。かえって倉庫の費用、機械購入費、人件費が増え、原価は上がってしまっている。

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

生産の流れを作る

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

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

LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会

LeSS Study LeSS本読書会 第7回

LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会 - Less Study | Doorkeeper

今回は大崎、オージス総研さんの会議室での開催でした。

いつもと異なり、大規模スクラム本で紹介されていた「システム思考」と「フィーチャーチーム導入マップ」のワークショップをやってみることが目的でした。 「フィーチャーチーム導入マップ」は参加者の実際の事例をベースにしているため参加者限定の非公開でした。

気温とビールの売れ行きについて

気温とアイスはシステム思考を最初にやってみる上でのいい事例だそうです。この日はビール好きが多いのかビールになっていました。

チームをスケールさせる

調整ごとを減らし、教育を充実させ、お金も稼ぐというある意味当たり前の結果に。

ベロシティを上げる その1

クソコードはいつも問題になりますね。

ベロシティを上げる その2

ふりかえりやコーチが関わる時間が入っているのが面白いかと。


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

LeSS Study LeSS本読書会 第6回

LeSS Study LeSS本読書会 第6回

LeSS Study LeSS本読書会 第6回 - Less Study | Doorkeeper

今回は新宿、グロースエクスパートナーズ株式会社 イベントスペース「G's LounGe」での開催でした。

Q: LeSS Hugeでエリアを分ける背景の説明に「チームが集中力を失う」とあるが、エリアを分けないLeSSでも起きうる問題なのでは?

A: 起きうる問題だが、結局誰もがやらなくてはならず問題になりにくいのかも。または プロダクトが小さいうちはエリアも小さく、少しは耐えられるという想定があるのではないか。

Q: LeSS Hugeを導入している会社・組織はある?

A: 海外ではあるようですが、勉強会参加者の知る限り国内ではなさそうです。 日本でLeSSを導入していると公言している会社ですとYahooやGROOVE Xが挙がりましたが、LeSS Hugeに取り組んでいるという話は聞いたことがないとなりました。

Q: マイクロサービスとLeSSの相性はどうなのか?

A: マイクロサービスごとにチームを構成していなければ両者は矛盾していない。

マイクロサービスは設計・アーキテクチャの話、スクラム・LeSSはプロセスの話。 責務をシンプルにしたサービスにすることでサービスを増やしたり・作り直したり簡単にできるようになるのがマイクロサービスのメリット。 スクラム・LeSSは多能工化したチームによって、フロー効率改善が期待できるメリットがある。

Q: コンポーネントとフィーチャーの違いがわかりにくい。予約はどちらか。

ものによりそう。

  • ホテル予約システム→フィーチャーではないか
  • カレンダーの会議予約システム→コンポーネントっぽい

単独で利益があげられたり、顧客価値が訴求できるならば独立したプロダクトであり、フィーチャーになるのではないか。

Q: チームで多能工化を目指すが、現実には専門家思考の人もいる。チームに加える時に考慮している事項はあるか?

特に何もない。尖った能力を持つ人もうまく組み合わせてクロスファンクショナルなチームを構成する。 仕事の配分はチームでやりくりしてもらう。

とはいえ、圧倒的な専門性を持つ人がチームで能力を発揮できないケースもあるので、その場合はチームから外して別の仕事を与えることも考える。

Q: うちのチームは顧客と会いたがらないのですが…

A: 組織が顧客に会わせる目的を「仕様を明確化して文書を作成する人」としか扱っていないのではないか?

または顧客のことを理解する手助けを組織として提供していないのではないか?

Q: 典型的なLeSS Huge組織において、スクラムマスターはどこにいるのか?

A: フィーチャーチームにいる。

書籍の例では教育・コーチングチームがあるが、ここに所属している場合もあるかもしれない。 能力の高いスクラムマスターや、外部コーチがここに入るのかも。

書籍の「典型的なLeSS Huge組織」はガイドであって、「こういう組織にしなければならない」というものではないので、自分の組織・メンバ能力にあったやり方を見つけていけば良い。

Q: 自己管理チームとはなにか?

https://less.works/img/management/xtypes_of_teams.png.pagespeed.ic.3OY-9MF31j.png

A: 上図の左から2番目。

  • マネージャー主導チーム
  • 自己管理チーム←LeSSはここ、スクラムもここ
  • 自己設計チーム←外部に働きかけができて、組織変革ができるチームのこと。
  • 自己統治チーム←アジャイルスクラムの対象外、取締役会とか。

Q: システム思考とはなにか?

A: 因果関係を整理したシステムとして事象を捉え、俯瞰した視点で問題解決にあたる考え方。 ロジックツリーでも問題分析ができるが、個別の問題だけを解決しても実際には要因間に因果関係があるので本当に解決できるとは限らないという考えに立っている。

枝廣 淳子さん、小田 理一郎さんが翻訳・監修で入っている本がおすすめ。

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

「学習する組織」入門――自分・チーム・会社が変わる 持続的成長の技術と実践

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

勉強会時に参考にしたブログ


大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

アジャイル・スクラムとHR・採用を組み合わせた用語の整理

アジャイルHR」とか「スクラム人事」とか、アジャイルソフトウェア開発から離れたアジャイルスクラムを冠する用語をよく聞くようになったので整理のためにまとめてみました。

アジャイルHR / アジャイル人事

ハーバードビジネスレビューでも特集が組まれたことのある用語。日本だけでなく世界でも使われている。


www.nikkei.com

従来の人事管理は任務遂行を重視しがちだが、アジャイルな人事管理は専門知識の育成、コラボレーションと迅速な意思決定に重点を置いている。マネジャーは、コーチングに優れているサーバントリーダーとして位置づけられる。 そのほか、(1)従業員に絶えず学びの場を提供する(2)従業員は絶え間なくフィードバックを受ける(3)成功指数は従業員の満足度と定着率、イノベーションを生み出しているかで決まる――などがアジャイルな人事管理の特徴だ。

「ソフトウェア開発で先行していた組織をアジャイルにする仕組みづくりを人事で取り入れていく動き」と考えて良さそう。

スクラム採用

herp.cloud

株式会社HERPが提唱する概念で日本だけの用語と思われる。 "scrum recruitment"でGoogle検索しても言及しているサイトは見当たらない。

この言葉は、チーム開発の手法としてインターネット系企業で広く取り入れられている、スクラム開発と同様に、共通のゴール(採用目標の達成)のために、全社員が一丸となって採用活動に取り組むことを意図して、弊社がネーミングしたものです。そしてスクラム開発の思想である、経験に基づくアプローチをベースに、現れた課題に柔軟に対応していくことを基本原則とする点も、同様にスクラム採用に欠かせないポイントだと考えています。

medium.com

ソフトウェア開発のスクラムを参考にしたようだが、「スクラムを使って人事・採用を改善する」ではない。

下記3つがスクラム採用のポイントらしい。

  1. 権限移譲
  2. 成果の可視化
  3. 採用担当のPM化

アジャイル開発・スクラムのプラクティスを使ったバックオフィス・採用の改善

アジャイルソフトウェア開発フレームワークスクラムそのもの、またはその中のプラクティスを活用してバックオフィス・採用の改善するアプローチ。ヴァル研究所とガイアックスの事例をよく聞くが、他の会社でも実は取り組んでいるのかもしれない。

www.slideshare.net

speakerdeck.com

qiita.com

speakerdeck.com

seleck.cc