チケット駆動開発

2022/01/15

Redmineにメンション機能が入るらしい

Redmine5.0にメンション機能のパッチが提供されたのでメモ。

akipiiさんはTwitterを使っています 「すごく嬉しい。RT @g_maeda: Redmine 5.0 でメンション機能が入りそう。 https://t.co/NY2SqPQ05P」 / Twitter

Feature #13919: Mention user on comment/description using @user with autocomplete - Redmine

@ユーザIDでメンションできる機能のパッチができた。
Redmineコミッタ Marius BALTEANUさんが提供しているので、おそらくtrunkに入るだろう。

Twitter、Slack、Teamsでも、メンション機能は当たり前。
この機能がないとすごく不便。
なぜなら、コメントした時に、相手に依頼したり問いかけても、応答しなかったり、そもそも気づかない場合もあるから。

こういう機能改善を見ると、Redmineは古株のPJ管理ツールなので、昨今流行している機能を取り込んで追随していく方向性になるかもしれない。
たとえば、似たような機能で今はない機能として、いいねボタンの機能もある。

とは言え、長年親しんで使い慣れたRedmineだからこそ、こういう細かい機能追加はとてもありがたい。
今後もチェックしていく。

| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

2022/01/10

チケット管理の運用を支える体制とは何か #redmine

チケット管理の運用を支える体制についてツイートがあったのでメモ。

【発端】
ところてんさんはTwitterを使っています 「「なんでプログラマーはチケットシステムが上手く回って、それ以外の部門ではうまく回らないの?」 「プログラマーの世界はプログラマーの中で比較的閉じてるからじゃない?部門をまたいで同じシステムを使わせるというのが色々と大変なのかも」」 / Twitter

akipiiさんはTwitterを使っています 「チケットシステムがなぜプログラマ以外では回らないのか?と言う問題提起」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii 一応工場で導入に成功はしましたが最低限チケット管理システムの扱いをわかっている人(≒プログラマ)と、管理が腐らないよう見張ってくれる人が複数いないと機能しないですね」 / Twitter

akipiiさんはTwitterを使っています 「@tomati2020 Redmineコミュニティでは、チケット管理のルールが守られて運用されているか定期的に巡回する人を「お巡りさん(Redmine警察)」、現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする人をマイスター(Redmine職人)と呼んでます。まさに2つの役割に相当していますね!」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii ですです。 なのでなんとか自部署での運用は成功しているんですが、適用範囲を拡大しようとすると自助努力ではどうしようもないので会社ぐるみでの研修プログラムなどが必要になってくるかと思われます。」 / Twitter

【1】チケット駆動のタスク管理は、一度運用が回ればスムーズに回る。
チケット管理ツールを基盤としたチケット駆動開発は、アジャイル開発のタスク管理と相性が良いので、変更の多いタスク管理に適用しやすい。
また、アジャイル開発のプラクティスを自然に適用できるので、朝会やKPTによるふりかえり、ペア作業、メンバーの自発的行動を促す雰囲気作りを適用することで、メンバの貢献意欲を引き出しやすい。
結果的に、チームの一体感も高まり、チームの雰囲気もすごく良くなる。

【2】しかし、いつもチケット管理が上手くいくとは限らない事実は以前からRedmineコミュニティでも議論されていた。

その原因の一つは、チケット管理を刺させる体制が不十分なので、チケット管理の運用ルールが守られず、形骸化してしまうことだろう。

【3】経験上、チケット管理をスムーズに運用する為には、4種類の役割が必要になると考える。

①お巡りさん(Redmine警察)
チケット管理のルールが守られて運用されているか、定期的に巡回する。
また、メンバーが困ったときには手助けをする。
Scrumで言えば、スクラムマスターみたいな感じだろうか。
チケット管理の守護神のようなイメージかな。

②マイスター(Redmine職人)
現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする。
それぞれの現場では独自のプロセスがあり、そのプロセスに基づく組織文化や業務手順がある。
それらをチケット管理ツールに反映することで、利用者の操作感を良くして、取っ付きにくさを軽減する。

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

③エバンジェリスト
チケット管理の伝道師としてメンバーを啓蒙する。
こういう熱い心を持った人が、チケット駆動開発を導入する時に旗印となって、メンバーを啓蒙して、心の熱量を注入していく。
もちろん、メンバーやプロジェクトマネージャへの教育も兼務するだろう。
最初は、エバンジェリストのような熱量のある人が、組織に息吹を吹き込む必要があるだろう。

④活動家
活動ログから現場の業務活動をモニタリングし、組織のあるべき姿(全体最適化)を目指す。
たとえば、標準化推進のPMOや、プロセス改善や品質管理を担当するSEPGが相当するだろう。
彼らは、Redmineの活動ログを元に、各PJの活動を見て、PJの進捗・品質・コストで異常がないかモニタリングし、何かあれば、プロジェクトマネージャにアドバイスする。

活動家はお巡りさんよりもさらにメタな観点で、チケット駆動開発をモニタリングする立場だろう。

【4】では、チケット管理を支える体制では、この4種類の人達だけで十分なのか?
その他のロールはないのか?
あるいは、2種類や3種類の役割に減らしても、チケット管理は上手く回るのだろうか?

こういう疑問を数多く集めて、この主張をさらに強化したいと思う。

| | コメント (0)

2022/01/01

チケット駆動開発のプロセスと開発基盤を再考する #Redmine

チケット駆動開発のプロセスと開発基盤を書き直してみた。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine: プログラマの思索の図を改良している。

チケット駆動開発は基本的に、ScrumやXPに似たアジャイル開発のプロセスと同一視される。
なぜなら、ロードマップをScrumのスプリント計画、XPのイテレーション計画とみなして、リリースサイクルに従って定期的にリリースされる仕組みとみなせるからだ。
つまり、チケット駆動開発は小規模リリースを実現するプロセス基盤でもある。

他方、チケット駆動開発というプロセスから発生する情報は、チケット管理ツールに全て集約される。
チケット駆動開発プロセスは、チケット管理システムに支えられて実装される。
チケット管理システムの構造は、Input,Process,Outputという単純なプロセスから成り立つ。
中核となるPMISは、フロー管理とストック管理という2つの機能を持つ。

フロー管理の機能は、チケット管理、チケット集計、ロードマップ、ワークフロー管理などがある。
つまり、チケットは流通媒体であり、ステータスに応じてサクサク流れる。
チケット集計には、ガントチャート、カレンダー、かんばんなどがある。
ロードマップとチケット集計を区別したのは、ロードマップがScrumのプロダクトバックログに似た機能であり、スプリント計画あるいはイテレーション計画で使われる重要な機能だからだ。

ストック管理の機能は、チケット管理、SCM連携、Wiki、トレーサビリティなどがある。
つまり、チケットは記録媒体であり、作業履歴や課題の内容、障害管理票などの帳票として記録される。
ただし、記録される媒体はチケットだけでなく、Wikiもあるし、GitやSVNなどの構成管理ツールにもある。
これらの情報と相互リンクすることで、チケット管理ツールにすべての情報が集約されて、ナレッジ基盤になる。

チケット駆動開発はプロセスであるから、処理が主人公になる。
一方、チケット管理システムは機能から構成されるので、機能を通じて記録されるデータが重要になる。
そのデータの特徴はフローでもありストックでもある。

チケット管理システムは、チケットにフローとストックの両方の意味を故意に持たせることで、幅広い運用が可能になる。
ある側面では、タスクかんばん上でステータス管理できるし、ある側面では、そのタスクや課題のチケットには、数多くの情報が記録されているし、その変更履歴も記録されているので、経緯や意図を把握できる。

このチケットの二重性という特質がチケット管理ツールに豊かな機能や利用シーンを生み出してくれるのだ。

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

| | コメント (0)

2021/12/28

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか?

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か?
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット+プロセス+アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん(Redmine警察)は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ(Redmineの活動タブ)を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel! Redmineでアジャイル開発を楽々管理:エンジニアがお薦めする 現場で使えるツール10選(3)(1/5 ページ) - @IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

| | コメント (0)

2021/12/04

「林業におけるRedmine活用」は林業におけるDXの良い事例だ

第21回勉強会 - redmine.tokyoで、「林業におけるRedmine活用」の講演は林業におけるDXの良い事例として、はてぶでバズっていたらしい。
ラフなメモ。

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

第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある: プログラマの思索

林業のタスク管理をRedmineでやる話|株式会社百森|note

[B! Redmine] 林業のタスク管理をRedmineでやる話|株式会社百森|note

深津 貴之 / THE GUILD / noteさんはTwitterを使っています 「DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/PTBB6RFfnM」 / Twitter

【他ツイート】
akipiiさんはTwitterを使っています 「この発想はありうる。RT @murasakimitsuru: リン業…林業にもredmine導入で農業・酪農にもredmine導入ありそう。(モバイルredmine化を妄想)」 / Twitter

yuutaさんはTwitterを使っています 「林業におけるRedmine活用 https://t.co/x6duLhY4ty」 / Twitter

akipiiさんはTwitterを使っています 「興味深い講演でした。まさにDX。配信内容は見れますよ。RT @fladdict: DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/tm7QNJwDhH」 / Twitter

金森悠介|才流さんはTwitterを使っています 「業務の見える化と、文字情報に落とす意義がよくわかる事例 林業におけるRedmine活用 https://t.co/TI33f0hhI4」 / Twitter

れぐなむさんはTwitterを使っています 「現場の地図が付いてるだけでわかりやすさ段違いって印象受けるな。これ手作業なら絶対貼らないけどITなら一瞬だもんな。こういう地味な改善ってドローン飛ばしてあれこれするより効果でかそう / “林業のタスク管理をRedmineでやる話|株式会社百森|note” https://t.co/IQpDaQF6fO」 / Twitter

宇埜隆士さんはTwitterを使っています 「DXへの第一歩。チケット文化を根付かせることができたのは凄い(小並感)。 / 他74件のコメント https://t.co/zxrf1ZiT4n “林業におけるRedmine活用” (545 users) https://t.co/QHobwimNdt」 / Twitter

株式会社グローバルネットコア【サーバー・クラウド・Webシステム&ホームページ制作・セキュリティ】さんはTwitterを使っています 「wikiやredmineを林業で活用・・・これは素敵ですね!!当社のようなIT系企業でよく使っているようなデジタルツールを、第一次産業の現場で導入している成功事例です。これぞまさにDX!! #DX #DX推進 #デジタル化 https://t.co/3ZkqysJTFe」 / Twitter

中野ヤスオ|ARIさんはTwitterを使っています 「勇気をもらえます。常識にとらわれず、もっとより良い働き方を追求していきたいです。 / 他70件のコメント https://t.co/xmmZzE8qzc “林業におけるRedmine活用” https://t.co/qkV5jAhww5」 / Twitter

ぽっとさんはTwitterを使っています 「プロジェクト管理システムとしてはかなり好きRedmine。あとはガントチャートの棒がドラッグ操作で動かせたら完璧のぺきなのよ(販売されているプラグインでできることは知っています) https://t.co/nGgFfQE8Uq」 / Twitter

(call me #'knjname)さんはTwitterを使っています 「Redmineの汎用性は異常なので、何かシステム組むぐらいならまずRedmineに落としてみてほしい現場はたくさんある / “林業におけるRedmine活用” https://t.co/ke9qHiRhgT」 / Twitter

きのくにさとしさんはTwitterを使っています 「IT木こりとして、興味深く拝見した。 https://t.co/8PcZGv8ezF ちゃんとみんなを巻き込めているのがすごい。そこに一番苦労しそう。」 / Twitter

Katsue NagakuraさんはTwitterを使っています 「林野庁出身のすごいDX人材が農水省にいらっしゃるのもあって、個人的には勝手に農業林業とDXが熱いです、最近 林業におけるRedmine活用 - Speaker Deck https://t.co/FjZQgdUhnJ」 / Twitter

テキスト×音声で記録するAI電話ピクポン代表の小幡さんはTwitterを使っています 「林業におけるRedmine活用 の第21回勉強会で発表した内容です! ひとことにITと言っても様々な業態があるように、林業にも様々な業態があります。今回説明させていただいたのも、あくまでも林業という多様な業界の一例である、というこ… https://t.co/Si920QOsQz https://t.co/YcLwuD2FJL」 / Twitter

t_takataさんはTwitterを使っています 「とても良い事例だった。作業をチケットに分割できてチケットテンプレート化できればかなり楽になるのは実感がある。 / 林業におけるRedmine活用 https://t.co/sqxWarxw0z」 / Twitter

【1】林業にRedmineを入れた背景となる問題意識としては、労働者の高齢化が進んでおり、口頭伝承の作業代わりと多いことだろう。
結局、若い人にノウハウが伝わらないし、単純な肉体労働みたいなイメージに思われてしまう。

そこで、Redmineを導入したことにより、チケットで全ての作業を手順化して作業の平準化と臨機応変な担当のアサインを図ったこと、作業チケットから生まれたノウハウや経験談はWiki(Note記事を読むとDocBaseのサービスらしい)にナレッジとして蓄積していくようにした。
すると、作業者の意識も主体的になる効果もあったらしい。
ツールを入れることでプロセスを改善するだけでなく、従業員を含めた組織文化も変化させた点が素晴らしいと思う。

【2】「木こりのジレンマからの脱却」という問題意識はよくある。
作業を手順化して標準化し、IT化しやすいようにしたいが、そんな作業に時間を書けるくらいなら、実際の作業をすることでビジネスでお金を稼ぐべきだ、みたなジレンマがよくある。

こういう苦労は普通はJカーブを描くのだろう。
つまり、作業のチケット化、作業の手順化や標準化をすることで、一時的に生産性は下がるが、その効果が出ると一気に効率が上がる。
こういう木こりのジレンマは、林業に限らず、事務処理でもIT業界のシステム開発でもよくあるだろうと思う。

【3】今回の林業の事例では、Redmineの導入により一連の作業をIT化したのは、思い切った改革なのだろうなと思う。
そもそもITに慣れていない従業員も多かったはずだろうだから、苦労も多かっただろうと推測する。

一方で、どこかの勉強会で、日本の省庁の中で最もデジタル化が進んでいる省庁は、実は農林水産省です、という話を聞いた時がある。
農林水産業は実はITと相性がいいのではないか、という仮説も持てる。
なぜならば、元々IT化されていない作業が多いだけでなく、IT化することで生産性が大きく増える点があるからだ。
今回はRedmine導入による作業の標準化、ナレッジ蓄積という問題解決だった。
他にも、ドローン導入やGPSを使って広大な農地を管理したり、AIを使って農産物の品質判断したり、という事例とか、素人でも色々実現可能なアイデアは割とたくさん出てくる。

つまり、農林水産業はDXと相性が良いのではないか、という仮説を持つこともできるだろう。
この辺りのアイデアも膨らませてみたい。

| | コメント (0)

2021/12/01

プリコラージュの対となる概念はエンジニアリングになる

【1】図書館で借りた本でふと見つけた言葉。
「レヴィ・ストロースが提唱したプリコラージュの対となる概念は、エンジニアリングなのだ」と言う言葉にものすごくしびれた。
こういう発想があるとは思わなかった。
Redmineによるチケット駆動開発は、たぶんプリコラージュに近い概念と思う。
一方、ソフトウェア工学のようなエンジニアリングはその対極にある。

【2】「勝つための論文の書き方」では、プリコラージュをこんなふうに説明している。
構造人類学を創始したレヴィ・ストロースは、どんなに原始的に見える未開人の行動や思考にも、それなりの論理と構造があるのだという事実を、フロイトの無意識理論やソシュールの言語論を構造把握の手法として借りて、証明した。
こういうやり方、つまり、他の分野から方法を借用して把握する方法をプリコラージュ、すなわち、素人大工仕事と呼んだらしい。

【3】Redmineでチケット駆動開発を実践するというアイデアは、元々は、多機能化した障害管理ツールをソフトウェア開発のプロジェクト管理全般に適用しようというものだ。
つまり、手元にある道具が割と高機能だったから、これを目の前の問題に当てはめてみよう、みたいな感じから始まったと思う。

RedMineでチケット駆動開発!: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

そのアイデアは、タスクの発生から担当者のアサイン、プログラムによる実装、テスト、ビルドしてデプロイまでの一連の作業履歴をチケットに全て集約することで実現される。
つまり、チケットは、ソフトウェア開発で発生する全ての作業のライフサイクルを全て包み込む。

チケット駆動開発の適用範囲part4~ウォーターフォール型開発への部分適用の注意点: プログラマの思索

【4】さらに、BTSには集計機能、分析機能が使えることから、データ集計基盤、さらにはソフトウェア工学のデータ基盤として使えないか、という発想に発展させることができる。
元々、障害管理ツールなのだから、バグの傾向分析や信頼度成長曲線は簡単に出力できるからだ。

ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索

【5】そんなことを考えると、本来はチケット駆動開発は、高機能化した障害管理ツールをプリコラージュした手法に過ぎなかったのに、いつの間にか、ソフトウェア工学を支援できるプロセスに発展できるのではないか、という妄想につながる。

2008年に僕が初めて講演したRedmineでチケット駆動開発を実践する~チケットに分割して統治せよでは、「チケット駆動開発は、中身は古いが新しい衣をかぶったアジャイル開発」と呼んだ内容は、プリコラージュの意味で使っていたのだと今になって気づいた。

2021年の今となってはもう当たり前の概念だし、普通にみんな使っているけれど、こういう考え方で新しく構造化できるのは面白いと思う。

| | コメント (0)

2021/11/28

第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

| | コメント (0)

2021/10/20

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

Microsoft Plannerを使ってみたら、Redmineと違って使いにくかったと感じたのでメモ。
その理由は、自分の用途に合っていないだけ。
ラフなメモ。

【参考】
Microsoft Plannerの活用事例紹介!ガントチャートでチーム運用状況がすぐわかる! - エク短|Extan.jp

【1】Plannerは、簡易なToDo管理ツールと思った方がいい。
Plannerのチケットは、下記で決められていて、カスタムフィールドは増やせない。

・バケット・・・プルダウンで選択する。選択肢は自由に設定できる。
例えば「機能」「顧客」に使う。
Redmineで言えばカテゴリ。トラッカーではない。
この機能が一番大事。

・タグ・・・2個以上自由に設定できるラベル。
タグなので、種類に使う。
Redmineにタグはないので欲しい。

・進捗状況・・・固定のステータス。未着手→進行中→完了で決まっている。
ステータスが固定なので、ワークフローを自由に設定できない。
結局、課題管理に向かないし、現場でカスタマイズしたいワークフロー管理を実現できない。

・担当者・・・複数のユーザを割り当てられる。

・優先度・・・固定の優先度。Redmineの優先度と同じ。

・開始日、期日・・・Redmineと同じく、予定日と実績日は同じ。
・メモ・・・説明欄。
・チェックリスト・・・チケットにチェックリストを作れるのは便利。
しかし、実際に運用してみると、タスクボードにチェックリストは表示されないので、逐一開かないと、チェックリストをどこまで消し込んだのか分からない。

【2】Plannerを使ってみて、ToDo管理以上の進捗管理には向かないと分かった。
Plannerのアンチパターンもある。

【2-1】バケットをステータス代わりに使うアンチパターン。

バケットにワークフローのステータスを割り当てると、Plannerのダッシュボードに円グラフや棒グラフで表示されるのは良い。
しかし、バケットにワークフローのステータスを割り当てる本来の意図は、Plannerの進捗状況は固定ステータスで使いにくいので、その代わりにバケットで制御しようとしているわけだ。
すると、実際の運用では、チケットをCloseする時、バケット=完了、進捗状況=完了の2つを設定する必要があって、割と操作が面倒。

こういう運用は、昔のBugzillaやMantisを思い出す。
BugzillaやMantisでも、Statusとは別に、Resolutionフィールドがあって、Resolutionでバグの解決状態をわざわざ設定する運用があった。
僕はこの運用が嫌いだった。
Redmineのように、ステータス1個で完了にすれば、わざわざ2つの項目で完了の意味をもたせる必要はない為だ。

また、バケットを複雑化したワークフローのステータスに割り当てると、複数のトラッカーのワークフロー制御をしたくなってきて、10個以上のステータスをバケットに割り当ててしまう。
すると、2本上のトラッカーのステータスが混じっているので、バケットから選ぶときに混乱してしまう。

結局、複雑化したワークフローや、複数の業務のワークフロー管理には向いていない。

【2-2】チェックリストをステータス代わりに使うアンチパターン。

チェックリストは、作業リストを分解して、それぞれの細かい作業を割り当てて、細かい作業が終われば消し込んでいく。
当初使っていた時は、自分1人の作業をチケットに書き、その作業をチェックリストに分解して消し込むのはやりやすかった。
しかし、チェックリストとは、結局、1個の作業の流れの中で、今どこまで作業を消し込んでいるのか、というステータスを表しているだけに過ぎないと分かった。

また、チェックリストの項目が10個以上あると、正直使いにくい。
普通は、チェックリストは上から順に消し込んでいくべきだが、10個以上あると、歯抜け状態のような形で消し込むケースが増える。
チェックリストの状況を一目で把握しにくくなる。

さらに、チェックリストはタスクボードに表示されないので、チェックリストが作業順序に並んだ作業の進捗状況を表しているならば、逐一チケットを開かなければ、その状況は分からない。

【2-3】タグをステータス代わりに使うアンチパターン。

タグにステータスを表示させる運用も考えたが、ワークフローのステータスが10個あった時、10個のタグが初期状態で表示されていてそれを1個ずつ消し込んでいくとか、ステータスが進むごとに以前のタグを消しで新しいタグを付け直すとか、運用は煩雑すぎる。
現実的でない。

【2-4】こういうアンチパターンを考えていると、結局、現場で管理したいステータス管理をPlannerでどのように実現すべきか、という問題に苦労しているのが分かってくる。
つまり、Plannerのステータスが固定である為に、現場で出てくる複雑なワークフロー管理をPlannerにフィットさせるのが非常に難しいのだ。

【3】Plannerでは、バケットの使い方が重要みたい。
なぜなら、ユーザが自由にカスタマイズできる機能は、バケットしかないから。
その他の機能は固定ステータスや担当者、期日のように、すでに用途が限られているからだ。

バケットに、分類すべき業務を設定すれば、ダッシュボードで担当者別・ステータス別にグラフ化してくれる。
つまり、バケットには、ToDoリストのタスクを分類したい観点を割り当てるべき。

【4】PlannerのタスクボードをExcel出力した場合、注意すべき点が色々出てくる。

Plannerのチケットに2個以上のタグを付けると、1セルに複数のタグがカンマ区切りで表示される。
つまり、1セルに入ったタグをExcelマクロで分割して取り出す、という操作が必要になってくる。
タグを使いすぎる時は注意。

同様に、担当者も2人以上割り当てられるので、1セルに複数の担当者名がカンマ区切りで出力される。

【5】Plannerで一番不満なのは、Redmineのクエリに相当する機能がないことだ。
全チケットのタスクボードと、自分にアサインされたタスクボードの2つしか選べない。

フィルタでバケット、日付、担当者などをフィルタリングできるが、その検索条件を保存できない。
だから毎回フィルタリングする必要がある。

結局、より複雑なクエリが欲しければ、Excel出力して、Excelデータをいじくり倒すしかない。

【6】こんなことを考えていると、Plannerの設計思想はタスクかんばんなので、そもそも複雑なワークフロー管理をしようとするのが間違っているのだろう。

Plannerをタスクかんばんとして扱うならば、小さな作業を割り当てて、1チケット=1担当者でアサインし、基本は1日1内にCloseする運用にすべきだろう。
そうでなければ、数多くの情報をチケットに詰め込められないので、すぐにタスクが溢れてしまうからだ。
ToDoリストであるからには、どんどんCloseして消し込んでいった方がいい。

つまり、PlannerはGTDと相性がいいのだろうと思う。
タスクをどんどん書き出して、日々消し込んでいくが、毎週の週次レビューで全チケットを見直す。

換言すれば、日々の業務をPlannerに落とし込んで運用できた場合、その業務はかなりルーチン化されていて、細分化されたタスクになっているだろう。
そういうフィットギャップ分析についても考えてみたい。

| | コメント (0)

2021/05/22

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

本日の第20回東京Redmine勉強会の感想をメモ。
Redmineを思いもつかない利用シーンで使われる事例ばかりで、久しぶりに刺激を受けた。

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

【オンライン開催】第20回redmine.tokyo勉強会 - connpass

2021/5/22 第20回勉強会 - redmine.tokyo #redmineT - Togetter

【1】@g_maedaさんの講演で、Redmineは細かな機能改善だけでなく、セキュリティ強化にも注力している印象を持った。
たとえば、2要素認証、通知メールのドメインの制限など。
OSSとはいえ、セキュリティホールがあると企業の基幹業務では使えないが、Redmineは世のトレンドの追随して、セキュリティのパッチもいち早く当てて対応しているのは信頼が持てる。

akipiiさんはTwitterを使っています 「二要素認証がVer4.2で機能追加された。Redmineを外部インターネットに公開する時は、このコロナ時代でDX時代では、もう必須の機能ですね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット更新メール通知機能の制限強化。セキュリティ面の強化は、Redmineをエンタープライズ面で利用するために必須。ISMSの観点でも必須。 #redmineT」 / Twitter

また、メール送受信のEndToEndでデータを暗号化通信するMIMEプラグインを使った事例もあった。
つまり、SMTPやPOP3という、今となっては相当古いプロトコルであっても、暗号化通信で機能強化することで、Redmineの通知メールを安全に取り扱うこともできる。

akipiiさんはTwitterを使っています 「Redmineの最新バージョンの2要素認証、メールドメインの制限、に加えて、MIMEプラグインでメールの暗号化でセキュリティ強化に貢献できた、と。 #redmineT」 / Twitter

UIの使いやすさも重要だが、セキュリティ機能の強化でユーザが安全に使える安心感をもたらすことも重要だから。

【2】Backlog x Redmine対談では、プロジェクトマネージャに必要とされる能力や役割が、コロナ時代やリモートワークによって急激に変化した印象を持った。

akipiiさんはTwitterを使っています 「プロジェクトマネジメントという言葉が嫌なのは、元請けSIのマネージャと下請けプログラマの開発者、みたいな役割が固定されてしまう響きがあるから。どうしても契約上の力関係がより強固になり、自発性を生み出さない、心理的安全性を生み出さない雰囲気がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット駆動の開発スタイルでは、マネージャの指示によるマイクロマネジメントは正直やりにくい。細かい作業が膨大になってチケット保守はマネージャ1人では回らないから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「結局、担当者にチケット保守を権限移譲して回す方針でないと、チケットは腐りやすい。マネージャ、開発者の役割は関係なく、チーム一体でチケットを消していくゲームにする。それがチケット駆動開発と思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「MoreEffectiveAgileに出てくる「開発チームをブラックボックスとして扱う」「マネージャはチームのInputとOutputだけを管理して作業の中身はマイクロマネジメントしない」やり方はチケット駆動開発に活かせると思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT マネージャも担当者もリーダー経験があると、マネージャはチーム管理が本当にやりやすくなると思います。リーダーの苦労が分かるので、先取りして準備段取りしてくれる。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、データを整備して意思決定しようとする環境を整備しようとしています。エビデンスベースドな意思決定は企業も政府も求められますね。チケット管理ツールはそのデータ基盤を与えてくれると思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「そうそう、門屋さんが言うように「自分がやったことがない技術を使ったシステム開発をマネジメントをする必要がある」。だからPJ管理力に要求される能力は非常に難しくなってきたと思う。特に複数ベンダーに開発委託する案件のマネージャは本当に大変。 #redmineT」 / Twitter

【3】もう一つは、チケット管理に至った結果までの道のりが、各発表者ごとに全く違っていたことも興味深かった。

たとえば、Googleスプレッドシートの情報をRedmineに集約する。
たとえば、チャットや描画ツールでラフな議論をした内容をタスクや課題としてBacklogに落とし込む。
たとえば、工場の現場でExcelのタスク管理をExcelライクなUIにお化粧してRedmineに載せる。
たとえば、全社のワークフローシステムは既にあるが、一つの事業部内の事務処理フローはRedmineに一元化して、全ての申請承認フローを載せた。

たとえば、コロナ感染サイトをRedmineで作った。
たとえば、人や店の地理情報をGoogleMapのAPIを使ってチケット情報に載せた、とか。
たとえば、RPAを使って、テストケースをRedmineに書いて、テストを実行し、テスト結果をExcelに吐き出して、それをチケットに添付して、チケットを更新する一連の作業を自動化する、とか。

とにかくいろんな発想、モチベーションを元に、チケット管理ツールを使いこなそうとしている。

akipiiさんはTwitterを使っています 「#redmineT 今日の勉強会で面白かったのは、Redmineがテーマなのに、Redmineという言葉の同音異義語が多かったこと。工場もあれば、事務の人も使うし、コロナ情報サイトでも使うし、チケット管理に至るまでの道のりも違うのに、参加者同士で話が通じ合うのもすごい。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、チャットのTypeTalkや描画ツールCaCooなどを使っている。何となくこんなのはどうなの?という話や雑談に近い話はBacklogだけでは吸い上げられない。そこでこんなイメージを絵にしたり、オンライン会議したり、色んなツールを駆使してる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、モヤモヤしたテーマや話を見える化した後でBacklogのチケットに書いて、管理しやすくする。門屋さんの場ではGoogleスプレッドで何でも書いてしまうのでRedmineに情報を集約しようとする。チケット管理ツールに行き着く道が違うのが面白いね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「情報の乱雑度合い、散在度合いを下げるために、チケットに集約してエントロピーを下げようとする。その道程は、アイデア発散→課題に収束のパターンもあれば、あちこちのデータを集約、のパターンもある。#redmineT」 / Twitter

akipiiさんはTwitterを使っています 「全社WFの社内システムはあるが、組織内のWFシステムはないのでExcel管理になってしまう。そこでRedmineで組織内WFを構築して上手くいった。あるある。これいいですね! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「都道府県=PJ、感染者=チケットに割当。Redmineの機能にフィットギャップ分析してる。ViewCustominze、MessageCustomize、Tagsなどのプラグインでチケット一覧の見た目をかなりカスタマイズしている。 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「データを可視化するときに、頭の中でDBが動いてた次元構造化をされたんだろうな・・・めちゃくちゃセンスのよさと頭の良さを感じる・・・DBの知識かなり深い方なんじゃないだろうか・・・ #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「RPAでテストして、テスト結果をExcelに書いて、チケットに添付して、チケットを更新する一連の動作を、RPAで実現した事例。RPAはWindows10でも簡単に使えるので色々試せそう。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Shelperのイメージは、チケットにテストケースを書いたら、チケットの更新時に、RPAがキックされて、シナリオ通りにテストされてテスト結果をExcelに残し、それをチケットに添付する一連の動作が自動化された、わけか。Redmine+RPAでテスト自動化ツールになるイメージかな。 #redmineT」 / Twitter


【4】だから、「なぜ、Redmineを使おうと思ったのか?」という理由を講演者に聞きたくなる。

昌。さんはTwitterを使っています 「#redmineT だからなぜこれをRedmineでやろうと思うのw」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineは、改革者を、何にでも解決できそうなツールに惑わせるのです。理由はないのですw」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@aj15_aj15 そこにRedmineがあるから #redmineT +そこにRedmineTokyo勉強会があるから」 / Twitter


【5】Redmineがもたらす組織面の効果は、はっきりとあると思う。
たとえば、Redmine利用者がシステムの機能やUIに目が肥えてしまい、社内のシステム保守担当者に厳しく要求する場合も増えた、という話もあった。

akipiiさんはTwitterを使っています 「Redmineを利用する事務の社員がシステムを見る目が厳しくなって、他システムへの八つ当たりが大きくなった笑 これは良い副作用?効果?ですね。 #redmineT」 / Twitter

たとえば、工場の現場ではベテランが経験を元にノウハウを伝承するが、若手はツールにすぐに慣れるので、逆に若手からベテランにRedmineの使い方を教え合う、という相互作用が生まれた、とか。

たとえば、Redmineの予実管理の機能を使って、見積もり能力を鍛えることができるよ、というメッセージ、とか。

yukiaさんはTwitterを使っています 「工数の予定と実績の管理をチームがしてる時点で、 そのチームは本当にすげぇと思う。 それがボトムアップ発なら、もう奇跡なんじゃないかとすら思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT 工場などの製造業では、工数管理は非常にシビアなので、予定工数と実績工数の管理は、作業管理と同じくらい重要でした。デメリットは、工数管理の間接作業の工数が割と多すぎて非効率な場面もあることですね。」 / Twitter

【6】グループディスカッションで話をしながら、プロジェクトマネージャに必要な能力は何だろうか?と考えていた。
僕は、一つは見積もり能力、もう一つはリスク対応力、と考えている。

akipiiさんはTwitterを使っています 「見積もりスキルのギプスとしてのRedmine。マネージャの能力の大半は「見積もり」能力と思っている。 #redmineT」 / Twitter

僕の数少ない経験上、プロジェクトマネージャの仕事の大半は計画づくりだ。
実際、PMBOKでもプロジェクト計画フェーズだけで、PMBOK本の半分を占めている。
スクラムやアジャイル開発でも、緻密で精細な計画で確定した計画ではないが、チームの開発の羅針盤としての計画は必ず作る。

その計画づくりに必要な能力は、見積もり力とリスク対応力。
これくらいの作業工数がかかる、これくらいの開発規模になる、という予測がなければ計画は作れない。
もちろん、要件定義前の企画フェーズでは、見積もりの精度は低いが、見積もりに必要な要素を探し出そうとすることで、システムのあるべき姿を描いていく。
最初は見当外れに近い仮説かもしれないが、イテレーションを経るごとに、段々と骨格が定まっていき、あるべき姿は明確化されていくので、見積もり精度も後になるほど高くなる。
アジャイル開発では、検査と適応により、フィードバックを重視するので、ソフトウェア開発にも学習による経験曲線効果を活かすことがきると思う。

また、プロジェクトのリスクがどこにあるのか、をいち早く検知することも大事。
マネージャは船の船頭みたいなもので、プロジェクトは一度動き出すと統制を取るのは難しいが、何とか、前進方向を保とうとする。
岩場にぶつかったり、天候異変で思わぬ方向に行きそうになったり、予測しきれない場面もがあるが、そういう場面をあらかじめリスクとしてイメージできるようにしたい。
リスクを全て洗い出すことは難しいが、リスクを拾っていき、そのリスクを自身で保持するのか、別の人に転嫁するのか、リスクの事後対応策や予防策を準備するのか、をイメージしながら、進めていく。

とはいえ、実際は難しいとは思う。
特に、内製開発チームのように、全てのリソースがマネージャの手の内にあればコントロールしやすいが、ステークホルダーが多く、複数ベンダーに開発を委託している案件であれば、複雑なパズルを解くような感覚になる。

【7】Redmineの面白さは、Redmineというツールがたくさんの可能性を秘めているだけでなく、Redmineを使って問題解決する人たちがこういうコミュニティに集まって議論できること。
コロナ感染サイトのように、Redmineをこんな所に使う発想、なんて誰が予想できただろうか?

実際にサイト運営者の方にお話を聞いたら、すごい悲壮感を持っているわけでもなく、なにか作ってみたかった、という気持ちから実現された、とのこと。
仕事はソフトウェア開発に直接関係しないのです、と謙遜されていたが、PythonのPandasでデータをパースしたり、Python-Remdine APIでRedmineにデータを取り込んだり、5種類以上のプラグインを駆使してUIをカスタマイズしたり、本当にいろんな技術を試されているのは、すごい。

自分が持っているアイデアやモチベーションを元に、即座にアイデアを実現できるツールの一つとして、Redmineがある。
僕自身も改めて、モチベーションをもらった感じ。


| | コメント (0)

より以前の記事一覧