パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai

Jasst関西がオフライン開催だったので10年ぶりに参加してきた。
感想をラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'23 Kansai

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

現場の経験知をパターン言語にするコツが分かった　#agileto2014: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

【1】今回のテーマは「思考停止」。
正直難しいテーマだったかなと個人的印象を持った。
基調講演の山口鉄平さんの話を聞くと、説明に苦労されている印象があって、本来は「ソフトウェアテストをカイゼンする50のアイデア」本から色んな改善事例を出してもらえるともっと聞きたかったのにと思った。

今の日本の社会情勢であれば、「思考停止」というテーマはたくさんの事象が出てくるだろう。
たとえば、円安やインフレ、少子高齢化による社会保障制度の不安、コロナ補助金不正、マイナンバーカードの名寄せ問題、EV車やAIに対応できていない製造業やIT企業、を見れば「思考停止」の事例はいくらでもあるだろう。
つまり、そういう問題に対し、本来の課題（イシュー）は何なのか、その課題を解決する時に一番効果のある対策は何か、予防策は何か、まで突き止めて考えなければならないのに、前提条件や制約条件を無視した議論がすごく多い。

一般に、日本の組織論で有名な「失敗の本質」本を読めば、日本人の「思考停止」の例はすぐに2つは思いつく。
1つは、個人では意見を持っていても、同調圧力に流されて集団浅慮やリスキーシフトに陥ること。
もう一つは、一般兵士のような下級レベルの労働者や兵士は真面目で優秀だが、戦略の目的に合致しない行動を取っているために、いくら真面目に働いても生産性や投資効果が低いこと。
野中先生が指摘した日本人の弱点は、1945年当時から80年たった今でも変わらない。

akipiiさんはTwitterを使っています: 「日本人が思考停止に陥りやすい例が自分のイメージと違っている気がした。日本人は集団浅慮に流されて自分の意見を言わないとか、一生懸命働くけど生産性を意識せず働く場合が多いんじゃないかな？ #jasstkansai」 / Twitter

こういう思考停止の事例を分析するには、なぜなぜ分析が結局使われると思う。
なぜなぜ分析で自分の言動を問い詰めて、最終的にはその人の油断、プレッシャー、焦りなどの心理背景まで突き止められるのではないか、と思う。

OL参加者の意見として、フレームワーク思考を習慣的な思考と考えて、思考停止になっているのではというツイートもあって面白かった。

akipiiさんはTwitterを使っています: 「#jasstkansai なるほど、フレームワーク思考は習慣的な思考と捉えるのか。SECIモデルならどれに相当するのか？形式知を組み合わせる連結化？形式知を暗黙知にする内面化？」 / Twitter

【2】今日のJasst関西で最も印象に残ったのが、「思考停止からの脱出 ～ あなたの"問い”が自律へと導く ～」ワークセッション。
テーマは「思考停止を題材にして、問題事象をモンスターで書いてみよう」。

「思考停止」というテーマを各人の体験から問題事象を洗い出し、それらの問題事象にモンスターとして名前付けする。
そのモンスターには、名前とモンスターの絵があり、モンスターのプロフィールとして得意技・どんな時・他の特徴という説明文が付与される。
そのモンスターに対し、必殺技でやっつける、という流れ。

僕は「打合せ大好きマン」というモンスターを書いてみた。
伝わるかな？

これはアンチパターンと言えるだろう。
つまり、モンスターの名前はアンチパターン名。
得意技は問題事象。
どんな時は、問題事象が発生するタイミング。
他の特徴は、問題事象の影響事例。
必殺技は、解決策に相当するだろう。
フォースに相当する項目があればなおいいね。

僕もパターンは好きだし、パターンを自分で作れないか、パターンカタログのようなものを作れないか色々考えていた時期があった。
しかし、深く考えるほど難しいなと思う。
モンスターにアンチパターンを当てはめると、ロールプレイングゲームのように気楽な気持ちでパターンカタログを作り出すことができる。

この発想は他のワークショップでも使ってみたいなと思う。
プレインステーションなどのゲーム経験が深い人ほど馴染みやすいかもしれないから。
もっと気楽にパターンを考えてもいい。

【3】久しぶりにオフラインでコミュニティに参加して気づいたことはいくつかある。

1つ目は、参加者に若い人もいるけれど、年齢層が割りと高そうなこと。
アンケートでは、SE経験が10年以上の人が参加者の半分を占めていた。
本来は20～30代の人たちが半分以上を占めていて、経験が少なくてもノリが良くて活気があるのが普通だが、ちょっと落ち着いていた感じ。
久しぶりに会った方と話していたら、最近は若い人が少ないですよ、とのこと。
昨今の日本社会の情勢である少子高齢化が出ているのだろうか？

2つ目は、オンライン開催のチャネルが勉強会コミュニティで必要になってきたこと。
コロナ禍を経て、開催側もオンライン開催の手段がすごく簡単と分かったし、参加者も簡単に集めやすいと分かった。
参加者もオンライン開催であれば、スマホさえあれば作業しながらでも聞ける。
わざわざ交通費を払って時間を拘束させる必要もない。

今後の勉強会の運営は、Jasst関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

「ゲームをテストする バグのないゲームを支える知識と手法」の感想

「ゲームをテストする バグのないゲームを支える知識と手法」を読んだ。
JSTQB FoundationLevelを取得した後に読んだので、ソフトウェアテストの基本を抑えていて、かつ、ゲーム業界特有の考え方や組織、技術に関する話があって面白かった。
ラフな感想をメモ書き。

【1】僕は業務系システム開発しか経験がないので、ゲーム業界のことは知らない。
「ゲームをテストする バグのないゲームを支える知識と手法」を読むと、ゲーム業界特有の特徴がいくつかあると感じた。

業務系システム開発では、機能の網羅性、性能要件やセキュリティ要件などを踏まえた品質担保を重視する。
決められた要件があって、その要件に基づいた機能の網羅性の品質を担保することをすごく重視する。
つまり、当たり前品質の確保にかなり重点を置くように思える。

一方、ゲーム業界の品質は単に機能が網羅されていることが重要視されているわけではない。
UIや面白さなどの魅力的品質がかなり重視される。
だからゲームでバッグのように、開発中のゲームをプレイしてバグを探すように、ユーザが楽しめるプレイを中心に見る。
そこには機能の担保ももちろんあるがUIや楽しさもかなり重視しているように思える。
この辺りは業務系システムがBtoBビジネスに対し、ゲームソフトがBtoCビジネスであることから生じている事情もあるだろう。

しかし、ゲームソフトのソフトウェアテスト専門会社が出現し、品質向上や品質の可視化を目的として目標とする品質を定め、専門的な技術を使ってその品質レベルに到達するために必要なテストを計画したり設計するようになってきたという。
つまり、ゲームソフトでも品質管理や品質保証という考え方がビジネスとして必要になってきたわけだ。

【2】「ゲームをテストする バグのないゲームを支える知識と手法」では、JSTQBのソフトウェアテスト体系に基づき、ソフトウェアテスト7原則、ソフトウェアテストの専門体制、テストの種類、テストの活動、ソフトウェアテストの技術が紹介されている。
ゲーム業界特有のゲームでバッグの話は面白い。
一方で、ゲーム業界に限らず、JSTQBのソフトウェアテスト体系に基づいて内容が紹介されているので、その知識があれば、より理解しやすくなるだろうと思う。

たとえば、テストの体制には、テストマネージャ、テストリーダー、テスト担当者ごとに役割がある。
テストの種類（テストレベル）には、機能テスト、非機能テスト、探索的テストなど各種テストがある。
テスト活動には、テスト計画→テスト分析→テスト設計→テスト実装、テスト管理などがある。
この辺りはJSTQBの話と全く同じ。
換言すれば、こういうソフトウェアテストの専門知識を持ってゲームソフトのテストを専門的に実施しているならば、かなり組織的にテストをやっているわけなので、品質管理や品質保証もかなりレベルが高いのではないかと思う。

JSTQBのテストプロセスの概念モデルを描いてみた: プログラマの思索

【3】ゲーム業界のテスターのキャリアマップは興味深かった。

管理系・技術系のキャリアに分かれている。
管理系キャリアは、テストマネージャやテストリーダー。
技術系のキャリアは、テスターから始まり、テスト設計者、自動化エンジニア、ゴッドハンドデバッガー。
この観点は一般的なプログラマやSEのキャリアに似ている。

【301】個人的に興味を引いたのは自動化エンジニア。
彼の役割はテスト自動化ツールを活用してプログラムを実装して自動テストを実現する。
Pythonの利用が多いらしい。
また、昨今はAIを活用したテスト自動化技術が注目されているらしい。
mablとかもそうなのかなと思う。

アジャイルチームのためのインテリジェントなテスト自動化ソリューション | mabl

テスト自動化が今後重要な役割を持つだろうと直感する。
ソフトウェアテストはどうしても手動テストや手動デバッグが多く、人海戦術になりがち。
そういう部分をプログラムそのもので自動化すれば品質が担保されるし、回帰テストによりデグレードも防げるメリットがあるのは誰もが理解する。
一方、テスト自動化は技術の難易度が高いし、やみくもにテスト自動化してもコスト削減効果がさほど得られない話もよく聞く。

テスト自動化の8原則という概念も初めて知った。
この辺りも色んなノウハウがあると思うので調べてみる。

テスト自動化研究会 - テスト自動化の8原則

テスト自動化の8原則について解説

【4】テストエンジニアの年収が記載されていたのも目を引いた。
一般アルバイトなら時給1072円、テストリーダーなら時給1172円。
年収は225万～400万円程度。
テストマネージャなら月給30万～50万レベルとのこと。
今はインフレなのでこれよりも高いだろうが、まだまだ低い気がした。
ソフトウェアテストの専門性が認知されれば、今後も上がっていくのだろうと思う。

第24回redmine.tokyo勉強会の感想 #redmineT

第24回redmine.tokyo勉強会の感想をラフなメモ書き。

【参考】
第24回勉強会 - redmine.tokyo

第24回redmine.tokyo勉強会(2023/6/3) #redmineT - Togetter

【毎月更新】Redmine リリース前の新機能を先行チェック！チケットのフィルタでOR検索ができる「いずれかを含む」など（2023年4月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！関連するチケットの番号を複数指定した絞り込みなど（2023年3月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！オートウォッチ「自分が作成したチケット」の追加（2023年2月コミット分） | Redmine.JP Blog

【1】@g_maedaさんの講演では、Redmineで未リリースだが取り込まれたパッチの機能改善が紹介された。
興味深い機能は、検索機能の強化だ。

チケットのフィルタでOR検索ができる「いずれかを含む」は、チケット項目だけでなく、フィルタ演算子にも適用できる。
たとえば、添付ファイル名の後ろが .png または .jpg で終わるチケットを抽出とか。
チケット一覧でSQLのように扱うことができるだろう。

また、「現在・過去の値、過去の値、履歴に一度もないの3つで検索する」機能も追加された。
使い方の例として、担当者が自分になったことがないチケット、 担当者が過去に自分だったチケット、Closeしたけど過去に自分が携わったチケット、などがあった。
過去レビューしたチケットを検索したい時に、細かな検索条件を追加することで対応できる。

akipiiさんはTwitterを使っています: 「チケットのJournalテーブルを参照して、現在・過去の値、過去の値、履歴に一度もないの3つで検索する。更新日の検索条件を入れた感じかな。OR検索といい、検索の細かい機能改善をやってますね。 #redmineT」 / Twitter

仕組みとしては、Journalテーブルの更新日を検索している。
よって、過去の履歴をより詳細にフィルタリングできるわけだ。
本来は直接SQLを書ければいいのだろうが、こういう機能改善によって、SQLの検索条件をチケット一覧のUIでカバーできるようになったのはありがたいことだ。

一方、Redmineの右上の検索ボックスの機能と全く同じであるため、チケット数が20万件以上になると性能要件に問題が出てくるだろう。

akipiiさんはTwitterを使っています: 「全検索対象テキストの機能は、性能要件は大丈夫なのかな？　チケットが数万件、数十万件でもレスポンスは問題ない？　インデックスを張ってあるのだろうな。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。Journalテーブルの件数が多くなると遅くなる。検索ボックスの機能と全く同じなので、検索ボックスのボトルネックを感じるなら同じ現象が起きる、と。」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。full_text_searchの検索結果と検索ボックスの検索結果は異なるケースが発生する。クリアコードさんに機能改善を対応してほしいなあという依頼ありw」 / Twitter

RedmineのデフォルトDBはPostgresSQLなので、パラレルクエリを使って、複数のCPUを活用するクエリプランを生成しクエリの応答をより速くする方法がある。
このチューニング方法を使ってもいいかもしれない。

akipiiさんはTwitterを使っています: 「#redminet Oracleのマテリアライズド・ビューみたいな機能を使ってクエリ検索の性能を上げたいアイデアがありました。PostgresSQLならパラレルクエリの機能があるんですね。なるほど。」 / Twitter

第15章 パラレルクエリ

【2】ChatGPTでRedmineチケットを自動作成する方法を試す事例があった。

akipiiさんはTwitterを使っています: 「Redmineの連携方法をChatGPTに聞いてみた。 #redmineT https://t.co/UzMAAe7dCj」 / Twitter

しかし、チケットの内容が微妙で思ったような内容でないらしい。
プロンプトエンジニアリングとか色々テクニックが必要な気がした。

akipiiさんはTwitterを使っています: 「#redminet Redmineチケット作成にも、プロンプトエンジニアリングが必要なのかもしれませんね。」 / Twitter

ボウコバさんはTwitterを使っています: 「@akipii ChatGPTは、知らないことは適当な情報で埋める傾向があるので、知らないことは勝手に決定せず、自分に質問しろと指示する案も出ていますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@bowkoba なるほど、機械の中身は統計処理の推測ですからね。どういう立場で情報がほしいとか、前提条件や制約条件をかなり追加する必要がありそう。」 / Twitter

しかし、ポテンシャルはあるから、ChatGPTで、埋もれたナレッジを再活用するとか、バグチケットに類似バグ調査、過去の類似チケット検索とか、AIで補完してほしいと思う。

akipiiさんはTwitterを使っています: 「Bingに同じことを聞いてみた。埋もれたナレッジを再活用するとか、まだマシかな？？ #redminet https://t.co/HKtFgxwrjG」 / Twitter

【3】川端さんから、逆引きでわかる！ Redmineハンドブック バージョン5.0対応の紹介。
今までの、いかにも土壇場で作ってきました講演と異なり、Redmineの事例紹介の内容がかなり詳しかった。
たぶん、7千社近い顧客企業の事例を持っているので、Redmineのチケット管理でタスク管理するにはどういう使い方がその企業に向いているのか、かなりノウハウが溜まっているのだろうと感じた。

(1) りょうまさんはTwitterを使っています: 「川端さんが真面目な話してるの、超久々に聞くんだが #redmineT」 / Twitter

Redmineのチケット管理でハマりやすい問題は、いくつかある。
1つ目は、ワークフローの複雑さと親子チケットの階層の深さのトレードオフだ。
講演では、レビュー中というステータスを外し、ワークフローを単純化して親子チケットで対応する方法が紹介されていた。
この手法は、トラッカーの種類を減らし、ワークフローを短縮化する一方、親子チケットの階層を深くしてでも対応することに相当する。
プログラマやガントチャート好きなマネージャはツリー構造に慣れているので、このやり方が向いているかもしれない。

2つ目は、PJで現れる工程やフェーズはRedmineバージョンで使うか、親子チケットで対応するか、というトレードオフだ。
一般に、WF型開発では、Redmineバージョンを要件定義、設計、開発、テストのように割り当てる時が多い。
しかし、このやり方では、システムとしてリリースできるタイミングはPJの最後の1点だけになり、リスクが大きすぎる。

講演では、バージョンを使わず、親子チケットのうち子チケットでフェーズ分けする手法が紹介されていた。
つまり、親チケットは実装する機能とし、子チケットで要件定義・設計・開発・テストごとに作成して、親チケットでタスク全体を管理する。
このやり方であれば、親チケットをどのイテレーションでリリースするか、だけ決めるだけでいい。
WF型開発であっても、小規模な改善が多い案件、保守案件ではこのやり方の方がアジャイル開発に似ているので運用しやすいだろう。

【4】中村さんの講演では、Redmineを外部記憶装置として扱い、少ない脳内メモリを有効活用しようという話だった。
GTDにある「頭の中で動く猿を追い出す」ことと同じだなと思う。

(1) アカベコさんはTwitterを使っています: 「チケットや Wiki などを外部記憶装置と認識、よくわかる。外部記憶、かつ長期記憶で起票とかメモすることで短期記憶のスタックを明け渡すようにしてる #redmineT」 / Twitter

【5】@yukiaさんの講演では、チケット管理ツールを個人向け、チーム向け、組織向けの3階層で分類していた。
個人＜チーム＜組織の順に、統制や標準化という押しつけが大きくなるイメージだろう。

中村さんの話でも、チケットに記載しない内容として、個人タスク、案件化していない情報などがあった。
だから、GoogleKeep＋Redmineを使っているとのこと。
確かに、GoogleKeppならメモやちょっとした履歴にも使える。
つまり、個人のタスク管理、メモ管理としてRedmineを利用する方法は実はあまり議論されておらず、今後、もっと試してみる価値はあるだろう。
僕の直感では、GTDのようなワークフローやUIをRedmineで実装できるかどうか、が鍵を握ると感じる。

(1) akipiiさんはTwitterを使っています: 「タスク管理ツールは3種類ある #redmineT https://t.co/IIOkSESd5Y」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チームのためのツールは課題管理がメイン #redmineT https://t.co/WeJGHxZEAD」 / Twitter

(1) akipiiさんはTwitterを使っています: 「組織のツールはワークフローで統制できること #redmineT https://t.co/bX9m8iwioG」 / Twitter

【6】@ryouma_nagareさんが紹介してくれたpython-redmineは試したみたいと思う。
REST APIはありがたい機能なのだが、チケット全件を取ろうとすると100件という制限があったりして割と面倒。
もっと手軽にデータを扱いたいから。

maxtepkeev/python-redmine: Python Redmine is a library for communicating with a Redmine project management application

【7】@MadoWindaheadさんから、チケット管理システム有識者の集いを開催したい、という要望があった。
チケット管理ツールの同盟を組んで、想いを実現したい、と。

(1) akipiiさんはTwitterを使っています: 「プロダクトマネジメントはプロジェクトマネジメントと確かに違うね。アジャイル開発やSaaSで多いかな #redmineT https://t.co/XSlKg04ykI」 / Twitter

(1) akipiiさんはTwitterを使っています: 「PJ管理ツールと同盟を組んだ #redminet https://t.co/OY0bUqbf3Q」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チケット管理ツールの同盟を組んで、想いを実現したい #redmineT https://t.co/e9sCIQZWCt」 / Twitter

今は色んなチケット管理ツールが有償・無償であり、それらの機能を比較して考えていくと、ああそういう使い方がしたかったのか、そんな利用シーンがあったのか、と気づく時がある。
プロジェクト管理の手法はまだまだ枯れておらず、色んなやり方を試せると思う。