AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される

デブサミ関西2026に行ってきた。
AI全振りの開発現場では「コードを手書かない時代」のエンジニアの真価が問われている。
実装コストがゼロとなった今、求められるのは単なる作業者ではなく、システム全体の説明責任を負うアーキテクトの思考だ。
全レイヤーを統括し、AIを使いこなすITエンジニアは皆、アーキテクトであるべきだ。

【参考】
Developers Summit 2026 KANSAI（2026.08.21）

AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi: プログラマの思索

【1】デブサミ関西2026に行ってきて、SIerの人は皆AIに全振りだなあと思った。
もはや、プログラムを手書きで書く人はいない。
ジュニアもシニアも皆、AIにプログラムを書かせる。
AIの方がプログラミングが楽だからだ。

すると、AI時代のソフトウェア開発者は、プログラマではない。
では、プログラマはAIに指示するだけのオペレータに過ぎないのか？
プログラマは、AIが作ったソースコードを読む必要はないのか？

【2】僕の考えでは、AI時代のソフトウェア開発では、エンジニアは皆アーキテクトを求められることだ。

つまり、AIでプログラミングのコストがゼロになったら、ITエンジニアは皆アーキテクトの 技術レベルを求められる。

なぜならば、WebサーバーもネットワークもRDBも開発フレームワークもアーキテクチャ設計もフロントエンドもコンテナも業務ドメインも全てAIで即座に実装して動作できるからだ。
中身はブラックボックスでもいい。

【2-1】つまり、ITエンジニアは、インフラ設計・DB設計・アーキテクチャ設計・詳細設計・業務設計・要件定義も全て自力で設計して、全てのコンポーネントや技術を組み合わせて一つのシステムを作らざるを得なくなるからだ。
全ての設計要素の整合性、品質担保は、ITエンジニアしかできない。
すべての技術を理解して、部品のように組み立てて、きちんと動かす能力が求められる。
そのような役割こそがアーキテクトだ。
低レイヤーからフロントエンドまでのIT技術を全て知り尽くして、顧客の要望に対して、最適なアーキテクチャ、すなわち、最適な設計コンポーネントを選択して実装して運用できる人は、アーキテクトしかいない。

たとえ、ジュニアのプログラマが大規模かつ複雑なシステムを開発できたとしても、顧客から、なぜこんな仕組みのシステムを作ったのか？と問われた時に、システムの中身に対する説明責任は必ず要求される。
システムそのもの説明責任の主体は、AIではなく、AIを実装したプログラマであるべきだ。

【2-2】アーキテクトとは、単にシステム構成に関するアーキテクチャを意思決定するだけでなく、意思決定した説明責任も負うからだ。
AIが作ったシステムの中身は分かりません、と顧客に言ってしまうプログラマは、正直最低だ。
自分は責任が持てません、自分は何も知らないから、と、自分の能力が無い事実をさらけ出しているだけだ。
自分の無能さを顧客の前にさらけ出して、恥ずかしくないのだろうか？

よって、ジュニアのエンジニアも、顧客の前ではアーキテクトとして振る舞うべきだ。
それができないならば、彼は顧客の前に立たない方が良い。

【3】デブサミ関西に行ってきて感じたことは、インターネット老人会のようなおじさん達がすごく生き生きとしていたことだ。
AIによりプログラミングの実装コストがゼロになったことで、リファクタリングやバックポートなどのような地道な作業から解放されて、本来のやりたいことを実現しやすくなったように思える。

サーバーやネットワーク、CPUアーキテクチャやC言語のポインタ、Linuxカーネル等のレベルの知識があるからこそ、彼らは最適なアーキテクチャ構成を考えることが出来る。
その後の開発作業、具体的には、多数の部品やインフラ基盤、開発基盤を組み合わせて協調動作させる開発作業は全てAIに任せれば、即座に実装できる。
インターネット老人会のような経験者にとっては、すごく楽しい時代になったんだろうな、と思う。

AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi

デブサミ関西2026に参加してきた。
デブサミ関西2026で踊る「AIによる自動化」や「FDE」の波。一見スマートな潮流に違和感を覚えたのはなぜか？
AI時代のプログラミングの本質、ITビジネスの構造、そして20年続くコミュニティの絆から、エンジニアが手放してはならない「思考の領域」と真の資産を考えてみた。
感想をラフなメモ書き。

Developers Summit 2026 KANSAI（2026.08.21）

【1】講演者の大半は、AIで手作業のプログラミングはなくなる、価値創造にフォーカスを当てるべきだ、エンジニアもビジネスにシフトしようと言っているが、むしろ、僕は、AIが普及しても人間によるプログラミング、アーキテクチャ設計は変わらないと思う。

確かに、AIによるプログラミングの方が人間の手作業によるプログラミングよりも高速で品質も一定だ。
人間のプログラミングは、漏れが多く、考慮する範囲やレベルも一般的に低い。
しかし、そんな状況でも、AIよりも人間のプログラミングが重要な点は2つある。

1つ目は、AIのプログラミングは、無駄にたくさんの機能を作り、無駄にたくさんの仕様を盛り込みすぎて、品質基準を超過しすぎる。
人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる: プログラマの思索
AIは高速かつ品質基準もクリアできるために、無駄に作った機能がないか、変な方向に機能作り込みしていないか、人間がコードレビューしている感じだ。
つまり、人間もAIが作ったコードを読んで理解する必要があるので、プログラミング力が不要になることはない。

2つ目は、ソフトウェのあるべき姿を考える時に、人間もプログラムという肝心の部品を理解する必要があるからだ。
AIは高速かつ品質基準もクリアできるツールなので、極端に言えば、システム中身のソフトウェアもアーキテクチャも、ブラックボックスでいい。
つまり、プログラミングやアーキテクチャも知らなくても、テスト駆動開発で仕様を満たせれば、中身のソフトウェアが汚くても無関係だ。
なぜならば、AIでいつでも作り直せるならば、いくら大規模なシステムでも、プロトタイプを作る感覚で、何度でもリプレースしてしまえばいい。
アーキテクチャもプロトタイピングの都度、極論、何度でも大幅変更しても、AIで対応できてしまうからだ。
大規模システムを今日はJavaで作った、明日はC#で作り直した、明後日はRubyで作り直した、1週間後にはRustで全部作り直した、というやり方も、AIなら問題なく可能だ。
AIなら、じきに品質保証という監査プロセスそのものもAIで自動化できるだろう。

AIによるプログラミングは、20年前に流行したモデル駆動開発やノーコード開発と同じだ。
プログラミングを知らなくても、GUIの設計だけでプログラムを自動生成すればいいという考え方だ。
今でも、SalesforceやKintoneによるローコード開発も似たような発想だ。

Xユーザーのakipiiさん: 「AIでプログラミング代替により、プログラムは使い捨てになる。あるいは昔のノーコード開発になる。本当にそれがあるべき姿なのか？僕は違うと思う。 #devsumi」 / X

モデル駆動開発、ノーコード開発、ローコード開発であれば、アーキテクチャを考える必要性はない。
すでにアーキテクチャが存在している前提で、アプリ層のビジネスロジックを実装するだけ、という発想だからだ。

しかし、それが本当のソフトウェア開発なのだろうか？
ソフトウェア開発にアーキテクチャなんて無視して、ビジネス要件さえ満たしていれば、中身はブラックボックスでよくて、QAなんか無関係で、ソフトウェア工学も品質保証も無関係でいいのだろうか？

僕は違うと思う。
AIがこれだけ高速かつ高い能力を持ったとしても、ソフトウェアのあるべき姿を思考する行為そのものは自分の範疇に納めたい。
AIが本当に良いソフトエアを作ってくれるのか、その仕組は理解したい。
AI自体の思考プロセスを理解したい。
アーキテクチャを自分が指定して、AIに指示させたい。

上記の理由は中途半端だけど、思考プロセスそのものをAIに手渡したくないのだ。

【2】FDE（Forward Deployed Engineer）はパランティアのエンジニアのモデルから生まれたらしい。
FDEは、ソフトウェア派遣委託のSESと同じだと思う。

Xユーザーのakipiiさん: 「#devsumi FDE（Forward Deployed Engineer）はパランティアテクノロジーズのビジネスモデルから生まれた、とスピーカーから聞いた。それなら理解しやすい。」 / X

FDE（Forward Deployed Engineer：前線配備エンジニア）とは、顧客企業の現場（最前線）に直接入り込み、自社プロダクトやAI技術を用いて、課題の発見からシステムの迅速な実装・運用改善までを一気通貫で担う職種だ。
確かに、従来のSEのように、顧客先に常駐して、顧客の要望に従って、WF型開発に沿って受託開発するわけではない。

しかし、外側から見れば、客先に常駐して、顧客の要望を収集したうえでプログラミングしてシステム開発スタイルは変わらない。
従来のSESであれば、顧客から指定されたアーキテクチャやWF型開発プロセスに従ってプログラミングするだろう。
一方、FDEは、自社のフレームワーク、特にパランティアのようなオントロジーのフレームワークの上でシステム開発して高速に開発サイクルを回し、顧客に確認しながらシステムを順次提供していくだけだ。
つまり、SESとFDEの違いは、ソフトウェア開発の基盤が違うだけで、ビジネスモデルは全く同じだと思う。

せいぜい、SESは準委任契約だろうが、FEDは成果連動の契約つまり請負契約に近い契約なので、その点は違うだろう。

【3】では、僕がなぜ、FDEはSESみたいだね、ビジネスモデルも契約形態もそんなに変わらないと思う理由は何なのか？
理由は、マッキンゼー、デロイト、アクセンチュアなどの大手ITコンサルタントであっても、彼らも客先常駐ないし客先と準委任契約中心の高級派遣業であって、SESの契約形態と本質的に変わらないと思うためだ。

SESはWF型開発従った受託開発のビジネスモデルだ。
いわゆる人月ビジネスであり、従来から凄く批判されている。

一方、アクセンチュアのようなITコンサルタントも、SESから高級派遣業にアップグレードしたに過ぎない。
どれだけのコンサル人数を入れて、売上を増やしていくか、というビジネスモデルだ。

FDEも客先常駐のスタイルは変わらない。
ただし、客先指定のオレオレ開発基盤の受託開発から、AIによる自社オントロジー開発基盤の受託開発に変わっただけだから。

【4】デブサミ関西に久しぶりに出たら、10年以上前に関西アジャイル開発コミュニティで一緒に活動していた仲間からたくさん声掛けしてもらって、まるでOB会みたいな感情が沸き起こった。
以前の会社の職場にいた同僚や上司も昇進していたし、その他の仲間も職場を変えても皆活発に活動されていた。

年数が経っても、昔は一緒に苦労したね、昔も楽しかったね、今も一緒にやろう、みたいに言える雰囲気があるのは楽しい。

会社に所属する期間は所詮65歳定年までであって、会社から離れると、守秘義務などもあるので基本的に関係はなくなる。
しかし、コミュニティ活動で一緒に苦労し何かを達成した仲間は、いくら転職しても、フリーランスで働いても、無職になっても、長年一緒に経験した人間関係は一生残る。

プライベートな人間関係につながるからこそ、ビジネスを超えた環境であっても、その人の人柄や能力、人格が優れていれば、自然に人は集まる。
人間関係は細く長く続けることで、その偉大さを20年後に初めて感じるわけだ。

今後も色々やっていきたいと思う。

Redmine × AIがプロジェクト管理を変える：祝・Redmine20周年！RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan

RedmineJapan Vol.5の司会を全うした。
すごく楽しかった。

【参考】
Redmine Japan ≫ Redmine Japan Vol.5

REDMINE JAPAN vol.5 オフライン開催＠ワテラスコモン - connpass

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

ドメイン駆動設計をはじめよう

【1】Redmineコミュニティは、高校の部活、大学のサークル、文化祭に似ている。
皆でワイワイガヤガヤ一緒にやるのが楽しい。
何かの目標に向かって、若気の至りをフルに使って、好きなことをやるのがいい。

大の大人が30代、40代、50代になっても、高校大学のノリで騒げるのが好き。
OSSコミュニティだからこそ、そんな雰囲気を楽しめる。

【2】RedmineJapanの講演で興味を引いたテーマは2つある。
1つは、NTTドコモソリューションズ、東芝、島津製作所、パナソニックなどの大手企業のRedmine運用の話。
もう一つは、RedmineとAIの話。

【3】大手企業のRedmine運用では、ユーザ1千人以上がRedmineを使っている。
興味を引いたのは、Redmineがいかに社内で浸透して使われて成果を出している、とアピールするために、色んな定量データを準備している点だ。
正直、ユーザ数、チケット数の時系列推移だけでもいい。

大手企業の中でRedmine運用が成果を出しているとアピールしなくていはいけない理由は何か？
Redmine運用は所詮、管理コストなので利益はないから、コストセンターに過ぎない。
よって、Redmineが活発に使われて、社内では無くてはならないツールなのだ、と社内で、特に経営層に アピールしなくてはならない。
だから、色んな定量データを集めて、目に見える形にする必要がある。

今なら、ユーザCSV、チケットCSVを出力すれば、AIに食わせて、要約や傾向分析、洞察まで出してくれる。
そこから色んな知見が得られる。
ここにも、AIがRedmine運用に新たな知見をもたらした事例が出てくる。

【4】Redmineが最近盛り上がってきた理由は何なのか？
理由は、RedmineとAIの相性が良いからだ。

AIは、MDファイルのようなテキストをインプットとして扱う。
Redmineに蓄積されたチケット、WikiをCSV出力すれば、AIに食わせて、要約、傾向分析、洞察が簡単に得られる。
最近、Wiki一括ダウンロード機能がリリースされたが、その意図は、AIに食わせたいことにあるだろう。
日々の作業やナレッジをRedmineに蓄積する運用ができていれば、AIに食わせて色んな使い方が出てくる。

問合せチケットをCSV出力してAIに食わせれば、問合せの傾向分析で有用な結果が出るだろう。
障害チケットも同様だ。

全文検索プラグインにAIもミックスして、セマンティックサーチする講演もあった。
つまり、異音同義語のような表記揺れもAIが上手く吸収して、検索機能を強化してくれる。
すなわち、Redmineに蓄積されたデータをさらにフル活用して、有用な結果を得る機能を強化してくれる。

一方、Redmine AI Helperプラグインは、チケット入力補完や子チケット分割、表記揺れ対応などもサポートしてくれる。

他に、RedmineにMCPサーバ機能を追加して、Teamsと連携して、Teamsチャットからチケット作成する事例もあった。
RedmineにMCPサーバー機能が追加できれば、Teams、Outlook、GitHub、Slackなど外部リポジトリと連携して、更に強力にチケット入力やチケット検索を支援できるだろう。
ボウコバさんから聞いた話では、PCログなどもAIに食わせれば、PC作業者が1日でどんな作業をしたのか、その作業がどのチケットに紐づくのか、チケットの実績工数を支援する機能も可能だ、と話されていた。
つまり、Redmine実績工数入力をAIが支援してくれるわけだ。

たとえば、Redmine実績工数入力をAIが支援し、予定工数を入力できる運用ができれば、EVM出力も可能になる。
RedmineでEVM出力できれば、各PJの週次報告の定量データとして扱えるメリットがある。
PJ報告の文章は、RedmineチケットからAIが自動生成すればいい。
つまり、Redmine上でPJ報告を作成する管理工数をAIが減らしてくれる。

従来は、RedmineでEVM出力は可能だが、予定工数や実績工数の入力が大変で、手間がかかる割にはメリットが少なかった。
しかし、RemdineとAIを組み合わせれば、全てのプロジェクト管理をRedmine上で一括管理できるハードルが劇的に下がるはずだ。

RedmineとAIの組み合わせは、プロジェクト管理の手法に新たな可能性をたくさん引き出してくれる。

【5】他には、製造業のRedmine運用は、SIerのRedmineと異なる点があることだ。

SIerでは、1案件に基本は作業者が張り付き、兼務する場合は少ない。
兼務する作業者は、インフラ担当のように案件共通で基盤構築が必要な場合だけだ。

一方、製造業では、1担当者は複数案件を兼務し、1案件に薄い工数で張り付く。
なぜならば、製造業は機能別組織なので、1案件に多数の専門技術者が一定期間だけ関与する体制だからだ。
たとえば、製造業では、営業部門、R＆D部門、設計部門、調達部門、製造部門、建設配置部門、品管部門のように、事業部組織よりも機能別組織が一般的だ。
よって、1案件の各工程で、専門の技術者が担当し、工程が分断された形で工程管理する。
1担当者は複数案件を兼務するので、事実上、製造業の組織はマトリクス型組織になる。

マトリクス型組織のデメリットは、２ボス体制になるので作業者のレポートラインが複雑になりがちなこと、部課長は要員計画を立てにくくなることだ。
作業者は案件のPM、自組織の上司の２人に報告する必要があるので、意思決定が食い違うと迷ってしまう。
また、部課長は、複数案件を自組織で責任を持つが、どの期間に誰を担当させるか、意思決定が難しい。
なぜならば、一般的に、PJ横串で毎月これくらいの予定工数が必要と集計されたデータは出てくるが、どうアサインすべきか、具体的に判断しづらいからだ。

つまり、製造業の工程管理では、単純な進捗管理だけではなく、工数管理もRedmineでやりたくなる。
製造業では、PL、BSだけでなく製造原価報告書も会計上必須なので、元々工数管理を厳格に管理する動機はある。
しかしそれだけではなく、要員管理、つまり負荷計画をきちんとやりたい動機もある。

Redmine標準の機能ではリソース管理は難しいが、LycheeRedmineならば、リソースマネジメントやタイムマネジメントの機能もあるので、予定・実績工数入力をきちんと運用できれば、生産性・稼働率も集計表示してくれるメリットがある。
ただし、LycheeRedmineの機能はかなり複雑にカスタマイズしているので、相当な調査が必要だろう。

製造業特有の工程管理や原価管理と、LycheeRedmineの操作や利用シーンを理解する必要があるので、かなり難易度の高いプロジェクトマネジメント技法になると思う。

【6】まあ、とにかく楽しかった。
昨日は、Redmine誕生20周年だったので、皆で20周年記念のケーキで祝ってを食べた。
すごく大きくて迫力のあるケーキだった。
また来年も開催してくれるので、すごく楽しみにしてる。

【7】現代チケット駆動開発の課題とマイクロマネジメントの罠を再定義する話をショートプレゼン20連発で話してきた。

プ譜でプロジェクトの目的を管理する

オープンソースカンファレンス大阪にてプ棋の話を聞きたくて参加してきた。
プロジェクト管理の一手法として、目的や課題の管理に使えないか、今実際に使っているが、まだ腑に落ちてない。
講演者に実際に質問をぶつけてみたら、将棋の棋譜みたいにプロジェクトの局面をストーリーや歴史みたいに鳥瞰できる感覚が掴めた。
ラフなメモ書き。

【参考】
紙1枚に書くだけでうまくいく プロジェクト進行の技術が身につく本 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

見通し不安なプロジェクトの切り拓き方 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

予定通り進まないプロジェクトの進め方 | 前田考歩, 後藤洋平 |本 | 通販 | Amazon

プ譜の書き方と書く“意味” ?あなたの成長を支える“構造と思考の地図”?｜前田考歩

1月31日(土) タイムテーブル - オープンソースカンファレンス2026 Osaka

【プ譜友の会】プロジェクトの「不確実性」を定量評価する挑戦！ - セミナープログラム - オープンソースカンファレンス2026 Osaka

【1】プロジェクトで仕事している時に一番問題に感じることは、目的を忘れて作業に没頭してしまい、見失ってしまうことだ。
もちろん、プロジェクト計画も作るし、プロジェクト憲章も作るし、WBSも課題管理表も作って管理する。
しかし、実際の仕事は、目的を考える時間よりも、たくさんの打合せや資料作成などの実作業にほぼ時間を取られてしまう。

なぜ、そんな計画を立てたのか？
そもそも今の作業は効果があるのか、正しい目的に沿っているのか？
課題に対する対策は、本当に効果が出ているのか？
その判断は正しいのか？

日本人の技術者も担当者も、実作業が与えられたら真面目にやる。
しかし、作業に没頭してしまい、その作業の目的、正統性、効果測定を忘れてしまう。

プロジェクトは、経営目標や経営戦略に沿って作られるものであり、経営目標に対してそのプロジェクトがどれだけ貢献したのか、成果や効果を評価すべきだ。

そこで、プ譜というツールを使ってみる。

プ譜は端的には、目的に対する施策とその評価結果をプロジェクトの各局面で履歴として残し、将棋の棋譜みたいに追跡できる仕組みだ。
つまり、プ譜はToBeとAsIsを端的に表した1枚の図だ。
実際のプ譜のPPTテンプレはすごく単純だ。

それはプロジェクトの各局面のスナップショットであり、プロジェクト完了時にふりかえれば面白い。
プロジェクトリーダーが課題を適切に管理できていたのか？
その判断は正しかったのか？
その意思決定を間違えていたら上手く元々の軌道に戻せたのか？

すなわち、プロジェクトリーダーの意思決定をふりかえり、自分自身の意思決定の質を上げていくための処方箋にもなりうる。

プ譜はプロジェクトリーダー向けのツールだと思う。

これから使いこなしてみたいと思ってる。

第22回 Redmine大阪の感想 #RedmineOsaka

第22回 Redmine大阪の感想をメモ。

【参考】
2025/9/21 第22回 Redmine大阪 #RedmineOsaka - posfie

Redmine-osaka-022 - Redmine.Osaka

入門Redmine第6版 : 石原佑季子, 前田剛: 本

5年ぶりの開催で盛り上がりを心配したが杞憂だった。
スタッフも参加者もテンションが高くて楽しかった。
東京、岐阜、福岡から参加者が来てくれた。
初めての参加者も若手で数人おられたが、すぐに馴染んで、本音ベースで話せた。

講演内容も多様だった。

【1】前田さんの話では、Ver4以前のRedmineは最新機能が全く取り込まれていないので、早くアップデートしましょうという主張だった。
メンション機能、チケット一覧での検索、フォントサイズやフォントの変更、テーブルタグを見やすくするUI改善が目に留まった。
次バージョンでは、いいね機能もリリースされる。
昨今のスマホのようなUIを取り入れていく改善は、地味だけれども、ユーザ体験をより良くするために重要だと思う。

【2】赤羽根さんの話では、チケット20万件以上、ユーザ数3900人以上の大規模な運用事例。
製造業という非常に縦割り組織の中で、10年以上Redmineを運用して、設計情報をRedmineに蓄積しナレッジ基盤とした運用はすごいと思う。
後で聞いた話では、Redmineをフローの管理、つまりタスク管理や進捗管理に使うのではなく、チケットに設計情報や製品に関する情報だけをどんどん蓄積していく運用に振り切った、とのこと。
だからこそ、10億字以上の文字が蓄積されるわけだし、全文検索エンジンGroongaの必要性が出てくる流れを理解できる。

【3】三浦さんの話では、自分はなぜかドキュメント管理の整備にアサインされるという話から始まって、ドキュメント管理の経験を語られた。
Wikiでナレッジが集約されるメリットがある反面、ドキュメントは負債にもなり得ること、ドキュメントの保守には工数がかなりかかる。
インセンティブや強制力を使って、ドキュメントを残し集約し、検索できるようにする基盤として、Redmineも候補になりうる。

【4】アジャイルウェア様の会場をお借りして本当に楽しかった。
広くて綺麗で、液晶モニタもすごく大きくて、プロジェクタ無しで投影できて素晴らしい会場だった。
ありがとうございました。

【5】Redmineコミュニティの良い所は、講演内容がRedmineの機能紹介やカスタマイズに偏ることなく、運用事例やプロジェクト管理、情シス部門の考え方、ナレッジ蓄積やタスク管理の考え方まで幅広く紹介されること。
このあたりが面白いなと思う。
だからこそ、かなり特殊なコミュニティもかかわらず、テーマが多様なお陰で、コミュニティが長続きしているのだろうと思う。

また次回も開催したいなと思います。

「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT

第27回redmine.tokyo勉強会で講演された「RedmineのUbuntu+Docker構築への移行」は内容が参考になったと思う。
ラフなメモ書き。

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

発表 #1609: 第27回 講演: ＜RedmineのUbuntu+Docker構築への移行＞ - redmine.tokyo

【1】今回の講演の背景としては、問題意識として、RedmineをCentOSで利用している場合、どのOSへ移行したら安全なのか、容易に移行できるのか、がある。
おそらく、Redmineはフリーで現場で使っているので、OSやサーバも自前で構築する時にCentOSを利用しているケースは非常に多い。
そこで、CentOSはサポート切れになってしまった状況では、セキュリティリスクがあるために、どこかのOSに移行せざるを得ない。
OSSのLinuxOSは数多くあるが、どれが最適であるのか？

さらに、どのOSが最適なのか、そして移行作業としてどれだけの工数や難易度が発生するのか、という問題も発生する。
RedmineというWebアプリ程度なら簡単だろうと思っていると、RubyやOSのバージョン、プラグインとの相性など色んな点で地雷を踏んでしまうリスクがある。

そういう背景を踏まえて、本資料を読み直すと価値があると考える。
本資料では2つの観点で整理できると思う。

【2】1つ目は、本資料では、CentOSからの移行先OSとして、Ubuntsを選択している。
移行要件詳細①を読むと、Ubuntsを選択している理由は明確だ。
s
Ubuntsを選択した理由を品質特性の観点で整理すると下記になる。

リリースの歴史が長く突然停止の可能性が低いこと
　→OSとして成熟しており、信頼性が高いと想定。

LTSの定期的な提供、2年単位の最新版提供により最新の機能が使える
　→最新の機能が使えるので、機能適合性が高いと想定。

Webクライアントとしてのシェアが高くナレッジ豊富
　→障害が発生しても障害解決の知見が豊富なため、信頼性(耐障害性)が高いと想定。
　→Ubunts上では、他のソフトウェアと共存し使用できる知見が多数あるため、互換性が高いと想定。

x86やARM等アーキテクチャを問わず稼働し、汎用性に優れる
　→x86やARM等アーキテクチャなど幅広く移植できるため、移植性が高い。

CentOS互換系のOS特有の機能を使わないのでCLIでよい
　→CLIでメンテナンス用プログラムを作成できるため、保守性が高いと想定。

CLIに慣れる事でLinuxに対する耐性や知見を上げる
　→CLIに慣れれば、UbuntsOSはCLIで操作しやすいため、使用性が高いと想定。

すなわち、信頼性、機能適合性、信頼性、互換性、移植性、保守性、使用性などでUbuntsの品質は高いと分析されている。
品質特性のかなりの数の観点が網羅されており、実際にRedmine移行で成功されたことを考慮すれば、Ubuntsを選択した理由には妥当性があると考える。

もちろん、RockyLinuxなど他のOSも候補に入るだろうが、普及されているUbuntsは移行先の有力候補になるだろうと思う。

【3】2つ目は、本資料では、Redmineの移行を今後も考慮するためにDockerを採用されていることだ。

vSphereの期限切れという事情もあるだろうが、Hyper-VとDockerのような仮想基盤の上にアプリ層を乗せる方が、今後の移行作業もコピーするだけでよく、作業しやすくなる。
「Redmineの移行」ページにソフトウェア構成図が記載されていて、Redmineが乗る基盤が層別に整理されていてイメージしやすい。

また、Dockerイメージを複製することで、移行後の動作検証やプラグイン検証、性能検証なども並行作業で実施しやすくなる。
本資料で注目すべき点の一つは、Redmine本体のDockerイメージ(sameersbn / redmine)とプラグイン込みのRedmineのDockerイメージを区別して準備されている点だろう。

既に準備されているRedmine本体のDockerイメージを利用する理由は、Webサーバやバックアップなどの基本機能が既にあり、プラグイン無しの標準機能がそのまま使えることだろう。
つまり、プラグインを使わずRedmine本体の標準機能だけで使うならば、公開されているDockerイメージをそのまま流用するほうが品質も担保されているし、検証や移行などの作業工数も無駄に使わなくていい。

一方、プラグイン込みのRedmineのDockerイメージはカスタムイメージで独自作成されている。
Lychee RedmineやFull Text Search等のプラグインを使われているそうなので、それらの動作検証を入念に行われたと記載されている。
確かに、プラグインの動作はRedmineのバージョンやプラグイン同士の相性、OSの相性にも依存するため、Dockerのカスタムイメージを作成した方が、プラグインを1つずつ入れて検証OKのDockerイメージを作りやすく、事前検証の先祖返りのリスクもないだろう。

本資料を読むと、View Customizeで改良した部分が動作しなかったり、Lychee Redmineのガントチャートの日本語表示はOSの日本語フォント配置で解決したり、応答速度低下のクレームにはインスタンスのスケールアップやMariageDBのチューニングで改善されたりしている。
やはり移行後には予期しないクレームも発生するので、色々対応せざるを得ない。
そんなケースでもHyper-VとDockerを使っているなら、インスタンスの性能チューニングも簡単だし、Dockerで移植し直すこともできる。

分かってしまえば簡単な内容かもしれないが、やはり実際に移行してみないと分からない時も多い。
そういう試行錯誤された事例として非常に価値ある内容と思う。

入門Redmine第6版 [ 石原佑季子 ] 価格：3,080円（税込、送料無料) (2024/11/24時点) 楽天で購入

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

本日、第27回redmine.tokyo勉強会にスタッフとして参加した。
非常に楽しかった。
ラフなメモ。

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

redmine.tokyoで第二回プロジェクトマネジメントあるある！　#redmineT | マドびっ！ Madosan's View

【0】今回もプリザンター様の会場を利用させて頂いた。
とてもきれいな場所で、映像や音声もきれいで、そのまま懇親会の会場に使えるので、とても素晴らしい会場でした。
いつも本当にありがとうございます。

【1】今回の勉強会はオフラインで久しぶりに約45人も集まってくださり、雰囲気も良くて盛り上がったと思う。
大阪、京都、松江、山梨など遠方から参加してくれた人もいた。
一方、懇親会などで話してみて気づいたのは、初参加の人が多かったことだと思う。

10年以上続けているとどうしても常連さんが多くなり、居酒屋でローカルに盛り上がっている場みたいになって、雰囲気も停滞してしまう。
しかし、初参加の方や若い人が入ってくれると、フレッシュな気分になるし、入りやすいコミュニティの雰囲気も出てくるし、気付きもある。

年2回程度で開催するのが、飽きることもないし、スタッフも準備に苦労するほどでもなく、ちょうどいいのかもしれない。

【2】発表内容は今回も多様だったと思う。
Redmineというプロジェクト管理ツール、チケット管理ツールの機能面、技術面の話だけでなく、情報の追跡性や保持の観点、プロジェクトマネジメントの観点、ISMS運用などの運用の観点もあった。
参加者にはなにか1つは心に残るものがあったのではないかと思う。

第27回勉強会 - redmine.tokyo

講演も盛り上がってしまって、15分ほど延長するくらい濃い内容だったと思う。

【3】最後に告知タイムがあったが、川端さんより、ウクライナにいるRomanさん会社の開発者がアジャイルウェア社と一緒に仕事することになった、とご報告があった。
前回6月の勉強会では、ウクライナ人のRedmine開発者Romanさんのショート動画を紹介した。

第26回redmine.tokyo勉強会の感想～多様性はコミュニティが成功する重要な要因の一つ　#redmineT: プログラマの思索

ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン: プログラマの思索

川端さんのお話では、Romanさんはウクライナに住んでいて、戦争の影響を受けている。
Romanさんの会社は5人の社員がいたが、戦争のために2人になっていて、今も戦争によるインフラの影響を受けながらRedmineの開発をされている。
アジャイルウェア社の技術者とコンタクトを取れたので、今後Redmineに関する開発を一緒に行っていくことになったとのこと。

Redmineというオープンソースのツールの中でもそんなに大きくなく小さなコミュニティであっても、時代の影響、そして世界の状況を垣間見るような事例だったと思う。
少しでもコミュニティから役立ててもらえればと思う。

【4】@netazoneさんが、今年もRedmineアドベントカレンダーを作ってくれました。
興味のある方はぜひ、ご参加してみてください。
一緒に楽しめればいいなと思います。

Redmine Advent Calendar 2024 - Adventar

第26回redmine.tokyo勉強会の感想～多様性はコミュニティが成功する重要な要因の一つ #redmineT

第26回redmine.tokyo勉強会にスタッフとして参加してきた。
久しぶりに常連や新しく知り合った人たちと話して気づいたのは、多様な属性の人達が集まり多様なテーマで議論するのがコミュニティの醍醐味ではないか、と思った。
ラフな感想をメモ書き。

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

2024/6/15 第26回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

プリザンター｜OSSのノーコード・ローコード開発ツール

【1】勉強会の場所は、OSSツールPleasanterを運営しているインプリム様の会場を借りて開催した。
映像、音響も非常に良く、そのまま懇親会の会場で、宅配のピザ、缶ビールやジュースの買い込みもできて、バーのカウンターもあって盛り上がった。
インプリム様には快く会場を提供して頂き、非常に感謝いたします。

今回の勉強会で気づいた内容をメモしておく。

【2】OSSツールPleasanterは、C#で作られたノーコード・ローコードツール。
前回の勉強会で、Redmineと連携してチケット作成などの機能をデモされた。
個人的には、こういうノーコード・ローコードツールは日本人に向いていると思う。
理由は2つある。

1つ目は、データベース設計さえきちんと設計できれば、画面や帳票はプログラムレスで初心者でも開発できること。
つまり、いわゆるノーコードツールはデータベース設計が肝。

データの格納場所は後で安易に変更しづらいし、テーブルに依存した画面設計になるので、テーブル設計がぐちゃぐちゃだと画面そのものも使いづらくなる。
テーブル設計に業務フローやビジネスルールの制約条件を反映するように設計すれば、無駄なロジックを実装する手間も減るし、画面開発も楽になる。

幸いなことに、データベースモデリングの技術は枯れているし、渡辺幸三さんなどの本で優れたノウハウはあるので活用するだけでいい。

2つ目は、日本人は現場で生産性向上のためにプロセス改善、業務改善するやり方に非常に強いから。
以前のメーカーのQCサークルもそうだろうし、Redmineがこれだけ日本各地で使われているのは現場で気軽に使って業務改善するやり方が日本人の気性に向いているから。
よって、ノーコード・ローコードツールのように、業務改善に気軽に使える道具は日本人の気性に非常にマッチすると思う。

たぶん、戦略的にトップダウンで設計や標準化するよりも、現場で改善する方が日本人に向いているように経験的に感じる。
それが日本人の良い点でもあるし、日本人の弱点であるのかもしれない。

【3】@g_maedaさんの講演では、Redmine本の出版に合わせて20年近いRedmineの歴史を振り返っていた。
気になった点は、Redmineの弱点と、その裏返しとなるメリットの観点だ。

特に直近5年ほどは、Redmine本体の機能も枯れてきており、ドラスティックな機能追加はほとんどない。
つまり、Redmineは安定してしたツールであり、一方、少しずつ時代に遅れつつある面も否めないと思う。
backlogやJira、Asanaなどのツールに比べると、機能改善の速度はやはり違う。
その理由はいくつかあるだろう。

JPLを含む少人数の開発体制が変わっていないこと、UI/UXではシングルページアプリケーションのままで画面遷移や画面更新に手間がかかりやすいこと。
チケットトラッキング機能以外に大きな機能追加が行われていないこと。

アジャイルウェアさんも同様の問題意識を持っており、RedmineのUIや機能をドラスティックに変えにくいので自分たちでRedmineクローンを公開し、Redmine本家にバックポートしていく戦略を話されていた。
ウクライナ人開発者のRomanさんも、RedmineのUIを昨今のスマホ・タブレットを意識したテーマに変更してアピールしていた。

一方、LTでも懇親会でも議論されていたが、Redmineの古いUI/UXが逆にユーザに安心感があるメリットもある、と言う。
RedmineのUIは古いと言われるが、逆に15年近くほとんど変わっておらず、使い慣れている。
JiraのようにいきなりUIが変更されるとユーザも混乱しやすい。

Redmineはシングルページアプリケーションでないけれど、画面更新や画面遷移に必要な機能は分かりやすいし、操作に慣れると、勝手に変更される方が戸惑いやすい。
たとえば、汎用機やクラサバの頃のUIのように、画面にたくさんのボタンやテキストが左から順に並んでいて、キータッチで入力する方がやりやすい、と。

すなわち、RedmineのUIが古いと言われるデメリットは、換言すればUIが変更されておらず一貫性があるので、日本人の気性ではメリットの一つでもある。
そういう観点があると知ったのは面白かった。

【4】今日の勉強会で面白かった点は、Redmineという一つのツールで数多くのテーマで議論できる内容があることだ。
今日の講演では少なくとも5つの観点の事例があった。
情シス、プロジェクト管理、ITIL、性能チューニングによるインフラ運用、プラグイン開発やテーマ開発などのようなRuby開発の観点だ。

【4-1】@netazoneさんの講演では、メーカーの情報システム部門の立場から、人事・総務・営業などのバックエンドの業務をチケット化することで、タスク管理の漏れをなくし、作業の経験や反省点を次回の作業に改善するようにナレッジ化していた。
つまり、会社のバックエンド業務を一括管理してナレッジ化するために、情報システム部門がRedmineを効率的に利用して業務改善している事例だった。

【4-2】@madowindowさんのディスカッションでは、プロマネやPMOの立場から、WBSの管理や策定方法、プロジェクト運営でリスクを感じる兆候の管理、たとえば、進捗90％症候群、頑張ります発言などを話されていた。
つまり、RedmineをSIerのプロジェクト管理に適用するやり方になる。

また、@ta_ke_chan_ さんのLTでは、工場での工数管理にRedmineを利用されていた。
つまり、プロジェクト管理のうち、労務管理やコスト管理、原価管理に適用した事例になる。

【4-3】岩崎さんの会社のRedmineプラグインの話は、ITILの観点で、障害チケットをツールが自動起票して漏れなく一括管理し、電話応答する機能まで実装されていた。
つまり、ITILのようなサービス運用やヘルプデスク管理の観点で、Redmineを効率的に利用して業務改善する事例だった。

【4-4】@akahaneさんの事例では、島津製作所の計測機器に関する事業部でRedmineを全面展開し、Redmine単体1つだけで日々の業務を全て管理されている。
その時に、約３千ユーザ、数十万チケットをRedmineでスムーズに運用するために、RubyのJITコンパイラによる高速化、アプリサーバやDBMSなどの性能チューニングを施して、Redmineがバージョンアップしても高速化を実現していた。

この講演の肝は、Redmineにプラグインを入れないだけでなく、Redmine本体には一切手を入れず、Redmineの外側のインフラ基盤だけで性能チューニングを図ることで、高速化を実現していることだ。
つまり、Redmineに関する知識だけでなく、ApacheやDBMS、VM、通信帯域などのインフラ基盤の技術も必要であることを示唆している。
こういう高度なインフラ基盤の知識が必要な理由は、システム計監査やBCP対策で非常に厳しいビジネス要求に対応する必要があったからだ。
RubyやRailsの開発経験だけでなく、インフラ基盤の経験も相当必要なので、かなり高度な運用内容になっている。

【4-5】ウクライナ人のRedmine開発者Romanさんの事例では、自社で開発されているRedmineテーマやプラグインを紹介されていた。
彼のLinkedInのプロフィールを見ると、開発者の経験が豊富であり、Redmineについてかなり知識を持っているのだろうと思う。
また、@mattaniさんの事例では、Gemの依存性に関する知見の話だった。
彼らの講演は、RubyやRails開発などのテーマに属する。

【5】以上のように、たった半日の勉強会に過ぎないのに、Redmineに関するテーマとして全く別々の５つの内容が議論されていた。
どれか１つのテーマなら詳しい人は参加者でも多数いると思うが、これら５つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

だからこそ、他の人の事例を聞くことで、自分たちが経験していない事例を聞いて参考にできて、盛り上がる要素の一つになったのではないか、と思う。

Redmineというたった一つのOSSツールに過ぎないのに、多様なテーマが存在しているということは、Redmineはまだまだ今後も発展できる余地がたくさん残されているのだろうと思う。

【6】最後にウクライナ人開発者のRomanさんのショート動画を紹介させてもらった。

Romanさんを知ったきっかけは、LinkedInで彼から僕に問い合わせがあり、LycheeやRedmica、hosting Redmineをやっている企業とコンタクトを取って日本市場に出たい、とのことだった。
Romanさんは自分の会社でRedmineテーマやプラグインを自社開発しており、それを日本市場で販売したい、そのために手を組める日本企業を探していたようだった。
僕は、@_maedaさんと川端さんを紹介した時に、redmine.tokyoで動画で紹介してはどうかと提案したら、彼が快諾してくて、この企画が実現した。

実際は、彼の動画が届くのは勉強会の１週間前でかなり直前になった。
彼から、5月末からウクライナでは電気が不安定で、動画を作るのに時間がかかってしまって申し訳ないと話された。
その話を聞いたとき、ニュースでちょうど、戦争で発電所などのインフラ設備にミサイル攻撃などがあって大変な時期だった、という話を思い出した。
彼の環境は、非常に大変だけれど、そんな中で、オープンソースのツールRedmineに関わって開発に取り組んでいる。
僕らとは違う環境でRedmineという共通のツールに興味を持っている彼に何となく共感したい気持ちがあった。
僕自身ができること、貢献できることは分からないけれど、コミュニティで共有することで何か連帯できればいいなと思っている。

【7】今日の勉強会では、常連だけでなく、新しく知り合った人たちとたくさん話ができた。
常連だけが盛り上がるのではなく、新しく参加した人たちとオフラインの場で一緒に経験を共有することで、より一層結束も強くなる。

Pleasanterの人たちも、こういうユーザコミュニティを作りたいんですよ、と言っていた。
Pleasanterはノーコードツールなので、パートナーと呼ばれる開発者兼利用者と強い関係がある。
それをベースにビジネス展開できている。
しかし、今のPleasanterコミュニティはビジネス色が強いと思われてしまうデメリットを感じている。
だからこそ、利用者自身がコミュニティを立ち上げて盛り上げてくれるやり方を模索している、と。
そんな話を聞きながら、思ったことは２つある。

１つ目は、Redmineコミュニティが長続きしているのは、熱狂的な利用ユーザがいて、Redmineコミッタやプラグイン開発者、Redmineプラグインやサービスを提供するベンダーの間で、活発な互恵関係があることだろう。
利用ユーザが困った問題があれば、利用ユーザはコミッタに聞いたり、Ruby開発者にプラグインの要望を出したり、有償プラグインではこんな機能がほしいなどを投げかけて、問題解決のメリットを得る。
一方、コミッタやプラグイン開発者、Redmineベンダーは、利用ユーザのニーズを直接聞きだすことができ、それをRedmine本体やプラグインの改善に役立てられるし、有償プラグインや有償サービスによりビジネス化できるメリットを得る。
そういうお互いにWin-Winの関係が成り立っているからだろう。

それは意図して作られた関係ではない。
最初は、利用ユーザがコミッタに声をかけよう、プラグイン開発者に来てもらおう、ベンダーにも来てもらおう、という程度から始まった。
そこから、数多くのやり取りを経て、お互いに信頼関係を築くことができて、あの人なら失礼な行為や不利益な行為はしないだろうという安心感が作れている。
そういう長期的な信頼関係が作れたからこそ、コミュニティが長持ちしているのだろう。

もう一つは、Redmineに関するテーマが多様であることだ。
そして、Redmineの利用ユーザや開発者も日本各地にいて多様性があることだ。
今日の勉強会でも、北海道、京都、大阪、福岡から参加者がいた。
さらにウクライナの開発者も動画を送ってくれた。
多様な属性を持つユーザが集まることで、予期しない化学反応が起きて、より熱狂的になれる。
熱狂的な楽しい経験を一緒に共有し、それを何度も続けていくこで、信頼関係を築いていく。
信頼関係がコミュニティを支えてくれる。
そういう体験がコミュニティ運営の醍醐味だろうと思う。

また、僕がブログにRedmineのアイデアをたくさん書き散らした記事について、すごく参考になったと話してくれた人もいて、非常に励みになった。
その人曰く、Redmineでこんな使い方もできる、あんな使い方もできる、という記事がたくさんあって皆読んでいるから、勉強会で盛り上がるのではないか、と話してくれた。
僕自身は強いミッションや使命感もなく、ただアイデアを書き残して公開しないとなかなか寝れなかったというだけだったのだが、そういう人がいてくれて非常に勇気づけられた。

僕自身は、OSSツールのチケット管理ツールRedmineとモデリングツールastahの２つにこだわりを持っている。
この２つのツールを使ったテーマは今後も考えていきたいと思う。

『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost

デブキャリで牛尾さんの講演を聞いた。
「世界一流エンジニアの思考法」を出版されている。

Developers CAREER Boost 2023 （2023.12.09）

デブキャリでこっそりシェアする三流エンジニアが『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法

話が上手いし面白い。
牛尾さんには15年以上前にXP祭り関西2006でXP寸劇にも参加して頂いたこともあり、あの頃の雰囲気を思い出した。

Subject: [ruby:1293] XP祭り関西2 006 in ワッハ上方

XP祭り関西2006 in ワッハ上方 (プログラミング C# - 翔ソフトウェア (Sho's))

【告知】XP祭り関西2006 in ワッハ上方: プログラマの思索

牛尾さんの講演の気づきは3つ。

1つ目は、常日頃から職歴を更新して、アピールできるレベルに随時ブラッシュアップすること。
牛尾さんはアジャイルのエバンジェリストでは超一流だったが、自身曰く、プログラマのスキルは低かった。
だから、マイクロソフトでプログラマになるべく、Githubに書いてアップしたり、エンジニアが来日したらAttendeしたり、色々アピールした、と。
そのためにも、職歴に、第三のスキルを常に磨いて記載するようにした、とのこと。
職歴は、LinkedInのプロフィールみたいなもの。
私はこういう人です、こういうスキルがあります、こういう職歴を積んできました、とアピールできるもの。
自分がより良い職業や職場に行きたいなら、そういうアピールできるものが必要。

一方、会社は「こういう人が欲しい」というジョブディスクリプションを出す。
それを見て、そのジョブディスクリプションに応募する。
その時に、会社が提示したジョブディスクリプションに対し、2つ上のレベルを目指すようにする。
そうすれば他人の目を引くことができるから。

牛尾さんほどの優れたエバンジェリストのレベルであっても、地道に努力されているんだなと思った。

2つ目は、何をやらないか、が大事なこと。
Be Lazyと言っていた。

Xユーザーのakipiiさん: 「Be Lazy。何をやらないか。物量よりもインパクトが大事。日本人は勤勉重視、努力重視なので価値観が正反対だよね。染み付いた価値観を捨てるのは難しい。 #devboost」 / X

どうしても日本人は「努力」が好きなので、全部をやろうとしてしまう。
捨てるのが難しい。

物量よりもインパクト重視。
たくさんできるよりも、何か一つ目立つものが成果として出れば十分。
そういう発想が大事。

3つ目は、「チャンスの時に受けないと次に進まない。受けましょう。」

Xユーザーのakipiiさん: 「牛尾さんが最後に伝えたこと。チャンスの時に受けないと次に進まない。受けましょう。つまり、挑戦しましょう。実力がなくても英語力がなくても関係ないと。 #devboost」 / X

今、牛尾さんはマイクロソフトでAzureファンクションのプログラマをされていると聞いた。
そのきっかけは、米国チームから、新卒に教えるのが得意なエンジニアで採用されたのがきっかけ。
そこからチャンスを掴み、今プログラマとしてバリバリ働かれている。
気後れせずに、チャンスをつかめ、というメッセージとして受け取った。

牛尾さんがすごいなと思うのは、40代を過ぎてから、英語を習得し、エバンジェリストからプログラマへキャリアを転換されたこと。
今までの実績や経験をすべてアンラーニングして一からやり直されたのはすごいと思う。
普通は、今までのキャリアやスキルをベースに深めていくのが普通であって、最初からやり直すのは大変。

本当に自分がやりたいことは何なのか、を深く考えて実行されたのだろうと思う。

第25回東京Redmine勉強会の感想 #redminet

第25回東京Redmine勉強会についてラフなメモ書き。

【参考】
第25回東京Redmine勉強会 - redmine.tokyo

2023/11/5 第25回勉強会 - redmine.tokyo #redmineT - Togetter

【1】前田剛さんによるRedmine5.1の機能紹介。
おそらく目玉機能は、クエリ検索にOR機能が入ったこと、プロジェクト画面やユーザ画面にクエリ検索機能が追加されたことだろう。
チケット一覧のクエリ検索では、SQLライクにかなり複雑な検索が可能になった。

また、全文検索後に、さらにクエリ検索で絞り込む機能も追加された。
利用シーンとしては、たとえば、Issueで検索して全文検索結果が出た後、さらに担当者や期間、ステータスで絞り検索することで必要な情報にたどりつきやすくなる。

つまり、Redmineを長く使い込んでチケット枚数が多い環境ほど、全文検索やクエリ検索の機能強化のメリットが出てくる。
RedmineはナレッジDBであるからこそ、過去の作業履歴から意味ある内容をいつでも検索できる点は重要なポイントの一つだろう。

【2】前橋市役所のRedmine利用事例はRedmineJapanの再演講演。
講演後に4人の質問があった事実からも、この事例に興味を持つ人が少なからずいたことが分かった。

ポイントはいくつかある。
一つ目は、Redmineを運用するためにかなり準備されていたこと。
たとえば、他部署からの問い合わせを受けて、情報システム部門が1次対応し、ベンダーにエスカレーションすべきかどうか判断していること。
ITILの運用を意識しているように見られた。

他には、事業年度ごとにプロジェクトを新規作成していること。
デメリットは、事業年度のプロジェクトに連なる子プロジェクト、チケットがいったんすべてリセットされること。
一方、メリットは、公務員は3年おきに配置転換されて担当がコロコロ変わるし、年度ごとのオペレーションの意義が重要なので、年度末にすべてのチケットを棚卸しするタイミングが発生することもあるようだ。

2つ目は、アジャイル開発のプラクティス、たとえば、KPTによるふりかえりを効果的に利用してプロセス改善活動につなげていること。
3つ目は、他の自治体とも連携してRedmine運用の幅を広げていること。

プライベートクラウドに載せているのでベンダにサーバ運用はお任せしているみたいだが、実運用に注力している点が興味深かった・

【3】RedmineのチケットDBをNoSQLのグラフDBで関連度合いをグラフ化し、関連チケットや類似チケットを表示する機能追加の事例もあった。
特徴は、RDBではチケットの関連度合いをSQL検索するのは時間がかかりすぎるが、グラフDBであれば検索機能もSQLライクに書けて、性能応答もかなり高速であること。
この特徴を活かして、関連チケットや類似チケットをチケット画面に表示する機能を追加したらしい。

レコメンドエンジンをRedmineのようなチケットDBに適用することで、お勧めチケットを表示する機能改善のアイデアは以前からあった。
その場合、機械学習で学習させる事前処理が必要だったが、今回の機能追加では、グラフDBへ格納する事前処理に置き換わった点があると思う。
この辺りのメリット、デメリットを聞いてみたいと思う。

【4】チケット管理システム有識者の集いのパネルディスカッションでは、Redmine・Jira・Asana・Backlogのユーザがパネラーとして意見を述べ合う話があった。

僕が興味深く聞いた点は、3つある。
1つは、プロジェクトとタスクの違いは何か？
プロジェクトは期間や独自性がある点、プロジェクトは引き継ぎの大きな単位、などのツイートもあり、興味を引いた。
やはりプロジェクトの基本は、達成したい目的があり、期間が限定されていることだろう。
実際、市役所での事業年度ごとのプロジェクト、農作業を毎年行う年度のごとのプロジェクトのように、繰返し性や定常業務の意味合いが強くても、何らかの期限を切っている。
そして、そのプロジェクトの作業履歴は過去資産として次年度にも流用する。
そういう観点があると思う。

2つ目は、Asanaのコンサルの方が話されていたが、プロジェクト型の仕事とプロダクト型や定期タスクのようなオペレーションでは、仕事のやり方が異なること。
プロジェクトの仕事はQCD管理が基本。
やはり納期が決まっているので、納期厳守が必須で、それが一番の評価になる。
一方、プロダクト型や定期タスクでは、明示的な納期がないので、日々の改善がタスクになり、プロジェクトという概念があまりない。
評価基準も変わってくる。

3つ目は、Asanaのコンサルの方が話されていたが、プロジェクトに入っているSIメンバーの立場と、既に事業やオペレーションを回しているユーザ企業の立場は異なること。
ユーザ企業であれば、既に事業は回っているし、その事業を強化する課題を一つのプロジェクトに切り出しているだけであって、プロジェクトは一つの部品に過ぎない。
しかし、プロジェクトに入っているメンバーや契約したコンサルは、その中で成果を出そうとするが、その観点が現場寄りであり、ユーザ企業の目線と異なるので、目的や評価が変わってくる時がある。

【5】コロナが終わってオフライン勉強会は3回目だが、盛り上がって楽しかった
Backlog、Jira、Asanaユーザの方から、11月3連休のど真ん中の休日に懇親会までこんなに人が集まるのはすごい、すごい熱気ですね、と言われた。

確かに、北海道、福岡、松江、山梨からも来られている人もいて、本当にありがたい。
また、いつものコアメンバーが盛り上げてくれたし、懇親会で聞くと、土木建築業界のユーザが問題意識を持って初参加されたり、友人紹介で初参加されたり、多様な人が入ってきたのはよかったし、刺激にもなった。

僕も今までたくさんのコミュニティ活動をしてきたけれど、ここまで皆が熱気を持つコミュニティは少ないと思う。
年2回、5月と11月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。