Redmineは組織のナレッジ基盤として実現可能なのか～島津製作所の事例を読み解く #redmineT

redmine.tokyo #27では、@akahane92さんが島津製作所にRedmineを導入し組織のナレッジ基盤として長年運用して成功された事例を講演された。
資料を改めて読んでみて、気づきや疑問もあった。
きちんとまとめたいけど時間がないので、ラフにメモ書きして、疑問形をラフに散らかしている。

【参考】
株式会社島津製作所_研究開発（集団協業と知的生産）の現場を支える、OSS知識基盤システムの導入 - Speaker Deck

Kuniharu AKAHANEさん: 「発表資料 全スライド 85ページ版（SpeakerDeck）です。 Redmine東京＃27、2024年11月9日＠中野 #redmineT https://t.co/52DZPkJfz2 （URL, QRコード は変更なし） https://t.co/QWQYCePqGY」 / X

2024/11/10 第27回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

【1】Redmineを導入し成功した事例では、いつも下記のような2つの疑問が問われる。

【1-1】Redmineの機能と、会社として実現したい問題解決の間にあるフィットギャップ

いくらRedmineが有用だといっても、それぞれの会社で抱える問題は個別であり、他事例を安直に移植できない。
Redmineの標準機能で、会社特有の問題をどの範囲までどのレベルまで解決できるのか？

問題解決に対し、Redmineに不足した機能があるならば、どのような手段を使って解決を試みたのか？
それはどのレベルまで解決したのか？

【1-2】Redmineの運用推進を支えるための組織体制づくり
いくらRedmineが有用だといっても、ツールの機能にプロセスは埋め込まれているわけで、そう簡単にユーザに根付くものではない。
Redmineを日々運用して普及を支える組織体制はどのように工夫しているのか？
どのような運用ルールを組み込んでいるのか？

【2】Redmineの標準機能をどのように使っているのか？

ITSの内部構造：

ITSプロジェクト＝PLM(対象装置、製品)毎に作成
ITSプロジェクト毎にメンバーと権限を付与
チケット＝対象装置に関する解決すべき課題
Wiki＝対象装置に関するメンバー間で共有する情報

ITSプロジェクトはどんな観点でどんな単位で割り当てているのか？
ITSプロジェクト＝1製品
プロジェクトの期間は長い
製品が企画されて設計されて、その後製品が販売終了し保守も完全に終わるまで、プロジェクトは続くと推測
そう簡単にプロジェクトはCloseしない
1つの製品プロジェクトに、数年、数十年携わった試行錯誤のチケットが蓄積される
サブプロジェクトに「研究開発　第◯次」が含まれる

Redmineインスタンスは
「分析計測技術ITS」「分析計測事業部ITS Global」の2つ

「分析計測技術ITS」が元々運用されていた
企画部門・開発部門が中心になって、製品企画から開発まで

「分析計測事業部ITS Global」は製品開発後に、製品そのものの製造・販売・サービス保守などと連携するために作られたと推測
インスタンスをわざわざ分けた理由は何か？
製品企画や製品開発までと、設計が完了して量産化体制に入った製品の生産や販売や保守は、情報の観点や管理する観点、部門間の関連度合いも異なる
「情報流通の壁」
販売情報まで企画や設計も含む1つのRedmineに集約する必要はない

プロジェクト数が1千個まで増えている
たぶん、製品寿命は数年以上と長いのでプロジェクトの生存期間は長い
製品が増えればプロジェクトは単調増加する

とはいえ、プロジェクト数が増えても、アサインされるメンバや権限を制御できれば、実作業するメンバは担当プロジェクトしか表示されないので、困ることはない

チケットの対象は？
WBS作業単位から、要求・仕様のストーリー単位
チケットは作業よりも課題
チケットはIssueとみなす
ITSという本来の使い方

チケットの説明欄の文字数が増えている
その理由は明らか
作業レベルではなく、要求や課題の背景、課題解決の試行錯誤まで書き残す

チケットは共有できる研究開発ノート
「後任者の道しるべ」

ナレッジ基盤としてチケット駆動が活用できるメリット
チケット同士の相互リンク
Wikiに技術勉強会などの共有ナレッジを集約

チケットにSubversionの成果物が紐づく
チケットに成果物の履歴もリンクされる
１チケット＝１クリアフォルダ

研究段階からチケットに記録されて、製品開発の担当者にも知見が共有される
試作した結果も研究者にフィードバックされる
研究や開発の相互の担当者にもメリットがある

チケットに添付ファイルを付ける
添付ファイル数が以前より2倍以上に増えている
製品開発に関わる画像やPDF資料が多いのではと推測
チケットにファイルを添付することで、課題の背景や試行錯誤をより説明しやすくなる

チケットの生存期間はどれくらいなのか？
毎週に週次の棚卸しを開催して、3ヶ月以上放置されたら積極的にCloseされている
チケットの生存期間は数週間レベルではないかと推測

チケットは年間で2万～3万件発行されるため、毎月2千件以上発行されると推測
チケット完了率が約80～90％と高いので、1ヶ月以上放置されることはあまりないと推測
チケットの内容が作業レベルよりも製品開発の課題であることから、チケットの難易度はそう簡単ではないと思われるため、チケット完了率の高さが驚き
チケットの作成や更新を担当するメンバーのモチベーションや意識が相当高いと推測

【2】Redmine運用を支えるための非機能要件は満たされているのか？
数千人、数十万チケット、数十テラバイトのデータを維持管理できるRedmine基盤を構築できるのか？

ITSの弱点は全文検索機能

問題点
ITS標準の検索機能はデータ量増加により性能要件を満たせない
検索できる範囲はせいぜいチケットとWikiくらいのみ
検索精度も文字列の一致だけで意味間まで見ていないので、有用な情報を検索できない
真の意味で、情報の追跡可能性を実現できていない

そこで
チケット、Subversion、添付ファイルを全文検索の対象範囲とする
GroongaとRedmineを連携させて全文検索させる

Groongaで Redmineを 高速全文検索 - Rabbit Slide Show

Redmineシステム内の文字列、添付ファイルやリポジトリまで全文検索を対象にしてくれる
スコアベース、畳み込み検索で高精度検索が可能
検索も高性能
元データは未加工、秘匿できている

おそらく、Groongaで定期的に検索対象データをクローリングし、索引を作って全文検索できる仕組みを提供しているはず
全文検索対象の記録文字のほとんどは、Subversionと添付ファイル
PDFやExcel、Word、パワポなどの資料が多いのではないか
それらを全文検索対象にしているはず
全文検索の基盤構築はそう簡単ではないと推測

情報の追跡可能性と非機能要件の確保を実現できたと言うが、3千ユーザ、数十万チケット、数十テラバイトのデータ類を鑑みると、インフラ基盤のチューニングは相当なノウハウが埋め込まれているのではないかと推測
そう簡単に実現できるレベルではない

【3】Redmineの運用推進を支えるための組織体制づくり

Redmineを社内全体に運用推進するための工夫は何か？
組織や体制はどんな構造にしているのか？

数千人の社内ユーザに説明して普及させるには、ITS事務局だけでは推進できない

週次ミーティングでチケット棚卸し
３ヶ月に１度、放置チケットを積極的にClose
問い合わせチケットは、常任モデレータを付けて「見つけてクローズ」

おそらくITS事務局の他に、各部門、各部署に専任のRedmine担当者を付けて、普及推進しているのでは？
そうでなければ、日々の細かな問合せ対応がITS事務局に集中してしまい、運用がパンクする
また、各部署へRedmine運用プロセス訂正通知や指示が流せない
組織をまたがるような指揮命令系統があるのではないか

今後の展望も興味深い
Redmineに蓄積されたデータをAI学習用データとして利活用できるか？

運用後まもなく、構成管理される成果物はDocumentsとSourcesで分類して運用されている
つまり、知識として確定したデータと経験で得られたデータを区別して管理されている
教師データとして使えるデータを区別できている

昨今成長著しいLLMを使えば、会社の事業領域に関する独自データを元に学習させて、学習モデルを作れるはず
過去に販売した製品、今研究中の製品について、AIに聞けば高精度の内容をすぐに回答できるはず
社内の生き字引みたいな人をAIが代用してくれる

こういう取り組みができるのも、Redmineに蓄積されたデータの品質が良いからだろう
チケットや成果物の記録内容の精度が低ければ、いくら学習させても使えない

【4】感想
島津製作所の事例では、@akahane92さんの講演を何度も聞いてきたが、やはりすごいなと思うし、自分もこういう運用をやりたかったなと思う。
Redmineの面白さや醍醐味は、実運用が定着すると、データが自然に蓄積されるので、そのデータを使えば定量的に分析できるし、実験データや研究データとしても使える。
有用なデータを蓄積できていれば、定量分析した内容も有意味になるはずで、いろんな利活用を膨らませることができる。

特に、機械学習などAI活用は全文検索の機能強化にも役立つ。
相互メリットを活かせば、今後も色んな研究に発展できると思う。

Redmineによるタスクマネジメント実践技法【電子書籍】[ 小川明彦, 阪井誠 ] 価格：3,608円 (2024/12/29時点) 楽天で購入

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

「世界一流エンジニアの思考法」の感想

「世界一流エンジニアの思考法」を読んでみた。
気づきをラフなメモ書き。

【1】試行錯誤は悪であること。
本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。
事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。

試行錯誤が良くない理由は、後で得られる経験知がないからだ。
やみくもにモグラ叩きのように潰して、ああ終わったというだけ。
障害解決した一つの経験が後で活用できない。

事実から推測して、起きそうな仮説を複数パターンで立ててみる。
そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。
どこに原因があったのか、後で振り返るときにも役立つ。

すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。
分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。

【2】コードリーディングのコツは極力コードを読まないこと。
すべての実装ロジックを理解しようとすると、脳みそのメモリが浪費されて余裕がなくなる。
空きメモリがなくなる。

動くものと仮定して、中身のロジックよりも、インターフェイスの役割やパラメータを調べて、関係性や動作を構造化することに注力する。
全体像を把握することと同じだろう。
この辺りは、コンポーネント図やシーケンス図、ステートマシン図、クラス図などを書きながら、構造を理解する方法もあるだろう。

コードリーディングは重要だが、いかに自分の脳みその負担を減らすか、に注力する。
自分にとって難しすぎると感じるときは、脳の使い方が間違っているというメッセージになる。

頑張る人、完璧主義の人、焦っている人ほど、脳みその空き容量がなく、脳みそを有効活用できていない。
そういうマインドセットを持つことも大事だと思う。

【3】日本独特の批判文化はソフトウェア開発と相性が悪いこと。
日本人は完璧主義すぎて、機能の網羅性や機能の品質を重視しすぎるために、ソフトウェアを漸進的に開発して品質を改善するやり方に馴染めていない。
最初に出したバージョンからソフトウェアに完璧を求める。

日本人は責任の所在や完璧を過剰に求めることで、開発者の心を砕いてしまう。
ソフトウェア開発者が先陣を切って何かにトライする行動に足かせを作らせる。
嫉妬、批判、冷笑、嘲笑が新しいことへのチャレンジ精神を阻害する。

人に何かを期待するのではなく、まず自分がどういう貢献ができるかという公共性をベースに考える。
これにより、互いにありがとうという感謝の精神が生まれる。

しかし、日本では理不尽なカスタマーハラスメントが起こりやすい潜在的な土壌が多い。
つまり、日本ではアジャイルなソフトウェア開発をやりにくい精神的土壌がたぶんあるのだろう。
従来からずっと言われているように、日本でソフトウェア開発がなかなか上手くいかない理由の一つは、国民性や文化的な側面もかなりあるのかもしれない。

また、日本の産業界ではハードウェア文化が強すぎて、ソフトウェアを甘く見てきている節もある。
どうしてもプログラマよりもマネージャ職の方が待遇面もキャリアも良いように制度も文化も作られてきた。
よって、アジャイル開発のように、現場の開発チームのメンバーが自分で実際に作って動かして、ソフトウェアを使って組織や世界を変えていくという方向性を実現しづらい。
現代のイノベーションは素人が集まっても作れるわけではなく、技術やクリエイティビティを持つ専門家集団がリードする必要があるだろう。

マイナンバーカードやデジタル庁、標準の公共システム開発にしても、色々頑張ろうとしているが、乗り越えるべきハードルは大きい。

【4】牛尾さんの本は過去にもたくさん読んできたが、「世界一流エンジニアの思考法」も同様に、文章は丁寧で読みやすく、内容は新たな価値に気づかせてくれる内容が多い。
アジャイル開発に慣れていれば当たり前の話だろうが、日本人がこれから乗り越えるべきハードルが書かれているので、非常に示唆に富む本ではないかと思う。

世界一流エンジニアの思考法 [ 牛尾 剛 ] 価格：1,760円（税込、送料無料) (2024/12/8時点) 楽天で購入