Redmine

2022/05/29

第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が向いているのかな、と改めて思う。

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/04/24

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かったのでメモ。
ラフなメモ。

【参考】
オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - AFFORDD

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - 経験論文

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - スライド資料

オープンソースERPパッケージiDempiereはいつか、仕組みを習得して、ERPはこういうものですよと自分なりに理解したいと思っていた。
ネット上の情報から、普通にインストールできる。
PostgresSQLのDBの中身を見ると、テーブル数は1千個を越えるので、OSSのわりに作り込んでいるERPだと思う。

こういうOSSのERPを自社開発、受託開発したい場合、必ずカスタマイズが入る。
その時に、どんな方針でカスタマイズすべきか、という問題が出てくる。
無造作にカスタマイズしていくと、開発基盤のバージョンアップに追随できなくなるし、今後の運用保守もやりにくくなるからだ。

そこで、ERPのカスタマイズに派生開発手法であるXDDPを用いて解決してみよう、という流れは自然に理解できる。
基本方針は、カスタマイズする場合、標準機能をラッピングまたは継承する形で、独自ロジックを実装する。

上記の資料で興味深いと思った点は、OSSのERPのカスタマイズで発生する問題として、標準機能の知識習得が難しいこと、派生開発により基盤である標準の品質を損ねること、という2点があげられたことだ。
そして、その解決方法として、教育環境の整備、開発規約の整備、開発体制の強化があげられていた。

意外だなと僕が思った理由は、派生開発のプロセスやiDempiereの開発基盤のアーキテクチャに焦点が当たると思っていたからだ。
しかし、よく考えれば、プロセスや技術面よりも、技術の習得や教育の方が長期的な問題なのだ、と理解すればいいのだろう。

得られた情報や検索した情報は、社内のRedmineで一元管理して共有している点も面白い。
Redmineを組織のナレッジ資産として使っているわけだ。

今後の課題として、XDDPのトレーサビリティマトリクスを利用して技術上の課題を解決していく点があげられていた。
iDempiereはOSSとはいえERPなので、相当な機能数があるから、すべてを理解するのが難しいのだろう。
そのために、XDDPのトレーサビリティマトリクスを利用したいのだろうと思う。

| | コメント (0)

2022/04/21

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール

プロジェクト管理の基本はテーラリングだと思う。
そして、Redmineはプロセスをテーラリングするツールだと思う。
ラフなメモ。

【1】プロジェクト管理の基本的な考え方は何だろうか?

QCDのコントロール、課題管理、スケジュール管理とか、色々あるだろうが、僕は、標準プロセスを各案件、それぞれの現場にテーラリングする能力が問われている、カスタマイズする能力が問われていると思う。
なぜならば、現場にあるプロジェクトはどれもバラバラであり、過去の経験と全く同じプロジェクトはありえない。
そこで、標準プロセスを元に、過去の経験やベストプラクティスのいずれかを、それぞれの現場の案件に適用して、プロジェクトの成功を目指すことになる。

つまり、案件の特徴を見抜いて、標準プロセスから、案件に合ったベストプラクティスを適用して効果を引き出すわけだ。
プロジェクトマネージャは、案件を自分のコントロールの配下におくために、自分の手持ちの武器のうち、有効な武器だけを抽出して、プロジェクトごとにカスタマイズして適用しているわけだ。

すると、2つの疑問が湧いてくる。

【2】1つは、標準プロセスがなければ、そもそもテーラリングができないので、テーラリングという考え方が合っているのか、という点。

PMBOKのようなプロジェクト管理の基本知識では、予実管理が基本だ。
つまり、標準が前提としてあって、実際の実績が標準からどれくらい離れるのか、を測定して制御するイメージ。

しかし、標準プロセスが事前に定まっている環境は、大企業や歴史の長いSIなど、それなりに自分たちの開発の歴史を持って、そこから標準プロセスを作り出した人たちだろう。
そうでない場合は、標準プロセスがあいまいか、そもそも存在しないかもしれない。

そういう状況は、カオスと言えるだろう。
案件を受注するたびに、いつも初めてのプロセスを自分たちで作って運用していかないといけない。
それはあまりにも大変すぎるし、失敗しやすい。

アジャイル開発がそんな場面で利用されやすいだろうが、スクラムのようなきちんと決まっている最低限のフレームワークを用いることで、そういうカオスを制御しようとしている。
スクラムから離れて自分たちのアジャイル開発を見出すのは、スクラムの守破離のうち、守りをきちんとマスターした後でいい。

だから、何らかの標準プロセスが前提にあるのが基本ではないかと思う。

【3】もう一つは、プロマネが標準プロセスからテーラリングできる自由度の範囲はどれくらいあるのか、という点。

PMOの立場では、標準プロセスを策定して、各案件のプロマネに提示して使ってもらう。
しかし、案件ごとに特徴がバラバラだから、標準プロセスをそのまま100%当てはめるて運用は難しい。
だから、プロマネには、基本は守ってもらうけど、ある程度カスタマイズして、プロジェクトをスムーズに運用してください、とある程度のカスタマイズお自由は手渡す。

では、どれくらいの自由度がプロマネにはあるのだろうか?
この自由度は、その会社のプロマネの能力レベルに依存する、という身も蓋もない話。

プロマネの能力が高ければ、標準プロセスを元に、担当案件ではこの部分をカスタマイズして、プロジェクトを運用しやすくします、と宣言して進める。
プロジェクトをコントロールするには、この部分のカスタマイズが必要だと彼らは分かっている。
彼らは、カスタマイズする根拠を説明して、ステークホルダーに納得させるだけの能力を持っている。

一方、プロマネの能力が低い場合、彼らは、プロジェクトの実績の妥当性を標準プロセスに求めたがる。
こういう運用をしているのは標準プロセスに即しているからです、開発を委託したベンダの成果物の品質が悪いのは標準プロセスに従ったからです、などと平気に言う。
つまり、プロマネは、案件の遂行の妥当性を第三者に説明する根拠として、標準プロセスを使おうとする。

すると、PMOは、標準プロセスが現場にフィットしていないからそういう意見が出てくるのだ、と判断して、標準プロセスをどんどん詳細化し、ガチガチに決めていく。
そうすることで、テーラリングの自由度が下がり、プロマネが自由に運用できる裁量が狭くなる悪循環に陥る。
自分で自分の首を絞めている感じ。

そういう現象も多いので、標準プロセスの策定では、プロマネにどんなインセンティブを与えれば、彼らが良い方向にカスタマイズしてくれるか、を考える時が多い。

その気持ちは、まるで法律家みたいだ。
政府が定める法規制によって、市場や社会を良い方向へ誘導しようと計画するが、実際は、生身の人間は小賢しいので、その意図をすぐに行動に反映して自分の利害に合うように変な方向にカスタマイズする、みたいな感じ。
マクロ経済学で言えば、ルーカス批判。
量子力学で言えば、不確定性原理みたいなものか。

【4】他方、Redmineを使うと、標準プロセスとテーラリングのバランスをある程度保証して、プロマネに運用してもらうことができると考える。

Redmineはとても自由度が高いプロジェクト管理ツールだ。
とはいえ、Redmineも汎用ツールなので、Redmineに埋め込まれた機能によって、プロセスの自由度はある程度限られる。
つまり、Redmineで提供する「プロジェクト」ごとに、スクラッチのシステム開発やパッケージ製品導入、サポートデスクなどのドメインで、ワークフローやチケット管理などをテンプレート化しておく。
そのドメインのテンプレートをプロマネに手渡し、そこから先はプロマネに自由に運用してもらう。

つまり、ドメインごとのテンプレートで標準プロセスは固めておき、それから先の運用はプロマネの自由裁量にある程度任せる。
もちろん、チケット起票やチケットの完了条件については、Redmineの機能で制限することは難しいから、運用ルールで縛ることになる。
ただし、各案件ごとに、開発者のスキルが違っていたり、開発やリリースの手順が違う時もあるだろうから、チケット管理にテーラリングを当てはめて、ある程度の自由裁量で運用ルールを変更する余地は残す。

そうすれば、Redmineで標準プロセスを元に、プロマネがテーラリングして、案件ごとに合った運用ルールを策定できて、プロジェクトを成功させる確率を高めることができるはず。

ただし、この運用の前提条件は、プロマネがRedmineの機能やカスタマイズできる範囲を理解し尽くしておくことだ。
つまり、Redmineをプロセスのテーラリングに使うツールとして用いることができる能力を前提としている。

そうでなければ、プロジェクトのテーラリングをRedmine上で実現できないからだ。
個人的には、Excel手順書で運用ルールを逐一テーラリングするよりも、ある程度ツールで標準プロセスを遵守して、ツールの基板上でテーラリングする方が、コントロールしやすいのではないかと考えている。

| | コメント (0)

2022/03/21

RedmineのWikiタグでタスクリストを書けるようになった

RedmineのWikiタグでタスクリストを書けるようになったのでメモ。
これは色々使えそう。

【参考】
【毎月更新】Redmine リリース前の新機能を先行チェック!タスクリストの記法など(2022年1月コミット分) | Redmine.JP Blog

Feature #35742: Enable task list items for Common Mark text formatting - Redmine

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

タスクリストを使いたい場面は、自分だけのタスクを分解してメモしたい時や、作業手順が決まっているルーチン作業の進捗管理に使いたい時だろう。
今からやるべきゴールがあって、それに対してどんな作業があるのか、洗い出して、それをタスクリストで順に並べて、1個ずつ消し込みながら作業を管理したい。
作業ができる人ほど、タスクリストのような地味な作業管理をきちんとやっているように思う。

しかし、Markdownでやろうとすると、箇条書きで作業手順を書いて、逐一取り消し線を引いていく、みたいな面倒な作業が多い。

そこで、タスクリストの記法を使えば簡単に、未完了の作業と消し込んだ作業を管理しやすくなる。
こんな感じで使えばいい。

* [x] Item-A
* [ ] Item-B
    * [x] Item-B-1
    * [ ] Item-B-2-a

ただし、注意点はいくつかある。
1つ目は、タスクリストのたびにコメントに履歴がたくさん残ってしまって、履歴が煩雑になってしまうこと。
だが、Redmineではチケットのコメント履歴をタブで分けてくれているので、見分けることはできるだろう。

もう一つは、タスクリストの作業状況はチケットを開かなければ分からないこと。
チケット一覧からタスクリストが見えないからだ。
消し込んだ状況と進捗率を同期する運用もあり得るが、手作業で更新するのが鬱陶しい。
よって、タスクリストを使う時はチケット一覧でタスク管理しなくていいイメージで考えた方がいいと思う。

こういうリスト、箇条書きを使った手法は、ライフハックの技法として数多く知られているので、色々試してみると経験しやすいと思う。

仕事と自分を変える 「リスト」の魔法 | 堀 正岳シンプルTODOリスト仕事術超・箇条書き―――「10倍速く、魅力的に」伝える技術 | 杉野 幹人の本が分かりやすかった。
いろいろ試してみたいと思う。

| | コメント (0)

2022/03/06

RedmineJapanで参考になった講演資料を読み直す

RedmineJapanで参考になった講演資料のリンクを集めておく。
ほかの講演資料もあるみたいだが、ネット上で検索するのが面倒。
まだ公式サイトにも講演資料のリンクも動画リンクもないので、自分が気になった資料だけリンクしておく。

【参考】
RedmineJapan vol.2 2022/2/25 - Togetter

【参考1】
情報のまとめ方を議論する  #redmineeva | マドびっ! Madosan's View

気になった講演内容がいい感じでまとめられている。
みうみうさんの講演では、「ストックとフローの話だけどPMISの話」「情報が分かれると検索性が落ちる」点は参考になる。

【参考2】
Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログ

理解できた内容は、下記に書いた。
ククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つ: プログラマの思索

【参考3】


【参考4】

後でじっくり読む。

| | コメント (0)

ククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つ

RedmineJapanで講演されたククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つと思ったのでメモ。

【参考】
Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログ

Redmineをサポートデスク管理に使う時に、いくつかの問題点を自社開発したプラグインで解決した事例。
とても参考になる。

【1】Redmineでヘルプデスクを扱うアイデアは、10年以上前から、@g_maedaさんが試されていたし、僕もそれに触発されて色々アイデアを考えていた。

Redmine 4.2で作るヘルプデスク向け問い合わせ受付・管理システム

Redmineを使ったヘルプデスクシステムでサポート業務を効率化

Redmineによるwebサポート窓口の実装と運用

Redmineによるメール対応管理の運用事例

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します: プログラマの思索

Redmineの最新機能でサポートデスク管理をより効率よく使う運用方法のアイデア: プログラマの思索

本来、顧客からの問い合わせ管理というヘルプデスクは、いわゆるSoEの観点では非常に重要な業務になっている。
顧客満足度を維持していくには、製品やサービスを売り切り型ビジネスではもはや意味がなく、購入後にいかに顧客の不満を吸い取って対応したり、事前に顧客の不満を解決するなど、事前事後の対策が必要だ。

その場合、顧客ごとに問い合わせ情報を管理して、過去の履歴を見れるようにして、オペレータが即座に対応できる体制を作りたい。
Redmineはチケット管理機能が強力なので、問い合わせメールをチケットに取り込むことさえできれば、メールの履歴はチケットのコメントに対応付けることで、一つのスレッドにまとめることができる。
チケットに情報が蓄積できれば、強力なチケット集計機能により、問い合わせ内容を分類したり、問い合わせ工数を集計して、顧客へ月次報告する元ネタに使うこともできる。
普通は実績ベースの作業工数を報告して、検収してもらって費用を回収する場合が多いはずだ。
だからこそ、顧客の問い合わせ管理をRedmineで集約して管理することは、ナレッジを蓄積したい目的だけでなく、月次検収をスムーズに行うために必要なツールになりうるはずだ。

【2】しかし、Redmineのデフォルトの機能では、問い合わせ管理のかゆい点に届かない場合も多い。

では、Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログにどんな新しい観点、問題意識があったのだろうか?

【2-1】サポートデスクでは、顧客からの問い合わせメールに対し、やり取りしながら対応する必要がある。
Redmineのデフォルト機能でも、rakeコマンドでメールをチケット登録できるが、問い合わせメールをチケットに登録したとしても、メールタイトルの揺れ、チケットの更新ミス、メール内容の反映漏れなどが発生しがち。

そこで、ClearCode Inc. / Redmine plugin email importer ・ GitLabを使う。
問い合わせ専用メールアドレスを各顧客専用に発行しておき、宛先メールアドレスに対応する顧客用のプロジェクトにチケットを自動起票する運用が可能になるので、起票済みの問い合わせに関するメールのやり取りを既存のチケットへのノート注記として自動的に追記できる。

【2-2】顧客によっては「その顧客専用の問い合わせ用メールアドレス」が発行されていない場合や、別のアドレス宛に問い合わせメールを送信されていたりする時は、Thunderbirdからメールを元にRedmineのチケットを発行・更新できるようにする。
メールから手動でRedmineチケットと対応付けたい時に便利だと思う。

RedThunderMineBird Plus - Redmine連携+ :: Thunderbird向けアドオン

【2-3】問い合わせに対して過去の回答を参照する必要がある場面は多い。
その時に、Redmineの全文検索プラグインを使う。
これにより、Redmineのデフォルトの検索機能よりも遥かに強力に検索できるから、Redmineに蓄積されたDBが事実上ナレッジDBとして扱える。

Redmineで高速に全文検索する方法 - 2016-04-11 - ククログ

全文検索プラグインにより、チケットに添付されたPDFやWord文書なども検索対象にできるので、RedmineDBも添付ファイルも全て検索対象になる。
つまり、実際の運用ではデータの整合性に神経質になるよりも、どんどんチケットに書き込んだり、ファイルをチケットに添付すればいいと思う。

【2-4】サポートデスク管理では、顧客単位にRedmineプロジェクトを割り当てる運用が多いだろう。
顧客ごとにチケット管理したいし、顧客ごとにナレッジを蓄積したいから、プロジェクト単位で分割したくなる。
すると、プロジェクト概要に顧客の基本情報を書いておくと便利。
しかし、実際の運用では、チケットで問い合わせ対応している時に、概要タブをワンクリックの作業をやって顧客が使うシステム環境、利用者情報などの情報を見る操作が一手間かかる。

そこで、ClearCode Inc. / redmine-plugin-descriptions-sidebar ・ GitLabを使って、チケットの一覧や個別表示の画面のサイドバーに「概要」の内容を埋め込み表示させる。
これにより、「画面を切り替える」という一手間なしに顧客情報を即座に参照できる。
こういうちょっとした機能が作業の効率化を進ませてくれる。

【2-5】サポートデスクの管理では、毎月の作業報告を顧客に送って、検収してもらって月次費用をいただくという契約が多いだろう。
すると、顧客単位のRedmineプロジェクトに、問合せチケットは蓄積されているので、チケット一覧からそのまま出せば良い。
そこで、重要な情報は、問い合わせチケットごとに記録された問い合わせ情報と実績工数だ。

しかし、Redmineのデフォルトの工数出力CSVはあるが、そこからExcelマクロに取り込んで、顧客向けの毎月の実績報告を作るのは面倒だ。
そこで、ClearCode Inc. / redmine-plugin-work-report-exporter ・ GitLabを使って、作業実績のExcel報告をワンクリックで出力できるようにする。

【3】改めてククログさんの資料を読み直すと、Redmineの素の機能をあまりカスタマイズせず、ヘルプデスクの機能を強化している点が素晴らしいと思う。

本来、ヘルプデスク管理の機能をRedmineに追加していけば、最終的にはRedmineはCRMと同じになると思う。
特に、アウトバウンドメールやインバウンドメールのような機能がRedmineにも欲しくなる。

しかし、Redmineをカスタマイズしすぎると、Redmineのバージョンアップに追随できなくなるデメリットが出てくる。
だから、Redmineの素の機能をあまりカスタマイズせず、ヘルプデスク管理機能を強化できるように、Redmineバージョンアップに追随できるように機能強化を図るという綱渡りのような技術が要求される。
そういう観点から見ても面白いなと思った。

| | コメント (0)

2022/03/04

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か?進捗率はどう決めるべきか?面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90%のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか?

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか?

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか?
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか?

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。

| | コメント (0)

2022/02/25

Redmine4.2のER図が公開されている

Redmine4.2のER図が公開されているのでメモ。
これはとても役立つ。

redmine_db_schema/4.2-stable at master ・ wate/redmine_db_schema ・ GitHub

ワテさんの力作。
テーブルを見て、自力でソースも見ながら外部キーのリレーションを見たりして、全て書ききったらしい。
すごいね。

データモデリング屋にとって、ER図があれば、そこから画面はどれだけ必要なのか、どんな機能が必要なのか、はほぼ分かる。
そこから、ER図が表現する業務の内容はほぼイメージできる。
ER図のリレーションから、業務の制約条件も分かってくる。

astah*を使えば、RedmineのDBをリバースエンジニアリングしてDB仕様書は作れるのだが、Railsの弱点は、外部キーや複合キーの設定がテーブル構造の情報だけでは取れないこと。
結局、Railsのソースを読まないと、テーブルのリレーションが分からない。

こういう力作は参考にして、Redmineの特徴を見てみたいと思う。

| | コメント (0)

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コミュニティを緩く長く続けたいと思います。

| | コメント (0)

より以前の記事一覧