こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

「受託開発だとアジャイル開発は難しい」という話をよく耳にします。顧客との関係性や契約など、たしかに制約は多いかもしれません。しかし制約があること自体は自社開発でも変わりません。

自社開発でアジャイル開発の経験を積んできた及部敬雄様 (株式会社ホロラボ) は、受託開発においてアジャイル開発に取り組んだ結果、成功できたと話します。そして、受託開発でも自社開発でも大事なことは変わらないという感覚を持ったそうです。

そこで今回の AWS Developer Live Show では、「受託開発だとアジャイル開発は難しい」と「受託開発でもアジャイル開発できる」この 2 つの違いについて考えます。実体験をもとに、受託開発でのアジャイル開発を紐解きます。ぜひ一緒に考えましょう。

会の様子

及部さんの講演

受託開発のイメージ

受託開発と聞くと、昔(転職前)の及部さん自身も含めて、ネガティブな話が多い印象を持っているという話が導入としてありました。

受託開発の難しさ

受託開発を実際にやってみて感じた難しさとしては、

チームが長続きしにくい
「私契約する人、あなたつくる人」問題
「私考える人、あなたつくる人」問題

の3つがあるという話でした。

まず、1個目のポイントですが、受託開発は有償稼働率を設けたくなるため、Project Based Teamになりがちだということです。

次に2個目のポイントとして、受託開発をすると「開発」フェーズで入ることになりがちで、いろんなことが決まっていたりと制約が多い中で仕事が始まってしまったということでした。

最後のポイントとして、発注者と受託会社の関係性として、「バックログ提供して」「その通り作ります」というのが繰り返されることで「私考える人、あなたつくる人」なりがちで、一生懸命仕事をするからこそ出てくる厄介な問題なのではないかということでした。

及部さんとしてはこの問題は繋がっているように感じるということで、

受託開発を普段しているためチームが存在しないことで、契約をする「契約者」が出てくる
顧客にではなく内部のチーム(チームビルディングなど)に集中しがちになるため、「私考える人、あなたつくる人」問題が生じる

という流れなのではと思っているということです。

及部さんのチームの取り組み

及部さんたちはチーム転職をしていることもあり、契約するところからチームで取り組むというのを繰り返したそうです。
及部さんたちは見積もりや契約も学習をする対象だと捉えているそうで、契約前の振る舞い方も上手になり、前述した問題を打ち破るように取り組んだということでした。

また、初手にデモをすることで、相手のイメージを詳細にして具体的に話をするようにしていたそうで、空中戦にならずにコミュニケーションを取ることができるということです。

受託開発の罠

経験上、基本的に顧客は何を開発すればいいか分かっていないし完璧な要件定義をすることもできないため、「何を作るのか？」にまで踏み込むことが重要だということでした。

また、新人を学生かのように扱うと学生のような振る舞いをしてしまうのと同じように、顧客が要件をくれる人のように扱うと前述したような振る舞いをしてしまうということで、顧客を問題解決を一緒にするパートナーだと捉えることが重要だと考えているそうです。

そのため、自分たちに仕事をくれた顧客が幸せになって昇進するような仕事の仕方を目指しているということでした。

まとめ

ここまでの話でも出てきたように実際に受託開発を経験して、

チームを案件にアサインするのではなく、案件にチームをアサインするような姿を目指している
受託開発かどうかとかではなく当たり前にやるべきことを当たり前にやることが大切
自分たちも発注者と一緒に未来を考えるようにしている

ということを今考えているそうです。

また、受託開発なのか自社開発なのかどうかはウォーターフォールかアジャイルかと同じように全然関係ないというのも改めて感じたということでした。

Q&A

講演のあとはQ&Aやパネルディスカッションがありました。以下、質問やトピックと回答を一問一答形式で記載していきます。

チーム転職という発想がなかったのでそれをしたのはすごい

いいチームを作っては解散し、というのを繰り返していたプロセスに意味がないと感じたので、社会実験的にチーム転職をしたところ成功した。

発注側とチームになるには？

相手のことを知らないし何も分からないことばかりなので、そこを武器にして話をし始めた。

2つめのチームはどう作ったのか？

社内で固定したチームで仕事をしたいという気持ちを持っている人たちがいたので、そこに及部さんがアジャイルコーチとして入ったりした。

受託開発でチーミングするときに気をつけたほうが良いことは？

一通り体験しないと何もわからないと思っているので、興味を持って取り組むことが大事だと思う。

固定スコープに対してどうアプローチしたのか？

どう考えても準委任じゃないの？みたいな発想でこれまでの慣習にとらわれずやっていた。

今日話した内容は最初から気がついていたのか？

受託開発だからどうというのはないんじゃないか？と元々ある種の仮説を持っていて、あわよくばプロダクトを作ってやれという気持ちで仕事に取り組んでいた。

チームのサイズはどれくらいなのか？

フェーズによるが3-4人くらい。ロールでPM, 開発者みたいな感じで分けるところもあれば、及部さんのチームみたいにあんまり役割が決まってないこともある。

会全体を通した感想

及部さんが主催しているコミュニティでも色々話を聞いたり及部さんのプレゼンテーションをいつも見ていたりしたので、そんなに何か新しい話があったというわけではなかったのですが、いつも通り面白かったです。

受託開発かどうかはあんまり関係ないというのはその通りだと自分も思っているのですが、受託開発をやってみるぞ！と思っていたからこそできた取り組みとかも実はあったりしないのかなあというのはなんとなく考えていました。

2024-10-08

大人のソフトウェアテスト雑談会 #233【供養】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

RSGT×QA
QA×スクラムマスター
一人目〇〇と新卒〇〇
気になるプロポーザル
全体を通した感想

RSGT×QA

QAの方がかなりRSGTにプロポーザルを出しているような気がするという話をしたところ、おおひらさんからQA(というか厳密に言うとテスター)の話をするプロポーザルは全然ないというコメントをいただきました。

QA×スクラムマスター

QAの人がスクラムマスターになりたいと思うのは、エンジニアがスクラムマスターになりたいという想いと同じように尊重できる一方で、品質を上げるためにスクラムマスターになるというのはよくわからないという話が出ていました。

また、QAの人はスクラムマスターのスキルを有しているというのもエンジニアの人はスクラムマスターのスキルを有しているというのと同じくらいの理由付けで、あんまりQAからスクラムマスターへのジョブチェンジする特徴的な理由はなさそうだという話もありました。

一人目〇〇と新卒〇〇

新卒一人目QAというなかなか葛飾らしい「闇」な単語から新卒スクラムマスターをはじめや新卒だからとりあえず作業してみたいな地獄の世界の話をしていきました。

最近はなくなってきたということですが、作業者とか人工思考だと自然とこういう話が出てしまうよねという話がありました。

気になるプロポーザル

色々と気になるプロポーザルを見ていきました。
「色々と」が肝なのであんまり詳細は書かないようにしておきます笑

また、likeをつける基準として、もちろん真面目に考えるのもいいけれど、自分の気持ち補正で(例えば前職の話で今どうなっているか聞きたいから)これ聞きたいみたいな思いでlikeをつけるのも全然いいし、素直に聞きたい話にlikeをつければいいんじゃないか？という話をしていきました。

全体を通した感想

葛飾の方のプロポーザルが少ないのが非常に悲しいのですが、いよいよRSGTが迫ってきたなあという感覚がある葛飾でした。

2024-10-07

アジャイルカフェ@オンライン第60回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を記載していこうと思います。

会の概要
会の様子
会全体を通した感想

会の概要

アジャイルコーチの木下さん家永さん天野さんがアジャイル実践者のお悩みに答えていくイベントです。今日のテーマは、「スクラムマスターと開発者の兼任はありか？」でした。

会の様子

兼任にまつわる説明

scruminc.jp

なしの主張

最初に兼務がだめだと言われている理由に関して話がありました。
以下、その理由を箇条書きで記載していきます。

スクラムマスターと開発者は必要な仕事がまったく違うのでそれぞれの役割に引っ張られてしまう
やることが多くなるため疲弊する
(特にコミュニケーション周りで)いろいろなところに気を払いながら開発者としての仕事をするのは難しい
マイクロマネジメントをこれまでの仕事で基本的にしてきたような場合、Howにまで踏み入ることで以前の振る舞いに戻ってしまうことが起きる

ありの主張

続いて、兼務をしてもよいと思えるような理由の話がありました。
以下、その理由を箇条書きで記載していきます。

チームの人数が少なめである場合
チームが安定してくると、スクラムマスターの仕事がなくなってくるので、そこで開発をはじめたりするのはあり
優先度が低いタスクに関してはスクラムマスターが担当するのもあり
開発者自らが価値を届けるという姿を体現できる可能性がある
完成の定義に関するコミットメントは開発者のロールのほうがイメージが持てるので、スクラムマスター自身が体験してみるのも必要な場合がある(ただし開発に関する意思決定をガンガンしている人がいるのならそれはスクラムマスターではないと思う)
責任を共有するという意味では例えば持ち回り制などをしてみるのはありだと思っている

会全体を通した感想

スクラムマスターと開発者が「する」「させる」の関係性を招きそうになるのが嫌だという話を聞いたり、スクラムマスターが開発者としてガンガン意思決定するのはスクラムごっこの予兆な気がするという話だったりと、特に木下さんが強い想いを持っている部分が垣間見えたのが非常によかったです。

2024-10-06

スクラムフェスニセコで今年も個人スポンサーをします

www.scrumfestsapporo.org

告知が続いて申し訳ないですが、公式ブログにもスポンサーロゴ(??)が出たので、今年もスクラムフェスニセコで個人スポンサーをしてくる宣言をしたいと思います。

昨年の記事
昨年から継続して個人スポンサーをしようと思っている理由
ゴールドスポンサーにした理由
個人スポンサーセッション
個人ブース
来年以降どうしていきたいか

昨年の記事

aki-m.hatenadiary.com

昨年から継続して個人スポンサーをしようと思っている理由

一番の理由は、昨年のスクラムフェスニセコの体験がとても良かったことです。
合宿型のカンファレンスというのは当時初めてだったと思いますが、密にいろいろな人と話ができて、自分がカンファレンスの中で一番好きなギャザリングの要素をたくさん楽しむことができました。
特に、とうまさんやくまごろーさんなどをはじめ、ここで初めて知り合って今もカンファレンスなどでお話する機会に恵まれている縁も多数あり、今年も最高の体験ができるんだろうなということで、そんな体験を他の人にも是非してもらいたいという想いからスポンサーをやらせていただくことにしました。

また、それ以外の理由として、昨年個人スポンサーをした理由から特に変化はないのですが、自分が大好きなアジャイル札幌のコミュニティを応援したいという気持ちが引き続きあったというのもあります。

ゴールドスポンサーにした理由

昨年はシルバースポンサーだったのですが今年はゴールドスポンサーにしました。

元々昨年もゴールドスポンサーを検討していたのですが、枠が昨年は埋まっていたので、今年は早めに申し込んだ結果ゴールデンスポンサーになったという形です。

プラチナスポンサーに関しても検討したのですが、カンファレンスで一番大きなロゴが載ることになるということもあり、それであれば地元に縁がある企業さんに譲ったほうが良いのではないかな？という想いから、ゴールドスポンサーを選択しました。

個人スポンサーセッション

昨年の話でもういいかなという想いもあるので、現時点ではやらない予定です。
スポンサーセッションは参加者全員が聞くことになるため、全員に刺さるような話をするのが難しく、自分がしたい話をただするのであればその時間はギャザリングに充てたいという想いがあるので少なくともスクラムフェスニセコではやりたくないなというのがその理由です。
ただ、もしアジャイル札幌の皆さんから何かしらリクエストがあったり、スクラムフェスニセコに参加する方の複数名からこういうテーマで話を聞きたいというのがありそうなら、検討しようと思います。

個人ブース

これもどう使ったらいいのかさっぱり分からないので使うのはやめておきますw

ただ、せっかくブースがあるなら皆さんが何か交流が捗るような場にしたり、会の趣旨をより実現しやすくするような場にするような使い方ができたらいいなあとは思っています。

来年以降どうしていきたいか

引き続きスポンサーしていきたいなと思っているのですが、個人がスポンサーし続けるというのが良いことなのかやや疑問に思っているところもあるので、思考停止でというのではなく、どういうメリットがカンファレンスにあるか？というのも踏まえて少し検討したいなと思います。(とはいえ現状では金銭的な観点でサポートができるというのがかなり大きいメリットだと思っているので継続できて自分もスポンサーしたいという想いがあるならスポンサーしたほうがいいんだろうなとは思っています)

2024-10-05

RSGT2025にプロポーザルを出した

RSGT2025にプロポーザルを出したので今日はその告知です。

confengine.com

発表概要
プロポーザルを出したきっかけ
チャレンジしたいこと
おわりに

発表概要

1本目

自分が外部アジャイルコーチとして現場に入るとき多く聞く要望の一つに、「チームや組織がどれくらいアジャイルになっているのかを客観的に評価してほしい」があります。(特にアジャイルチームを立ち上げてちょっと時間が経っている現場では多い印象です)
しかし、評価を求めている動機によっては、評価をしても何も成果をあげられなかったり、最悪の場合はアジャイルな組織やチームから後退する可能性もあります。
本セッションでは、評価が有効に活用された歴史や評価が惨事を招いた歴史を探りながら評価の性質を考え、「チームや組織がアジャイルになっているかを客観的に評価してほしい」が失敗しやすい動機を説明します。
最後に、評価の歴史や性質と自身のこれまでの経験を統合し、評価とどのように向き合っていくと良いのかを紹介していく予定です。

2本目

Scrum is a framework used in software developed that is often employed to deal with areas of high uncertainty. Software created using scrum tends to emphasize characteristics such as modifiability and testability. Increasing modifiability and testability requires high cohesion and loose coupling.

However, efforts to excessively reduce the level of coupling often result in systems with low modifiability and testability. A typical example of this is the deterioration of system maintainability due to a misunderstanding of microservices. The level of coupling should be balanced, not reduced.

Thus, the question that arises is: what are the specific perspectives and principles that should be considered in order to balance the level of coupling?

In this session, we will analyze the degree of coupling and combine it from various abstractions and perspectives in order to understand it from a balanced perspective and build systems with high ease of change, which is often required when using scrum.

プロポーザルを出したきっかけ

まずRSGTに出すプロポーザルとしては、今年一年間仕事で実際に取り組んできたテーマを出したいなというのを例年通り考えました。

その上で考えられる候補は幾つかあったのですが、まず最初に一番継続的に関わり続けてきたチームや組織のアセスメントに関するテーマを出そうと考え、1本目のプロポーザルを出すことにしました。

次に、来年以降仕事やコミュニティでグローバルな活躍ができるようになることを目指しているため英語で話がしたいということと、コンテンツの準備にそこまで時間がかからなさそうなことを踏まえて、2本目のプロポーザルを出すことにしました。
※英語で話すといつもやっているようなコンテンツの準備に加えて英語でプレゼンテーションするための準備や資料づくりの準備が必要になるため、少しでもコンテンツの準備は軽い方がまずは良いかと思いました。

チャレンジしたいこと

1本目に関しては、これまでのどのプロポーザルよりも構造や性質、メカニズムといった部分の説明が細かくできることを目指したいと思います。
仕事で何かKPIがあるとかは全然ないのですが、話を聞いた人が自分にアセスメントの相談をしたくなるような発表をしたいです。

2本目に関しては、英語で喋ることがとにかく大きなチャレンジだと思うので、英語でそれなりの人数の前で話すことができて内容が伝わればまずはそれで良いと思っています。

おわりに

かなりプロポーザルを出すのがギリギリになってしまったことに加え、プロポーザルのレベルがどんどん上がってきている印象があるので、正直かなり厳しそうだなあとは思いますが、とりあえず出せたことは結果的によかったのかなと思いました。

2024-10-04

XP祭り2024のスライド

xpjug.connpass.com

スライドをまとめたので公開します。(LTセッションは後日追記します)

また、見つけられていないものもあると思うのでもし記載されていないスライドがあれば教えていただけると嬉しいです。

Extreme Programmingとオブジェクト指向 20年目の答え合わせ
Scrumに出会って人との関わり方を改善していく事に夢中になっていた結果、その知識と実践がエンジニアとしての成長にも繋がったお話。
エンジニアによるユーザーリサーチのススメ　〜価値あるプロダクト開発を目指して〜
QAtoAQパターンの活用事例
開発者体験を向上させるボトムアップな組織改善
銀河英雄伝説に学ぶ、スクラムチームに必要なリーダーシップ
XP祭りでMX実践会！エクストリームに"MX"していくための公開作戦会議セッション
AI時代のアジャイル開発
TDD with 生成AI ライブコーディング
UMLモデリングカフェ実演
変化を乗り越えろ！インドから来たチームワーク体験ワークショップ
"Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス
アニメに学ぶチームの多様性とコンピテンシー
ユーザーストーリー for ビジネス
個人事業主型開発からの脱却
つよつよリーダーが抜けたらどうする？～ナビタイムのAgile支援組織の変遷～
一人目デザイナーに「オンボーディングしながら最速で成果を出してもらう」ためにアジャイル的なアプローチを試みたらすごい良かった
思い起こせば、あれはアジャイルなマインドだった件
MPSVフレームワークによる目標設定ワークショップで目標の解像度が向上した話
スクラムマスターの成果が3倍になる賛同を得る技術
現場にも管理職層にも経営層にも…モブワークを制するものがアジャイル、いや全てを制する！
最新 AI 駆動フロントエンド開発ツールを使って Web アプリ、ネイティブモバイルアプリを開発してみよう
テスト自動化と末長くお付き合いするためのN個のこと
4年間のプロジェクト支援で学んだ組織変革に必要な心と行動
複数プロダクトの技術改善・クラウド移行に向き合うチームのフレキシブルなペア・モブプログラミングの実践
動作する読みやすいE2Eを目指して
XPを始める新人に伝えたい近道の鍵
対話をする前に知っておくべきこと -人格主義を基本とする関係構築-
スクラムマスターを始める前に知っておきたかった10のこと
四半世紀ウォーターフォールでやってきたメンバーが感じた、アジャイルのうさん臭さとその原因
1日1エントリにもがく中で見えてきたXPの「フィードバック」の価値
コードレビューとチームと私 - 2200件以上のコードレビューを通してたどり着いた現在と過去と未来
「プロダクトマネジメントのすきま」を知って、無意味な忙しい作業や膨大なタスク管理からおさらばしよう！
XP2024 っていう国際会議に行ってきたよの記
多様性のあるプロダクトチームで目指した共創の3年間の変化
え、私のテストコードの網羅性低すぎ！？ Property-based Testingのススメ
センタリングプロセス読書会
TDDトレーニング
他人の気持ちがわからないを体験するゲーム
スクラム導入の舞台裏：QAエンジニアがスクラムマスターになるまで
ネガティヴ・ケイパビリティから考えるアジャイルチームの在りよう
エクストリームな「人」を真似てみることのススメと対策
アジャイルの知見の少ないメンバーの多いチームづくりの1年半をふりかえる
開発者兼スクラムマスターとしてチームへ参画した件にまつわるエトセトラ
モブワーク、ぶっちゃけどうなん？〜全部モブでやってみた〜
eXtreame recording
たった一人で始めた音楽制作が気がついたら会社公認の部活動になっていた話〜組織の垣根を超えるコラボレーションを実現するには〜
『Tidy First?』もエクストリームプログラミングのかけら
『アジャイルとは何か？なぜアジャイルなのか？』1年間のアジャイルコーチとの1on1を通してやっとわかったアジャイル
生成AI時代のテスト駆動開発
輪読会でつなぐフルリモート環境のコミュニケーション
「アウトプット100回！YOWフレームワークで実践するふりかえりとその効果」
新卒エンジニアチームが、XP を学びながらプラクティスを導入していく

Extreme Programmingとオブジェクト指向 20年目の答え合わせ

スライドなし

会の概要

会の様子

及部さんの講演

受託開発のイメージ

受託開発の難しさ

及部さんのチームの取り組み

受託開発の罠

まとめ

Q&A

チーム転職という発想がなかったのでそれをしたのはすごい

発注側とチームになるには？

2つめのチームはどう作ったのか？

受託開発でチーミングするときに気をつけたほうが良いことは？

固定スコープに対してどうアプローチしたのか？

今日話した内容は最初から気がついていたのか？

チームのサイズはどれくらいなのか？

会全体を通した感想

RSGT×QA

QA×スクラムマスター

一人目〇〇と新卒〇〇

気になるプロポーザル

全体を通した感想

会の概要

会の様子

兼任にまつわる説明

なしの主張

ありの主張

会全体を通した感想

昨年の記事

昨年から継続して個人スポンサーをしようと思っている理由

ゴールドスポンサーにした理由

個人スポンサーセッション

個人ブース

来年以降どうしていきたいか

発表概要

1本目

2本目

プロポーザルを出したきっかけ

チャレンジしたいこと

おわりに

Extreme Programmingとオブジェクト指向 20年目の答え合わせ

Scrumに出会って人との関わり方を改善していく事に夢中になっていた結果、その知識と実践がエンジニアとしての成長にも繋がったお話。

エンジニアによるユーザーリサーチのススメ 〜価値あるプロダクト開発を目指して〜

QAtoAQパターンの活用事例

開発者体験を向上させるボトムアップな組織改善

銀河英雄伝説に学ぶ、スクラムチームに必要なリーダーシップ

XP祭りでMX実践会！エクストリームに"MX"していくための公開作戦会議セッション

AI時代のアジャイル開発

TDD with 生成AI ライブコーディング

UMLモデリングカフェ実演

変化を乗り越えろ！インドから来たチームワーク体験ワークショップ

"Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス

アニメに学ぶチームの多様性とコンピテンシー

ユーザーストーリー for ビジネス

個人事業主型開発からの脱却

つよつよリーダーが抜けたらどうする？～ナビタイムのAgile支援組織の変遷～

一人目デザイナーに「オンボーディングしながら最速で成果を出してもらう」ためにアジャイル的なアプローチを試みたらすごい良かった

思い起こせば、あれはアジャイルなマインドだった件

MPSVフレームワークによる目標設定ワークショップで 目標の解像度が向上した話

スクラムマスターの成果が3倍になる賛同を得る技術

現場にも管理職層にも経営層にも…モブワークを制するものがアジャイル、いや全てを制する！

最新 AI 駆動フロントエンド開発ツールを使って Web アプリ、ネイティブモバイルアプリを開発してみよう

テスト自動化と末長くお付き合いするためのN個のこと

4年間のプロジェクト支援で学んだ組織変革に必要な心と行動

複数プロダクトの技術改善・クラウド移行に向き合うチームのフレキシブルなペア・モブプログラミングの実践

動作する読みやすいE2Eを目指して

XPを始める新人に伝えたい近道の鍵

対話をする前に知っておくべきこと -人格主義を基本とする関係構築-

スクラムマスターを始める前に知っておきたかった10のこと

四半世紀ウォーターフォールでやってきたメンバーが感じた、アジャイルのうさん臭さとその原因

1日1エントリにもがく中で見えてきたXPの「フィードバック」の価値

コードレビューとチームと私 - 2200件以上のコードレビューを通してたどり着いた現在と過去と未来

「プロダクトマネジメントのすきま」を知って、無意味な忙しい作業や膨大なタスク管理からおさらばしよう！

XP2024 っていう国際会議に行ってきたよの記

多様性のあるプロダクトチームで目指した共創の3年間の変化

え、私のテストコードの網羅性低すぎ！？ Property-based Testingのススメ

センタリングプロセス読書会

TDDトレーニング

他人の気持ちがわからないを体験するゲーム

スクラム導入の舞台裏：QAエンジニアがスクラムマスターになるまで

エンジニアによるユーザーリサーチのススメ　〜価値あるプロダクト開発を目指して〜

UML モデリングカフェ実演

MPSVフレームワークによる目標設定ワークショップで目標の解像度が向上した話

たった一人で始めた音楽制作が気がついたら会社公認の部活動になっていた話〜組織の垣根を超えるコラボレーションを実現するには〜