チームと個人の可能性を最大化する - パフォーマンスを落とさない体制構築とセルフマネジメント方法に参加してきた

developer-productivity-engineering.connpass.com

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

会の概要

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

本イベントでは、エンジニア組織の生産性向上支援ツールの開発をしている、FindyTeam+開発チーム 副部室長/EMの浜田さん、フロントエンドリードの熊野さんに、マネジメント目線とプレイヤー目線からみた、開発体制づくりについてお話しをお伺いします。

【マネジメント目線】メンバー増加をしてもパフォーマンスを落とさないために、チーム体制をどのように考えるのか
【プレイヤー目線】無駄な作業を減らすための取り組み実態とFindy Team+を使ったセルフマネジメント方法

開発生産性の向上や組織体制づくりに関心のあるエンジニア、組織運営に携わる方々にとって、貴重な学びの機会となることを目指すイベントです！

会の様子

講演1〜『開発パフォーマンスを最大化するための開発体制』〜

発表のコンテキスト

最初に開発状況の説明として、開発者の人数が2022年からの2年間で、10人→16人に増えたという前提が話としてありました。

デイリースタンドアップの形骸化

人数が増えたことで直接関わっていないメンバーが増え、開発状況の共有がただ行われるだけになってしまったため、デイリースクラムを一部メンバーに限定するようにしてみたということです。

ただし、効果は限定的であり、一部メンバーにとってはむしろ効果が下がるような事象も起きてしまったため、1ヶ月でやめたということです。

職能でチーム分割

そこで、バックエンドとフロントエンドでチーム分割するようにしたということです。

ただし、結局バックエンドとフロントエンドで密な連携が必須になってしまい、チームを分割した意味があまりなくなったので、不採用になったということでした。

機能でチーム分割

続いて機能毎にチーム分割したそうですが、コンフリクトが度々発生してしまい開発が遅くなってしまうことから、結果的に不採用になったということでした。

ドメインでチーム分割

バックエンドに開発作業が集中してしまうため、ドメインでチーム分割をするとチームの負荷が偏ってしまうということで、不採用となったということでした。

コンプリケイテッド・サブシステムチームで分割

複雑性が高い領域があるということで、その複雑性に対応するチームとしてコンプリケイテッド・サブシステムチームを採用したということでした。

ただし、2チームに分割したとしても両チームともドメイン知識が必要になってしまう*1上に、1チームあたりの人数が2チームに分けても多いので、最終的には領域ごとに3チームに分けるようにしたということです。

講演2〜自己改善からチームを動かす！「セルフエンジニアリングマネージャー」のすゝめ〜

開発フローをはやくする

システム開発をするにあたっては、プロセスを段階的に進める必要があり、プロセスを減らすことができない点が難しいという話がありました。

そこでFindyの開発では、以下のような工夫を行っているということでした。

• CIの高速化(修正箇所に応じて自動テストを回す部分を限定するとともにキャッシュを活用)
• PRがアサインされたりすると、自動でSlack通知が来るようにしている
• QA箇所の自動生成
• フィーチャーフラグの活用

何がチームのパフォーマンスを妨害するか？

個人の開発速度は急に成長しないうえに、コードを書く時間とコードを書いたあとの時間で分けて考えるとコードを書いたあとの時間の短縮が重要になってくるという前提で、プルリクエストをとにかく小さくするようにしたということです。

プルリクエストを小さくすることで、誰でもできるレベルまで作業難度を落としたり型による自動チェックが行え、コードがほぼ衝突しないようになったため、ほとんどコードが書けないようなPdMが22件のPRを出してくれるレベルになったということでした。

セルフエンジニアリングマネージャーのすすめ

自分のパフォーマンスをあげるためには、チームのマネジメントをしてチームの苦手を減らすようにする必要があるという話がありました。

そのために、まずは自分で自分のパフォーマンスをマネジメントすることが重要だということで、実際にshootaさんは自分のPR数を測定し、プルリクエスト数が他の日より少ない日でも、MTGが詰まっているにもかかわらずその少ない件数を出せたことをマネージャーに主張したりすることができたということでした。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を常体かつ一問一答形式で記載していきます。

チームを分けた事で、サービス内での境界が曖昧である事が理由で「この機能はそっちのチームで作ると思っていた」みたいなコミュニケーションミスは発生したか？チームを横断するPdMみたいな人か仕組みが必要に感じた

最初に分けたタイミングでは、どっちのチームが作りますか？という意味でコミュニケーションコストが非常に大きかった。

次にチーム分割した後は、そういった問題は発生しなかった。

フロントエンド、バックエンドのエンジニアを同じチームにした際に、コンプリケイテッド・サブシステムチームを作るほどではない一時的な作業量の偏り(暇な人)の解消のために、もし何かしら対策を講じたことはあるか？

基本的には暇な人はいなかった。機能開発以外の改善タスクもあるので、仮に手が空いた人がいれば、その作業をするようにしていた。

独自のslack appはgithub公式のと比べてどの辺に良さがあるのか (どういう運用をしているのか？) もうちょっと深ぼって聞きたい

Slack IDとGitHub IDが紐づけされているようにしている部分が非常によい。

業務上生じた問題について上司からの部下へのフォローの仕方で良い事例があれば知りたい

ポストモーテムを活用し、障害や問題を起こした人に焦点を向けないようにしている。

おそらく今回の発表での「リードタイム」はファーストコミットからマージされる or デプロイされるまでなのかなと思いながら聞いていた。リードタイムの定義は様々かと思うのですが、プロダクトの課題が発見されてからそれがデプロイされるまで、という定義での改善活動はなにかされているか？エンジニア組織内で完結しないプロダクトチームとしてのリードタイム短縮に向けてどのように活動されてるかを知りたい（よくあるのは課題がふわっとしていて着手しても要件定義で時間がかかるだったり、手戻りが発生したりで伸びたりするケースがあるのかなと思っている）

明確に仕組みとしてはない。課題発見からという意味だと、発見しきれていない課題というのもあると思うので、開発チームとしては如何にそういう関係性を速く維持するのか？という意味で大切にしている。具体的には、Storybookを活用するとか。

熊野さんのGitHubコントリビュートの分析の仕組み化づくりや運用はどこにどうやって情報をとって、どのように分析→共有しているか？

完全に宣伝になってしまうが、自社が作っている製品であるTeam+がやっている。

タイトルにある「パフォーマンス」をどのように定義し、計測・分析しているのか知りたい。またチームでパフォーマンスの状態について振り返る機会があればその仕組みや方法が知りたい

これもCMになってしまうが、Team+を使っている。パフォーマンスに対するふりかえりはFour Keysを活用している。

プログラミングをしていないエンジニアの生産性はどのように測るか?

難しいとは思う。Issueをまとめてもらってそこを見てもらうようにしたり、定性的作業の生産性評価も組み合わせしている。

「やっぱりやめます！」を受け入れてくれるチームづくりで意識されていることや、施策として具体的に取り組まれていることはあるか？

採用として、前向きかどうかといったValue Matchを重視している。

また、無策で臨むのではなく事前に根回ししたり実施のロジックを説明しておくことで、もしだめだとしても受け入れられやすくなると感じている。

会全体を通した感想

最初の浜田さんの講演に関しては、アンチパターンも踏んでいるとはいえ、チーム体制を短いスパンでどんどん変化させていくスピード感がさすがだなあと思って見ていました。

shootaさんの講演に関しては、自分のパフォーマンスを上げるためにチームのパフォーマンスを上げよう、チームの苦手を取り除こうという姿勢がすごく素敵だなあと感じました。

*1:システムがX as Serviceになっていない

デブサミベストスピーカー再演！Launchable Show #1に参加してきた

launchableinc.connpass.com

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

会の概要

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

シリコンバレーのスタートアップ、Launchable。
今回は日本から活躍するエンジニアたちのお話を デブサミ2024ベストスピーカーに入賞したセッションを含む2本をお届けします！

会の様子

講演1〜非同期開発体制を支えるドキュメント文化〜

最初にKonboiさんから話がありました。

なぜドキュメントを大切にしているのか？

まず、組織的な話として、日本とアメリカで活動しているため時差の問題があるという話が挙がっていました。
また、ドキュメントにすると生成AI系のツールに頼ることができたりして、苦手意識がある英語に対するサポートが手厚い点も理由の一つだということです。

また、ドキュメント自体のメリットとして、

• (メンテナンスは必要ではあるが)一度書いてしまいさえすれば半永久的に使える
• 書くプロセスを通してより深く考えられることができる
• フィードバックが深く平等にできる

というのもドキュメントを大切にしている理由だという話がありました。

どんなドキュメントを運用しているのか？

最初にProject Proposalが挙げられていました。
Project Proposalは、新しい機能を提案するときに作るもので、誰がいつ提案して誰が担当していつ終わったのか？というのが記載されているそうです。職種に関係なく書くものであり、MTG途中で議論が始まって論点が不明瞭になってきたタイミングで書かれることが多いそうです。
本文は、

• なぜプロジェクトをやるのか(エンジニア以外が読めるものを想定)
• 先行事例(関連資料や類似プロジェクトなど)
• 専門的な言葉を使って開発チーム向けな解像度高い説明
• 具体的にどのように進めるのかの詳細

で構成されているということでした。

次にDACIが挙げられていました。
こちらは、比較的重要な意思決定をする際に書くドキュメントだそうで、意思決定する人も決まっているような状況で書くということです。(ただし意思決定者以外もコメントするのは自由)
項目としては、

• 影響度
• 誰が進めるのか
• 承認者
• 作業者
• 承認者ではない関係者
• 関連データ
• 進める背景
• 代替案
• 実行するためのTODO

が書かれているそうです。

次にPostmortemが挙げられていました。
こちらは障害が起こった際に書くようなドキュメントで、いつインシデントが起きてどういう対応をしていつ対応完了したのか？というのを記載するそうです。
また、インシデント対応完了後には、犯人探しにならないように注意しつつ、再発防止策や対応にあたってよかったことなども記載するそうです。

最後にCS Investigation Logが挙げられていました。
こちらはCSに対して情報を共有する目的+ナレッジシェアの目的で情報を記載しているそうです。

どう運用しているのか？

Launchableでは、オンボーディングでもドキュメントを書いたり、Rocket Fuel Day*1でハードルが低いドキュメントを書く機会が多かったりと、普段からドキュメントに慣れ親しめるような工夫をしているということでした。

また、ドキュメントを置く場所は部門ごとにConfluenceのスペースを分け、古いドキュメントはアーカイブに移動するなどといった取り組みをされているそうです。

ドキュメントはドキュメントごとにフォーマットが決まっているので、書く人も書きやすく読む人も読みやすいということです。
これに加えてFBに関しても30%/60%/90%*2でFBすることを型として定義し、コメントの中でも意見と提案と委任をはっきり分けることで対応が必須のコメントなのかできれば対応したほうが良いコメントなのかがはっきり分かるようにしているそうです。

講演2〜Flight of a Decade:10年間の旅路と再会〜

speakerdeck.com

続いてYoshioriさんから、2014年にベストスピーカー章を取った際の続きに関する発表がありました。

何を決断したのかではなく何を考えて決断したのか

Yoshioriさんは、何を決断したのではなく何を考えたことが重要だと考えているという話がありました。

例えば2016年当時に色々と大変な状況で人事部長を引き受けた際、大変な状況で人事部長をしたという決断よりも、岩田さんの「よくなるチャンスがあるのに当事者にならないのはもったいない」*3という言葉に感銘を受けて決断したというのが重要だと考えているそうです。

発表の前提

ジュニアエンジニアやシニアエンジニア、スタッフエンジニアといった用語やグレードはGoogleのラダーをイメージして話をしているということでした。

視座/視野/視点

「経営視点が欲しい」「技術だけではなくサービス視点を」...といった視座/視野/視点*4といった話が自分のなかで附に落ちたそうです。

視座が違う経営層と現場では同じ方向を見ても見えるものがぜんぜん違うのが至極当然なので、フィードバックをするときに「もっと長期的視点をもて」「サービスの価値を考えろ」といったアドバイスをするのではなく、まずは見えている姿を説明することが重要だということです。

仕事の振られ方

まず、実装レベルで振られるのか、課題から振られるのか？がジュニアエンジニアとシニアエンジニアとの違いが挙げられるということでした。

一方で、スタッフエンジニアやプリンシパルエンジニアに関しては、グレードが上がってくると他の人が解決できなかった問題が上がってくるので、ジュニアエンジニアやシニアエンジニアと異なり正解がないため、仕事の進め方や意思決定をするポイントがはっきり変わってくるということです。

そのため、「前言っていたことと違う」と「情報増えたんだからそりゃあ違うでしょ。前のやり方に固執されても...」のようなギャップが注意しないと出てくるそうで、情報が増えたスタッフエンジニアやプリンシパルエンジニアは、次やること以上に「もうやらないと決めたこと」を言わないといけないと感じているそうです。
なお、決定力を減らすためにジョブスやオバマの真似をしてYoshioriさんもTシャツや美容室などの決定をしないようにしたそうですが、特に何も効果はなかったそうです笑(ただし日常業務の決定が決定疲れになっているんだろうなというのは分かった)

自身の影響力

ジュニアエンジニアは自分と自分の周り、シニアエンジニアはジュニアエンジニアより広い範囲(シニアエンジニアの周り+ジュニアエンジニアへの影響)の影響が求められるようになるということでした。

一方でシニアエンジニア以降になると、下方向ではなく上方向への影響力が追加されるということでした。(プリンシパルエンジニアになると全社的な影響が求められる)

例えばハッカソン開催の事例であれば、最初は影響範囲を全社に持って、その後に影響力の上方向(CTOへの説明)/下方向(周りの参加者への説明)を意識するといったことが事例として挙げられるそうです。

決断とチャレンジ

わざわざ時間を割いてこのような発表を聞いたりしている人は相対的に他の人よりも仕事が上手な可能性が高いものの、仕事が上手いだけに失敗しない仕事を選んではいないかが気になっているという話がありました。

Yoshioriさんは、GoogleがRailsのアップグレード話(バージョンごとにアップグレードするのではなくメインブランチの最新コミットを持ってくるローリングアップデートをしている話)を聞いた時、挑戦的な仕事の重要性を実感したそうです。

そうした経験があった後は、挑戦機会を探すとともに、仕事をふるときも挑戦的な仕事を挑戦的な仕事であることをはっきり話したうえで相手に渡すことを意識して仕事をするようになったということでした。

ここまでのまとめ

話したことは特別なことではなくどの会社にも書いてあるようなことですが、実際に経験したことで言える話をしたということでした。

物語の主人公で居続ける

時間の都合上、途中で話が物理的に(Google Meetが切れて)終わってしまいました...笑

会全体を通した感想

ドキュメント運用に関しては取り組みをかなり具体的に話してもらえた上に、文化や仕組みが洗練されている様子が伺えて学びになる点が多かったです。

Yoshioriさんの話は、ソフトスキル的な要素がありながらも、Yoshioriさんが実際にやってきた経験とリンクさせてYoshioriさんから出てくる言葉で話をしてくれていたので、よく聞く言葉に対する解釈の視点が増えて、こちらも非常に学びになりました。

*1:月一度のリフレッシュDay

*2:コンセプトレベル、課題解決の手段レベル、文言調整

*3:内容をメモしきれなかったので原文とは少しずれています

*4:視座は高低差で評価されるが価値とは無関係。視点は広い狭いで評価され、時間軸と空間軸で分かれるため混乱しやすい。視点は鋭いか鈍いかで評価される

スクラムフェス金沢のプロポーザルを眺めたり、書いてみたりする会に参加してきた

distributed-agile-team.connpass.com

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

今日はタイトルの通りスクフェス金沢のプロポーザルを書いたり見ていく会だったので、見たプロポーザルと

活用して育むコミュニティ〜5,000回コミュニティに参加して得られたもの〜

confengine.com

• 「コミュニティに知的努力習慣を浸透させる」は特に気になる
• 推し活が気になる
  • (コメントへの本人からの返信) ただし既にスクフェス福岡で話してしまった
• コミュニティの話ってコミュニティだけじゃなく仕事にもとても影響出ると思っていて、そういう展開が出来そうかどうかも気になる
  • (コメントへの本人からの返信) このあたりはテーマ的にあまり話せないと思われる
• コミュニティー参加から、どうやって知識を発達させていっているのかが気になります
  • (コメントへの本人からの返信) ここは話せる
• コミュニティを育てるが、最初からテーマですが聞き手によってはコミュニティが育つと何が良いかが、ざっとあっても良いかと思った
  • (コメントへの他参加者からの返信) 何が良いか？だと、共感度合いがやや弱いので、コミュニティを発展させる際にありがちな課題をした方が共感できるかなと思った

頼られるのが大好きな皆さんへ　- 支援相手との距離の測り方、突き放し方 -

confengine.com

• 人に助けてもらうことが多く、うまく頼る方法が知りたいので、頼られるのが大好きな人の視点が知りたい
• プロポーザルを見て、スゴイ盛り上がっているので、皆興味はある話だと思うので、特定のポイントで整合したら、聴いててとても面白そうだと思った
• プロポーザルをかなり具体的に書いてもらえているので議論が色々できている
• 「よく喋る壁」という表現初めて見た。「よく響く壁」というイメージかな？
• 頼られるのが大好きな皆さんに聞いてほしいプロポーザルなのかなあというのは気になりました。Target Audienceにある「誰かの支えになりたいけど、その距離感がうまくつかめない人」ともずれているような
• 距離感が課題なのかはさておき、距離感を遠ざける方向の話だけなんですかねー距離感を近づける方向もあるのかな、とは思いました
• 距離を測る方法、には触れられていない
• 1聞かれたときに4,5答えたことははたして問題なのか？とは思った。プロポーザルの中だと、1聞かれたときに1答えるというのが良い感じはあるが、関係性が続くのは5知りたかったのに1しか答えてもらえなかったら5回に分けて1を聞いたほうがよいみたいなのはありそう
• 「１聞かれただけなのに、ついつい４，５くらい答えちゃった」はよくある気がする。距離が遠ざかっていくのを感じることあるけど、その距離って測定できないからわからないよなあ..自分が感じてるだけの距離だから。相手がどう感じてるかは聞いてみないとわからないし
• 1を知るには2とか3がどれくらいかがわからないと測れない？
• 4、5含めて「1です」みたいに思わせてしまったら悪い方にはたらきそう
• 5のうち2は代替手段があったり必ずしもその方法である必要はない中、5答えてしまうとかはよくなさそう
• 伝えすぎのデメリットはあるが、距離感とは違う気もする
• OSTでこのテーマを出したら色々な視点で話が出てめちゃくちゃ盛り上がりそう
• ジャストアイデアだが、最初にこのプロポーザルを10分くらい話してもらって、そのあと集まった人でOSTをするとめちゃくちゃ面白いのではないか？と思った

やめるという決断がもたらした変化

confengine.com

• 金沢のスタッフ運営MTGのときにkeynote的な感じで話してほしい
• 「私自身は今回「やめる」という決断をしてみて、「続ける」こととは違う学びがたくさんありました。」にある学びをぜひプロポーザルに書いてほしい
• 出し惜しみしないで何を学んだか書いてほしい
• むっちゃ気になる。Kiroさんのプロダクトを諦める話とかともつながる何かを見つけられると良いなーと思っている。やめる、あきらめるを前向きにとらえるメンタリティを身に付けたい
• コミュニティー内で、やめようと最初に発信した人の思いとか聞いてみたい
• (念の為の確認で)今回は現地登壇オンリーとしているのですが、現地で発表してくれるかが気になっています
• やめたことで無理をしなくなって、できるようになったことがあると思うからそれを聞いてみたい

スタートアップにおける組織設計とスクラムの長期戦略

confengine.com

• とても気になる内容！
• outlineには問いの回答について何も書かれていないので、一例で良いので書いてあると嬉しいです
• Linksの内容はプロポーザルに対してどう絡んでいるのか？というのが示されていると非常にありがたい
• 今あるトピックに関して、1個あたり課題と回答を喋るとすると、1個あたり話せるのは5分位になる。そう考えると、量が多すぎる気はする
• 問いが全部ハードなので話の中で重視して話したい所があればそれもわかるとうれしい。軽重つけてもらった方がいいかも(ハードなので)
• どれも1日話せそうな内容なので、トピック絞った方が面白いかもと個人的には思いました笑
• 書籍化できそうな内容だった
• 「こういう観点を話す」と話の領域は示されてるけれど、「その観点にこういう意見を持っている」という話の方向も示されていると、どんな話なのか安心感を持ってlikeしたり採択できそうだな、と読んでます
• 極端な話ではあるが、すべての項目に関して「要はXXとXXのバランスです」みたいな話になってしまうのは避けてほしいので、そういうプレゼンテーションではないですよ、というのをプロポーザルの中で示してもらえるとありがたい(話す内容をもう少し書いてもらえるとありがたい)
• 発表に繋がっている考えや理論、想いをプレゼンで知りたい
• 「スクラムとマネジメントの関係性がクリアになる」に関して、個人的にはこれが learning outcomeなので、聞いてみたいです。いつもよくわからない部分なので
• 「一緒に考えましょう！」とあるのだが、問いかけだけされて終わったりすると一緒に考える感じはないので、どういう感じで一緒に考えることを想定しているのか書いてもらえるとありがたい。トピックごとに７席にわかれて40分のOST？？とか？

ゾンビスクラム先生が語る過ちと教訓！俺みたいになるな！

confengine.com

• 何が話されるのか明確に書かれているので助かります
• 「抵抗勢力」という記載はチームメンバーの事だと思いますが、チームメンバーが、こう書かれてて気にしないかは気になりました。チームでOKであれば全然大丈夫です
• ゾンビはヘッドショットじゃないと...心臓貫いてもだめでは？というどうでもいいことが気になってしまった
• 身につまされそうな話だけど聞いてみたい...
• とはいえ、以前の経験が生きてた部分も無いのかはちょっと気になりました
• 話を聞いてみないとわからないが、試してみることが悪いというよりは試してみるタイムスパンが長すぎることが問題だったという可能性はありそうだと思った
• 「現状を打破したい思いはあるが、チームへの適切なアプローチが分からず悩んでいる方」というTarget Audienceになっていますが、もう少し範囲としては狭くてゾンビスクラムマスターとして振る舞っているかが不安な人くらいなのかな？
• 押し付けたことは具体的に書いてるけど、自分の振る舞いを変えてからチームで取り組んだ変化への取り組みの具体が知りたい
• ここでいうスクラムマスターって、チームの外の人なんだなーって感じの印象を受けてしまった
• 理想が高いだけでゾンビだとチーム側は思ってなかった可能性も
• 開発者の具体的な感想とか資料に書けると、良さが増しそう
• (余談) 2000年代〜2010年代におけるソフトウェア開発で顧客にリーチして現実的なアウトカムを得られる現実的な期間の中央値が1-2週間であり、それがスプリント期間なので、それ以外の活動に関してはスプリント期間を無視したほうが良いと思っているため、チームを立て直していくコンテキストにおいてタイムボックスはぜんぜん違うので、スプリント期間ごとに試すみたいな話だともったいないなあと思う

全体を通した感想

見たプロポーザル自体はそんなに多くなかったのですが、一個辺りのプロポーザルに対してめちゃくちゃ議論が盛り上がって、2時間以上話をして、これぞわいわい会というイベントでした。

プロポーザルわいわい会もそうですが、分散アジャイルチームに参加すること自体も久しぶりだったので、とても楽しかったです。

オブジェクト指向のこころを読む会 Vol.13に参加してきた

yr-camp.connpass.com

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

会の概要

タイトルの通りオブジェクト指向のこころを読んでいくのに加えて、エアコンのモデリング品評会を行う会です。

今日はエアコンのモデリング

会の様子

モデリング品評会

引き続きエアコンのモデリングを行っていきました。以下、参加者それぞれのモデルと話したことを貼っていきます。

モデルその1

• コンテキスト境界を意識して書いてみた
• Facadeが有効に使えているのかどうかは、XXユニットの詳細次第によりそう

モデルその2

• AirConditionerFacadeとModeは図では表されていないものの依存関係に
• 一旦概念モデルから書いた方がいいかもしれない
• パターンを使おう！から入ってしまったかもしれない。実装から入ってしまうとControllerとかConfigといった手段に依存したモデリングができてしまい、目的が手段に依存してしまう

モデルその3

• マスタ側のエアコンと部屋のエアコンはリンクしていないので、マスタ側のエアコンがあるのがおかしいかもしれない
• 室外機とエアコンが切り分けられているのが違和感ある。室内をコンテキスト境界として定義してしまうと室外機がコンテキストの外に出てしまうため、部屋の壁紙も適切なコンテキスト境界としてはいえなさそう
• 書きながら前提のチェックをして、また書いてその後に前提に戻るというサイクルを繰り返している

モデルその4

• 実装とモデリングを行き来して作った
• 名前に関して、HeatよりもHeatCarrierとかの方がよさそう
• すっきりと整理されているように見える

会全体を通した感想

モデリングの感想戦をしていたら2時間弱経過してしまいましたが、前回よりもそれぞれのモデルに対してフィードバックをしたりどういうプロセスで書くといいのか踏み込んで考える時間が長くて、楽しかったです。

ただ、肝心の読書会が全然進まないので、次回以降は隔週でモデリングをしてみようという話になりました笑

大人のソフトウェアテスト雑談会 #208【素直さ】に参加してきた

ost-zatu.connpass.com

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

品質保証という言葉の違和感

品質保証というと、OKかNGかを判定するような印象がどうしてもあるという話が出ていました。
そのため、QAが品質保証をするというのは何か違和感があるということです。

ロール名

テスターというロール名で呼ばれるのが嫌な人も多いのであまりテスターと言わないようにしているという話がありました。また、同じような話が、プログラマーとシステムエンジニアみたいな話はあるよね、という意見も出ていました。

ただ、ロール名が悪いというよりはHRTの原則を守れない人が嫌だという話な気もしていて、テスターという言葉が悪いような気はしないという話も出ていました。

なお、miwaさんは自らのことをテスターと言っているので、おおひらさんはテスターという言葉で自分を名乗ることにおこがましさを感じるそうで、「ただのテスター」と名乗っているということでした。

Dirty Tester

note.com

Dirty Testerという言葉に込めた想いの話から、同じような想いで名乗るときにどう名乗るといいのかという話が出て、Beautiful TesterやClean Tester、シャイニングテスターといったアイデアが出ていました。

なお、シャイニングテスターはハッピーパスしか見えなさそうなのでという理由で却下されていました笑

trunkベース開発

開発者体験の向上にtrunkベース開発が良いのは分かるのだけれど、ビジネス的には良いのだろうか？という話も出ていました。開発者体験がビジネスの話と区別できるというのが良いのではないかという話や、feature Toggleを一緒に使うことができればビジネスサイドが開発者の手を借りずしてリリースするかの判断ができるのがよいのではないか？という話や、CS対応や営業の資料反映とかプロダクトの内部資料の同期とかではないか？という話が出ていました。

また、自動テストを作ってからじゃないとtrunkベース開発ができないというよりは、trunkベース開発をやるから自動テストが必須になるという方が近いのではないかという主張も出ていました。

全体を通した感想

今日は参加者の方が素晴らしいおつまみ？を持ってきてくれたおかげで、自分が記憶している限りテストの話がされている率がもっとも高い会でした。

あと、Dirty Testerはかっこいいなあと思って聞いていました。

「合宿をしなさい！！ 」アジャイルな合宿のすすめに参加してきた

agile-studio.connpass.com

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

会の概要

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

「合宿をしなさい。形式的な会議で決めることはできない。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。

そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこからはじめて、一つの共通理解が生み出される。この過程をみんなで踏みなさい」これは『アジャイル開発とスクラム』に掲載されている野中郁次郎氏の発言（一部抜粋）です。

まさにこの言葉に合宿をやる意義が凝縮されていると思います。

とはいえ、準備などのことを考えると合宿をやるのに二の足を踏んでしまう方もいらっしゃるのではないでしょうか。今回のウェビナーではそういった方の背中を少しでも押せるように、合宿経験者がそれぞれの事例をお話しします。

会の様子

チームに協働の意識を芽吹かせる合宿のススメ

最初に小泉さんの講演を聴いていきました。

小泉さんは2023年7月から2024年3月に至るまで合計4回合宿をしているそうで、合宿を行うにあたっては、最初に計画&準備をしているということでした。

計画&準備はメンバーからの疑念噴出などがでてくるタイミングということもあって一番大変ということで、予定日だけ仮決めしてしまい、少人数であればAirbnbで家も借りてしまうのがよいと思っているというお話がありました。
こうすることで、なしくずし的に合宿をやることが決まっていくので、おすすめだということです。

合宿当日は最初はタイムライン作成などでinputから入り、1日目の飲み会で関係性向上のためのワークショップをするところが一つの山になるということです。ワークショップに関してはドラッカー風エクササイズを活用して時間制限などがない状態でリラックスして自己開示をするのが重要だということでした。
ドラッカー風エクササイズに関しては、場が温まってきたタイミングではB面を実施するのもおすすめだということでした。
他にも、ジョハリの窓からこんにちはゲームをするといったワークショップもおすすめだそうです。
どんなワークショップをやるにしても、緊張感が多少あるような自己開示をすることが大切で、何をやるかよりもなぜやるか？を大切にすることが重要だということでした。
こうしてワークショップを実施して関係性を作った後は、ラディカルビジョンステートメントなどを活用するなどしてビジョンを設定したりするということです。

最後に、合宿後は、満足度調査をすると評価のハックができてしまうため、仕事につなげるまでが合宿であることを最後に共有することが重要だということでした。

株式会社エヌ・ティ・ティピー・シーコミュニケーションズ様と2回合宿したお話

続いて渡辺さんから、オンラインでずっと仕事をしてきた中、ようやくコロナが明けてオフラインで会えるタイミングでクライアントと実施した合宿に関して話がありました。

最初の合宿では、

• KPTを使用したふりかえり(緊急度と重要度でマッピング)
• Thanks Cardを実施し、宝物としてとっておく
• ドラッカー風エクササイズをチームの価値に昇華する

を実施し、2回目の合宿では、あだ名で呼び合うという工夫をしたうえで、

• 感情曲線を活用したふりかえり
• 未来日記を作成し皆が見える場所に貼る
• お困りごと相談会+懇親会

を実施したということでした。

2回の合宿を通して、リモートでは気づかない気づきがあったり、相手の理解が深まったり、チームで笑いが増えたというお話がありました。

合宿はいいぞ

続いて上坂さんから、チーム立ち上げのタイミングでキックオフ合宿をしたエピソードに関して話がありました。

色々な取り組みをしたためすべてを今日のイベントで紹介することは難しかったということでしたが、以下に実施したコンテンツを記載していきます。

互いを知る(1回目の合宿)

POから直接「こういうサービスを作りたい」という話を聞いたり、偏愛マップで自己紹介をして懇親会を実施したということです。

チームビルディング(1回目の合宿)

なぜここを各メンバーから洗い出し上でチームメンバー決めを実施したということでした。

お別れ会(1回目の合宿)

ジブリの森美術館に行って、雑談をしたりしながら素晴らしい合宿をふりかえりしたそうです。

2回目の合宿でやったこと

1回目の合宿が成功したこともあり、2回目の合宿も実施したということです。

ドラッカー風エクササイズを実施したり、バリューズカードを実施して、チームの価値観とそれぞれの人生で大切にしたいことを確認したりして、最後は深大寺を巡ったということでした。

なぜ研修を合宿型でやるのか？

最後に木下さんから、合宿型の認定スクラムマスター研修を反転授業の形式で実施した話を聴いていきました。

研修所までバスで合宿施設(ルポの森)へ移動した後、4人×4チームを組んで研修を行ったそうです。
研修の中では、社内見学をした後に紙飛行機ワークショップを実施したりしたということでした。

研修の後は飲み明かせるスペースを用意して懇親会を行い、研修の最後には、「スクラムとはなにか？」を各チームでOutputしてもらうようにしていたそうです。

こうした研修は、反転授業活用して設計したそうですが、同じ経験をしてもぜんぜん違う見方をしたりする人や経験から考えると突飛なことをやってしまうような人が出てくることが大切だと考えているそうで、コルブの学習モデルを回す中で個々人がぜんぜん違うことをしてもらえると嬉しいという話がありました。

Q&A

発表の後はQ&Aがありました。以下、質問の内容と回答を常体かつ一問一答形式で記載していきます。

泊まりで合宿する場合、平日に開催するのか？土日に開催するのか？勤怠はどうしているのか？

どちらもある。土日開催なら休日出勤扱いにしている。合宿をやると決めて会社と相談したらうまくいった。

合宿を嫌がるメンバーはいないのか？

• 合宿が嫌という人はあまりいないと思っていて、家庭事情で自分だけ参加したくないのが嫌という人はいると思っている
• 過去には経験がない。もしいたら、「何をしたいのか？」と聞かないようにする
• 過去に経験がない。もしいたら、嫌な理由を直接聞いてそこに対処すると思う

合宿は狙って効果を出しに行っているのか？狙わずに効果が出ているのか？

• 実際は狙っている。食べたり飲んだりしてリラックスしながら関係性を深めるのは鉄板だと思っている
• ご当地のお土産を持っていって雑談をしたり、美味しいご飯を食べにいったりしている
• 狙わずともお酒を持って話をするだけでも全然違うと思う

合宿人数の上限はあるのか？

• 人数が多い場合は人をグループ分けしていた。15人なら3チームに分けるなど

合宿でやらかしたエピソードはあるか？

• PO忙しい問題により、POがずっといてくれなかった(懇親会だけ死守していた)
• 付箋を壁に貼ったりして色々書いた結果壁が汚れたり、道具が使えなかったりした
• タイムキープが難しかった。ワーキングアグリーメントを作るときは特に苦労した

会全体を通した感想

自分は、はじめてオンサイトでイベントに参加したときも、合宿に初めて行ったときも、オンラインとはまるで違う感覚をうけたので、お三方のどの話に関しても共感がありました。

チームで合宿したことはまだないので、今日の発表を聞いてぜひやってみたいと思いました！

スクラムフェス金沢の打ち合わせ第12回目をしてきた

今日もスクフェス金沢の打ち合わせをしていったので、話した内容を書いていきます。

プロポーザルを引き続き募集しているので、ブログをみてくれている皆さんはぜひ投稿してください！

www.scrumfestkanazawa.org

confengine.com

スクラムフェス金沢のアイコン決め

アイコンに関しては以前からBuriKaigiなどのアイコンを作ってくれている方にデザインをお願いしていたのですが、最終的には以下の4アイコンに選別され、最終的にB1アイコンに決まりました！

スポンサー募集

追加でスポンサー募集を募ったところ、本当にありがたいことに9社の方がスポンサーに手を挙げてくださり、各社さんのロゴ受領状況などに関して確認を行いました。

本当にありがたいことに想定以上に集まったので、スポンサー募集はこれにてクローズさせてもらうことにしました。
万が一どうしてもスポンサーがしたくて現在準備中だったという方がいらっしゃれば、運営のメンバーに連絡いただければと思います。

基調講演の確認

keynoteを岩間さんにお願いできたということもあり、どんな内容で話してもらいたいかを確認していきました。

これまでの北國銀行さんの取り組みに加え、なぜアジャイルやスクラムに取り組んでいるのか？能登半島地震をうけてデジタルを活用して何かしら支援を行ったりしているのか？といった内容を現時点では考えているという話がありました。

チケット発売

当初は5/1にチケット発売の予定でしたが、GW休みを取って家族旅行などに出かけている方も多くいらっしゃるであろうことを考慮して、5/7 12:00-に決定しました。

請求書発行の準備

スポンサーへの請求書発行に向けた準備として、各スポンサーそれぞれの情報を整理しました。

Eventbriteの準備

Eventbriteに今日参加していたメンバーに対してはEventbriteの閲覧権限をつけてもらいました。

全体を通した感想

バックログを整理したおかげで話さないといけないことの優先順位がクリアになり、すっきりした感じがありました。

スポンサーさんも無事に多数集まって、チケット発売の準備に関しても目処がたったので、いよいよ開催の実感が湧いてくるなあという会でした！