パターンカタログよりもモンスターカタログの方が面白いね #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関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

デブサミ2023の感想

デブサミ2023の感想をラフなメモ。
自分用のメモ。

【参考】
Developers Summit 2023（2023.02.09-10）

DX、アジャイル、プロセス、テストなどを色々聞いた。
その中で僕が興味を惹いたのは、Rustとテスト自動化の2つの講演。

【1】RustはFirefox、Linux、Androidなどで使われ始めていると聞いたが詳細は知らなかった。

Rustは所有権の概念を持つ。
所有権とは束縛した変数みたいなもの。

Rustは一生コンパイルが通らないと言われる。
理由は、コンパイラが強いから。
そもそもプログラミングが難しい。
代入可能な変数かどうか所有権で決まる
所有権で解決する。
コンパイラが教えてくれる。

Resultはエラーハンドリング。Scalaにもある。
インターフェイスからエラーを返すか判断できる。

OptionはJavaのOptionalと同じ。
ScalaのOptionalみたいなものか。

enumはパターンマッチ。

traitはジェネリクス関数をシュッとしてくれる。
ScalaのTraitと同じ。

「なんでもかんでもclone()をつけたくなってしまいます、どうしたらいいですか？」という質問に対して、Cloneで妥協していい。
Cloneせずにコーディングすればメモリを小さくできるが、コーディングが難しい、と回答があった。

僕はRustはC言語の代わりとなる低級プログラミング言語と誤解していた。
しかし、こういうRustの話を聞くと、C言語のように扱える関数型プログラミング言語と見なした方が良いと思った。

【2】テスト自動化では、今はE2EテストがAIによって更に加速している。
画像の物体認識、画像処理のディープラーニングを使って、画面UIをテストする方向に進化しているらしい。
しかし、OCRのような、画面の文字認識の精度が低いらしい。
むしろ、テスト後に画面変更をAIが検知して、テストプログラムを自動修正する方向に進化しているらしい。

AIをテストに利用する発想がよく分かっていなかったが、AIが物体認識や画像処理に特化している強みを生かすことで、UIテストを強化しているのは面白い。

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体｜山本 正喜 / Chatwork CEO｜note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか？

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5～7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか？

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか？
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム（SoR）が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。

XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)。
テスト駆動開発なら、テスト駆動開発、実践テスト駆動開発。
継続的インテグレーションなら、継続的インテグレーション入門、継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化。
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~。
ふりかえりなら、アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き。
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計。
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。

第23回東京Redmine勉強会の感想～コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

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

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か？
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

面白すぎる。RT @NAGAYASU_Shinya: Redmineにて塩漬けチケットがしぬほどある部署にいたとき、ついカッとなってここ1ヶ月更新のないチケットを一気に却下にしたったことある
……すごい怒られた、そして別に業務になんの支障もなかった。

— akipii (@akipii) March 10, 2017

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査　事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね？ #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか？
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ！という話。
チケット駆動が楽しい！
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

組織を芯からアジャイルにする対談の感想～今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

本日のグラレコいただきました！ pic.twitter.com/C2nh8MDDaY

— Kenji Hiranabe (@hiranabe) August 4, 2022

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

第22回東京Redmine勉強会の感想 #redmineT

第22回東京Redmine勉強会の感想をラフなメモ。

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

2022/5/28 第22回勉強会 - redmine.tokyo - Togetter

【1】三浦さんの講演は興味深かった。
プロジェクトで発生する情報源として、3種類を抽出している。
エクセルファイルのような静的ファイル、Slackのような動的なチャットログ、日々のタスクやWikiなどの静的でもあり動的でもあるデータ。
資料では、一昔前の管理方法、昨今のリモートワークの管理方法、redmine.tokyoの管理方法などが紹介されていて、この発想が面白い。
具体例を見ると、Googleドライブ、SlackやTeams、RedmineやGitlabのように、数多くのサーバーが乱立して連携する形が多いみたい。
むしろ、情報源は1つのサーバーにまとめるのは逆に管理が面倒かもしれない。

三浦さんの考え方では、3種類の情報源はそれぞれの管理方法が違う。
エクセルファイルは共有ファイルサーバーだったり、Googleドライブで管理する。
チャットログは、メールよりもSlackやTeamsの方がいい。
チケット、Wiki、GitHubは別サーバーにある。

これらの情報は参照関係が双方向ではなく、単方向であるという制約がつく。
たとえば、チケットから共有ファイルサーバーの資料リンクはあるが、エクセルの設計書にはチケットのリンクを貼ることはあまりない。
そういう作業履歴の情報は不要だから。

また、チケットのコメント、GitHubのコメントはSlackのチャットログに流れた方が管理しやすい。
更新メールがたくさん流れても困る。

つまり、これら3種類の情報に分けた時、双方向の参照関係が実はあまりない。
この気付きが面白かった。

【2】かるねさん、門屋さん、ワテさんのRedmineの使い方はみんな異なる。

ワテさんは、ソフトウェア開発の受託案件が複数個走っているので、案件テンプレートを準備して、チケット管理のワークフローや初期設定、Git連携などは事前にテンプレート化しておく。
チケットの進捗管理、ステータス管理は細かく設定されている。

門屋さんはチケット一覧を重視する。
チケットの親子関係をうまく使って階層化してチケットをグルーピングしたり、ソート順を決めて、管理しやすくする。

一方、かるねさんは事務処理をRedmineで管理しているので、ロードマップ画面で、毎月のルーチンワークをバージョンで設定し、毎月ごとに事務処理チケットのボリューム感をコントロールしている。

それぞれの目的に応じて、Redmineの機能をピックアップして使っているのが面白い。

【3】ボウコバさんの講演では、Redmineを導入するときに、ボトムアップとトップダウンの手法をうまく組み合わせる点を話されていた。
たぶん、大企業では標準プロセスが揃っていて、それに従う必要がある。
そこで、標準プロセスをRedmineで実現しておき、スモールスタートで運用を開始して、成功しているよ、という雰囲気を社内に作り出す。
そこから少しずつ広げて、トップダウンで最後に広げていく、みたいなイメージ。

以前アカベコさんが、Redmineの運用では活況を演出するのが重要だ。
なぜならば、活発に更新されてすごく便利そう、という雰囲気を醸し出さないと、根付かないから、と言われていたが、そのやり方に似ているな、と思った。

僕は、ボウコバさんのように、チケットに情報を集約する方が好き。
そのチケットは、日々のタスク管理のようなフローの情報、課題管理や障害管理のようなストックの情報の二重性を持つ。
チケットに2つの情報が集約されることで、検索機能やハイパーリンクが使えて、Redmineがナレッジデータベースになるというイメージ。

【4】内藤さんの発表では、直近4回位のRedmine勉強会の参加者が常連さんに偏っている点がグラフで示されて、正直びっくりした。

その原因は色々あるだろう。
オンライン勉強会になったので、地方の人も参加しやすいが、対面で知り合う機会がないので、初対面同士で盛り上がりにくい。
自然に、すでに知り合いの仲間同士で盛り上がってしまい、その輪に入るのはなかなか難しい。

一方、Redmineの機能改善も、チケット管理ツールのライバル製品の機能を取り込む方が多くなっているので、独自性をアピールする点が不足していることもあるだろう。

他方、チケット管理ツールの概念はある程度知られてきていて、イノベーターやアーリーアダプターにとっては新鮮味があまりない点もあるかもしれない。

このあたりの原因は色々聞いてみたい。

とはいえ、今日の勉強会の中身も濃かったと思う。
講演もLTもちゃんと聞いていると、こんな使い方もあるのね、とか気づきが多かった。

【5】西崎さんがRedmine開発者コミュニティを作ろうと提唱されていた点も興味深かった。

やはりRedmineの開発は情報源が少ないので、もっと多くの人を巻き込まないといけない。
Redmine開発者コミュニティがハブになって、他のRedmine勉強会の人たちをつないで、開発に興味を持ってもらったり、ユーザに使ってもらってフィードバックをもらうことを考えられていた。

一方、山崎さんはRedmine Marketplaceを作り、Redmineのプラグインを集めて、有償販売できたりするWebサイトを準備されていた。

つまり、Redmineをさらに使いやすくしたり、手に届くような環境を作ろうと活動されている。
こういう活動を見ていると、やっぱり日本人にはRedmineが向いているのかな、と改めて思う。

『ものづくりの数学』の感想 #もの数

今朝、講演会『ものづくりの数学』に参加してきた。
感想をラフなメモ。
全くロジカルでないメモ。

【参考】
講演会『ものづくりの数学』 - connpass

講演会のテーマは、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の著者の先生に、企業の技術者と理論物理・純粋数学の科学者という２つの立場から、ものづくりの現場に現代数学をどのように導入して効果を上げるべきか、という内容だった。
内容は相当難しいと思う。

改めて『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読み切ってみると、読者の対象は、大学で純粋数学や理論物理、理論化学を学んだ後、社会人では一般企業の技術者や管理者、IT業界の技術者になった人だろうと思う。
大学の理論研究の経験と一般企業でのビジネス経験の両方がなければ、この本の意義は理解しにくいだろうと思う。

なぜなら、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の内容はすごく抽象的だからだ。
実際、数式は出てこないけれど、現代数学がメーカーの製品開発の背景にあるという経験がなければ腑に落ちないだろう。
また、ポパーの反証主義、トーマス・クーンのパラダイム論やフッサール現象学、ソシュールの記号論などの概念がふんだんに引用されるので、なぜこの知識が必要なのか、という意図がつかめないだろう。
専門の科学者集団はパラダイムに囚われすぎているという先生の指摘は斬新ですごく面白かった。

僕が感じた感想は３つある。

【１】今の日本の弱点は、ハードウェアに付加価値をつける点では新興国の韓国・台湾・中国に追い越され、ソフトウェアやシステムで付加価値をつける点では、米国に負けてしまっていること。
その問題を解決する時に、現代数学が役立つよ、という主張だった。
その製品開発のフェーズに現代数学を使ってモデル化を図って、理論の裏付けを持った技術に育て上げるような方向性だろうか。

だが、ハードウェアの付加価値に差別化を図ろうとする場合、より尖った製品を開発するのは困難だろうと思う。
そのマーケットがそもそも売上や利益が出るような規模なのか、そこにマーケティングを実施して掘り起こせるのか。
その市場で売上を確保できる期間が十分にあるのか。
今の時代は、世界の工場である中国にほとんど製造拠点を持って行かれているので、日本も米国のように、おそらくAppleのように安いハードウェアにソフトウェアやブランドという付加価値を付けて高値で売るようなビジネスに行かざるを得ないのではないか、と思った。

すると、ソフトウェアやシステムで付加価値をつけるフェーズで、現代数学とコンピュータサイエンスを組み合わせて、技術の差別化やビジネスモデルの構築を図る、みたいな方向性が王道になるのではと思う。
しかし、日本から世界に通用するプラットフォームビジネスを生み出せるのか。
日本で現代数学も使えるようなIT技術者を育成できるのか。

先生のお話を聞くと、日本の大学という制度はもう時代に即していないんだなと改めて思う。
明治から昭和までのやり方を未だに大学で続けようとしているが、令和の時代では違うでしょ、みたいな感じ。

akipiiさんはTwitterを使っています: 「今聞いているけど面白い。今の日本の大学という制度は時代に即していないと先生が言い切るのがすごいね。大学もお金を集めないとやっていけない現状、理論の専門家が企業に必要なのに大学が人材供給できていない現状とか色々あるだろうな。#もの数 講演会『ものづくりの数学』 https://t.co/8ijd5ko08g」 / Twitter

【２】先生のお話で面白かったのは、純粋数学や理論物理などの科学者の専門集団はパラダイムに囚われすぎていて、彼らだけに通じる基準と運用で維持し続けられているが、常にその存在意義の正当性を問われているという指摘だった。
自分も大学で数学の研究に従事していた時があったので、その雰囲気がそういう観点で見られているのが斬新だった。

『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法』にかかれているトーマス・クーンのパラダイム論の解釈を読むと、科学者という専門集団は真理を追いかけているように見えるが、すごく閉鎖的な集団なんだよ、という意見に聞こえてしまうのが不思議だった。

akipiiさんはTwitterを使っています: 「問題解決者よりも問題定義者が重要。学会はパラダイムに囚われすぎている。ビジネスの現場で抱えている問題は既存の学会や理論で解決できるとは限らず、むしろ無い場合が多い。現場の問題に忠実に認識してその問題を数学で分解して定義し、その一つを大学へアウトソースして解決してもらうとか #もの数」 / Twitter

一方、ビジネスマンは企業の現場で解決したい問題がすでにある。
その問題は理論や学術面で意義は小さいかもしれないが、その現場ではすごく価値がある。
そういう問題を解くのに現代数学という理論を使うとより効果的だよ、と。
そして、大学での理論研究と企業の現場の違いを認識して上手く利用したほうがいいよ、と。

akipiiさんはTwitterを使っています: 「ビジネスと理論のような大学の場の双方を知るような人材をどうやれば育てられるか？先生曰く。ビジネスマンは大学の弱点や問題点を知るのが大事。そんな話を聞くと、日本の大学は時代に即していない感じがするね。 #もの数」 / Twitter

特に、理論と技術の間にはタイムラグがある。
このタイムラグはいわゆる、死の谷、魔の川、ダーウィンの海に相当する。
すると、理論を研究したり使う時も、その技術がビジネスに使えて実際に威力を発揮できるには、いくつかのハードルを越える必要がある。

akipiiさんはTwitterを使っています: 「#もの数 フィリップスを作ったカシミールの考え方。科学と技術は違う。資本主義企業が科学を引っ張るというモデルを経営者は持つがそうではない。量子力学が生まれた時、ビジネスとも関係なく、半導体やコンピュータのビジネスに繋がることは誰も知らなかった。」 / Twitter

【３】なぜ現代数学の理論が企業の技術者やIT技術者に求められるのか？
その理由は、現場の問題を解決しようとする時、既に知られている技術や小手先の知識だけでは対処できず、２０世紀以後の現代数学の理論を最終的に使わないといけない場面が出てきているからだろう。

例えば、線形代数の利用シーンが連立方程式や固有値計算だけではなく、代数・幾何・解析・確率論などの色んな場面で使われている。
特に、線形代数の理論は、ニューラルネットワークや機械学習のモデルの計算ではよく使われている。

akipiiさんはTwitterを使っています: 「先生曰く。現代数学は線形代数化している。現代数学は幾何学化している。代数幾何学も線形代数にすぎない。色んな所で線形代数が出てくるのにどの書籍にも解説していない。だから出版した、と。 #もの数」 / Twitter

akipiiさんはTwitterを使っています: 「平鍋さん曰く。行列はAIや機械学習で解きたいデータを表現していて、それを線形代数の理論で解くものと思っていた。なるほど、そういう見方で考えれば画像認識技術にAIが使われる意味が分かる気がする。 #もの数」 / Twitter

先生の話では「位相」という言葉がよく出てきて、どういう意味で使っているのか、当初は理解しにくかった。
『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読んでみると、いろんな事象を分類する基準、その構造の近さを同値関係で表していると思った。

akipiiさんはTwitterを使っています: 「位相とは何ですか？という質問に先生曰く。数学者は点ではなく部分集合で考える。だから、関数単体で考えるのではなく、関数の集合で考えて、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するわけか。工業化学をやった人はこの考え方が分かってないと言われた。 #もの数」 / Twitter

代数幾何学が楕円曲線をドーナツの形で分類するように、いろんな事象を数学で捉える時、点ではなく部分集合でカテゴリ化して、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するという発想と思えた。
たぶん、現代数学を知らない人向けにそういう意味で使っているのかな、と想像した。

【４】『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』はとても良い本と思うけれど、現代数学の知識を適用する場所は、メーカーの現場の問題よりも、経済学に関する問題の方がよりインパクトがあるのではないかと僕は思っている。
なぜなら、数学者や物理などの科学者は1990年代頃から経済学や金融にシフトしていること、数学の理論を使えばIT技術と経済学や金融がすごく相性が良いことが分かってきたからだろうと思う。

講演会の参加者には、データサイエンスに詳しい方が割と多い気がしたけど、その人達のバックグラウンドはむしろ、経済事象やマーケティング事象などの社会科学の方が近い気がする。

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

計量経済学における統計上の根本問題: プログラマの思索

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法～確率統計編」の感想: プログラマの思索

僕の問題意識はちょっと別の方向にあるかもしれない。

RedmineJapan vol.2が開催されました #RedmineJapan

本日、RedmineJapan vol.2が開催されました。

RedmineJapan vol.2 2022/2/25 - Togetter

REDMINE JAPAN vol.2 オンライン開催 - connpass

Redmine Japan - Redmine Japan Vol.2 ?明日の仕事を変えるために必要なモノ?

参加して良かったです。
とても参考になった講演は、市谷さんの仮説検証アジャイル開発の講演、和田さんの開発プロセスの話。
Redmineに関係ないです、と二人とも語っていたように、Redmineとは無関係の話でしたが、アジャイル界隈、テスト駆動開発の界隈では超有名人なので、話は面白いです。

また、RedmineAwardを私も受賞させていただきました。嬉しかったです。
今後もRedmineコミュニティを緩く長く続けたいと思います。

第21回東京Redmine勉強会の感想 #redmineT ～Redmineは業務も組織も包み込む柔軟性がある

第21回東京Redmine勉強会の感想をラフなメモ書き。

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

2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter

【1】最初は、@g_maedaさんのRedMica、そしてRedmineの最新機能の紹介。

【1-1】複数キーワードによるAND検索の実装は嬉しい。
チケット一覧から、Google検索みたいに細かい条件で検索できる。
チケット検索機能の強化につながるので、Redmineをナレッジ資産として使う現場としては貴重な機能と思う。

【1-2】チケット一覧でカスタムクエリをデフォルトで表示できるようになった。
PJごとに、みんなが見たいビューはたいてい決まっている。
最初にカスタムクエリで絞り込んでおけば、今日はどの作業に注力すればいいのか、考える必要もないはず。

【1-3】CommonMarkdownの試験的なサポートも興味深い。
斎藤さんのLTでは、Confluenceがすごく便利と話されていた。
実際、Confluenceでは、Wordのような直感的なUIで表も挿入できるし、履歴管理もすごく楽。
Confluenceがあれば、Excelの設計書を廃止して、すべてConfluenceで設計書を書くことができる。

一方、RedmineのWikiでは、Markdownの原稿を逐一プレビュータブで開いては確認する手間がかかる。
また、表のセルの結合、細かな文字の装飾も直感的ではない。

本来は、WikiはWordやExcelの代替機能になるべきだ。
そうすれば、Redmine上で、日々のタスク管理や課題管理はチケット、技術情報や設計書はWikiに全て集約できる。
それ以外の足りない機能は、REST APIやGit連携などの機能によって、他の外部ツールと連携すればいい。
最終的には、Redmine一つでPJの情報をすべて一括管理できるし、Redmineはナレッジ基盤そのものになるはずだ。

【1-4】Mermaid.jsによる作図機能は面白い。
PlantUMLみたいに、UMLのクラス図、シーケンス図、フローチャートをテキストで表現できる。
ただし、redmica_ui_extensionプラグインの機能なので注意。

個人的にはPlantUMLは好き。
モデルそのものもテキストで管理できれば、Gitで履歴管理できるので、設計書をソースコードと同じように管理できるのはいい。

My Redmine インストール済みプラグイン | My Redmine

GitHub - redmica/redmica_ui_extension: This plugin adds useful UI improvements to RedMica.

plantuml - Plugins - Redmine

Redmineには2つのPlantUMLプラグインがある - taikii blog

【2】第21回 パネルディスカッション ＜Redmineとわたしたち＞では、モデレータ、パネラーの女性5人によるフリーディスカッション。

【2-1】面白いのは、5人の女性のキャリアが全員違うことだ。
もちろん、5人全員がRedmine経験歴は10年なのでベテランばかり。

akipiiさんはTwitterを使っています 「Redmineを使う女性だけのパネルディスカッション。サーバ管理者、プロジェクトマネジャー、SEPG、PMO等の色々なキャリアを持つ。組込ソフトウェア会社、外資系、サービス系、メーカー系など色々な属性。面白そう。 #redmineT」 / Twitter

【2-2】僕の琴線に触れたのは、ともこさんとりょうこさんの発言だった。
りょうこさんは外資系SIのPMでPlanioを使っているので、プロマネ観点が多い。
だから、Redmineパトロールみたいにチケット保守や、多数の社外関係者のユーザの権限管理の観点が多くなる。

akipiiさんはTwitterを使っています 「PMの方の意見では、Redmineのパトロールが大事。Redmineの運用がずれてしまうので、定期的にチケットの運用をパトロールする。ゾンビチケットを駆除したりとか。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineの良さ。半年前のチケットを元にコピーして今回の作業チケットを作れるので、差分だけ見ればよく作業漏れがなくなる。関連チケットでチケットを相互関係付けられる。色んな会社の人が使うので権限管理が細かく決められるのがいい。 #redmineT」 / Twitter

一方、ともこさんは全社のソフトウェアの障害管理、全社PJのゲートレビューの管理、Redmineサーバーの管理をされているので、PMOの観点が多い。

akipiiさんはTwitterを使っています 「Redmineが使いにくい所では、UIが初心者のハードルが高い意見が多いが、UIよりもワークフロー設計の方に課題がある意見の方に興味を持った。トラッカーとステータスで障害管理、定常業務の作業管理のワークフローをどう設計するか？の方が重要だし腕の見せ所と思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineに限らずチケット駆動の弱点の一つは、チケットの説明欄が自由すぎること。起票者の能力によってバラついて作業連携やコミュニケーションにロスが出る。そこでテンプレートを用意したり、事前にテンプレートチケットのリンクをWikiに用意して誘導する。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを通じて対面だけでなく非同期のコミュニケーションもやっている。1年前の障害チケット、既に去った人が書いたチケットを読んで意図を理解する。チケットの説明欄に、障害内容や関連するチケットがこれです、と書けば伝えられる。書いて伝える能力が要求される。 #redmineT」 / Twitter

【2-3】女性ならではの観点では、お母さんみたいな役割もあるらしい。
この辺りは中年男性の僕には分からない笑。

akipiiさんはTwitterを使っています 「管理者がオレオレ運用ルールを押し付けると、メンバーは何でやねん！と反発してしまう。そこで相談しやすい雰囲気を作って、お母さんみたいな役割を持って、悩みを聞きまくる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineをパトロール中に、この表現はダメだよね、と気づいたら、チケットもコメントもコッソリ直したり指導する。IT技術者の説明はぶっきらぼうで、これが仕様です、と書いてもノンITの人には伝わらない。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「心理的安全性を高めて雰囲気を良くして、チケットに書いたら、お互いに時間を有効に使えるよ、と伝えたい。 #redmineT」 / Twitter

【2-4】5人のディスカッションでは、「柔軟性」というキーワードが多かった。
「Redmineはユーザとツールの観点で柔軟である」と。

ツールの観点では、Redmineはプラグインやパッチのおかげ機能追加がすごく柔軟な特徴を持つ。
一方、ユーザの観点では、Redmineは現場の人たちのニーズに応じて、運用ルールを柔軟に変更してFitさせることができる。

僕は、「柔軟性を英語でいうと、Elasticと思う。AWS用語でよく出ると思う。 #redmineT」と思っていたが、どうやらFlexibilityの方がイメージが合っていると思う。

akipiiさんはTwitterを使っています 「柔軟性には、ツールの柔軟性と人としての柔軟性の2つの観点がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「100人上のユーザの中で女性PMが一番Redmineが詳しいが、若い人の意見に時々はっと気づく時がある。自分が決めた運用ルールが絶対ではないのでこう変えてもいいかもと思う時もある。人の柔軟性を実現してくれる柔軟なツールがRedmine。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineは、各人が貯めている経験や知識を吐き出すのに向いている。他人の言葉にハッとする時はむしろTwitterや対面の方が多いのではないか。 #redmineT」 / Twitter

【3】田畑さんの森林管理でRedmineを利用している事例はとても面白かった。
岡山の山奥の村に、林業でDXをやっているらしい。

【3-1】Redmineを使う場面は、補助金の申請業務や日々の作業管理。

akipiiさんはTwitterを使っています 「林業だけでは収入が少ないので、補助金の書類が大事。書類が多い。そこでRedmine。人によって情報格差が大きい。知っている人は作業できるが、知らない人は作業できない。ストレスが溜まる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ステータスは、下請けさんの作業街が多いので追加。監督者対応中も追加して65歳の監督者を想定。補助金の申請業務は他者対応待ちを追加。実際の業務で必要だから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「プロジェクト＝現場。バージョン＝作業監督。チケット＝作業で数時間。トラッカー＝設計、実施、監査など。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「トラッカー＝設計、監督、実施後で作ったが、WFが同じなので分ける必要はなかったかもしれない。 #redmineT」 / Twitter

【3-2】Redmineで工夫している点は、ワークフロー設計と、GTTプラグインを入れて、チケットに地図情報を記載している点だ。
実は、第20回勉強会 - redmine.tokyoで「 第20回 LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介」で知って、取り入れたらしい。

Redmineと地図情報を組み合わせるアイデアは面白いと思う。
営業活動や配送管理などにRedmineを適用できるのではないか。

akipiiさんはTwitterを使っています 「森林管理は口承伝承。作業手順を文字化して標準化したい。作業手順記録はWiki、作業状況確認はRedmine＋GTTプラグイン。前回勉強会LTのGeoTaskTrackerプラグインを使う。 #redmineT」 / Twitter

GitHub - gtt-project/redmine_gtt: Plugin that adds spatial capabilities to Redmine

akipiiさんはTwitterを使っています 「チケットにGTTプラグインの地図情報が表示される。チケット説明は簡単に書く。詳細はWikiに書く。チケットの説明に詳しく書くと流用しにくい。 #redmineT」 / Twitter

【4】僕も久しぶりに「Redmine屋から見たMS Planner #redmineT」を講演した。
Teamsに付属しているPlannerを使っているのだが、とにかく使いづらくて仕方ない。
Plannerは所詮ToDo管理に過ぎず、もっと細かなタスク管理や課題管理をやるのには向いていない。
当たり前なんだけどね。

MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから: プログラマの思索

懇親会で聞いてみたら、ブレークアウトルームの大半の人はTeamsを使っている。
Slackを使う人はごく少数。
Office365を使う企業は多いので、Teams利用者が圧倒的に多い。
すると、フリーのPlannerも付属してくるので皆知っている。

しかし、Plannerは使えませんという声が圧倒的だった。
興味深い意見は、Plannerのタスクには更新履歴が残らないので、ナレッジにならない。
使い捨てのカードみたい。
PostItの感覚でしか使えない。
本来は、Redmineのように、完了したチケットでも後から参照したいのに、と。

【5】今回の勉強会は参加者が100人にも到達しなかった。
同日開催の裏番組のOL勉強会が多かったせいだろう、という意見が多かった。

また、@naitohさんのRedmine.tokyo21 questionnaireの通り、初めての参加者が少なく、4回以上の参加者が圧倒的に多くなっている。
この傾向に危険を感じる人も多い。

でも僕はあまり気にしていない。
我々の勉強会が楽しくて盛り上がっていれば自然に人は集まる。
誰でも参加できるような雰囲気さえあればいい。
他人の都合に合わせる必要はないし、こちらの雰囲気が良くて気になるなら、こちらの都合を合わせてくれればいい。

コミュニティはボランティアなので、過大なコミット感まで持たなくていい。
むしろ、緩く長く続けることのほうが大事と思う。
年2回開催という絶妙のバランスのおかげで、スタッフの作業負荷も大きくない。
5月、11月に定期的に開催できるリズムがあるから、参加者もスタッフも講演者も予定を入れやすい。

この勉強会ももう10年以上も続いているのは一つの奇跡だと思う。
他のアジャイルコミュニティも浮き沈みがあって、スタッフの入れ替え時期には開催できなかったりしていた。

三浦かずひとさんの通り、純粋に楽しめればいいと思う。

みうら かずひとさんはTwitterを使っています 「#redmineT 最近RedMineに対する思いもないし、特段興味を持って参加ではなかったのだけど…「利用者視点かつファンでない視点で見つめる」と、「お、工場？」「お、林業？」とか、凄く純粋に楽しめました。」 / Twitter

【6】2021年もAdventCalendarをやっているので、興味のある方はぜひ応募してみてください。
書いてみると、1年後には記念になるのがいいです。

Redmine Advent Calendar 2021 - Adventar

Redmine屋から見たMS Planner #redmineT from akipii Oga

RedMica 2.0 (2021-11) 新機能ハイライト de Go Maeda

ある工場の Redmine 2021 ( Redmine of one plant 2021 ) from Kohei Nakamura

Redmine.tokyo21 questionnaire from Jun Naitoh

Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) pluginの紹介 from Ko Nagase