• Home
• ブログ
• RedmineのWikiの移行をRedmineで管理しました

本村です。健康的に体重を増やすため、筋トレに取り組み始めました。筋トレと言えば、腕立て伏せ、懸垂、スクワットが代表的ですが、懸垂ができる場所が案外なく、何か良い方法がないかと思案しています。

さて、今回はRedmineのWiki移行をRedmineで管理した事例を紹介します。

弊社では、サービスのサポートスタッフが確認するルールや手順をRedmineのWikiにまとめています。これらのナレッジは100ページ以上のWikiページから構成されていました。情報量が多いため、新しく業務に参加したスタッフにとっては、必要な情報がどこに書かれているかを探すのが大変でした。また、「探している情報が見つからない」のか、「そもそもWikiに書かれていない」のかも判断しにくい状態でした。さらに、一つのページだけでは判断できず、複数のページの情報を組み合わせる必要がある場合もありました。

そこで、複数のナレッジを横断して必要な情報を探しやすくするため、AIの活用を考えました。ただし、AIが利用できれば、人には見づらくてもよいというわけではありません。引き続き人もWikiを閲覧・確認するため、AIと人の両方が利用しやすい構成を目指し、ページの再分類やページフォーマットの統一などを行いながら、新しいWikiへ移行しました。ページの再分類や内容の修正などの移行作業は、主にCodexとRubyスクリプトを使って進めました。

移行作業中にも元のWikiが更新される

今回の移行作業には、主に2つの課題がありました。

• 移行元のすべてのページについて、移行先を確認できるようにすること
• 移行作業中に移行元のWikiが更新された場合、その変更を移行先にも反映すること

今回の移行には、およそ2か月半かかりました。その間も移行元のWikiは業務で使われており、ページの更新が続いていました。一度移行したページについても、その後に変更されていないかを確認し、変更されていれば移行先のページに反映する必要がありました。

3つのトラッカー

Redmineに次の3つのトラッカーを作成し、移行作業を管理しました。

• Source Page

  • 移行元ページのメタデータを管理する
  • ページ名やWikiのバージョンを記録し、更新検知などに利用する

• Target Page

  • 移行先ページのメタデータを管理する
  • ページ名やページの親子関係など、移行先Wiki上の構成に必要な情報を記録する
  • この情報をもとにRubyスクリプトでWikiへページを登録する

• Source-Target Link

  • Source PageとTarget Pageの関係を管理する
  • Source Pageが更新された場合に、どのTarget Pageを確認する必要があるかなどを記録する

Source-Target Linkが1件も紐づいていないSource Pageを抽出しました。該当するページが残っていなければ、すべての移行元ページに移行先があると確認できます。

また、Source PageとTarget Pageは必ずしも1対1ではありません。実際の移行では、1ページを複数ページに分割したり、複数ページを1ページに統合したりしました。

ただし、その関係を表すだけなら、Redmine標準のチケット関連機能でも対応できます。 Source-Target Linkを独立したトラッカーにした理由は、移行元のページが変更されたときに発生する確認・修正作業を、独立したチケットとして扱いたかったからです。

移行元ページの変更を移行先ページへ反映する

移行元のWikiページが更新された場合は、次の手順で対応しました。

バージョンを確認し、前回から変更されていればdiffを作成します。まず、Rubyスクリプトで移行元のWikiページのバージョンを確認し、前回の確認時から更新されていれば差分（diff）を作成します。次に、AIがdiffを読み、変更の影響を受けそうなSource-Target Linkを特定し、人が確認すべき内容を整理します。その後、Rubyスクリプトで該当するSource-Target Linkのチケットにコメントを追記し、ステータスを「フィードバック」に変更します。

人が確認作業を行う際は、Redmineでステータスが「フィードバック」になっているチケットの一覧を表示します。各チケットのコメントには、diffをもとにAIが整理した確認内容が記載されています。まずコメントを読んでおおよその変更内容を把握し、そのうえで必要に応じてSource PageとTarget Pageを確認しました。修正が必要であればTarget Pageを修正し、確認が終わればSource-Target Linkのステータスを「解決」に変更しました。

Redmineで管理しやすかったか？

振り返ってみると、今回の作業はRedmineでなければできなかったわけではなく、Excelなどのスプレッドシートでも管理できたと思います。それでもRedmineで管理して良かったと感じたのは、作業管理に必要な「型」が最初から用意されていることでした。

• ユーザー：スクリプト用のアカウントを作成したため、履歴を見れば、人とスクリプトのどちらが行った操作かを確認できました。
• チケット：「このSource Pageの変更について、このTarget Pageを確認する」という一つの作業を、Source-Target Linkという独立したチケットとして扱えました。
• コメントとステータス：AIがdiffから整理した確認内容をコメントとして残し、人による確認が必要になったら「フィードバック」、確認が終わったら「解決」と、作業の状態を管理できました。
• ワークフロー：ステータスの遷移を管理できるため、今回の作業を「新規 → フィードバック → 解決」という流れに当てはめることができました。

そして、Redmineにはこうした型に沿ったUIがあります。「フィードバック」のチケットだけを一覧表示し、チケットを開いてコメントを確認し、作業が終わればステータスを変更できます。

スプレッドシートでも同じ情報を持つことはできますが、誰が操作したのか、作業の状態をどう表すのか、履歴をどこに残すのか、今確認すべきものをどう一覧にするのか、といった仕組みは自分で決める必要があります。一方、Redmineでは、ユーザー、チケット、コメント、ステータス、ワークフローといった仕組みと、それらを操作する画面が一体となっています。

今回、Redmineが使いやすいと感じたのは、個々の機能や画面の便利さに加え、チケットを中心に作業を管理する仕組みと、それに沿って操作できる画面が一体となっているからだと思います。

移行したWikiをAIで活用する

今回の移行の目的の一つは、AIを使ってナレッジを活用しやすくすることでした。AIを用いた情報検索にはGemini Notebookを利用しています。選んだ主な理由は、弊社がGoogle Workspaceを契約していることと、移行期間中にソースの自動同期機能が提供されたことです。

RedmineのWikiページはMarkdownとして取り出せるため、MarkdownからGoogleドキュメントを生成し、Gemini Notebookのソースとして登録しています。これにより、一つのWikiページだけを検索するのではなく、複数のナレッジを横断して情報を確認できるようになりました。

実際に使ってみると、既存のナレッジを探すだけでなく、ナレッジや業務の改善を検討する際にも役立ちました。

最後に

今回のWiki移行には、もう一つ目的がありました。AIを活用してページの分類やフォーマットを検討し、その内容をドキュメントにまとめて、別の業務のWiki移行でも再利用できるようにすることでした。

実際に、今回作成したドキュメントとAIを活用し、Redmine以外のWikiやスライド資料の内容を、RedmineのWikiへ移行できました。

---