天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

スクフェス新潟2024にプロポーザルを出した

confengine.com

confengine.com

confengine.com

連日になりますが、スクフェス新潟2024にもプロポーザルを出したので、今回はその告知です。

プロポーザル概要

エビデンスに基づいたメンタルヘルス改善〜メンタルヘルス一次予防ガイドライン(EBM)探訪〜

メンタルヘルスを維持(改善)していく際には、個人が考えた取り組みや非専門家から勧められた取り組みではなく、医学的な根拠に基づいた取り組みをしていくことが重要だとWHOによって提起されています。

しかし、メンタルヘルスの維持(改善)方法を紹介している記事や本は、個人の経験則に基づいたものが多く、医学的な根拠に基づくいた取り組みを学べる題材は限られています。

そこで、本セッションでは、医学的な根拠を基に作成されたメンタルヘルス一次予防ガイドライン(Evidence-Based Medicine)を読み解き、メンタルヘルスの維持(改善)に役立つことがエビデンスから明らかになっている取り組みや、それら取り組みを実施する腕のTipsを紹介します。 取り組みやTipsを知ることで、自身の現場やセルフケアで取り入れることができそうなものをいくつか発見し、メンタルヘルスの維持(改善)ができるようになることを目指します。

※注意 ガイドラインにもある通り、現場での実施の際には、専門家の協力を仰ぐのは望ましいです。セッションでもこの点は勿論触れる予定です。

more effective mobile testing

本セッションでは、モバイルアプリ開発の中でテストを実施する際に役立つ知識やテスト戦略を紹介することで、モバイルアプリのテストをしている中でぶち当たりやすい課題に対処できるようになることを目指します。

最初に、モバイルアプリ固有のテスト観点を紹介します。紹介する観点は必ず網羅的にテストすべきものではありませんが、観点を知っておくことで、アプリの特性に応じたテスト計画を考えたりする際などに役立つと考えています。

次に、モバイルテストを実施する際に役立つテスト戦略や自分がテストする際に考えている観点を紹介します。具体的には、以下のようなトピックを紹介する予定です。

・テストデバイス選定

・Emulatorと実機テストの使い分け

アクセシビリティテスト実施時に考えること

ユーザビリティテスト実施時に考えること

・パフォーマンステスト実施時に考えること

・セキュリティテスト実施時に考えること

・探索的テスト実施時に考えること

なお、開発手法はあまり関係ない内容のため、アジャイルの文脈にフォーカスしたモバイルテストを知りたい方にとってはミスマッチなセッションになる可能性が高いです。

知識と実践を紡ぐChatGPT

プロダクト開発をしていく中でぶち当たる課題は、ほとんど全てが困難なものであり解決不能な問題に感じることもあるかもしれませんが、意外と多くの問題は既に先人たちがぶつかってきたものであり、その気になって調べれば知見があっさりと手に入ることもあります。知見は時を重ねるごとに充実してきており、スクラムやテストの知見に関しても、多くの書籍が発売され、数年前と比較すると非常に充実した学習環境が整っているように感じます。一方で、その知見を現場で活かすための練習機会というのは知見を手に入れる機会と比較するとそれほど恵まれていません。また、得た知見をそのまま自分自身の現場で実践する難度も知見を得る難度と比較すると高いことが多いです。

そこで、生成AI(ChatGPT)の出番です。生成AIはその性質上、得た知識を練習する機会の創出が可能であり、得た知見をもとに実践して試行錯誤する場を簡単に手に入れることができます。

本セッションでは、自分自身が「知見は溜まってきたけど経験が浅い」状態だったアジャイルコーチングを実践する際に生成AIを活用して行ってきた練習機会の創出方法やプロンプトのチューニング方法を紹介することで、「知見は溜まってきたけど経験が浅い」方々が、得た知見を自分自身の現場に合わせて実践する機会を手軽にたくさん作れるようになることを目指します。

プロポーザルを出すまでの経緯

エビデンスに基づいたメンタルヘルス改善〜メンタルヘルス一次予防ガイドライン(EBM)探訪〜

メンタルヘルスカテゴリがあるのはスクフェス新潟ならではなので、メンタルヘルスに関するプロポーザルを出そうと思いました。

メンタルヘルスカテゴリは毎年面白いプロポーザルが多くて、今年も興味深いプロポーザルが幾つもあったのですが、WHOがメンタルヘルス改善に必要だと提言している医学的根拠に基づいた話はまだ見たことがなかったため、今回は医学の分野で有名なEBMに関する話をしようということでプロポーザルを出しました。

more effective mobile testing

スクフェス新潟といえばテストなので、テストの話をしたいなあと思いプロポーザルを出しました。

ただ、テストの話はめちゃくちゃプロポーザル数も多く、普通に出しても他の方が話す内容とコンフリクトしてしまうので、あまりスクフェス界隈では見ないモバイルアプリ開発のテストに特化したプロポーザルを出すことにしました。

モバイルアプリ開発におけるテストでも、モバイルアプリ開発に閉じないテスト知識のほうが重要だったりすると個人的には思っているのですが、意外とモバイル固有の観点は見逃されがちなので、有益な発表になる方も多いのかなあと思いプロポーザルをしたためました。

知識と実践を紡ぐChatGPT

スクフェス新潟2024のプロポーザルを見ていたところ、生成AIカテゴリのプロポーザルが一つもないことに気がついたので出すことにしました。

自分は昨年の中頃からアジャイルコーチとしての仕事にチャレンジしているのですが、アジャイル開発を実践してきて溜まった知識はあれど社外向けアジャイルコーチの経験はほぼ0だったのでその経験を補うためにChatGPTを活用しており、その取り組みが一定形になった&1年弱の実践期間を終えたのでここで一旦プロポーザルにしておこうということで出してみました。

今回チャレンジしたいこと

エビデンスに基づいたメンタルヘルス改善〜メンタルヘルス一次予防ガイドライン(EBM)探訪〜

シンプルに、EBMに基づいたメンタルヘルス改善の取り組みがもっと企業に広がるような話ができればと思っています。

よく言われている定期的な1on1とかリフレッシュ休暇も大事ではあるのですが、実は医学的根拠はなかったりするので、専門家のもとでエビデンスに基づいたメンタルヘルス改善の取り組みがいろいろな企業でされるような発表になるとよいなあと思っています。

more effective mobile testing

モバイルアプリ開発は如何にテストを必要最小限にできるかが勝負みたいなところがあるので*1、テストを必要最小限に実行できる手助けになるような発表ができればよいなあと思っています。

知識と実践を紡ぐChatGPT

(特に技術的な勉強以外で)本を読んだけど頭でっかちになってしまいなかなか実践できないという悩みを抱えている方は多いので、実践機会を容易に作れるような発表をしたいと思っています。

もし話せることになったら、発表後にやってみた報告が溢れるようになる状態になることを目指して準備していこうと思います。

*1:もちろんモバイルアプリ開発以外でもそうですが特にその要素がプロダクトに与える影響が強いと思っています

DevOpsDays Tokyo2024にプロポーザルを出した

confengine.com

タイトルの通りDevOpsDays Tokyo2024にプロポーザルを出したので、その告知になります。

プロポーザル概要

DevOpsを実践していく中でセキュリティの向上はDevSecOpsという形で一つのテーマになっています。 本セッションでは、OWASPのDevSecOps lifecycleに沿った形で、セキュリティ向上に繋がるプラクティスをDevOpsの中で取り込んでいくために自身が実践した方法と、実践していくうえで課題となる点とその乗り越え方の事例をお伝えし、よりセキュアなシステム構築ができるようになることを目指します。(紹介するプラクティスの詳細や話す予定のコツはOutlineを参照ください)

なお、RSGT2024でも「アジャイル開発で役立つセキュリティプラクティス」というタイトルでも講演しましたが、本セッションではDevSecOps lifecycleの部分のみにフォーカスします。(対応優先順位づけやテスト、セキュリティ専門家がチームと協働する際に役立つプラクティスの話はしません) また、ツールやプラクティスの紹介はRSGTのスライドを見れば一通り分かると思うので、ツールの話は割愛し、プラクティスに関しても簡単に概要を紹介するのみに留めます。 その代わりに、DevSecOps lifecycleで活用できるプラクティスを実践するうえでのコツや、実践の際に自分自身が考えていることを重点的に紹介し、一通り理解したツールやプラクティスを現場で実践する障壁をより下げることを目指します。

プロポーザルを出すまでの経緯

RSGT2024でAcceptしていただいた話の続きをどこかで出したいという想いがあり、今回出させてもらいました。

RSGT2024では、セキュリティ×アジャイルのエントリーポイントとなるような話がしたいなあと思っていてそれが実現できたので、個人的にはここからがスタートの感覚で、そのスタートが今回のプロポーザルになります。

RSGT2024では、全体観の紹介に努めて薄く広くという感じだったのでここからテーマごとに少しずつ掘ってきたいと思っていて、まずはDevSecOpsの観点でもう少し掘り下げようというのが狙いで、RSGT2024で消化したプラクティスが現場でより実践しやすくなることを目指そうと思っています。

今回チャレンジしたいこと

セキュリティの話がもっと広がると良いなあという想いは引き続き持っているので、今回のプロポーザルがもしAcceptされて講演できたら、その講演をきっかけに現場で実践してそこからまた別の話が出てきたら最高だなあと思っています。

また、今回は参加者層的にセキュリティのスペシャリストの方々も来ると思うので、その方から意見をいただけたり議論が広がっていくようなテーマもいくつか投げかけられたらいいなと考えています。

RSGT2024のセッションを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

長いオープニング

スクフェス新潟が間近だけれどもホテルが予約できないという話や、デブサミの話をしていきました。冗談なのか本気なのかはわかりませんが、もしかするとRSGTも羽田空港でやるかもしれないという話が出ていたようです。

A-CSPO研修

きょんさんが最近A-CSPO研修を受けてきたということで、その感想戦や他の研修(CSP-SM)の話を聞いていきました。

A-CSPO研修はJoeの研修を受けたそうですが、きょんさんが仕事しながら40,000歩歩いていることをJoeに絡まれたり財務分析ができないPOはだめだという話を聞けたりAI推しを随所に感じられたりして楽しかったそうです笑

全体的に面白かったそうですが、Learning Objectivesに書いてあることは全然話がないように感じたということでした。
他のAdvancedなPO系研修に出た方も似たような感想を持っていたり、参加者とのディスカッションは楽しいけれど研修で教えられる内容が断片的すぎるのは気になっていたということでした。(CSMなどもしかり)

研修後はJoeが研修のFBを欲しがっていたので、良かったところ*1と改善してほしいところ*2をFBしたところ、日本企業のサクセスストーリーや中村健也の話をぜひしてほしいとJoeから直々にお願いされたということでした。

また、Joeはその日辛口だったようで、マネジメント3.0の考案者は知り合いだけれども現場を全然知らないので現場で使いにくいプラクティスが多いという話をしていたりもしたそうです。

新潟のプロポーザルわいわい会

今日はちょうどスクフェス新潟のプロポーザル締め切り日ということで、プロポーザルをみていきました。

以下、みたプロポーザルと出ていたコメントを記載していきます。

confengine.com

  • 合いの手を入れて勢いをつけていくスタイルのプロポーザルがすごい
  • このプロポーザルにおける積読のイントネーションがきになる
  • ふりかえるポイントは設けるのか気になる

confengine.com

  • 熟年夫婦という表現は大丈夫なのだろうか
  • うっとなってその後「でもやってみよう」となっているのがすごい
  • Learning Outcome、本当はもうちょい踏み込んだ思いがあるんじゃないかと、勝手に思った
  • 悩みを「自分が考えている」なのか「BPさんが考えている」なのかによって話が変わりそう
  • 執行役員ってなにする人なの?という状態から、自分なりの覚悟ができるまで」は2つに分けて考えてもよいと思った
  • 部長と執行役員の違いとか、CxOとの違いとかは気になる人も多いかもしれない
  • 執行役員から見て、イケてない執行役員ているんじゃないかと思うんですが、心の中を聞いてみたい
  • 現場のメンバーと執行役員との関係とかあると、エンジニアの方にとって、より興味もてそうになるかな…ステークホルダーの中の人の悩みをしれる、みたいなラーニングアウトカムになる
  • スプリントレビューに期待すること、顧客に約束したスケジュールに間に合わないときに考えていること、とかも聞いてみたい
  • 執行役員レベルでないと解決できない問題とかも知っておけると、エスカレとかもしやすそうだなって思った

confengine.com

  • アジャイルコーチへの依頼が下手くそな状況がずっと続いている(いろんな人から聞く)けど、あまり状況はよくなっているようにはきかないので、具体的なプラクティスをかこうという想いでプロポーザルを出した

confengine.com

  • EBMが何の訳か書いておいたほうがよいかもしれない(スクラム界隈だと本家EBMよりも有名なEBMがあるため)
  • セッション時間がおかしい(2時間??)

confengine.com

  • ChatGPTの活用方法みたいなセッションは意外とスクフェス関連だと少ない気がするので気になる

全体を通した感想

急遽スクフェス新潟のプロポーザルを眺める会になりましたが、気になる話題で盛り上がれて非常に楽しかったです。
プロポーザルもすごい数になっていて70以上集まっているのはなかなかみないなあと思いながら眺めていました。

個人的には、久しぶりに*3一番最初から一番最後まで参加し続けることができたのも嬉しかったです。

*1:プロダクトのアーキテクチャが分かる人がプロダクトオーナーシップを持てるという実例があるのはいい

*2:テスラなどの話ばかりで日本企業の話が出てこない

*3:おそらく数年ぶりに

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

yr-camp.connpass.com

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

会の概要

タイトル通りオブジェクト指向のこころを読んでいくイベントです。

今日は特別回で、溜まっている練習問題をひたすら解いていきました。

会の様子

6章応用問題1

意味を説明してください、とありますが書かれているのが意味そのものなので問題文の通り、もしくはそれをただ言い換えするだけになってしまうね、という話をしました。

例としては、BFFが適切なのかな?という話が最初にありましたが、話をしているうちに、BFFをFacadeの抽象的概念として捉えるのは正しそうだけれども、BFFの具体的な実装パターンがFacadeで、BFFをFacadeというのは少し違いそうだと議論が出ました。

例としては、本にも書いている通り各機能単位で名前をつけられるようなことができるのはFacadeなのかな?という話になりました。

6章あなたの意見1

あくまでも既存機能を簡素化するものなので、使えないという結論になりました。

6章あなたの意見2

システムの利用状況を追跡したり、システムを交換することがメリットとして挙げられるという話になりました。

また、問題とは関係ありませんがkiroさんのスライドを見ながらストラングラーパターンの話と誤ったマイクロサービスの使い方(機能を小さくするためのマイクロサービス)の話をしていきました。

hub.attractor.co.jp

6章あなたの意見3

頻繁に起こるケースではないものの、社内システムであり(お金を払って利用しているユーザーがいない)、既存システムがあまりにもレガシー化している場合は新たなシステムを作成するかも知れないという話がありました。

6章あなたの意見4

Facadeの由来や意味を英英辞典で調べた結果、ふさわしい名前だという話になりました。特に大きな建物の一部というのはしっくり来るという話が出ていました。

7章応用問題1

相変わらず問題文そのものが意味なので、意味を聞かれても難しいという話になりました。

また、Adapterパターンは最終手段的に使うもので普段の開発で頻繁に使うようならコミュニケーションの取り方を見直したりしたほうがいいということで、例としてもあまり出てこないという議論をしていました。*1

7章応用問題2

これも参加者が全員ラップという言葉を知っていたので、そのままだねという話になりました。

7章応用問題3

簡素化するかどうかが違いだという話をしました。

全体を通した感想

初めて矢田さんと二人でゆっくりお話ができて楽しかったです。

二人ということでいつもよりぶっちゃけた話ができたり、Adapterパターンの利用方法に関して再確認ができたのは特に満足しました。

*1:自分が使う予定のオブジェクトを作っている開発者が自分のイメージと異なるインターフェースを作っている状況は突っ込みどころが多すぎる。また、使えると思ってもユースケースが異なる場合は既存のデータパターンの見直しが必要になったりして、Adapterパターンを使わずに1から作り直したほうが速い

(オンライン読書会) これが現象学だに参加してきた

educational-psychology.connpass.com

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

時間位置と空間位置

2つの基体に収斂されるパターンとして、時間位置と空間位置が本書では紹介されていましたが、時間位置というのが空間位置と比較してよくわからず、話をしていきました。

時間位置というと、1秒違うだけでも異なるように思えますが、ここで紹介されているのはあくまでも2つの基体に収斂されるパターンなので、時間位置が異なるからといって「必ず」同一基体に収斂されるわけではないという解釈で良さそうだという話が出ていました。(例えば犬が100年単位で異なる時間位置にいた場合、同じ空間位置にいたとしてもそれは異なる基体として収斂される可能性がある)

客観的時間

わざわざ「客観的」と言葉をあてている部分は、個人の主観から客観への変遷を示しているとも捉えられるよね、という議論をしていきました。

基体しかないノエマはあり得るのか?

153ページで、数や意味はノエマから抽出された抽象的成分であるという話があり、これは納得できるものの数や意味がノエマであるというのは納得できないという話が出ていました。

P133の本書におけるノエマを見る限り*1、現出をまったくまとわない裸の現出者の存在は認められていないので、数や意味をノエマということは難しいのではないか?という話があったり、逆にノエマそのものとして捉えることもできるのではないか?という話が出ていました。

「原」印象

我々が直観している現在だからこそ「原」をつけているのかもしれないと勘ぐりたくなるような言葉選びだという話がありました。

事実と異なる直観

その人が経験している直観が事実と異なっている上に他人も直観が事実と異なっている場合、エコーチェンバーによって事実と異なる直観が強化される可能性もあるよね、という話をしていきました。

想起と構築の違い

人は完全に一言一句正確にその場を記憶することはできないので、その人が想起だと思っていても実際やっていることは構築だという場合があるのではないか?という話がありました。

ただ、その人が想起しているという時点でそれが仮に事実と異なるものだとしても、それはその人にとっては直観であるため、構築ではなく想起といっても良いのではないか?という結論になりました。

逆に、その人が直観できていない場合(例えばさっき自分は何をしていたのか?と考える場合)、それは近い過去であっても、想起になるのではないか?という話がありました。

客観的時間か中立的時間かは人によって異なる?

上記の議論を基に考えると、客観的時間に属する事象だとその人は思っていても、別の人から見れば中立的時間に属するものだと思っている可能性はあるため、その物事が客観的時間か中立的時間かは誰にとっても明らかなものではない可能性があるという話をしていきました。(あくまでもその人の解釈の違い)

このあたりは、フッサールは明証性を使って説明しているのではないか?という意見も出ていました。

全体を通した感想

メンバーも固定化されてきて、アイスブレイクや前置きをほぼせずに、本の内容にがつっとダイブしていけて、非常に楽しかったです。

明証性の問題と客観的時間/中立的時間の概念は結構ごっちゃになっていたので、そこが紐解けて良かったのと、自分が直観したことに改めて立ち返って考える重要さを実感できたのが、今日の大きな取れ高でした。

*1:ノエマの解釈には東海岸解釈と西海岸解釈それぞれが存在する

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

ost-zatu.connpass.com

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

ガンダムビジネス

ガンダムは出ているコンテンツの種類や量自体はすさまじいものがあるのにもかかわらず、売上は一部のコンテンツに依存しており、ストーリーでヒットを生み出しているのがそこまで無いので厳しそうな気がするという話がありました。

一方で、メカデザインをする経験を得る機会を提供しているとも言えるので、若手が育ったり経験を積める希少なプロダクトという側面も見逃せないということでした。

WACATEのポジションペーパー

若手の育成機会の話から、テストの話(WACATE)に戻ってきました。

王はWACATEに2回参加したことがあるそうですが、その際にポジションペーパーで表彰されたということで、どういう経緯や狙いがあってポジションペーパーを毎回募集しているのかはなかなか気になるという話が挙がっていました。

ドメインモデリング研修

www.eventbrite.com

今日あったドメインモデリング研修の話をしていきました。

Joeが日本に来ることになり、そこで研修をやりたいという話が2週間前に来て、急遽やることになったのが研修の経緯だそうで、企画は品川アジャイルがやっていたということです。

準備に時間がなかったこともあり、全編英語(ただし資料は機械翻訳で日本語にした)だったそうですが、単語もそこまで難しいものが使われず、ワークショップの際にネイティブの人達とキャッチアップができたので、普通に研修についていくことができたということです。Joeもめちゃくちゃ優しくて、ワークショップのたびにたくさん褒めてくれたということでした。

研修の内容としては、ドメイン分析やイベントストーミングをした後に境界を見定めていく体験ができたり、Value Objectとはなにか?が点として説明されている本とは異なって一つの物語としてドメインモデリングにまつわる知識が増える体験ができたり、マイクロサービスをどのように切っていくのか?切る必要があるタイミングはどんなときか?が体験できたりして、最高だったそうです。

おまけに研修費用も10000円ということで、桁が1つ違う印象があったということでした。

BPがいるチームでの意思決定

BPの契約更新が印象で決まる場合、契約更新のマイナスになりそうな場合その人の経験や知見を隠してしまうことがあるという話をしていきました。

そのため、BPに意思決定をお願いしている場面を見ると危うさを感じるということです。

全体を通した感想

前回に引き続き真面目な話が多く、葛飾らしくない葛飾が続く回でした笑

ドメインモデリングの研修は話を聞いていると参加しなかったことを後悔するようなイベントで、次の機会があったら必ず参加しようと決意したのと同時に、やはり英語力は機会の獲得にめちゃくちゃ大切だなあというのを改めて実感しました。

ソフトウェアアーキテクチャメトリクス - Forkwell Library #44に参加してきた

forkwell.connpass.com

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

会の概要

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

第44回目では『ソフトウェアアーキテクチャメトリクス - アーキテクチャ品質を改善する10のアドバイス』を取り上げます。 本書では、アーキテクチャが目標にどれだけ合致しているかの計測、追跡すべき適切なメトリクスの選択、可観測性/テスト容易性/デプロイ可能性を向上させる方法、アーキテクチャに対する取り組みの優先順位付け、学びに満ちた適切なダッシュボードの構築などを解説しています。

今回は訳者の島田浩二氏をお招きし、書籍に登場するメトリクスやその背景にあるソフトウェアアーキテクチャやソフトウェア品質の考え方、計測をアーキテクチャ上の決定に活かす方法などを紹介しながら、ソフトウェアアーキテクチャメトリクスの基礎について解説していただきます。

会の様子

講演〜ソフトウェアアーキテクチャメトリクスの基礎〜

書籍概要

経験豊かな10人のアーキテクトが知っておきべきメトリクスをケーススタディとともにまとめた本で、2022年6月に原著が発売されたという話がありました。

ただし、本書はアーキテクトの今現在の関心事への取り組みが書かれている本であり、ソフトウェアアーキテクチャメトリクスというタイトルに惹かれすぎると、期待からずれてしまい失敗するということです。

本書の補助線1〜SQuBOK〜

ソフトウェアアーキテクチャメトリクスは品質の計測に関する本であり、品質マネジメントの知識体系であるSQuBOKの品質マネジメント(品質計画/品質保証/品質管理/品質改善)を知ったうえで本書を読むとよいという話がありました。

ソフトウェアアーキテクチャプロセスは品質マネジメントにあると島田さんは考えているそうで、プロセス品質/内部品質/外部品質/利用時の品質をそれぞれ保証するために計測と評価を行うのがメトリクスの役割であるという話がありました。

また、SQuBOKでは、定義された測定方法および測定尺度としてメトリクスは定義されており、製品やプロセスの品質を定量的に把握し、継続的に改善するために用いるもので測定することは目的でないと記載されているそうです。

本書の章自体も、全ての章に関して品質にまつわるトピックが書かれているということです。

本書の補助線2〜アジャイル品質パターン〜

QA2AQの文脈でアジャイル開発プロセスへの品質保証の考え方および活動の組み込みの核心となる活動や考え方をパターン形式でカタログ化したものがアジャイル品質パターン*1も本書の補助線になるという話がありました。

QA2AQはアーキテクトたちが継続的にアーキテクチャ改善していこうとしているプロセスと近しいものを島田さんは感じるということで、例えば「品質のインテグレート」パターンは進化的アーキテクチャや継続的アーキテクチャの実装と読むことができたり、「システム品質ダッシュボード」の話を実装したのが1章だと捉えたりすることもできるそうです。

他にも、プロダクト品質チャンピオンパターンはアーキテクトが果たす役割として捉えることもできるだろうということで、アーキテクトはQAに品質を任せきりにするのではなく、システムの品質保証や品質改善の取り組みを推進していることが重要だということでした。

Q&A

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

プライベートビルドの章があまり理解できなかったのだが、マイクロサービスでサービスが分離している場合、すべてのマイクロサービスをローカルでビルドし、追加機能に対して全てのサービスを通してローカルで動作確認する必要があるということか?

この章は2つ話がある。

1つ目は、CI/CDが正しいみたいな話はあるが、もしそれでプロセスのメトリクスが落ちるならそういうやり方に縛られずにプライベートビルドしようという話。

2つ目は、プロセス品質を計測するための実例。

機能要件も品質要件も不明確な状態でアーキテクチャ設計と品質設計をバラで進めるコツや並列で進めるコツは?

まずは機能要件と品質要件を明確にすることから初めたほうがよいのではないか?と思う。もちろん大体こんな感じかな?とアーキテクチャ設計はするが、機能要件と品質要件が不明確な状態でできることはたかがしれている。

多様なメトリクスから組織や案件に応じて柔軟に「何の手札を使うと妥当な品質判断ができるか?」を考えるのが難しいのだが、アドバイスはないか?

6章や10章は一つの回答になるのではないかと思う。

メトリクスはゴールありきなので、メトリクスが手札として多いけれどゴールが決められないと言うなら、経営層も巻き込んでゴールを決めていく必要がある。

ゴール&ストラテジ入門なども参考書籍としておすすめ。

品質チャンピオンを作り上げるためのアプローチは?

自分たちのプロダクトに対する品質ってみんな気になるんじゃないか?とまずは思う。プロセスが人を作ることを考えると、DevOpsの実践やSREに学ぶことが大切。エラーバジェットを考えるプロセスなどから考えられるとよりよい。

Clean Architectureの次に読む本としてソフトウェアアーキテクチャメトリクスはおすすめできるか?

これまで読んできた本がわからないのでなんとも言えないが、Clean Architectureとメトリクスは距離が遠い気はする。たくさん本を読んでほしい。

ソフトウェアアーキテクチャメトリクスは様々なトピックがあって面白かったが、具体的に何かアクションするというところに繋ぐことが難しかった。どこから始めるといいか?

1on1でならもっと話せそうだが、まずは自分たちが何を目指しているんだっけ?みたいなことを考えるところから始めてそこに向かってやるとよいかも。3章は今すぐにでも実践できそう。

メトリクスを収集しているが機能開発に追われて活用や改善ができていない。どうしたらいいか?

何かしらは変えていくところから入らないとメトリクス収集自体も負債になってしまうので、早めに何かしら改善をしないと、なぜ取っているんだっけ?という話になる。

管理職とのコミュニケーション不足とかもありえるかも知れない。

メトリクスのアラートに対して担保したい品質特性などを明記することでアラートの存在意義を明確にするアプローチを適応度関数の概念を基に実践しているのだが、適応度関数を初めから定義するのに良いアプローチがあれば知りたい

SLOスタックとかの事例などから考えることができるかもしれない。

本書はSREにもおすすめの内容か?

SREではない人や内部品質に抱えている問題を理解するためには使えるかもしれない。

一番翻訳が難しかった章はなにか?楽しかった章はなにか?

2章が難しく、ストーリー調である6章が楽しかった。

プロダクト品質チャンピオンってどのように取り組んでいるのか?(品質保証部門などが存在する組織を想定)

QA2AQなどが大切であるという世界観をわかって貰ったうえで、皆でプロダクト品質チャンピオンの各領域をサポートし合ったり、できそうな人がいるならその人が担うことになるのだと思う。

会全体を通した感想

書籍はざっと読んだのですが、たしかにメトリクスがたくさん紹介されている本だと思って手に取るとGapが大きそうだったので、今回の講演は本を買うか悩んでいる人にとっては非常によかったのかなあと思いました。

質問は普段以上に具体的な質問も多く、メトリクス関連でみなさんがいろいろな実践をされていたり関心を持っているんだなあということが想像できて面白かったです。(特に適応度関数の実践例は面白かったです)

*1:中核パターン/品質のアジャイルなあり方/品質の特定/品質の可視化で構成