成長を続けるfreeeとマネーフォワードはサービスの信頼性をどう担保しているのか？に参加してきた

freee.connpass.com

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

会の概要

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

組織の規模の拡大、サービスのユーザ数の増加によってサービスの信頼性確保がより強く求められています。

サービスの信頼性を確保し安定稼働を実現するには、スピーディかつ必要な水準を満たしたインフラ構築や安全なリリースの仕組み、急激なユーザリクエストにも耐えられるリソースの確保など超えなければならないハードルがいくつもあります。

これらのハードルを乗り越えてサービスの信頼性を確保するために、SRE はインフラ構築の仕組み化やスケーラビリティの確保、コスト最適化の両立などに頭を悩ませています。 このイベントでは急成長を続ける SasS 企業である freee とマネーフォワードが実際に実践しているサービスの信頼性確保の取り組みをお話します。

スピーディかつ安定したサービスリリースを提供する方法、スケーラビリティを確保しつつコストの最適化を図る方法などを LT 形式で紹介していきます。

会の様子

LT1: 100以上のクラスタに立ち向かえ〜freeeのEKS Upgradeに対する取り組み〜

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

freeeのインフラ構成は、kube-aws- > EKSへと2019年から段階的に移行していったそうで現在では95%以上、100クラスタ以上がEKSで稼働しているそうです。
また、EKSのセットアップは、terraform-aws-modules/eks/awsをラップした社内モジュールによるAWSリソースの構築後にk8sリソースの構築をするという形でしているということでした。

EKS Upgradeは元々SREが担当していたそうですがクラスタが増えるにつれてSREが全て担当するのは難しくなり、開発チームに作業移譲をするようになったということでした。

ただ、それでも30-40hかかってしまっているため、暫定的な対策として、手順整備&改善を実施しながら、Argo Workflows化をしたり、長期的にはk8sのテナント再設計をしてクラスタ数が本当に適切かを検討しているということです。

LT2: KEDAでスパイク負荷を迎え撃つ〜メトリクスとスケジュールドリブンなオートスケールでKubernetes上のプロダクトの信頼性を高めよう〜

次に佐々木さんから話がありました。

サービスが急激にスケールしているような段階では、インフラをお金で増強する手段もあるとは思いますが、組織が一定大きくなってプロダクトも安定してくるとコスト削減しながら高い品質を保つ重要性がより高くなるため、そこで如何にしてコストと品質の両輪を保つか考えてみようということでした。

考えるにあたっては、勤怠システムを事例として、KEDAを使ったイベントドリブンのオートスケールの話がありました。

KEDAはCronをはじめイベントドリブンでスケーリングをすることができますが、KEDAを使ってチューニングする際は、大きな山だけを見るのではなく変化率の観点で負荷分析するのが重要だということで、もし負荷分析ができていないなら本当に少しずつチューニングすることが必須だということでした。

LT3: 1ヶ月から1週間へ！ freeeのインフラ構築ツール紹介

続いて、Nagaokaさんから、freeeops(自社ツール)でインフラを自動構築した話を聴いていきました。

freeeでは、サービス特性上aws基本構成の類似点が多いことから、freeeopsでテンプレートを作成したそうで、50個以上のタスクがone commandで実行できるようになり、1週間で構築ができるようになったということです。

ツールを開発/運用するに当たっては、

• Golang開発経験が少なく開発が属人化した
• ドキュメントが足りず問い合わせが殺到した
• freeeopsのテンプレート内で利用する社内モジュールアップデートを手動反映する必要があった

といった課題を解消しながら開発したそうで、チームの情報共有や自動化などを活用したということでした。

また、リリース前にインフラ状態をチェックするためのチェックリストを作って、品質の担保も行うようにしているそうです。

LT4: 〜計測でサービス危機を未来予測する〜 MySQLテーブル毎のデータサイズ集計をDatadog × Prometheus Exporter × Kubernetesを使って自動化した話

最後にVTRyoさんから話がありました。

サービスの信頼性は重要だと言われ続ける一方で、フェーズによって重要視するメトリクスも変わり、結果的に運用作業限界への恐怖が次第に出てきたそうです。

そこで、データサイズ集計を自動化したそうで、Datadog, Prometheus Exporter, k8sを活用することにしたというお話がありました。

また、活用の際のポイントとしては、

• k8s manifest(Dockerでの使用方法のみしか説明がないのでk8s用に修正した)
• MySQL settings(UserとGRANTが必要)
• Datadog Dashboard view(あらゆる形式で表示できるようにする)

があったということでした。

会全体を通した感想

発表者の方々が抱えているサービスの特性上、高い信頼性が求められると思うのですが、その信頼性を担保するために運用でしている工夫(それも5年-10年の過程)が聞けて非常に面白かったでうｓ。

自動化関連のお話は、自動化する前にここを自動化しようと踏み切ったステップに関して話があるとよりありがたいなあと思ったのですが、ここはまた次回に期待しようと思いました。

エンジニアのための目標設定の技術 - Forkwell Library#41に参加してきた

forkwell.connpass.com

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

会の概要

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

第41回目では『エンジニアのための目標設定の技術』を取り上げます。 2024年も始まり、目標を新たに設定する方もいるのではないでしょうか？ みなさんは目標を設定する際、どんな方法で考えていますか。「どうやって効果的な目標を作成したらいいんだろう？」「目標を設定しても、達成までやりきれない…」という方に向けて、今回は目標設定のテクニックについていろんな事例を取り上げている、「エンジニアのための目標設定の技術」という本を取り上げます。

今回は、その中からいくつかの章を取り上げつつ、この本が生まれた経緯、明日から使えるテクニック、などをこの本の著者の代表である親方さんに伺います。

会の様子

本が生まれたきっかけ

4年前(2019年1月25日)にあった、目標設定の技術を勉強する会がきっかけだったということでした。

ここでやったLT会の内容がよかったため、本にしようという話になり、まずは36ページくらいのお試し版で発行されたそうです。お試し版も受けがよく、その後は半年後くらいに160ページくらい、さらに数ヶ月後には190ページくらいになり、合計で2500部ほど売れ、最終的に今回のように本になったということでした。

本の内容紹介

異なる章を異なる人が読むことができる本で、オムニバス的に気になる章を読むことができるという話がありました。

その後、幾つかの章の紹介がありました。

4章

マンダラチャートを用いて目標達成できない理由を分析してた結果、色々なところで似たようなキーワードがでてきて、そこから弱点の明確化に繋がったそうです。

その後は弱点を基に、達成目標を再設定したあと、具体的な行動目標を設定したそうで、小さく具体的に進めたりヘミングウェイ方式で達成条件を複数立てたり、本当にやりたいことを改めて具体化するといった行動をとったということでした。

9章

目標設定のためにTODOリストをどのように活用できるかという話がされているそうです。

具体的には、ずっと引き継がれる項目の見直し方法だったり、アクションの実行可能性や心のコストを考慮することが挙げられていました。

10章

ABC目標の活用法ということで、最高の状態で達成できる目標と適切な目標と最悪の事態に陥った時の目標を3点設定する話が書かれているということでした。

13章

ふりかえりから始める目標設定に関して話がされているということでした。(内容からして誰が書いたかすぐわかりますね)

様々な期間のふりかえりを目標設定にどのように組み込むかが記載されているそうです。

28章

積みタスクはどんどん増えてしまうということで、早く終わらせるために損切りしたりプロジェクトを完遂させるためにゴールを小さく軌道修正したりする話が紹介されているということでした。

30章

そもそも目標設定が必要なのか？という話が書いてあるそうで、目標設定ができないことをやらない理由にしないことの重要性が記載されているということでした。

31章

目標から挫折した場合、それはそれで新しい別のゴールが存在するし、決して目標から挫折したら地獄になるわけではないというマインドセット寄りの話が書いてあるということでした。

32-38章

タイムマネジメントの話が書かれている章ということで、家事の時短テクニックや子供がいる中での時間捻出やSNSとの付き合い方に関して話がされているそうです。

おまけ(アウトプットのすすめ)

技術同人誌でアウトプットすることで、

• 技術の棚卸しや整理ができる
• アウトプットの規模がちょうどいい
• マーケティングから告知まで全ての工程を経験できる
• 商業化の可能性がある
• 本を書いたことがあるエンジニアになれる(転職などのアピール材料)

といったメリットがあるという話が最後にありました。

また、合同誌であれば参加ハードルはより低くなるので、初めて書いてみる場合はまず合同誌からの参画がおすすめだということでした。

Q&A

発表の後はQ&Aがありました。以下、内容を常体かつ箇条書きで記載していきます。

エンジニアの業務は数値化が難しいと思うが、数値化をしながら目標設定する方法はあるか？

実質定性目標になってしまうがABC目標がお勧め。異なる種類の業務に対してABC目標を設定することで、3段階評価ができる。

なお、上司に伝える方がいいのかはどちらとも可能性があるので、注意。

技術力に関する目標設定はどのようにするといいのか？

技術力の向上とはそもそも何かというのはあるが、まずは何かしら動くのものを小さく作り上げてみるのが良いと思う。

あとは本を書いてみることがお勧め。

評価に関して達成目標の定性化にまつわるノウハウはあるか？

評価できているのであれば定量化でも定性評価でも業務が回っているなら良いのだが、もしどうしてもしなければいけないのならば、目標に関して同僚や上司に相談するのが良いのでは？と思う。

アウトカムを評価に入れるのは、アウトカムが遅行指標であることが多いがゆえに難しいのではないかと思うが、どうすると良いのか？

難しいのは事実だと思う。正直遅行指標を決めるアイデアはない。

AIツールを活用した壁打ちのコツはあるか？

自分で使ってみるしかないと思うが、今困っていることの対処をしてもらって自分の整理をするのは大切だと思う。

新卒1年目なのだがどれくらいになれば本は書けるのか？

今すぐにでも書ける。自分が困っていることは間違いなく他の人も困るので、今こういうことに困っているというのを書けば良いと思う。

OKRのメリットデメリットは？

他の所に幾らでもまとめられていると思うので調べてもらえばいい。

ミクロの目標を立てるコツを知りたい

まず人によって、ミクロの目標を立てるのが得意な人とマクロな目標を立てるのが得意な人がいる。もし後者なら、目標のブレイクダウンスキルを身につけることができると良いと思う。

目標設定には複数パターンがあるので色々な手法を知ることが大切。

全体を通した感想

目標設定にまつわるTipsが知れたのはもちろんよかったですが、それ以上に同人誌が商業本として売り出されるまでの一つの流れが掴めたのがよかったです。

Oyakataさんがforkwell libraryでお話しているのはなかなか新鮮でした。

フロントエンドの技術選定 ~2023を振り返る~ Lunch LTに参加してきた

findy.connpass.com

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

会の概要

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

2023年5月に、Next.js 13.4がリリースされ、AppRouterがstableとなりました。その後、実際に自社のプロダクトに導入する組織も増え、改めてPages Routerに戻す方やRemixへの移行を決断する方など、メリットとデメリットも見えてきております。

本イベントでは、上記の流れにおいて自社のサービスにおいて、SSRやSSG、またはSPAが適しているのかという点について考え技術選定を行われた方々をお呼びし、明日から使える気づきや学びを得られるイベントを目指します。

会の様子

LT1「RemixでWeb標準を学んだ一年間」

最初になかざんさんから、社内向けの収益計算システムでRemixを採用した話がありました。

Remixを採用したのは、Next.jsへの逆張り的な側面はありつつも、一番はWeb標準を覚えられることができる点が魅力的に映ったということです。

実際に採用してみて、昔からあるWeb標準を改めて知ることができたり、MDNを参照する頻度が格段に増えてRemixやReactに依存しないスキルを身につけることが結果的にできたということでした。

LT2「React ViteからNext.jsへ切り替えたプロセスとApp Router化のボトルネック」

続いて、sumirenさんから、React ViteからNext.jsへ乗り換えした事例紹介(ただしApp Routerにはできなかった話)がありました。

React ViteからNext.jsへ乗り換えしたのは、FCPが遅かったことに対する問題意識が背景にあったということです。(Next.jsのPages Routerが魅力的だった)
また、移行する際は、React ViteとNext.jsそれぞれを並行運用したそうで、いつでも移行を中断できる体制を整えながらじっくりQAができたということでした。

ただし、App Router化はルーティングにボトルネックがあることで断念したそうで、複雑なルーティングとブラウザバックサポートがまだまだ発展途上な点が解消されるまでは移行が難しいと判断しているそうです。

LT3「一休レストランで Next.js App Router から Remix に乗り換えた話」

次に、Next.js App RouterからRemixに乗り換えた事例の話を恩田さんがしてくれました。

恩田さんが所属している一休さんでは、React Server Componentへの魅力からNext.js App Routerに移行したそうですが、

• History APIのstateが操作できない
• Cache-Controlヘッダを自由に設定できない
• 安定性や継続的なアップデートに懸念を覚えた

の3点の課題が発生し、そこから2ヶ月でRemixに乗り換えたということでした。
Remixは、上記3点の課題を解消できることに加えて、なかざんさんからも話があったようにWeb標準APIの重視が魅力的だったそうで、結果的にFastlyを有効活用できるようになり、

• Cache Hit Ratioが5ポイント向上
• レスポンス速度向上
• Back Forward Cacheで既存画面との遷移体験がよくなった
• Prefetchを積極的に利用できるようになった

といった結果を得られることができたということです。

LT4「Next.js App Router を例に考える、技術との距離感と技術選定」

最後に、izuminさんから、新プロダクトの技術選定時にどのようなことを考えていたのか？という話がありました。

izuminさんは、まず「何のためにWebフレームワークを導入するのか？」を考え、そこでルーティング機構とそれに最適化されたビルドシステムの獲得が一番の理由だと考えたそうで、これに加えて世の中に知見が多く溜まっていることや学習コストが低い点を踏まえてNext.jsとApp Routerの採用を決めたということでした。
また、上記のように重要視するポイントを決めたことで、パフォーマンスは一時的に優先順位を下げてもいいなという意思決定ができたということです。

こうして技術選定をする際には、(決定的な差がない場合は)撤退可能なパスを残して一定距離を取ることを厭わないことも大事ですが、その一方でBet Technologyするために余白を作っておくことも重要だというお話でした。

なお、プロダクトリリース時には結果的にApp Routerから撤退することになったそうで*1、やはり一定距離を取りながらApp Routerを採用していてよかったと思ったそうです。

会全体を通した感想

App Routerの採用がここ最近増えてきているなあというのは感じていたも一方でなかなか実現が難しい機能もあると思っていたので、撤退する企業さんの事例がこれだけ聞けたのは、納得感がありました。

また、フレームワークに依存しない技術力の獲得という意味でRemixはやはり魅力的だなあと感じました。

*1:作りたい機能がApp Routerでは実現できなかった

スクフェス金沢が開催されます

まだまだ具体的な内容はこれからですが、スクラムフェス金沢2024、7月開催を目指して動き出しました。#scrumkanazawa

— スクラムフェス金沢実行委員会 (@ScrumKanazawa) 2024年1月20日

sizu.me

スクラムフェス金沢が開催されることが決まり、現在色々と動いているので、今日はその告知も兼ねてブログ記事を書いています。

なお、本当にスタートしたてなので、あくまでもここに書いていることは途中経過だと思っていただければありがたいのですが、一度話に出て一定確からしい話のみ記載しています。

開催形式

ハイブリッドで開催できればという話が今のところ出ています。

他のスクフェスでも実績がある形式(プロポーザルを募ってオープンプロポーザル形式でセッションを決める等々...)で進めていく予定です。

開催経緯

元々、ここ何年かずっとスクフェス金沢開催の機運はあったのですが、なかなかタイミングが合わなかったりして開催には踏み切れていない状態でしたが、今年は元旦に能登半島地震が発生し、復興の意味合いも含めて何かしら金沢に貢献したいという想いが金沢とゆかりが強いメンバーから生まれ、立ち上げに至りました。

このあたりの経緯に関しては一度改めて整理して言語化したいなーという話も出ているので、もう少し整理して正式な場所で正式な形(開催趣意書など)でお伝えすることになるかと思っています。

開催日時

今のところ、7/19, 7/20を予定しています。

余談(自分の関わり方)

これまで運営として何かのスクフェスに参加したことはなかったのですが、今回は運営委員として参加しようと思っています。

この関わり方を選んだ理由は複数あるのですが、以下が主な理由です。

• 自分が初めて登壇したのがスクフェス大阪の金沢トラックだった
• オーガナイザーのyanagiさんは、アジャイルコミュニティででできた初めての知り合いだった*1
• 能登半島地震に対して、募金以外でも何かしら復興支援をしたかった
• 金沢に行きたい

おわりに

やや急ピッチな上に、運営経験がないメンバーがコアメンバーには多いので、色々ばたばたするかもしれませんが、とにかく楽しみの一言です！

少しでも気になる方は、7/19, 7/20をぜひあけておいていただければと思います！

*1:知り合いの定義にもよりそうなので補足をすると、自分が顔を見せて声を出して会話した初めての人という意味です

禅とアジャイル〜無門関を通してアジャイルを学ぶ〜に参加してきた

distributed-agile-team.connpass.com

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

講演

講演のもとにあった読書会

Jim Coplienがスクラムの説明をする際に、禅の十牛図の話をするそうですが、その際に「日本人なんだからわかるでしょう」みたいなテンションで来るので、もっと詳しく知りたいというところから読書会がスタートしたそうです。

なお、実際に読む本は、中埜先生の影響も大きいということでした(禅とオートバイ修理技術や弓と禅、無門関を紹介してもらった)

禅を学んで目指したかったこと

アジャイルコーチも禅問答のようなものをしていることはあるので、禅とアジャイルには一定の親和性があると考えているそうで、究極的にはアジャイル公案(禅問答)を作成しそれを世界に広めることを目指しているということでした。

第一則〜趙州狗子〜

仏教は生きているもの全てに仏性があるという考え方がありますが、「それなら犬にも仏性はあるのか？」と聞かれた際に「無だ！」と言ったエピソードから、「僕らはアジャイルできていますか？」とアジャイルコーチが聞かれた際に、「できている」「できていない」ではなく「有無」と答える*1のがアジャイル公案になるのではないか？ということでした。

第一則は、「無」という答えがないものに対しても向き合い続けていこうね、という話であるため、「無」という概念はそもそもないし、説明もどこでもされていないというのがポイントで、普段の仕事でも答えが出なくてもそこに対して向き合い続けていくことを大切にしたいというお話が読書会でもあったそうです。

第二則〜百丈野狐〜

「私は500回も野狐になっている」という話をした人に対して、「因果をくらまさない」と答えることで見事に野狐を成仏した話と、成仏に成功した後に「問題がない場合はどうなるのか？」と弟子が聞いてきて、そこに対して「教えてやろう」と答えたところ弟子が近づいてきて引っ張たかれて喜んだという話がありました。

アジャイル公案であれば、「WFで500回成功したからWFでやればきっと成功するよ！」と言っている人は野狐の可能性があり、「必ずプロジェクトを成功する方法を知ったんだ」というアジャイルコーチがいたら引っ張たかれて喜ばないといけないという話がありました。

第三則〜倶胝竪指〜

倶胝は何を質問しても常に和尚に指を立てられており、それを見た倶胝は真似をして倶胝にきた質問に対して指を立てるようにしたところ、その指を切り落とされたというエピソードの話がありました。

これは、アジャイルコーチが言っていることをスクラムマスターが真似したらアジャイルコーチが✕マークを口に貼ると、アジャイル公案になるのではないか？ということでした。(指ではなく指の先にあるものを見ないといけない)

第四則〜胡子無髭〜

西から来ただるまになぜ髭がないのかを聞いた際に、「それはだるまになるしかない」と言われたという話の紹介がありました。

アジャイル公案であれば、スクラムとはなんなのか聞かれた際に、あーだこうだ説明するのではなく、スクラムをいいからやれと言えるのではないか？ということでした。

なお、読書会でも禅とはなにかをあーだこうだ言っているときに、禅をまずやれという話が出た例が挙がっていました。

全体を通した感想

会が始まる前のオープニングトークでは、気楽にみんなで楽しみながら聞いてほしいという話があったのですが、禅の知識がなさすぎて訳の分からない話が次から次へと出てきて、なんにも分からないの連続でした。

アジャイルとの結びつきは特によく分からなかったですが、これまで一度もしたことがない捉え方を知れたのは素直に面白かったです。

*1:ダジャレでは決してなくあるでもないでもないという意味

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

yr-camp.connpass.com

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

会の概要

オブジェクト指向のこころを毎週1章ずつ読んでいくイベントです。今日は第2章でした。

会の様子

20:00-21:00は該当章を読み、21:00-は読んだ章の感想戦をしていくグループと練習問題を解いていくグループに分かれました。

自分は練習問題を解いていくグループで参加していきました。

1章の練習問題の回答

練習問題は、第1章がまだ残っていたということだったので途中から(応用問題の4から)やっていきました。なお、基礎問題は本に書いてある内容を覚えているかのチェックに近いので、参加者の皆で解くのはやめています。

以下、問題ごとに回答+議論した内容を記載します。

応用問題4

回答

オブジェクトを使う側/使われる側があったとき、使われる側にインターフェースを適用することで、使われる側の詳細に関してオブジェクトを使う側が知る必要がなくなり、変更に強くなる。

議論した内容

インターフェースを切る具体的な例も答えてほしい意図なのかな？という話が出ていました。

応用問題5

回答

()内は、本には書かれていないけれどおそらく必要になってくるであろう責任

• 教室...自らの場所を把握する、(収容可能人数を把握する)
• 学生...今いる教室を把握する、次の教室までの移動する、(セミナーを受講する)
• 先生...次の教室に移動することを命じる
• 情報提供者...次の教室までの移動方法を教える

議論した内容

題材が抽象的なので、もっと責任を出そうと思えば出せそうだけれど、本に書いてある内容で区切るとこれくらいかな、という話が出ていました。

あなたの意見1

回答

実際に作った後に、実現したかった要求が誤りだと気がついた

議論した内容

事業戦略レベルで要求の変更があるときは、ここに書いているような話はあまり使えなそうだけれども、レイヤーを分けたり要求分析をすることで変更が起きやすそうな戦略は一定はわかるのではないか？という話をしていきました。

あなたの意見2

回答

規模が小さいものでなければ同意できる。機能分解を用いて構造化プログラミングを行うと、プログラムが階層構造になり、一番上の階層のプログラムはすべてを把握する必要が出てくる。

議論した内容

最初は規模の話が出てこなかったのですが、規模が小さいプロトタイプのようなものであれば機能分解でも全然問題ないよねという話が出ていました。

また、長期間メンテナンスをすることを想定してないようなプログラムだったりは変更回数が少ないので、そういった場合は機能分解して作ってもいいかもしれないという話も出ていました。

あなたの意見3

回答

• 要求には変更が起こる前提で開発をする
• 要求分析ツリーを作成し、レイヤーごとに論点を整理している。その上で変更が起きやすいレイヤーと起きにくいレイヤーを特定する。

議論した内容

開発の基本スタンスとしては、要求には変更が起こる前提で開発をするのが良いという一方で、質の高い要求を引き出すための工夫も必要だよねという話をしていきました。

具体的には、上に書いた要求ツリーの話だったり、実例マッピングなどを活用してテスト可能な状態に要求を落とす&曖昧な要求を探して必要に応じて明確化するといったテクニックがあるよねという議論が出ていました。

2章の練習問題の回答

続いて、2章の練習問題の回答をしていきました。こちらも基礎は飛ばしています。

応用問題1

回答

本に書いてある条件を満たすような形で例を挙げるなら猫と動物、猫と動物園。ただし、色々批判がされている例である。

議論した内容

猫と動物をis-aとすることに対する批判はどこからスタートしているのだろうか？という話をしていきました。

批判自体はそこそこ出てくるのですが、批判の原点はよくわからず、時間を使いすぎてもあれなので暇があったときの宿題になりました。

応用問題2

回答

13派...単純に、13この矢印が記載されているため

3派...手順と呼べるのはMainからShapeDBに対して伸びている矢印のみなので、3

議論した内容

そもそも「手順」に関する定義が本書に出てきていない気がするので、そこから議論がスタートしました。結局「手順」がなんなのかは分からなかったのですが、話の流れから、本書のシーケンス図の粒度はめちゃくちゃなのでは？という話になりました。

1-13を並列にして比べるとたしかにぐちゃぐちゃで、一つのシーケンス図として読みにくいという意見があった一方で、本書の定義に従えばシーケンス図はオブジェクト同士のふるまいを表現する相互作用図的な意味合いが強いので、オブジェクトの粒度が適切であると仮定すれば、シーケンス内の処理に関する記載粒度が変わるのはそこまで違和感がないという意見も出ていました。

あなたの意見

回答

上記の応用問題の流れで突入したこともあり、明確な回答をだすというよりは議論の延長線上で色々話している感じでした。

議論した内容

最初に処理の粒度をはかる具体例として、「AWS S3にオブジェクト置く」は適切なのか？という話が出ました。
オブジェクトが「データ保管庫」くらいの粒度でしか表現されていない場合は、やや詳細すぎる気がする一方で、クラス名の候補が決まっていたり「AWS S3」といったオブジェクトが登場しているなら、適切な粒度なのでは？という話が出ていました。

その後はやや脱線して、シーケンス図を使いたいシチュエーション(実際の現場で使っているシチュエーション)に関して話をしていきました。
シーケンス図はプログラマー同士の会話で使っているという意見や、アーキテクトが事業戦略を表現する際に使っているという意見が出ていたのですが、後者のような使い方をしている場合、シーケンス図の前に概念モデリングなどを挟んでいないと、オブジェクトの粒度がめちゃくちゃなシーケンス図ができあがる可能性があるため、危険だよねという話が出ていました。
話の流れから、本書に出てきたクラス図はどう使うの？という話になり、正直そこまで使っていない気がするが以下のような状況では使っているかも...?という話がありました。

• 保守用のドキュメントとして求められる場合
• ドメインエキスパートやビジネスサイドと会話する場合(この場合、Miroやホワイトボードなどでクラス図よりももっとラフな図で会話するという意見もありました)
• クラス図を作っているツール会社に所属している場合

全体を通した感想

時間を延長するくらい議論が盛り上がり、様々な話ができてよかったです。

本の特性上、実際に現場で実践されている方同士で議論できるのがよく、せっかくなので具体的なコードを書きながら(モブプロしながら)理解をより深いものにしていきたいなあと思いました。(次回以降どこかのイベントで機会を作れそう？)

大人のソフトウェアテスト雑談会 #195【厄払い】に参加してきた

ost-zatu.connpass.com

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

新しいコンテンツの生成

類似イベントや小さいカンファレンスを高頻度で開いていくと、ネタやテーマが被りがちで、半年くらいで新コンテンツが生成されていかないと知識体系コミュニティとしての形を維持するのは難しいよね、という話をしていきました。

Software Design 400号

豪華なコラムが多くあったのですが、やや気になる部分があったという話をしていたのですが、どうやらX(旧Twitter)上でも話題になっていたという話が出ていました。

ただ、いくら探しても震源地が特定できず、話が終わりました。

燃料投下

logmi.jp

「話題になっていた」という話から燃料が投下されました。

自分たちがやった話をするのは全然構わないものの、「プロダクトマネジメントとは...」と言ってしまったりすると、(情報発信量が多いような方だとなおさら)業界全体で変な常識ができてしまったりして大変なので、慎重に発信できるとよいなあという話をしていました。

スクフェス福岡

そろそろスクフェス福岡が開催されるということで、スクフェス福岡の話をしていきました。

スクフェス福岡には現地に行きたいけれど、都内だと距離が遠かったり、ホテルの争奪戦が大変なことになっていたり(1泊3万円する模様)、そもそもチケット争奪戦が激しすぎたりと、現地に参加するハードルがなかなか高いという話をしていきました。

その後、品川トラックが誕生するという文脈で、葛飾トラックが誕生すると面白そうだという話や、Tommyさんが非公式なトラックを意図的に用意することでやりたい話などを聴いていきました。

全体を通した感想

今回は50分弱テキストチャットのみでコミュニケーションが行われる謎の時間もありましたが笑、福岡への盛り上がりを感じられたり色々な燃料が投下されたりして、非常に面白かったです。

非公式トラックだからこそできる取り組みとかはたしかにありそうなので、色々やってみるのも面白そうだなーと改めて思いました。