天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

大人のソフトウェアテスト雑談会 #151【ワンダーフォーゲル】に参加してきた

ost-zatu.connpass.com

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

Mark Radio

今日は祝日だったこともあって人数が少なかったこともあり、MarkさんのRadio話を聞いていきました。(上柳昌彦さんの話のうまさに触発されてラジオトークを開催してくれました)

  • スクフェス新潟で英語のプロポーザルを書いた理由(Markさんが35歳という節目を迎えたことでこれからの人生を考えたいと思ったときにこれまで海外カンファレンスで英語の発信をしていないことに後悔していたのでその過程としてスクフェス新潟を一つ活用したいと思った + 元々学生の時から世界史が好きだったこともあって自身が世界人だという認識を持っていた)
  • 割れ窓理論の話をなぜするか?(トピックとしてホットではないものの、犯罪心理学で研究されていて他分野にも多く応用されている話だし、英語だと学術的な研究もそれなりに進んでおり、品質という観点でも発見が多くある。ISO9001でも同じことを言っていた)
  • Markさんが昔放送部に所属してラジオパーソナリティを目指していた話
  • トラックライバーとラジオの親和性

特にMarkさんのプロポーザルはとても気になったので、ぜひ聞いてみたいです!

confengine.com

フリートーク

おおひらさんがフリートークをする際に、話をするヒントを拾ったり目に入ったものを口に出したりしながら周りの雰囲気を読んで話をしているということを聞いていきました。

ISO9001

ISO 9001で品質を分類しているという話として、プロセスの品質、人間の品質、プロダクトの品質といった分類の話を聞いていきました。

森さんの四季

森さんは常に引きこもっていることもあって、四季をそんなに感じないし、そのおかげで服を選ばなくて良いのがすごく楽だというお話をしていました。

関東の物件事情

関東の物件事情の話を色々としていきました。

全体を通した感想

Markさんラジオから始まった濃い会でした。

祝日で最初は人数が少なかったですが、徐々に人数が増えているのも面白かったです笑

JaSST nano vol.22に参加してきた

jasst-nano.connpass.com

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

会の様子

“品質”をみんなのものにするために行なっている入社者オンボーディングについて by miisanさん

まずはmiisanさんから、令和トラベルさんでやっているオンボーディング(全社関連のオンボーディング、)に関して紹介がありました。以下、やられているオンボーディングの内容を紹介します。

  • 全社関連のオンボーディング(Slackのワークフローにて整理がなされていて、雇用形態に合わせてワークフローをこなす形で完了できるような工夫を取り入れている)
  • 各部署のオンボーディング(部門を知るためのインプットやドメイン知識を知るための講座が用意されている)
  • 担当部署のオンボーディング(プロダクトや仕様のキャッチアップの他、日次で1on1を実施して個別の困りごとを解決する)

また、非QAエンジニア向けにもQAオンボーディングを実施しているということで、これには以下のような理由があるそうです。

  • IT未経験のエンジニアもいるため、QAという言葉自体に馴染みがない人がいるため
  • 品質づくりをチーム戦で行えるようにするため(品質に関するものは全部)
  • 品質とは答えがない定性的なものなので、QAチームだけではなく全員で一緒に考えていくようにするため

このQAオンボーディングでは、

  • "品質保証"とはどういう人か?
  • QAエンジニアとして大切にしていること
  • この会社における当たり前品質/魅力的品質とはなにか?
  • 品質が重要な理由
  • トレードオフを突きつけられた時の考え方
  • 品質指標の共有

などをしているそうで、プロダクトチーム全体で品質に対するマインドセットが向上していることや、QAがプロダクトチームと交流できるといった結果も出ているそうです。

ユニットテストの品質改善周りについて  よけいさん

次によけいさんから、1ヶ月でテストコードを15,000行リファクタリングした話を聞いていきました。

リファクタリングの背景には、

  • 元々のテストコードが読みづらく仕様がわからない
  • 開発生産性の停滞
  • 質とスピードのトレードオフが発生

があったそうで、妥当性/十分性/可読性の3つをポイントにして、テスト実行時間/テスト成功率/信頼できるテスト比率*1/定性指標をメトリクス*2にしながら、40%くらいのテストコードをリファクタリングしたということでした。

テストコード改善の際には、hotspot値分析をかけた後にブラックボックス的な観点でテストコードの十分性/妥当性を確認し、最後にホワイトボックス的な観点でテストコード改善をしたということで、改善をしていく過程で以下のような点を課題として感じたそうです。

  • テストツリーのContextとitの抽象度が揃っていない
  • 不要なテストが多い
  • 定義されている変数がテスト対象から離れている

gTAAってなんなの?  やまずんさん

続いてやまずんさんから、gTAAに関する話がありました。

gTAAは、generic test automation architectureの略で、JSTQBシラバスでは以下のような定義がされているということです。

gTAAは、gTAAのレイヤー、コンポーネント、インターフェースを表す。これらは特定のTAS向けのTAAとして具体 化される。これにより、構造化されたモジュール形式のアプローチを利用して、以下の方法でテスト自動化ソリューションを構築できるようになる。

• 内部および外部で開発したコンポーネントによってTASを具体化できるように、TASのコンセプト、レイ ヤー、サービス、インターフェースを定義する

• シンプルなコンポーネントを利用して効果的かつ効率的なテスト自動化を行えるようにする

• 各種ソフトウェアの製品ラインや製品ファミリー、およびソフトウェア技術やツールが異なるものを含め、 別のTASの開発やTASの改良の際 にテスト自動化コンポーネントを再利用する

• TASの保守や改良を容易にする

• TASユーザー用の基本的なフィーチャーを定義する

やまずんさんとしては、gTAAは下レイヤーから理解をしていくのがよいのではないかと考えているそうで、レイヤーごとに以下のような具体的なツールをイメージしているそうです。*3

  • テスト適合レイヤー...selenium
  • テスト実行レイヤー...Junit5, Jenkins等
  • テスト定義レイヤー...キーワード駆動とかのスプレッドシート, CucumberなどのBDDツール等*4
  • テスト生成レイヤー...エッグプラント, GIHOZ, ChatGPT等

また、テスト自動化の世代からgTAAを考えてみると、世代が進むにつれて柔軟なTAA, TASが多くなっているなっているとも言えそうかもしれないという話も出ていました。

色々話したものの、謎が深い点*5もまだまだ多いそうで、是非フィードバックがほしいということでした。

エンジニア参加の実験や商用開発のケーススタディで欠陥やバグについてわかったことと今後の実験    森崎さん

最後に森崎さんの発表を聞いていきました。

まず、実現手段依存の欠陥について説明がありました。
実現手段依存の欠陥とは、仕様レビュー時には気が付かないが仕様確定後の決定で仕様が曖昧となってしまうコンテキスト依存な欠陥のことで、例えば「ファイルに出力するデータは改行で区切る」という仕様があった時、Unixで書き込んでWindowsで読み出すコンテキストでは欠陥が見つかるような欠陥を指すということです。
このような欠陥はシステムの主要な目的に着目してゴール指向要求分析を実施するのが効率的だということでした。

次に、PRレビュー戦略の調査の説明がありました。
この調査では、116名の技術者に振る舞いを変えるPR/振る舞いを変えないPRをレビュー計8つしてもらい、全部のレビューが完了した人の戦略を調査したそうで、以下4戦略を取っているという結果が得られたということでした。

  • タスクの内容から既存コード、変更コードの特定部分を確認
  • 既存コード、変更コードをざっと確認
  • データの参照、更新部分や実行順序等の依存関係をたどって確認
  • 変更部分のみを確認

同時に、所要時間がかかっているPRの調査もしたそうで、参照している/されている変数の数が多いほど読解時間をかけていることなどもわかったそうです。

以上の研究結果から、以下の2点が結論として導かれるということでした。*6

  • 自分たちのコンテキストで未然に防止できているような欠陥、検出できている欠陥を把握すると効率的になる
  • 検出できていない欠陥を把握すると検出できるようになる可能性が高い

会全体を通した感想

久しぶりの参加でしたが、濃密なプレゼンが多く楽しかったです。

いろいろな系統の発表が多かったですし、久しぶりにお話を聞く方もいらっしゃって、充実した時間を過ごすことができました。

*1:品質保証の観点でテストが正しくされている割合、hotspot値

*2:gilotで可視化

*3:ただし合っているかはわからないのでフィードバックがほしい

*4:テストスクリプトそのものも含まれる?

*5:出典が不明、マネジメントとの関係性が不明、テスト自動化フレームワークとの関係性は?、流行りのSaaSテスト自動化ツールはどこ?我々はどうやってTAAにしていくのか?、そもそもgTAAは使う?TAA設計する人っている?

*6:発表では冒頭にこの結論が示されていました

Agile PBL祭りに参加してきた

agilepbl.org

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

Opening

伊藤さんから簡単に今日の会の趣旨説明やスポンサー紹介、会の流れやグランドルールなどの説明がありました。

Jyozawa Shunsuke / Kondo Atsushi / NAKANO Eito / SOTOZAKI Kensuke / SUZUKI Mizuho - 騒がしい5人のスクラム生活~「はこレクト」作ってみた~

confengine.com

チーム開発未経験の3人がどのようにして初めてのチーム開発を行っていったのか?という話を聞いていきました。まずは、

  • SCRUM BOOT CAMP THE BOOKを読んでスクラムの知識習得
  • SMの中野さんによるスクラム説明会
  • 1週間スプリントを回してみる
  • 平日22時にデイリースクラム実施(技術的な進捗に加えて)

といった取り組みを行ってスクラムの知識を底上げしたりスクラムに慣れたということです。
また、開発の中で、議事録を丁寧に書いたり、会話脱線防止係をおいたりといった工夫が挙げられていて、わいわい騒がしいチームの特性に合わせた工夫もされたということでした。

未経験で理解が浅いスクラムに苦戦したり共通認識のブレが頻発したりといった点には苦しんだものの、プロダクトのアップデートがインクリメンタルにされていく様子を見れたり、新しい技術に触れられたりチームで仲良く開発ができたりと、楽しい開発ができたというのは素晴らしいことだなあと思いました。

enPiT修了生の日常の仮説検証〜研修・業務でチャットを活用したら信頼と繋がりを得た話〜

confengine.com

続いてKatsuyaさんからPBLで学んだことを社会人一年目の現場でどのように活かしたのか?という話を聞いていきました。

enPiTでは、

  • 問題解決に対する姿勢(=困りごとから考える)
  • ふりかえりをする
  • メンタリング
  • テキストコミュニケーション

といったように様々なことを学ぶとともにKatsuyaさんはスクラムが大好きになったそうです。

もちろん現場でもこの経験は活かされたそうで、特に問題解決をする際に困りごとから考える姿勢は研修の際に役に立ったということでした。

具体的な例としては、新人研修で質問チャンネルがあるけれどなかなかそのチャンネルで話が聞けないという困りごとにフォーカスするために実況チャンネルを勝手に作ってみたエピソードを挙げてくれました。(この作ったチャンネルはフィードバック+ふりかえりをもとに改善を繰り返して最終的には研修で表彰されるまでになったそうです)

発表が上手で、会場も盛り上がった発表でした。

推し活カレンダー/All-about-your -faves-Calendar

confengine.com

続いて、こちらの発表を聞いていきました。

最初に、めちゃくちゃ具体的なペルソナを設定したそうで、その上でユーザーリサーチを実施し、処理フローを整理して開発を実施したそうです。(開発はMySQLの参照問題などに苦しんだものの最低限の機能開発はできたということでした)

アジャイル開発ではデイリースクラムミーティングをできる限り実施したり*11週間ごとに進捗報告をしたりチームの得意分野に合わせてタスク分担したりといった点を工夫しながら進め、最初は微妙な距離感があったチームも最終的にはいい意味で遠慮がなく1限に間に合うチームになったということでした。

デザイン力がめちゃくちゃ高いプレゼンで、過去に自分が経験したことのないプレゼン体験でした。

悔しすぎて授業が終わった後成果を出したチームの発表

confengine.com

続いて、enPiTの発表会では表彰されなかったことが悔しくて授業が終わった後も開発をやり続けた結果外部企業の成果発表会で賞をもらったチームの話を聞いていきました。

最初に、成果発表会で賞をもらったAI Speculation Quizの簡単な紹介を見せてもらいました。(めちゃくちゃ発想力が豊かなプロダクトで、ぜひ触ってみたいと思えるプロダクトでした)

その上で、このような成果を出せた理由として、

  • 基本を抑えた上で工夫する(アジャイルソフトウェア開発宣言の価値観をまずは意識しながら、ふりかえりの中で適宜使えそうなものを取り入れていく)
  • 価値を追求するなら0からやることを躊躇しない(途中で競合アプリが出てきた際、1から作り直しをすることを決定した)
  • 粘っていればいいことがあると考えていた

を挙げてくれました。

パッション溢れる発表から突き通す力を感じて、すごく楽しい発表でした。

デモ展示

続いて、ここまで発表された方々を中心にデモ展示が行われました。

ただ、デモスペースが大盛況でデモを見るスペースが乏しかったことと、スポンサーセッションのスライド準備を急遽していたこともあり、デモを見ることはできませんでした。

その代わり、けんちゃんを拝んでいたり村上さんやkiroさんやまつしゅーさんやゆーじさんや47機関メンバーと雑談をしたり、リアルKatsuyaさんに初めてお逢いしたりしていました。

ランチ

豪華な(?)ランチを食べていきました。

一応ランチスポンサーですが、手配は全部きょんさんがしてくれていたので、自分は何もせずただご飯を食べているだけの人でした笑

ランチ中は、主に47機関メンバーとChatGPTや週末の話などを雑談していきました。

スポンサーセッション〜株式会社エイチーム

スクラム開発を導入して得られたもの」*2というタイトルで、株式会社エイチームさんの発表を聞いていきました。

スポンサーセッションといいつつも会社紹介はそこそこに、実際に会社でスクラムを実践している様子を(スクラムイベントを中心にしながら)エイチームさんが抱えている引越し侍というプロダクトの刷新プロジェクトを例に説明してくれました。

スクラムを導入したことで、

  • プロダクトの状況を全員が把握できるようになったことで、ステークホルダーがチームの状況を知ることができ、無理難題をふってこなくなった
  • 自己管理的な組織ができたことで、マネージャーがチームの改善を行っていたのがチーム全員で改善する方向に変わった

というメリットが発生したという話や、スクラムを導入したことで出てきた課題の話などを素直に話してくれているのが素敵でしたし、一緒に学ぼうという姿勢を常に打ち出しながら発表されていたのも非常に好感が持てる発表でした。

スポンサーセッション〜デロイト トーマツ コンサルティング合同会社

話してきました。

計画通り1時間前に準備を終え、計画通りぶっつけ本番で突っ込んだので、計画通りの出来に落ち着きました。

地味に(?)47機関メンバーが対外的に話しているのはレアなので、勝手に興奮していました。

発言をすべて可視化したらわいわい開発できた件

confengine.com

続いて、RSGTやスクフェスですっかりおなじみになったうきうきなっとうさんから話を聞いていきました。

発表では、琉球AgileMiniCampで発明した

  • おーててつないでさあわたろ
  • このゆびとーまれ

の2つのフレームワークの話を中心にしてくれました。

おーててつないでさあわたろは、同じことを同じタイミングで実施する際に活用するフレームワークで、付箋量を増やすためのKPTでの活用事例を説明してくれました。
このゆびとーまれは、違うことを違うタイミングで行う際に使用したフレームワークで、タスク分担の際に活用した事例を話してくました。

うきうきなっとうの方々の発表はRSGTでもスクフェス福岡でも聞いていますが、今回は10分バージョンにも関わらず発表の練度が上がっている様子を見られて、すごくよかったです。

琉球大学のDX化(RX)やってみよう!

confengine.com

続いて、沖縄から海を超えてやってきたチームの発表として、入構許可証発行手続きをペーパーレス化するプロダクトをアジャイル開発で実践した体験談を聞いていきました。

アジャイル開発初実践ということもあって、

  • 初めて使うツールなので機能を実装するまでに遠回りしてしまう
  • 依頼者と開発者の認識齟齬発生
  • データ損失

といった課題が出てきたそうですが、チーム全員でいかに協力するのか?という点にフォーカスし、

  • 関わる相手を知る活動を増やす
  • 何を何のための目的で実施しているのか?を都度確認する
  • バックログなどを活用した状況可視化

などの工夫を行っていったということです。

落ち着いた発表の中でも確実な前進や前に進む勢いを感じる内容で、素晴らしかったです。

筑波大生のための匿名掲示板「A+つくば」をアジャイル開発し、現在も運用している話

confengine.com

続いて、enPiTの中で開発した匿名掲示*3開発の話(初期リリースから運用保守まで)を聞いていきました。

ファーストリリースは夏休みの一ヶ月で行ったそうですが、これはPOの熱意や短期的な締め切り, 2日に一回行ったデイリースクラム、開発者の高いモチベーションが寄与した結果だそうです。

その後運用保守をしていくにあたっては、使用したユーザーからのフィードバック*4を受けながら雑談スレッド機能を作ったり、質問をもっと見る機能を作ったということでした。
また、機能拡張していくのはユーザーに喜んでもらってユーザーを増やしてもらうためにやっているため、決してソフトウェア開発やソフトウェアの機能拡張だけにこだわっているわけではないというお話もありました。

最後には今後プロダクトが目指したい姿の話をしてくれたのですが、プロダクトの利益やCI/CDなどを通した開発効率の向上なども話されていて、全体を通してマチュリティの高さと視野の広さに驚かされる発表でした。

最高の開発手法、アジャイルを捨てよう!!

confengine.com

次に、MTGなどが多いアジャイル開発に疑問を抱き、アジャイル開発を捨てた結果起きた話を聞いていきました。

アジャイルを捨ててとにかく開発に集中した結果、最初は爆速でチケット消化が進み、フロントエンド/バックエンド含めあっという間に実装ができたそうですが、一週間位進むと頭の中がとっちらかってしまい、最低限情報を整理しようとした結果、5W1H(何を作るの?どうやって作るの?いつまでにやるの?)を中心に情報をまとめることにたどり着いたそうです。

後半はこの5W1Hにしたがって色々アレンジをしていくとWFやアジャイルに近づくのでは?という内容で、見たことがあるドキュメントや見たことがある風景が出てきて、どんどん発表に引き込まれていきました。

デモ展示

今度こそデモを...と思いきや、推し活カレンダーを作成していたチームの方々やazamiさんやKatsuyaさん、宮本さん...たくさんの方々がスポンサーブースに来てくださって、LTで話していたネタの深堀りなどをしていきました。

判断が遅い!ズ(仮)がいいチームになった話

confengine.com

続いて、筑波大学で今年のenPiT最優秀賞をもらったというこちらの発表を聞いていきました。

発表では、実際に作った「青い栞」を開発していく過程を中心にお話してくれて、以下のような工夫を紹介してくれました。

  • 感謝の気持ちをひたすら投稿する遊び心を取り入れたチャンネル
  • 自動デプロイパイプラインの構築
  • 分散型休憩システム
  • 並行作業と集中作業の活用(最初はモブで初めて次にペア作業、最終的には個人作業という段階を踏んでいった)
  • 名言集(迷言集?)
  • AMFのカスタマイズ

これらの工夫が生まれた背景として、いいプロダクトを完成するのはもちろん大事だけれど、それ以上にチームをうまいこと回す&残業0を目指した結果生まれてきた工夫だという部分が個人的にはすごくいいなあと思いました。

函館補完計画 : 序 〜助走付きスクラムを導入した話〜

confengine.com

次に、公立はこだて未来大学のプロジェクト学習でスクラムを実践した話を聞いていきました。

こちらのチームでは、スクラム未経験であるばかりかサービス開発をすることが半数メンバーにとって未経験だったが故にスクラムでモチベーション維持していくのが難しいと判断し、助走つきスクラムを導入したそうです。

具体的には、

  • 非同期デイリースクラム(決められた時間の間に進捗をSlackへ投稿)
  • なんちゃってスプリント(SMが宿題という形で学習タスクを設定し、発表)
  • 無自覚なスプリントレトロスペクティブ(自分の行動でよかったところのみを挙げて褒めてもらう)

を実施したそうで、うまく助走できたことで楽しくスクラムを実践できたということでした。

自分たちのモチベーション維持を第一に、無理なく楽しみながら持続可能な開発をしている姿が印象的で、スクラムの楽しさがひしひしと伝わってくる発表でした。

enPiT修了生は、大学卒業後の一歩をどう選んだか

confengine.com

最後に、不確実性が高い就職活動でazamiさんがどのような道のりを歩んできたのかを聞いていきました。

最初は国家公務員を目指していたものの、enPiTでPBLやスクラムを経験したことで就職活動に対するモチベーションや取り組み方が大幅に変わったということで、以下のようなアプローチを就職活動では取るようにしていったそうです。

  • 自分がやりたいことや考えていることをどんどん大人にぶつけてみる
  • 自分をサポートしてくれるネットワークを独自に構築し、信頼できる先輩や信頼できるリクルーターに大事な面接前に壁打ちをお願いしてみる
  • 内定先で実際にアルバイトをしてみることができないかお願いしてみる

全体を通して素晴らしい発表だったのですが、自分が楽しいことを大切にしている部分や、授業で経験したアジャイルをソフトウェア開発を超えた形で適用している部分、例え難しいテーマであっても自分の人生に関わるテーマに対して真摯に向き合い続けている部分の3つは本当に感銘を受けました。

デモ展示

ついにデモを見るときがきたか...?と思いきや、うきうきなっとうのふじえもんさんとはやとさんが来てくださり、

  • 本の読み方
  • アウトプットをインクリメンタルにしていくコツ
  • 自分がしたアウトプットをどのようにふりかえりするか?
  • 自分が楽しいことをし続けるために工夫していること
  • パーソナルコーチングの話

などなど、いろいろな濃い話をすることができました。
RSGTでお話することはできたものの、そのときはワークショップ形式で形式的な会話に近い話しかできておらず、今回のような濃い話をすることはふじえもんさんとできていなかったので、満足感溢れる素敵な時間を過ごすことができました。

クロージング

最後に川口先生とChiemi先生からクロージングがありました。

簡単に今日の総括があった後、個々人のNext ActionやAgilePBL祭りというコミュニティのNext Actionを考えていきました。
以下のようなNext Actionが出ていました。

  • この場の学びがより浸透できるように、これからも手を動かし続けたい
  • なんでもかんでもやってみるのは大切にしつつ、登壇する際に内容を絞って言語化できるようになりたい
  • スポンサーになれるように動いていきたい
  • こういう場を作り続けていきたい

その後は、AgilePBL祭りができた経緯として、チームが経験するすべてのプロセスを経験できるような場を作りたいと思っていてその一歩として実施しているという話を聞いていきました。
この後の懇親会につながる素敵なクロージングでした。

全体を通した感想

素晴らしいセッションをたくさん浴び続けられて楽しかったのはもちろん、デモ展示の時間でスポンサーブースに来てくださったみなさんと濃い雑談をすることができ、めちゃくちゃ楽しかったです。

発表してくれていた方々が皆さんとにかく楽しそうだったのがすごく印象的で、自分自身が楽しめているか?を今後問い続けていきたいなあと改めて思いました。
初参加でしたが本当に充実した時間を過ごすことができて、大満足の1日でした。

*1:授業という形で限られた時間で実施していることもあり

*2:Discordではちゃんと?スクラム開発警察が出動していました

*3:授業に関する質問板

*4:直接ユーザーからもらった声だけではなく、Google Analyticsなども活用

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

記事のタイトルどおり、スクフェス新潟にプロポーザルを出しました。スクフェス福岡に引き続き、複数(3つ)のプロポーザルを出しています。

www.scrumfestniigata.org

confengine.com

confengine.com

confengine.com

それぞれのプロポーザルを出した経緯

JUnitで学ぶTest smells撃退法

スクフェス福岡で発表することになった「菅原道真スクラム」に続く、領域展開*1です。
これまで技術的な内容での発表がなかったので、何かしら技術的発表ネタを考えていたところ、最近読んでいた論文でTest Smellsが未だに多く残存している問題を知ったので、JUnitを使ってTest Smellsを撃退する方法を話してみようと思いました。

テストど素人が探索的テストを勉強したら混乱した話〜探索的テストの本, 論文, 記事を362本読んでわからなかったこと〜

アジャイルを実践しようと試行錯誤していたこともあって、自分がテストを学び始めて最初に本格的に勉強を始めたのは探索的テストでした。

探索的テストは奥深くて楽しいのですが、論文や文献によって実施方法や前提条件にまつわる解釈が大きく分かれているため、ある程度深く勉強しようとすると混乱した方も多いのではないか?*2と思って誰かしらに役立つ内容になるのでは?という想いからプロポーザルをしたためました。

競技人口100万人以上のゲームで世界一を取った人間がN=1で語るメンタルヘルス

前々から話してほしいと一部の人に言われていた話をプロポーザルにしました。

メンタルヘルスカテゴリがあるので元々出す気満々だったのですが、プロポーザルを作っている最中にメンタルヘルスカテゴリがばんばん出てきて、出すことを一度躊躇することになりました。

ただ、メンタルヘルスカテゴリがあるのはスクフェス新潟なのでここで出さないと来年になってしまい、来年は自分自身がこのテーマをもう話したいと思わなくなっている可能性もあるなあと感じたので、諦め半分で出すことにしました。

プロポーザルを出すまで

スクフェス新潟のプロポーザル締切は3/19だと知っていたので、3月はじめの時点で油断していたのですが、いざ蓋をあけてみると3月は超多忙な日々が続き、3/19の夜までプロポーザルを書く時間がまったくないという事態に襲われました...笑

そうこうしている内に出そうと思っていたメンタルヘルスカテゴリのプロポーザルも出すタイミングがどんどん失われ、ネタが完全に尽きる事態に陥って、締め切り15分前に滑り込むというとんでもない失態を犯す羽目になりました。

複数プロポーザルを出した経緯

なんとなくの気分でというのもあるのですが、スクフェス福岡に引き続き、プロポーザルを複数出してみました。

複数プロポーザルを出そうという経緯はスクフェス福岡で複数本出した際の経緯と動揺なので、詳細は割愛します。

どれを話したいか?

複数本プロポーザルを出した人への定番質問として、「どれを特に話したいのか?」という質問があるのでそれに答えておきます。
個人的には、今回は以下の順で話をしたいですが、今回はスクフェス福岡のときほど話のしたい度合いに大きな差はなく、どれが来てもまあ驚かず話せるかなあという感覚を持っています。

ただし、一番下のメンタルヘルスカテゴリのプロポーザルに関しては、だいぶ過去の話なのでうまく話せるかどうかが不安&あんまり人の役に立たなそうなセッションなのでスクフェスで話していいかが不明、という点は懸念に思っています。*3

confengine.com

confengine.com

confengine.com

*1:これまで自分が話してこなかったような内容にチャレンジしてみよう、の意

*2:何を隠そう自分が混乱した

*3:とはいえもし選ばれたらそれは運営の方々が面白いと思ってくれているということなので、喜んで話します

エンジニアのためのドキュメントライティング - Forkwell Library #19に参加してきた

forkwell.connpass.com

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

会の概要

以下、イベントページより引用です。

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。

Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第19回目では2023年3月11日発売の『エンジニアのためのドキュメントライティング』(原題:Docs for Developers)を取り上げます。 「ドキュメントを書いておけばよかった」 開発者であれば一度は思ったことがあると思います。 本書は架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測定、保守に至るまで、開発を最適化するためのドキュメント作成の技術を解説しています。 基調講演では本書の翻訳を担当されたfukabori.fmでも有名なiwashiさんをお招きし、エンジニアがドキュメントの作成・運用に苦しまない様なノウハウをお伺いしていきます。

会の様子

基調講演〜エンジニアのためのドキュメントライティング〜

まずはiwashiさんから基調講演がありました。以下、内容を記載していきます。

発表の前提

発表の前提として、今日のイベントの対象者が「ドキュメントを書いておけばよかった」と思ったことがあるけれど書き方を体系的に学んだことのないエンジニアである旨の説明がありました。

書籍の概要

大まかに分けると、

ドキュメント作成の準備→ドキュメントの作成→ドキュメントの公開と運用、の3つのPartから成り立っているというお話がありました。

併せて、

ユーザーを理解してジャーニーを書く→仮説検証のために実装→リリースして反応を見る

というプロダクト開発の流れと近似しているのでは?という話もありました。*1なお、各章の目次としては以下のようになっているということです。

1章 : 読み手の理解
2章 : ドキュメントの計画
3章 : ドキュメントのドラフト
4章 : ドキュメントの編集
5章 : サンプルコードの組み込み
6章 : ビジュアルコンテンツの追加
7章 : ドキュメントの公開
8章 : フィードバックの収集と組み込み
9章 : ドキュメントの品質測定
10章 : ドキュメントの構成
11章 : ドキュメントの保守と非推奨化

読み手の理解(1章)

本書で一番重要なPartがここだということでした。
ドキュメントを書く上で一番大事なのはユーザーを理解する(誰がユーザーで何を達成したいのか?)ことだというお話で、これができないとビルドトラップの兆候になりかねないということです。

ユーザーを理解するためには、まずは過去に課題を解こうとする際に作られたログやメモをまずは読み込んで仮説を作って、その仮説を基にユーザーと直接話して仮説検証する方法が本書では紹介されているということでした。

また、ここで得た情報はユーザーペルソナやユーザーストーリー、カスタマージャーニーマップとしてまとめておくことも重要だということでした。*2

なお、ここまでの話を聞いたり1章を読むと、顧客へプロダクト提供するときのドキュメント or 開発者向けのAPIの話が対象かと勘違いしがちですが、実際にはほとんどのドキュメントで応用できる考え方なので、そのつもりで読んでほしいということでした。

ドラフトの執筆(3章)

白紙状態から脱出することが一番難度が高いため、まずは手に馴染んでいるツールを使ってドラフトを書き始めることが重要だということでした。
ドラフトを書き始める際には、冒頭で「誰が」「なんのために」読みにくるのかを考えてからタイトルとアウトラインを決めることがポイントで、そこにどんどん肉付けしていくことが推奨されているそうです。

肉付けに使える要素としては、

  • 見出し(ドキュメント内の標識として機能する。最も重要な部分を書く)
  • 段落(ドキュメントの詳細理解に役立つ。情報量が多いので読むのはしんどい点に注意)
  • リスト(要素がざっと読める。順不同が基本だが重要順に並んでいたりアルファベット順に並んでいるとなお良い)
  • コールアウト(もしかしたらシステムにやばいことが起きる、みたいなものを色付きで記載)

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

ただしユーザーはFパターンでざっくりとドキュメントを読むので、全部読まないといけないドキュメントではなく、ユーザーが流し読みで必要な情報を見つけられるような状態が理想だということです。(最も重要な情報は冒頭で述べる、大きな文章のかたまりを分割する、方法ごとに分割する)

フィードバックの収集(8章)

ドキュメントもフィードバックを収集して必要に応じて直していく必要があるということでした。

フィードバックを集めるためには、

  • フィードバックを送れるための経路を用意
  • ドキュメントが役に立ったかどうかをクリックする動線を用意して感情を集める
  • ロイヤリティが高いユーザーが集まる場で質問を投げかける

といった方法がありますが、ユーザーが多い場合にはフィードバックが集まりすぎる可能性があるため、フィードバックをトリアージしておくことも大切だということです。(k8sのIssue Triage Guidelinesが参考になる)

ドキュメントの品質測定(9章)

ドキュメントの品質定義は、「目的(ユーザーの特定の行動を促進すること+組織のゴールを達成すること)にかなっていること」だと言えるだろうということで、要素としては機能品質と構造品質に分割できるだろうというお話がありました。(ただしこの2つの品質であるなら機能品質の方が圧倒的に重要)

具体的に言うと、機能品質とは、

であり、構造品質は

  • Clear(明確)
  • Concise(簡潔)
  • Consistent(一貫)

と表現できるということです。

また、ドキュメントのメトリクスとしては、PV数/ユニークユーザー数/直帰率/TTHWなどがあるものの、確認するメトリクスを絞り込むことやメトリクス活用の計画をたてることが重要だということでした。

日本語特有の観点

日本語の作文技術に関する書籍は多く存在しますが、理科系の作文技術日本語の作文技術日本語スタイルガイドヘルプサイトの作り方、などを読んでおくと良いのではないか?ということでした。

Q&A

以下、Q&Aであった話を一問一答形式かつ常体で記載していきます。

ドキュメント作成の文化や習慣を会社に浸透させるためには?

まずはドキュメントの価値やどれくらいの優先度なのかを話し合うのが重要。優先度が下がりがちな原因としては、ドキュメントを書くスキルがないことや痛い目にあったことがないことが挙げられる。

ドキュメントの保守を褒め称える取り組みの?

kudoカードなどがおすすめ(既存の仕組みとして用意されている部分に乗っかる)

ドキュメント管理ツールのおすすめは?

アトラシアン、Notion、GitHubなどがおすすめ。
特にNotionのリマインド機能で、定期的にドキュメント価値を話すことは重要。

ドキュメントのオーナーは?

書いた人がオーナーになるのがいいと思う。

設計ドキュメントがない状態で開発を引き継いだ場合は何から始めるといいのか?

書きやすいところから書く。ユニットテストがない状態で何から始めるのか?という話と似ている。

運用しやすい運用ドキュメントのツリー構造はどう決める?

書籍にあるドキュメント構成パターンを使う。カードソーティングを活用するのも手。

ドキュメントが増えてきた場合にどこにあるのかを明らかにするためにできる工夫は?

誰か一人担当を決めておくか、検索でどうにかするパターンの2つがあると思う。Flutterをはじめとした優れたドキュメントを確認するのも一つの手だと思う。

キャリアが長いゆえにドキュメントの必要性を感じないシニアエンジニアにどうアプローチするか?

真正面からフィードバックするのが一つの手。

ChatGPTでどこまで対処できるのか?(ChatGPTがドキュメントを書くのを代替する時代が訪れるのではないか?)

まだもう少し時間がかかるのではないか?例えば、日本語特有の修飾語の順序の違いなどを直してもらうのはまだ無理だった。

ドキュメントって書けば書くほど保守性が低くなるし実装との乖離が起きるリスクがあると思うがなにか知見はあるか?

DODに含めてしまうのは一つの手。

WFでドキュメント納品を求められるのだがどうしたらいいか?

ビルドトラップにはまっている。合理的になぜ必要なのかを相手に聞いたほうがいい。しれっとさぼってみるという手もある。

ドキュメントにもLinterはあるか?

textlint, Just Right!(有償)

複数人でドキュメントを書くと内容の粒度や一体性がなくなるのだがどういう対処方法があるか?

フィードバックしてアラインするようにしないと将来的にはスケールせず大変なことになるので、一人で全部直すよりはフィードバックをして直してもらうのがおすすめ。

理科系の作文技術は漫画版でも参考になる?

なった

会全体を通した感想

Q&Aも基調講演もiwashiさんらしく内容が見事に整理されていて、本書の内容の有益性がひしひしとしみる内容でした。

自分自身、ドキュメントを書く機会というのは増えてきているので、本書をぜひ読んで、ドキュメント作成が得意&楽しくなればいいなあと思いました。

*1:ただし、エンジニアのドキュメント技術にフォーカスしているので、ロジカルライティングやパラグラフライティングなど書いてない内容もある。これらの内容が読みたいときは、理科系の作文技術ロジカル・ライティング考える技術・書く技術あたりを読むのがおすすめ

*2:ただし認知バイアスの一種として知識の呪い(知っていると思っていることを伝えられない)に陥らないように注意。知識の呪いを断ち切るためには、フリクションログを作成して引っかかった体験を書いていくことやユーザーに共感することが有効

スクフェス新潟のプロポーザルを見たり、コメントしたりに参加してきた

distributed-agile-team.connpass.com

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

先週コメントしたプロポーザルのdiffを見る

先週コメントしたプロポーザルがコメントをどのように反映しているのか確認していきました。

confengine.com

  • 内容的に少し難しそうなので、BeginnerではなくIntermediateだと思った
  • アウトカムに期待

confengine.com

  • 中身が詳しくなっているが、もっと詳しく知りたい
  • おそらく誤解ってよくない結果につながるものなんだと推測するので、誤解が招きがちな問題があったらそれも知りたい
  • 誤解がなぜ起きるのかとか、紹介しないほかの点で誤解が出てきたらという対処方法に言及できるのであれば、してくれるともっと各個の現場で使えそう(ただしちょっと内容的にはずれそうである)

confengine.com

  • Outlineがわかりやすくなった
  • インセプションデッキの部分が加わって楽しみになった
  • 読みやすくなった

confengine.com

こちらはそもそもフィードバックがないようで更新はなかったですが、けやきビールフェスを優先するためオンライン参加になった*1のと、時間が45分に拡張されました。

confengine.com

  • Outlineが詳細になった
  • 逆にマインドフルネスとのつながりはわかりにくくなってしまった

前回見ていないプロポーザルを見ていく

続いて、前回見ていないプロポーザルを見ていきました。

confengine.com

  • ジャイアントキリング的なストーリーってなにか?
  • 現状のプロポーザルだと何を話すのかがよくわからない
  • セルフのファシリテーションがわからなかった。普段他の人にお願いするのを自分たちでやるということ?
  • ダウンロードコンテンツとかって表現から、3人のチームは直接支援せず、教材を配布してたくさんある各チームがそれを活用して組織変革できた、ということ?
  • WHY/WHATの具体性をあげてほしい

confengine.com

  • 「カッとなって」と書いてあることから若いときに勢いにまかせてプレゼンを書いたようにも思えるので、そこからどのように今変化しているのか?を聞けるのが楽しみ
  • 「最後まで行う」なのかな?
  • 前職ディスリまくってる感は気になる。。
  • 主語がでかい話に主語をでかくして返すと負け戦だな、というのは感じる

confengine.com

  • AbstractやOutlineの内容だと、Learning outcomeの内容(特に2つ目)にどう結びつくのかがいまいちわからずでした
  • Learning Outcomeがダイレクトに得られる構成になっているのか確信は得られない(人の夢を聞いたおまけな感じになってしまっている)
  • 聞いたら間違いなく熱くてそのあと語りてえええってなる予感がすごくしている
  • いい話なのは間違いないんだけど、5分の内容を9回繰り返しているような感じなので人によっては苦手に感じるかもしれない
  • ゴールについて話しているのだけど、現在地や問題について書かれていない感じはする
  • それぞれの項目が似かよっている気がする

全体を通した感想

もう少し盛り上がりがほしい感じもありますが、徐々にスクフェス新潟のプロポーザルも増えてきて、最高のフェスになる気配がふつふつとしてきました。

スクフェス新潟、とっても楽しみです。

*1:けやきビールフェスよりも優先度が高くなるイベントはないそうです

『ソフトウェアテストをカイゼンする50のアイデア』読書会を聴く会に参加してきた

connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(若干遅れての参加だったので冒頭にあった話は聞き取ることができていません)

苦情

P33で苦情が来たのはP33でリリースした機能のせいだと思いこんでいるという前提はまずありそうだよね、という話がありました。
また、苦情の内容としても映像品質がよくないことに関する苦情だったんだろうけれど、これって映像品質をよくすることが解決策になったんだろうか?という話も出ていました。

yoshitakeさんやmiwaさん的には、映像品質が甘かったこととユーザーストーリーが完了したかどうかの基準が「ライブラリがアップデートされたかどうか?」だったのもあまりよくなかったのかもしれないということです。

テストをするときにはメリットよりもなんで役に立つか?を考える

はじめは、「なんのメリットがあるんだっけ?なんの役に立つんだっけ?」ではなく「なんでこれがいるんだっけ?」と考えたくなるという話がありました。
sekiさんからも、最初はユニットテストではなくて本当にこの機能いるの?から始まることが多いということです。

「なんでこれがいるんだっけ?」とかは自動テストがしにくいので、プログラマー視点だと作る部分にフォーカスするので、なかなかフォーカスが効かないとかはあるかもしれないという話も出ていました。

また、miwaさんから、現場であまり話題にならないときは、わざとらしく話題にするところからはじめるのがいいのかな、というコメントも出ていました。

自分の言葉で説明してくれるエンジニア

エンジニアの中でテストが上手い/下手の軸とは別に、自分自身が選んだ解決策に対して自分の言葉でしっかりと説明できるかどうかという軸はあって、自分自身が選んだ解決策を説明してくれる人はいいよね、という話がありました。

また、miwaとsekiさんのチームだと、そういった人がもし解決策を間違っている場合は、どういう部分がおかしいかという話を徹底的に容赦なく言う*1ということです。
ただ、これは指摘をされたときに盲信されない前提があるからというのはあるよね、というお話がyoshitakeさんからあり、例えば指摘されたらそれに対応されてしまうのが絶対だと感じてしまうような新人に関しては、意図的に指摘を複数書いたりこの指摘があっているとは限らない旨を細かく補足したりといった工夫をするということでした。*2

全体を通した感想

今回は共感できる会話が非常に多く、「そうだよねー」と思いながら終始会話を聞いていました。

また、今回の内容に関しては、miwaさんたちは反対のことをやってそれを論文にしようという取り組みもしているというコメントもあり、論文がAcceptされて発表されるのが非常に楽しみです。

*1:その指摘が全然違っていても仕方ないと思っている

*2:徐々に指摘を盲信しなくなってくるとすごく嬉しい