「モブプログラミング・ベストプラクティス」を読んだ

はじめに

メーカー企業でコーポレート部門でソフトウェアエンジニア兼スクラムマスターとして働いているモンゴルと申します。
チームではペアプロ、モブプロを取り入れて開発しているのですが、モブプロではモブの立ち振舞がわからず難しいと感じることがあるので次の本を読むことでここらへんの疑問が少しでもなくなるのではと感じて読んでみました。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

感想

ペアプロとモブプロは効果が違う

今までペアプロとモブプロは同種だと思っていたが、異なる関係性、異なる取り組み方、そして、結果的にもたらされる効果も異なることがあることがわかりました。
本書では、ペアよりもモブの方が膠着した場合にすぐに解決しやすいということが書いてあって、今まで意識したことはありませんでしたが、業務でモブプロをやっていてもそういう場面あったなと思い出しました。

今までのタイピストの仕事の仕方が間違ってた

今までタイピストとモブが対話しながら進めていましたが、本書ではタイピストはモブが言っていることを理解し、実装することに専念し、疑問がある場合は実装後に相談するということが書かれていました。
実践してみたところ、それまでよりも指示ミスによる小さな手戻りが発生するものの、その手戻りによりメンバーの認識が共有され、自信を持って進められるようになってきました。
この共通認識は設計方針、思想だったりもするので、中長期的に意味がありそうだなとも感じました。

モブの立ち振舞がわかった

今まで、リモートでやっていたこともあり、指示がぶつからないようにナビゲーターを指定してやっていました。
ただ本書ではモブの中で役を特に指定せずに、具体的に支持したり、説明したり、次の工程で必要そうなことを調査、準備しておいたりすると書かれていた。
私達のチームでも実践していきたいなと思いました。

手探りな仕事のモビングのやり方が分かった

詳しくは本書を読んでいただきたいのですが、

• タイムボックス付きの探求
• 強いモビング

が紹介されていました。
私のチームではストーリーポイントが大きい場合（ほとんどが手探りの仕事）にモブで実装していたため、これらのプラクティスを実践してみたいなと思いました。

まとめ

本書ではモブプロに関するコツ、進め方が紹介されているので、モブプロのやり方で困っている方はぜひ読んでみるといいと思います。
現在のつまり解消のヒントが得られると思います。

「ファシリテーション入門」を読んだ

はじめに

メーカー系企業のコーポレート部門でエンジニアとして働いているモンゴルです。
今回は私のチームを支援してくださっているアジャイルコーチから進められた「ファシリテーション入門」を読んだのでその感想を書いていきたいと思います。

ファシリテーション入門＜第２版＞ (日本経済新聞出版)

感想

個人的に心に残ったのは 「ファシリテーションがもたらす三つの効果」と「場をデザインする五つの要素」でした。
この2つについて書いていきます。

ファシリテーションがもたらす三つの効果

本書では以下のように書かれていました。

• 相乗効果を活かし、高い成果を生み出す
• 納得感を高め、やる気を引き出す
• 学習するスピードを高める

私は2つ目の「納得感を高め、やる気を引き出す」の中で説明されていた「行動するかをどうかは、結論の良し悪しだけでは決まりません。いかに結論が腹に落ちるか、プロセスが重要になります。」ということに非常に共感しました。
ステークホルダー含めてプロジェクトに関わるメンバーは様々な考え、知識をもって集まっているため、結果、全員が納得できないまま、声の大きい人、多数決で決まってしまうことも多いと思います。
結論は当たり前のことになるかもしれませんが、全員で考えて、議論して、話し合い、腹落ちに近づける地道な活動は、時間はかかりますが大事だと感じました。

場をデザインする五つの要素

本書では「次の要素を決めて共有する」との記載がありました。

1. 狙い
2. ゴール
3. プロセス
4. ルール
5. メンバー

たまに、狙い、ゴール、プロセスが曖昧であるがために、本来目指している議論にならなかったり、発散してしまうことがあるので、この型を意識してやれるとすごく良くなるだろうなと、感じました。

とはいえ、見えないことを議論するときに、ゴールをどの程度高めに設定するかという加減が難しい場合もあると思っています。（本書では、ストレッチゴールを設定する良いと書かれていました。）
ここらへんの塩梅は経験ですかね。

終わりに

この記事には記載はしませんでしたが、「七つの基本プロセスを使いこなす」「会議を変えれば組織を変えれる」なども非常に良い章でした。
全体通して、会議の型がたくさん紹介されていますので、定期的に見直して進め方の型を学び、実践して定着させていきたいなと感じました。

「デザインリサーチの教科書」を読んだ

はじめに

コーポレート部門でエンジニア兼スクラムマスターをやっているモンゴルです
チームメンバーにおすすめされて「デザインリサーチの教科書」を読んでみました。

結論から言うと、デザインリサーチという言葉自体この本で初めて知ったというほど初心者でしたが、スクラムやアジャイルとも近しいものがたくさん出てきたのでスムーズに理解できました。
また、リサーチという、スクラム、アジャイルでは多くは語られていない領域について、本書では具体的なことも織り交ぜ紹介してあって非常に勉強になりました。

デザインリサーチの教科書

感想

この本を読んで、次のことを理解しました。

• デザインリサーチの流れがリサーチ→分析→デザインであること
• デザインを行う人がデザイナーだけだったところが、ステークホルダー、というかエンドユーザーと共にデザインしていくようになってきているということ
• リサーチツールがいっぱいあること

以下に、気になったこと、思ったことを書いていきたいと思います。

これからのデザインプロジェクトについて

従来はデザイナーが成果物をクライアントに納品して、それを使用してクライアントがカスタマー、ユーザーにサービス、プロダクトを提供するという流れだったことに対し、これからのデザインプロジェクトではデザイナーとクライアントが共創していくという姿は非常に共感しました。

最近DXという言葉が流行っていますが、発注側の能力が低い、というか、「ユーザーの課題を整理し、要件に落とし込み、デザイナーに認識相違なく伝える」というのはよっぽど慣れていない限り不可能になってきていると思います。

デザイナーはプロとしてもっとプロジェクト初期から入り込んで、チームをコーチング、ファシリテーションすることにより、画面のデザインだけでなく、ユーザー体験やユーザー価値といったプロダクトデザイン自体を作るところまで、クライアントと一緒にできると非常にいいなと思いましたし、そうしていこうと思いました。

私のチームでも近しい体制になっているので、デザイナーの方と共にもっとユーザーを理解できる機会を作っていきたいなと感じました。

人々を理解し、人々からインスピレーションを得る

インスピレーションは大事だし、それを引き出すために人々を理解する活動は重要だなと感じました。
私のプロジェクトでは価値を提供する人々への組織的距離があるばっかりに、価値を提供する人々のことに関して思考停止してしまっているところがありました。
難しい状況を少しずつ壊して、かき集められるだけ、かき集める必要があるなと。で、インスピレーションを得たり、価値を提供する人々のイメージを持ちながらシステムを開発したいなと、感じました。

人々のところは価値を届けたいと考えている人々、つまり想定ユーザーだけでなく、デザインに取り組んでいる人、デザインによって影響を受ける人を含むと筆者が考えているのは非常に面白いと思いました。
価値を届ける人々だけでなく、ステークホルダーにも目を向けてみんなで腹落ちするものをデザインしていきたいなと、思いました。

で、どうやってリサーチするのさ？

この本の素晴らしいところはここだなと、私は思っています。
インタビューを中心に、リサーチツールをうまく活用しながら現状の把握をしていくことがリサーチの流れだと私は理解しました。

インタビューのコツ、気をつけること、いろいろなツールの特徴、やり方の紹介をしてくれています。
気になる方はぜひ読んでみてください。

おわりに

リサーチツールを色々使ってみたいなと思ったのと、チームのデザイナー中心に、プロダクトに関わる人々を理解するために彼らの生活、風習、仕事の仕方を観察、分析したいなと思いました。

ふりかえりのファシリテーションパターンを整理してみる

はじめに

メーカー系企業のコーポレート部門でスクラムマスター兼ソフトウェアエンジニアとして働いているモンゴルです。
ふりかえりをやっているときに、ファシリテーションをやることが多いのですが、ここがうまく回せないと感じることが多いので、パターンをまとめていきたいと思います。

今回は、あるネガティブな事柄（以下、ふりかえりごと）を掘り下げてふりかえるというシチュエーションを想定してファシリテーションのパターンを整理しようと思います。

最初に聞くこと

1. ふりかえりごとに対して気になった！と言っていた人から、どういったことが気になったか？と聞いてみる
2. それを受けて、ふりかえりごとを書いた人を中心に、関係者に詳細を聞いてみる

ここからは4つのパターンに分岐すると思います。

• ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がある場合
• ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がない場合
• ふりかえりごとに対して、対応が明確な場合。掘り下げる余地がない場合
• ふりかえりごとに対して、対応が明確な雰囲気が出ているが、掘り下げる余地がある場合

パターン別ふりかえり方

ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がある場合

チーム立ち上げ初期に多いパターンに思えます。

議論を発散させていきます。
次のステップで、全員で案出しをするためにも、気になるところ、不明点を数人に聞きます。問題点をあぶり出していきます。
場合によっては、問題点の依存関係を整理していきながら話を聞いていくのもありかと思います。

問題点が出揃ったら、対応案を案出していきます。
私は時間を決めて付箋に書き出すことが多いです。
付箋に書いたら、グルーピングして、投票してTryを決めていきます。

ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がない場合

あんまり見ないパターンな気がします。
自分の認識に自信がなければ、皆に問いかけてこれ以上掘り下げるかどうか尋ねてもいいと思います。
私は親指投票（上だったら賛成、下だったら反対、横だったらどちらでも良い）で皆の考えを聞くことが多いです。

ふりかえりごとに対して、対応が明確な場合。掘り下げる余地がない場合

自分が掘り下げられないと思いこんでいる場合もあるので要注意。
とはいえ、明らかに明確な場合もあると思うので、私はメンバーに案があるかどうか、親指投票でTryとするかどうか聞いて進めることが多いです。

ふりかえりごとに対して、対応が明確な雰囲気が出ているが、掘り下げる余地がある場合

このパターンはそれなりにあると思います。
自分がチームメンバーに積極的に質問していきます。そして、自分の質問をきっかけに問題点を探っていきます。

問題点がわかったら、「ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がある場合」の流れと同じくブレストして、グルーピングして投票してTryを決めていくことが多いです。

まとめ

今回で、それぞれのパターンでの流れを整理することができました。
ただ、「ふりかえりごとに対して、不明点が多い場合。掘り下げる余地がある場合」では、どう問いかけていくかが難しいので、今度どういう文言で問いかけをするとよいか整理したいと思います。

また、ふりかえりに限りませんが、「ファシリテーション入門」という本がおすすめなので、気になる方はぜひ読んでみてください！

ファシリテーション入門〈第2版〉 (日経文庫)

ではまたー

「スクラム実践者が知るべき97のこと」を読んだ

はじめに

仕事で支援してくださっているアジャイルコーチからオススメされたので読んでみました。

スクラム実践者が知るべき97のこと

感想

自分が見開き1ページで1トピックになっているので、気軽に自分が興味あるところを中心に読みすすめることができました。
少し気になったのは電子ツール、リモートワークはよろしくないという記述ですね。
コロナ禍により、電子ツールやリモートワークのツールや取り組み方も、全世界的に成長したと感じています。
とはいえ、対面は対面でコミュニケーションの密度も濃くなると思うので、コロナ禍が終わったらここのパワーバランスは変わるんだろうなーと感じました。
私が気になったのは以下のトピックです。

1. スクラムについて誰も教えてくれない5つのこと

「スクラムは問題を解決してくれない」「スクラムをやることで早くはならない」はすごく共感しました。
スクラムは難しい状況で、チームの成功率が上がるようにするやり方なんだなーと感じます。

20. プロダクトバックログを通じて優先順位付けされた要求を伝えるには

プロダクトバックログは優先順位ではなく、提供する順番に並べられているというのは、すごくいい記述だなーと感じました。
優先順位順で書くべしというのをよく見た気はしましたが、実際は依存関係があるので、悩ましいなーと思っていました。
この記述によって日頃の悩みの一部が解消されました。

50. スプリントレビューはフェーズゲートではない、51. スプリントレビューの目的はフィードバックの収集。以上

スプリントレビューでは検査に集中することで、計画プロセスの焦点が学びの最大化にシフトする。できる限り早く勝ちを届けるように変わるのだ。

という文が心に残りました。
スプリントレビューでは、新機能、改善を受け入れるかどうか、という出し方をしてしまう事があるので、定期的に思い出して、みんなで検査して、継続的に学習できるようにもっていけるように促していきたいと思う。

67. チームは単なる技術力の集合体ではない

多くの場合、プロジェクトへの人の割当は空き状況とスキルだけに注目して行われる。個人の人格がチームの成功に与える影響はあっさりと無視されてしまう。

という部分、すごく賛同できました。場合によってだと思いますが、マネージャー層はスキルマップだけでみて、追加の人材を考えていることもあると思います。
スクラムマスターはチームメンバーの一人一人の個性を理解し、新しいメンバーを考えていくということが大事だと感じました。
一方、私見ですが、ポジティブ、変化に前向き、顧客志向なメンバーが集まれば成功し、そうでないメンバーが多ければ、失敗する確率が高まるのでは？と、現在のプロジェクトを見ていて思ったりしています。
多様性や、それぞれの相性は考慮しつつも、ベースとして〇〇ないる持っている価値観は大事！みたいなことが言及されていたらよかったなと思いました（そういうものはないのかもしれませんが）

74. 優しく変化する方法

形と乱取りの例えが面白いと思いました。
スクラムに限った話でもないと思いますが、なにかの仕事を上達するためには、定められた状況での技能のトレーニングと、実践に近い状況でのトレーニング、の両方が不可欠だと改めて気付かされました。

まとめ

スクラムについて、たくさんの意見が述べられていて視野が広がりました。
みなさんも読んでみて、是非お気に入りの節を見つけてみてください！

Next.jsのAPI Routeの作り方について思っていること

はじめに

同僚から、APIのテストどうしてるん？と聞かれたので、個人的に思っていることを書いていこうと思います。

自分が考えている指針

API Routeに限った話ではないですが、、

• HowとWhatの分離をしてコーディングしていく
  • 記述と実行の分離とも言う
  • 「具体的な処理」と「どういう振る舞いをさせるか」を分けるということ

結果として、API Routeは以下のようなコード構成をしています

handler層

httpリクエストを受けつけて、リクエストに応じて処理を呼び出している層。1httpリクエストに対し、1関数作る。
Next.jsのAPI Routeでは、Next.js側でhttpメソッドを考慮したルーティングはされないので、httpメソッドのチェックもこの層で行う。

service層

ユーザーからのリクエストを受け付けて、データをユーザーに返すフォーマットに整形して返す層。ユーザーの一つの行動に対応して、1関数作る。
後述するRepository層の関数を複数回呼び出して、データを集計、変換し、handlerにデータを返す。

repository層

service層からの呼び出しを受けて、永続化層（≒SaaSやDBなど、外部のデータソース）へリクエストを代行する層。永続化層への1リクエストに対応して、1関数作る。
SaaSに対するリクエストの場合は、jsonでデータが返ってくるのでパース、オブジェクトへの変換もここで行う。
また、複数のリクエストを送ったり、処理の分岐はさせず、ただ単にリクエストしてオブジェクトに変換するという責務だけ持たせる。

API周りのテストをどう考えているか？

mockを使用して、各層毎に単体テストのみを行う。
すべての層を横断的にテストする、結合テストをした方が良いが、単体テストでそれなりに品質は担保できているであろうと判断。

また、網羅性の高いテストを行おうとすると n(handler層のテストケース) * m(service層のテストケース) * l(repository)層のテストケースが必要になり、実行にも時間がかかるし、テストケースの準備も大変なのでこのようにしている。
網羅性は単体テストで担保し、正常系だけでも結合テスト行えばいいのでは？という意見については同意するものの、今回は見送っている。

現時点でどうしているか。今後どうしたいか。

handler層

httpリクエスト、service層の関数のモックを作り、リクエストとserviceからの返り値を変更して、想定するレスポンスが返ってきているか確認するテストを作成している。
現状で満足している。

service層

repository層の関数をmock化し、mockの返り値、関数呼び出しの引数を変更して、想定するデータが返ってくるか確認するテストを作成している
現状で満足している。

repository層

DBへのテストは、インメモリデータベースをテスト起動時に起動してリクエストする方法が考えるが、数日取り組んだものの実現しなかった。（技術的には可能なので、もう一度チャレンジすれば多分いける）

SaaSへのリクエストのテストについて、実際にリクエストをするのは、テスト実行の排他制御も必要であったり、実行に準備がかかるので、テストを実施していない。
fetch関数をmock化する事もできるので、それによってテストができるが、SaaSのスキーマ変更により、テストは通っていても実際には動かないみたいなことも発生するので、個人的にはこのテストだけではあまり意味ないと判断。
また、ここのテストを実装しなくても、問題が起きづらくなるように、repostory層には単純にリクエストしてレスポンスをオブジェクト化するというだけの関数を作るようにした。

テストではないが、httpレスポンスに型がつけられる aspida を導入したいなと悶々と考えたりしている。

チーム/社内勉強会の形式はまずは「音読会」がオススメ

はじめに

チームで勉強をする機会を作りたいみたいなことが有ると思います。
その手法としてチーム/社内勉強会を開催することが有ると思うのですが、私のチームでは"音読会"の形式で勉強会を開くことが多くあり、それが結構良さげだと感じたので、メリットややり方、気をつけることを書き留めたいと思います。

そもそもチーム/社内勉強会のメリット

• チームで知見を得たり、共有することで、同じ意識、文化をもってチーム開発ができる
• チームの士気が高まる

個人的には1つ目の同じ意識、文化を持ってチーム開発ができるは非常に大きいなと思っています。
従来は、レビューくらいでしか技術的な深い会話を行ってこなかったのが、勉強会という形を取ることで、別の角度で技術的な深い話ができ、かつ、（本にもよりますが）設計やアーキテクチャ選定等、レビューでも話さない話題で会話することができます。
直接的な仕事の話ではないにも関わらず、このような会話により同じコンテキストを共有することで、その後、ぐっと開発速度や開発の質もぐっと上がると感じています。

音読会のメリット

• 準備が不要
• 担当の概念もないので、急に欠席しても問題ない

これが全てであり、非常に大きいと思います。
皆、仕事が忙しい中参加するのでできるだけ負担をかけない形にしないと継続は難しいと考えています。
準備した輪読会のほうが深い議論ができたり、スピーディーにすすめるかもしれませんが、とりあえずはこの方法がノンストレスで楽しめそうだなという印象です。

やり方

順番を決めて区切りのいいところまで読んでいきます。読んだら次の人を指定します。
節の区切りなどで、その節の要約であったり、自分の感想、発見、わからなかったことを一言二言言って、周囲と軽い議論をします。

全員に順番が回るようにしたほうがいいので、そこらへんは空気を読んで個々人が分量を調節します。

気をつけること

• コードを触る本であれば、VS CodeのLive Share等を使用してみんなで触りながら進めていく。
• 参加者全員が話せるようにする。そのために最大人数を決める（私の所感だが、最大は5, 6人が限度かなと）。
• 比較的業務が落ち着いているタイミングにやる。（私のチームでは、作業が一旦落ち着く、スプリントレビューの日に開催しています）