アジャイルカフェ@オンライン 第62回に参加してきた
https://agile-studio.connpass.com/event/334991/
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
アジャイルコーチである木下さん天野さん一條さんのお三方が、アジャイル実践者からの質問に答えていくイベントです。
今回は、「アジャイルな考え方をチームに定着させるには？」でした。
会の様子
アジャイルな考え方とは？
アジャイルソフトウェア開発宣言の考え方が実践できていればベースとしては良いと思いつつも、もう少しこれよりは具体的な行動みたいなところがあってそれを抽象化することで「アジャイルな考え方」が定義できてくるという話がありました。
例えば、包括的なドキュメントを書くことを一旦やめるという決定をすることで、「完璧なものを最初から作っていくのは難しい」という考え方が生まれてくるだろうということです。
定着しないと何が嬉しいのか？
アジャイルな考え方が定着しないと、進捗報告が乱発してしまい開発者のモチベーションが下がり、継続的にパフォーマンスを出すことが難しくなるという話がありました。
定着すると何が嬉しいのか？
アジャイルな考え方が定着すると、自分ごととして仕事を捉えることができるという話がありました。
定着のさせ方
まずはOSをupdateしないとソフトウェアが載らないと同じように、まず工業社会から知識社会への考え方の変化をさせることが重要だということでした。
ただし、開発の仕方(インクリメントに作るのかどうか)のようなところはすぐに変えられる一方でOSのupdateは大変なので、一時的にやり方だけ変えてみて、OSのupdateが必要なことを認知してもらうようなことが重要なのではないか？ということです。
具体的な取り組みとしては、Fail Fastをしてみるように取り組んでもらったり"効率"が悪いじゃんとならないようにソフトウェア開発をしてもらうようにするということです。
会全体を通した感想
今回はアジャイルコーチ同士の会話の中でも、お互いの理解をどうすり合わせていくのか？という点で学びがあってよかったです。
また、木下さんのメタファーの使い方は背後にある前提を明確にするという意味で本当に使い方が上手だなあと思いました。
また、途中で2層でアジャイル開発を説明する時間があったのですが、内容はわかった一方で話の流れ的にどう繋がっているのかだけがちょっとわかりませんでした。
データ民主化の現在地〜「誰もがアクセスできる」のその次へ〜に参加してきた
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
会の様子
ばんくしさんのLT
最初にばんくしさんからLTがありました。
ばんくしさんが所属しているエムスリーでは、コロナの患者推計などを行っているそうで、データエンジニアの人たちは利益貢献や事業価値の高いデータ基盤を社内外に提供できるようにしているということです。
なぜこのような考え方を持っているかというと、データが扱えるのみならず利用が促されてデータ基盤構築に参加してもらえるような状態を理想が前提にあるということでした。
この理想に到達するためには、優れたデータ基盤やBIツールの仕組みが必要だと考えているそうで、その仕組みを実現するデータ関連チームやエンジニアといったユーザ意識が重要であり更に言えばそのユーザー意識を支える売上やデータ市場が必要だと考えているそうです。
土川さんのLT
続いて土川さんからのLTがありました。
土川さんは社内の誰もがデータにアクセスして理解し活用できる環境を構築できることがデータの民主化だと捉えているそうで、社員の従業員数が一気に増えた中でどのようにデータ活用に関して考えていったのかの変遷に関して紹介がありました。
初期はRedashやLooker StudioによるBIツールを整備しながらSQLを皆がかけるようにすることで徐々にデータ活用のハードルを下げていったそうです。
そんな中で中期になり、社内誰もがSQLを書けるようにするというよりはデータをもとに素早く意思決定できるかのほうが重要だと思いだしたそうで、Lookerを導入して指標統一をしてLooker活用人材を目指したということでした。
こうした取り組みは成果を上げた一方ユースケースが爆発的に増えてしまい、最近はデータ生成者やデータ利用者が一緒にデータ民主化を目指すようになったそうです。
パネルディスカッションとQ&A
登壇の後はパネルディスカッションがありました。以下、テーマと回答を一問一答形式かつ常体で記載していきます。
データ民主化の理想形態は？
- ビジネスは大体ないデータが価値を生むことが多いので、データがほしいと思ったら生み出せるような状態になることが理想的である
- 社内データチームを介さずともデータが使えるようになること
LLMがデータを内包してくのではないかと思っているのだが、各社その世界に向けてやっていることはあるのか？
- ユニークなデータを作ること
- アウトプットの自動化をしていくためには使えるがアウトプットの信憑性が薄いというのが原因であんまり上手く使えていない
- 計算リソースが足りていなさすぎる
データ民主化を進める時によくある失敗と対策
- 社員の人数が多くなってユースケースが増えてしまい、取り組みをしようと思うと影響範囲が大きすぎてなかなか取り組みが進まない。そのため、ミニマムに実験しながら取り組むようにしている
- このデータがあればこういうことができそうだ、が先行してしまい、そのデータをどうやったら使えるのか？みたいなのがわからなくなってしまう
組織が増えていくことで変わったことと変わらなかったこと
- データを使う文化というのは変わらなかった
- みんながデータに対して意識を持ち続けていること
- グループ会社が増えてくるとデータに関する要件がどんどん増えていった。そのため、仕組みやデータのパターンを作るようにしていった
データ関係者以外がデータを発見できるようにするために担当レベルのデータエンジニアができることがあれば教えてほしい
- データの活用方法を学んできた人とかはいないので、データ活用事例をたくさん知ってもらうようにすることが重要だと思う
- 社内のデータ活用事例をリーダーが積極的に進める
Timeeではデータを具体的にどのように使っているのか？
- ヘルスケアやダッシュボードを見ているし、優先順位付けにも使っている
ユーザー側のデータも営業は分析しているのか？見られるデータが多すぎると情報過多になってしまう
- 与え過ぎはよくないというのはそのとおりだが、一応営業がユーザーのデータも見ている
会全体を通した感想
かなりの大人数の方がデータを使い、データの種類やユースケースとしても相当多い状況でどう活用していくのか？という話が聞けたのは特によかったなと思いました。
LLM登場の話もありましたが、データの利用者という観点でもデータはどんどん増えていくんだろうなあという予感が強まるイベントでした。
スクラム祭りの打ち合わせ(12回目)をしてきた
こちらの打ち合わせをしてきたので、会の様子と感想を書いていこうと思います。
今回はインタビュー計画を主に立てていきました。
インタビュー候補決め
各地のスクラムフェスやRSGTのスポンサー事情を見て、趣意書を実際に見てもらいながらスポンサーする価値があるのか？をインタビューしたい候補を決めていきました。
さすがに具体的な企業名の記載はしないでおこうと思いますが、
- すべてのスクラムフェスにスポンサーしているというわけではない
- 地域スクラムフェスやRSGTの半分程度スポンサーしている
- 思いついたらスポンサーするというよりは何らかの基準を持っていそう
- 企業の社員の方に、気軽な雑談の一環として話が聞けるくらいの関係性がある
という基準でいくつかインタビュー候補を決めました。
HP作成
前回までできていなかったスクラムフェス祭りのHP作成をしていきました。
公開できる必要最低限の情報を入れただけでまだ色々と直すところがあるのでブログでアナウンスするのはやめておきますが、次回あたりには公開できるようになっているのかな？と思います。
値段がそこそこ上がっていたのと、オブジェクトのグループ化の仕組みが今ひとつよくわからないところで苦戦しましたが、川口さんのおかげもあって、一時間弱(金沢のときの半分)くらいの時間で公開まで持っていくことができたので、良かったです。
大人のソフトウェアテスト雑談会 #238【ギャンブル】に参加してきた
今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。(途中30分くらい抜けていました)
おおひらさんのイベントのふりかえり
昨日のイベントのふりかえりをしていきました。
個人的にはおおひらさんが、「このくらいのテストをすれば運用でやっていけますよね」「これくらいテストすれば十分ですよね」という話をしていたところで、何かしらの定量的な指標や具体的な根拠を示す方向ではなく「ちょうどいい」といった定性的なものがあればなんで十分だと思えたのか？というのが気になったいたのでそのことを質問しました。
おおひらさん的には、エンジニアへのリスペクトがあることやビジネス部門と距離が近く自分たちが持っている感覚が間違っていないことの自信が生まれやすいことが前提としてあって、それが故に「これくらいでいいですよね？」が確認できているというのが大きいということで、さすがおおひらさんだなあというのを実感しました。
カバレッジ
カバレッジは品質保証をしないという話から、広義でいうカバレッジは品質保証をする(業務のユースケースを洗い出してそこから何%くらいのテストができているのかを説明する)し、テストの基本はカバレッジだという話が出ていました。
ただしコードカバレッジのようなものだったり、数値遊びのような形で使われてしまう可能性があるテストカバレッジ(C1カバレッジ...)に関しては意味がないよねという話がありました。
自動車トーク
葛飾は自動車好きが多いため、コアな自動車トークが行われていました。肝心の内容はよくわかっていないのですが笑、久しぶりに参加されていたMarkさんが元気そうだったのが何より印象的でした。
QAのパネルディスカッション記事
Markさんが登壇した記事が公開されたという話を聞いていきました。
エンジニアの2%しかQAエンジニアがいないという情報がさらっと公開されていて、これはどこ調べなのだろうか？第三者検証機関を考えるとどう考えても2%は超えているんじゃないのか？という話で盛り上がっていました。
全体を通した感想
前半に久々にテスト要素があふれる話が展開されていて満足でした。
自動車と漫画は葛飾区民を名乗るなら分かっていないといけないんだな、というのを実感する会でした。
QA engineer at a Startup vol.1 おおひら編に参加してきた
qaengineeratastartup.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(仕事の関係で前半のおおひらさん講演部分は聞けていません...)
会の概要
おおひらさんの経験ベースで、スタートアップの現場で働くQAエンジニアが普段どういうテストをしているのか？という話を聞いていくイベントです。
会の様子
冒頭で書いた通り講演部分は参加ができなかったので、講演後にあったパネルディスカッションとQ&Aの様子に関して、テーマごとに質問と回答を常体で記載していきます。
テストで理解度を上げるというのは誰の理解度を上げるイメージを持っているか？
テスト設計ツール自体がコミュニケーションツールになっている側面があるため、具体例をもって、チームやQAエンジニア(自分自身)の理解度を上げていくことをしようとしている。
チームみんなでテストをやっているという話だが、テスト設計や実装はどういう役割分担をしているのか？
明確な役割分担はしていない。
一応テスターなのでおおひらさんはテスト分析がチョットできると思っているため、テンプレートを作ったりはするのだが、テスト設計自体はQAエンジニア以外のエンジニアも含めて全員でやっている。
また、みんなでやりやすいようになるべく小さい単位でソフトウェアを扱うようにしているように工夫している。
最初からできていたわけではないが、おおひらさんが少しずつテストを先に実施するようにしてからエンジニアの人たちもその効果を実感するようになり、今のような状況に至った。
新規事業ということもあり、みんなで成功していくぞという一体感があり、コミュニケーションを取るハードルはすごく低い(基本的には対面でコミュニケーションを取っているしリモートのときもGatherで常に集まっている)ので、こういったことが実現できているのだと思っている。
小さい単位とはどれくらいの単位になるのか？
もちろん厳密にいえばそうではないときもあるのだが、スプリントをまたがないくらいの単位でやっている。
テスト分析・設計はどれくらいの時間で終わらせているのか？
ハイレベルなテストケースを作るまで大体2時間くらい。
プロダクトの〇〇フェーズだと〇〇のテストを重視したほうが良いというパターンのようなものはあるのか？
性能系のテストは顧客の数によってだいぶ絞りやすいなと思っている。
あとはエラー系のテストをどこまでするのか？みたいな話もかなり絞りやすいと考えている。
全体的に定性的な話にはなってしまうが、会話の中で「このくらいですよね」を常に探っている。
テスト以外で気にしているコミュニケーションはあるか？
みんな元気かな？は気にするようにしている。あと、「これ大変そうだな...」みたいな空気や場の雰囲気、リアクションみたいなものは気にしていると思う。
また、スクラムにとっていい振る舞いか？は大切にしているが、スクラムマスターというほどチームにフォーカスしているかというとそんなことはない。
ソフトウェア開発で起こる問題は多くの場合認識の不和が原因なことが多いとおおひらさんがキャリアを積んでいく中で考えているので、ちょっとしたコミュニケーションを取るだけで全然改善するならそれはROIが高いなと思ってこうしたことに気をつけて取り組んでいる。
リリースノートやマニュアルを作っておきた変化はなにか？
ビジネス部門から多くの質問が仕様に関して来るようになった。
リファインメント段階からビジネス部門の人にはもちろん入ってもらっているのだが、リリースノートのタイミングで質問が来るようなケースも多々増えてきて、そういったところは良いなと思っている。
また、おおひらさん自体が安心感を持ってリリースに向かえるようになった。
会全体を通した感想
おおひらさんが日常的にどのようなことに気をつけてQAとしての活動をしているのか？というのがたくさん聞けて楽しかったです。
コミュニケーションやチームの変化に気を配りながらも、品質に目を向けるんだからあくまでもテスターでスクラムマスターではないよと言っているあたりにおおひらさんの生き様が現れていて良いなと思いました。
マスタリングAPIアーキテクチャ - Forkwell Library#72に参加してきた
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
この10年の間に、ソフトウェア開発を行う方法は大きく変容しました。
作業に依存関係が生じるモノリシックなアーキテクチャから、APIによるマイクロサービスアーキテクチャが主役となりつつあります。
この本はモダンなAPI駆動型アーキテクチャについて解説する書籍で、REST APIの基礎から、最適な設計、構築、運用、バージョン管理、およびテスト方法など実践的な方法を交えて学ぶことができる1冊となっています。 今回は訳者の石川朝久氏に本書のポイントについてお話していただきます。
会の様子
書籍の概要
架空のカンファレンスシステムを例に、オンプレシステムの一部APIを移行していく様子を記述しているアーキテクチャの進化や改善手法がわかる書籍だということでした。
イントロダクション
実はかなり重要な章だということで、
- C4 Model
- カンファレンスシステムの概要
- ADR
の3つが記載されており、書籍の全体像がわかる章になっているということでした。
ただし、アーキテクチャの推移だけにフォーカスしたい場合は10章から読んだほうがよいということです。
第一部
APIやテストに関する基礎的な知識が整理されているということで、APIを設計するにあたって必要不可欠な知識やテストが記載されているそうです。
第二部
本書籍は一部モジュールをAPIに移行するという話であるため、APIゲートウェイとサービスメッシュそれぞれでトラフィックごと(外部トラフィック/内部トラフィック)に考慮すべきことを説明しているということです。
第三部
APIは継続的にリリースをしていくという前提にたった時に必要な知識を一通り説明した後に、セキュリティ運用の話として脅威モデリングやAPIの認証認可周りの話が記載されているということでした。
第四部
アプリケーションレベルやインフラレベルで、アプリケーションを再設計するためにどのようなことが必要なのか？という話がされているということです。
具体的には、3種類の基本的な概念(結合、凝集、情報隠蔽)だったり、6Rを利用したクラウドへの環境移行が検討されているということでした。
本書の特徴
本書は、APIのアーキテクチャ設計が体系的に学べる書籍であり、実例を通してアーキテクトの思考方式を学べる点が特徴の一つとして挙げられるということでした。
また、モノリスからの移行技法が学べるというのも本書の特徴の一つだということです。
アーキテクトの役割
アーキテクトは、
- システム全体の構造や設計を定義する
- 技術的なガバナンスと標準の確立
- 技術選定と評価
- セキュリティとリスク管理
- コミュニケーションと調整
- 技術的な問題解決とサポート
が仕事の一つとしてありますが、本書ではこれらの話がすべて抑えられているため、アーキテクトに必要な業務が一通り丁寧に書かれているのが良いポイントだという話がありました。
Q&A
講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
石川さんがアーキテクトとして働くうえで気をつけていることはなにか？
色々な分野に興味を持つことは大切にしている。また、判断できることとできないことをはっきり認知しておくことや追加情報を取る術を持っておくこと。
また、どういう点に気をつけているのかどういうことに注意しているのかといった意思決定の記録をドキュメントに残しておくようにしている。
マイクロサービス界隈ではシステム間接続のインターフェース不整合に対する定石はあるか？
定石と言えるかはわからないが、テストに力点を置く。スキーマ定義に基づく静的型付けチェックなどもする。
どういうきっかけで翻訳を始めたのか？
企画を持ち込むようにしている。
一からプロダクトを立ち上げるために必要な技法は本書にのっているのか？
機能要件から必要なAPIを抽出するという話は載っていないのだが、リソース名の名付け方などは少し書いてある。
コントラクトテストとは、Pactなどのツールを利用して開発字からAPIの利用者・開発者が比較的密な状態で行うという理解で良いか？
そんなイメージ。ただし、APIの利用者と開発者が密にやり取りできるかというとそんなことはないので、変更の主導権を持っている人たちに対してどうしていくか？という話になると思う。
Actorモデルのような設計もAPIアーキテクチャで取り扱われているか？
書籍には書かれていない。石川さん個人としても、そんなに見たことはない。
認証認可サービスとそれ以外の連携方法がなかなか難しいテーマだと思うが、実践的な例が欲しい
本書では少しだけ扱っているが、どちらかというと理論寄りの記載になっている。
会全体を通した感想
書籍が出た時にタイトルと目次だけ見てなんとなく気にはなっていたのですが、想像していたよりも広範囲のテーマを扱っているというのが分かったので良かったです。
リアルなシステムに近い実例が取り上げられながらも理論的な説明も多くあるということだったので、一度で読み切るというよりは状況に応じて見直す前提で読んでみようと思いました。
freee × ラクス プロダクトマネジメントに向いてる人はどんな人？現役PdMに聞いてみよう！に参加してきた
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
プロジェクトマネージャーはビジネスと技術の両方の知識が必要なプロダクトにとってとても重要な役割です。
業務アプリケーションを提供している株式会社ラクス (以下、ラクス) とフリー株式会社 (以下、freee)。その両社のプロダクトマネージャーは、複雑なドメインが絡み合う中で「プロダクトの司令塔」としてプロダクトの成長を引っ張っていく存在である必要があります。
そんなプロダクトマネージャーにはどんな人がいるのかについてラクスと freee の 2 社を例にお話します。また実際にラクスと freee でプロダクトマネージャーとして働く人のバックグラウンドや今後のキャリアについても触れていきます。
会の様子
話の前提
PdMと一口に言っても様々な役割があるため、各社においてPdMがどういう役割を担っているのか？という話を聞いていきました。
ラクスさん
Deliveryにも足を踏み入れつつ、主軸としてはDiscoveryの領域(ペルソナ定義や市場分析や競合分析...)に主軸をおいていると良いことでした。
また、プロダクトにあまり変化を加えたくないがゆえに開発手法はWFを選択しているということで、最上流工程を担っているということです。
freeeさん
ビジネス、デザイン、テクノロジーを理解して、プロダクトのビジョン設計をもとに色々な人を巻き込みながら解決策や優先順位付けを行う職種だということでした。
基本的には色々なことをやるということで、将来像定義やOKR、ロードマップ作成、調査や分析、要件定義、開発、品質保証、インパクト検証...といったことをやられているそうです。
PdMになる前には何をしていたのか？
今回のイベントはパネルディスカッションがメインコンテンツだったので、色々なテーマで紀井さん、山口さん、mihoiさん、しんちゃんさんが議論をしていきました。
最初はPdMになる前にどういう仕事をしていてどういう経緯でPdMになるのか？というテーマでした。以下、それぞれの回答を箇条書きかつ常体で記載していきます。
- コンサル的な仕事としてPMなどをやっていたが、事業として結局何をやるのか？を決められるのは一般的なコンサルじゃ無理だな、と思ったのでPdMになった
- エンジニアだったが、技術を極めるのに向いていないなと思ったのでPdMになった
- 色々仕事をしていたらやっているのがほぼPdMじゃん！という話になり、PdMになった
プロダクトの機能追加や廃止はPdMが最終決定するものなのか？
- 顧客の課題から考えて提案をするのはPdMだが、最終意思決定は事業部の責任者
- 最終決定する
(freeeで)PdMとPMMはなぜ分かれていないのか？
- 組織が結構な頻度で変わるが一時期は分かれていたこともあった。今は、PdMがそれなりの人数いるので、分かれていないんじゃないか？と思う
エンジニア出身だとコードを書けなくなることにもどかしさはないのか？
- エンジニアリングを深めたいタイプではないのでもどかしさはないが、ソースコードは読める
- 特に抵抗はない。ソースコード読むし分析でコード書いたりとかもする
- 思ったことはないのだが、もどかしさを感じる人なら向いていないと思う
PdMに向いている人は？
- 80点を早く取れること
- 相手の気持ちを考えられて、コミュニケーションを上手に取れること
- パッションがありそれを相手に伝えられるだけの言語化があること
- 人を巻き込めるところ
- なぜ？が自然に考えられて、考えるのが楽しめること
会全体を通した感想
想像以上にゆるめの座談会的な感じだったので、そのあたりはスタンスが出ていて良かったなと思いました。
PdMと一口に言ってもやることも全然違いますし思想や特徴も違うんだなあということがよく分かるイベントでした。
