Redmine

2024/06/15

第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つだけで日々の業務を全て管理されている。
その時に、約3千ユーザ、数十万チケットを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に関するテーマとして全く別々の5つの内容が議論されていた。
どれか1つのテーマなら詳しい人は参加者でも多数いると思うが、これら5つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2024/04/21

Redmineで持ち株管理する事例

Redmineで持ち株管理するツイートを見かけたのでメモ。
単純に面白いなと思った。

Redmineのチケットにそれぞれの持ち株の情報を記載し、ステータスごとにチケットパネルでカンバン風に表示している。
ステータスは、候補、買付注文中、保有中、売却注文中がある。
おそらく、株の候補をリストアップし、ネット証券などで買付し、保有して、配当をもらいながら、最後に売却するという流れなのだろう。

メリットは、ステータスごとに持ち株の状況がわかること。
だが、実際はこれだけは使いづらいだろう。
現在のそれぞれの持ち株の運用損益や評価金額、すべての持ち株のサマリ情報も表示したい。
また、持ち株の運用損益や評価金額の履歴も表示させたい。

すると、ネット証券のAPIを使って持ち株の最新情報を日次で取得し、持ち株チケットに紐づけて、履歴情報を持たせるような仕組みが欲しくなる。
結局、ネット証券会社のアプリの簡易版みたいな機能が欲しくなってくるだろう。
つまり、Redmineのプラグインでそういう仕組みを作りたくなってくるだろう。

ここで、Redmineのチケットは、かんばんやワークフローのようにステータス管理させたい「フロー」の概念と、情報を資産として蓄積させたい「ストック」の概念の2つを持つ。
今回の持ち株の事例は、チケットをストックとして扱う事例に相当するだろう。

チケットはデータでとプロセスの二面性を持つ #redmine: プログラマの思索

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

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

こういうアイデアは面白いなと思った。
ちょっとしたデータ管理にRedmineを使ってみる事例は色々集めてみる。


| | コメント (0)

2023/12/24

チケットはデータでとプロセスの二面性を持つ #redmine

Redmineのチケットとは一体何だろうか?

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。

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

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

その他にも、Redmineでは、課題チケットという一つのインシデントという情報(データ)として意味を持たせていたのに、課題を解決する対策の作業手順(プロセス)もチケットとして登録される、というケースがよくある。

つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されてステータス管理されるプロセスのケースの2つの性質を持つ。

たとえば、課題、障害、問い合わせのようなインシデントは、都度発生したタイミングでチケット登録される。
それらチケットには、当初のインシデントの内容だけでなく、調査結果や作業ログ、解決策や再発防止策も記録される。
最終的には、解決策や再発防止策は、ナレッジとして蓄積される。

チケット管理システムが持つ検索機能によって、それらナレッジはいつでも取り出すことができる。
つまり、チケット管理システムはナレッジデータベースの側面も持つ。

一方、作業チケットは、何らかの目的に対していくつかの作業手順に分解されてチケット登録される。
一般には、親子チケットで管理されるだろう。
作業チケットは作業手順の一部であるから、作業の順序が重要になる。
チケット管理システムでは、作業の順序はガントチャートのような進捗管理機能として実現されているだろう。

つまり、チケット管理システムは、作業手順というプロセスを管理する仕組みが必要なので、必然的にチケットの先行後続関係を表現したり、クリティカルパスを表現したり、作業チケットのステータスを管理する機能が必要になる。
一般にチケット管理システムでは、進捗管理機能はチケット集計機能の一部として実現されるので、今までに知られているプロジェクト管理システムとして普遍化されるだろう。

そんなことを考えると、チケット管理システムでは、チケットはデータであったりプロセスだったりするし、ストック型プロセスで使われるときもあればフロー型プロセスで使われるときもある。

そういう二面性をあえてチケットに持たせることで、より柔軟にプロジェクト管理しやすくする仕組みを持たせているわけだ。


| | コメント (0)

2023/12/17

PMO観点でRedmineの使い方とは何だろうか

PMO観点でRedmineの使い方とは何だろうか。
以下は経験を元に、アイデアや妄想をラフなメモ書き。

【参考】
PMO観点でRedmineの使い方とは何か: プログラマの思索

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

PMOの役割は、プロジェクトマネージャのサポート役から、プロジェクト管理支援のための事務局、そして、最終的にはシステム監査やIT統制と連動してプロジェクトを第三者的に監査する立場まである。
そういうPMOの立場では、Redmineをどのように使いたいのか?

PMOとしては、プロジェクトが火だるまになる前に事前に状況をキャッチし、プロジェクトのQCDをコントロールできる状態で維持し続けたい。
結局、Redmineからリスクを早めに検知したい。
ではそのリスクはどこから現れるのか?

PMOはプロジェクトの受注段階からリリース完了まで関わることができる前提とする。
そうであれば、受注前のプロジェクト計画を精査して、そこからRedmineにどこまで詳細化できているか、が一つのポイント。
すぐに思いつくのは、スケジュールや工数の観点で、チケット化されているかどうか。

当初計画でどこまでタスクを詳細化してカバーできているか、WBSの粒度はどうなのか。
当初の要員計画からタスクがチケット化されて作業負荷も吟味されて現実的なスケジュールになっているか。
当初計画した工数やマスタスケジュールを元に、マイルストーン単位に無駄なくタスクが落とし込まれているか。

だが実際はすぐにチケット化されているわけではない。
マスタスケジュールのマイルストーン単位に区切られて、直近のマイルストーンまでのタスクを詳細化していくのが現実的だろう。
その単位でチケットに整合性があるのか。
また、Wikiに必要な情報が掲載されているか、も必要な観点だろう。

そして、プロジェクト実行フェーズでは、プロジェクトの活発度合いより不吉な匂いが出ていないか、が一つの目安になるだろう。
チケットの更新頻度、コメントに前兆がないか。
チケットが活発すぎているのか、忙しすぎて逆にチケットに反映漏れが出ていないか。

特に、チケットの種類ごとに内容を見ておきたい。
課題チケットで案件を妨害するような支障は出ていないか。
障害チケットに品質悪化を示す兆候はないか。

プロジェクト計画時点で、システムのアーキテクチャの課題、プロジェクトの目的となる解決した課題と機能要件の実現性、非機能要件のリスクは普通洗い出しているはず。
特に、レスポンス、スループット、ネットワーク通信などの非機能要件とか。
それを念頭に置いて、どこでリスクが出そうなのか、考えていくべき。
特に昨今は、スクラッチ開発よりも、パッケージ製品の導入やカスタマイズ、他社のSaaSや外部システムと連携するアーキテクチャが多いので、開発リスクは以前よりも大きいと感じる。
そういうリスクがチケットに現れていないか、も一つの観点になりうる。

案件の実行中に、定期的にふりかえりをやっていればいいが、実際は忙しくてそれどころではないだろう。
日々の開発の中で小さな課題を一つずつ潰していく。
その活動の履歴がチケットの更新履歴に出てくるはず。

チケットの消化度合い、消化速度、残チケット数も一つのポイント。
当初計画されたチケット枚数から、さらに課題や障害によりチケット枚数が増えたとしても、案件をコントロールできて入れば、チームが消化できる範囲内に収まるはず。
残りの期間とチームの消化速度(実際はベロシティのようなもの)から、バーンダウンチャートで着地点が見えるはず。
それがコントロールできない場合、チームは混乱しているだろう。
特にテスト工程では、障害チケットの解決をどこまでコントロールできるか、が鍵を握る。

PMOは第三者観点の役割なので、プロジェクトを実行するチームを支援するがチームと一体化しない。
第三者の立場で、気づきをフィードバックし、マイルストーンでの上役への報告を支援し、最後のリリースで出荷可能な品質なのか判断を下す。
だからPMOはプロジェクトから見ると余計なお世話の役割であり、嫌われやすい。
しかし、PMOがしっかりしているからこそ、プロジェクトの暴走を早めにキャッチして防ぐこともできる。
この辺りの駆け引きの中で仕事している感じ。

PMO観点でRedmineの使い方はもう少し色々考えてみたい。

| | コメント (1)

2023/11/05

第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月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。

| | コメント (0)

2023/06/03

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

第24回redmine.tokyo勉強会の感想をラフなメモ書き。

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

第24回redmine.tokyo勉強会(2023/6/3) #redmineT - Togetter

【毎月更新】Redmine リリース前の新機能を先行チェック!チケットのフィルタでOR検索ができる「いずれかを含む」など(2023年4月コミット分) | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック!関連するチケットの番号を複数指定した絞り込みなど(2023年3月コミット分) | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック!オートウォッチ「自分が作成したチケット」の追加(2023年2月コミット分) | Redmine.JP Blog

【1】@g_maedaさんの講演では、Redmineで未リリースだが取り込まれたパッチの機能改善が紹介された。
興味深い機能は、検索機能の強化だ。

チケットのフィルタでOR検索ができる「いずれかを含む」は、チケット項目だけでなく、フィルタ演算子にも適用できる。
たとえば、添付ファイル名の後ろが .png または .jpg で終わるチケットを抽出とか。
チケット一覧でSQLのように扱うことができるだろう。

また、「現在・過去の値、過去の値、履歴に一度もないの3つで検索する」機能も追加された。
使い方の例として、担当者が自分になったことがないチケット、 担当者が過去に自分だったチケット、Closeしたけど過去に自分が携わったチケット、などがあった。
過去レビューしたチケットを検索したい時に、細かな検索条件を追加することで対応できる。

akipiiさんはTwitterを使っています: 「チケットのJournalテーブルを参照して、現在・過去の値、過去の値、履歴に一度もないの3つで検索する。更新日の検索条件を入れた感じかな。OR検索といい、検索の細かい機能改善をやってますね。 #redmineT」 / Twitter

仕組みとしては、Journalテーブルの更新日を検索している。
よって、過去の履歴をより詳細にフィルタリングできるわけだ。
本来は直接SQLを書ければいいのだろうが、こういう機能改善によって、SQLの検索条件をチケット一覧のUIでカバーできるようになったのはありがたいことだ。

一方、Redmineの右上の検索ボックスの機能と全く同じであるため、チケット数が20万件以上になると性能要件に問題が出てくるだろう。

akipiiさんはTwitterを使っています: 「全検索対象テキストの機能は、性能要件は大丈夫なのかな? チケットが数万件、数十万件でもレスポンスは問題ない? インデックスを張ってあるのだろうな。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。Journalテーブルの件数が多くなると遅くなる。検索ボックスの機能と全く同じなので、検索ボックスのボトルネックを感じるなら同じ現象が起きる、と。」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。full_text_searchの検索結果と検索ボックスの検索結果は異なるケースが発生する。クリアコードさんに機能改善を対応してほしいなあという依頼ありw」 / Twitter

RedmineのデフォルトDBはPostgresSQLなので、パラレルクエリを使って、複数のCPUを活用するクエリプランを生成しクエリの応答をより速くする方法がある。
このチューニング方法を使ってもいいかもしれない。

akipiiさんはTwitterを使っています: 「#redminet Oracleのマテリアライズド・ビューみたいな機能を使ってクエリ検索の性能を上げたいアイデアがありました。PostgresSQLならパラレルクエリの機能があるんですね。なるほど。」 / Twitter

第15章 パラレルクエリ

【2】ChatGPTでRedmineチケットを自動作成する方法を試す事例があった。

akipiiさんはTwitterを使っています: 「Redmineの連携方法をChatGPTに聞いてみた。 #redmineT https://t.co/UzMAAe7dCj」 / Twitter

しかし、チケットの内容が微妙で思ったような内容でないらしい。
プロンプトエンジニアリングとか色々テクニックが必要な気がした。

akipiiさんはTwitterを使っています: 「#redminet Redmineチケット作成にも、プロンプトエンジニアリングが必要なのかもしれませんね。」 / Twitter

ボウコバさんはTwitterを使っています: 「@akipii ChatGPTは、知らないことは適当な情報で埋める傾向があるので、知らないことは勝手に決定せず、自分に質問しろと指示する案も出ていますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@bowkoba なるほど、機械の中身は統計処理の推測ですからね。どういう立場で情報がほしいとか、前提条件や制約条件をかなり追加する必要がありそう。」 / Twitter

しかし、ポテンシャルはあるから、ChatGPTで、埋もれたナレッジを再活用するとか、バグチケットに類似バグ調査、過去の類似チケット検索とか、AIで補完してほしいと思う。

akipiiさんはTwitterを使っています: 「Bingに同じことを聞いてみた。埋もれたナレッジを再活用するとか、まだマシかな?? #redminet https://t.co/HKtFgxwrjG」 / Twitter

【3】川端さんから、逆引きでわかる! Redmineハンドブック バージョン5.0対応の紹介。
今までの、いかにも土壇場で作ってきました講演と異なり、Redmineの事例紹介の内容がかなり詳しかった。
たぶん、7千社近い顧客企業の事例を持っているので、Redmineのチケット管理でタスク管理するにはどういう使い方がその企業に向いているのか、かなりノウハウが溜まっているのだろうと感じた。

(1) りょうまさんはTwitterを使っています: 「川端さんが真面目な話してるの、超久々に聞くんだが #redmineT」 / Twitter

Redmineのチケット管理でハマりやすい問題は、いくつかある。
1つ目は、ワークフローの複雑さと親子チケットの階層の深さのトレードオフだ。
講演では、レビュー中というステータスを外し、ワークフローを単純化して親子チケットで対応する方法が紹介されていた。
この手法は、トラッカーの種類を減らし、ワークフローを短縮化する一方、親子チケットの階層を深くしてでも対応することに相当する。
プログラマやガントチャート好きなマネージャはツリー構造に慣れているので、このやり方が向いているかもしれない。

2つ目は、PJで現れる工程やフェーズはRedmineバージョンで使うか、親子チケットで対応するか、というトレードオフだ。
一般に、WF型開発では、Redmineバージョンを要件定義、設計、開発、テストのように割り当てる時が多い。
しかし、このやり方では、システムとしてリリースできるタイミングはPJの最後の1点だけになり、リスクが大きすぎる。

講演では、バージョンを使わず、親子チケットのうち子チケットでフェーズ分けする手法が紹介されていた。
つまり、親チケットは実装する機能とし、子チケットで要件定義・設計・開発・テストごとに作成して、親チケットでタスク全体を管理する。
このやり方であれば、親チケットをどのイテレーションでリリースするか、だけ決めるだけでいい。
WF型開発であっても、小規模な改善が多い案件、保守案件ではこのやり方の方がアジャイル開発に似ているので運用しやすいだろう。

【4】中村さんの講演では、Redmineを外部記憶装置として扱い、少ない脳内メモリを有効活用しようという話だった。
GTDにある「頭の中で動く猿を追い出す」ことと同じだなと思う。

(1) アカベコさんはTwitterを使っています: 「チケットや Wiki などを外部記憶装置と認識、よくわかる。外部記憶、かつ長期記憶で起票とかメモすることで短期記憶のスタックを明け渡すようにしてる #redmineT」 / Twitter

【5】@yukiaさんの講演では、チケット管理ツールを個人向け、チーム向け、組織向けの3階層で分類していた。
個人<チーム<組織の順に、統制や標準化という押しつけが大きくなるイメージだろう。

中村さんの話でも、チケットに記載しない内容として、個人タスク、案件化していない情報などがあった。
だから、GoogleKeep+Redmineを使っているとのこと。
確かに、GoogleKeppならメモやちょっとした履歴にも使える。
つまり、個人のタスク管理、メモ管理としてRedmineを利用する方法は実はあまり議論されておらず、今後、もっと試してみる価値はあるだろう。
僕の直感では、GTDのようなワークフローやUIをRedmineで実装できるかどうか、が鍵を握ると感じる。

(1) akipiiさんはTwitterを使っています: 「タスク管理ツールは3種類ある #redmineT https://t.co/IIOkSESd5Y」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チームのためのツールは課題管理がメイン #redmineT https://t.co/WeJGHxZEAD」 / Twitter

(1) akipiiさんはTwitterを使っています: 「組織のツールはワークフローで統制できること #redmineT https://t.co/bX9m8iwioG」 / Twitter

【6】@ryouma_nagareさんが紹介してくれたpython-redmineは試したみたいと思う。
REST APIはありがたい機能なのだが、チケット全件を取ろうとすると100件という制限があったりして割と面倒。
もっと手軽にデータを扱いたいから。

maxtepkeev/python-redmine: Python Redmine is a library for communicating with a Redmine project management application

【7】@MadoWindaheadさんから、チケット管理システム有識者の集いを開催したい、という要望があった。
チケット管理ツールの同盟を組んで、想いを実現したい、と。

(1) akipiiさんはTwitterを使っています: 「プロダクトマネジメントはプロジェクトマネジメントと確かに違うね。アジャイル開発やSaaSで多いかな #redmineT https://t.co/XSlKg04ykI」 / Twitter

(1) akipiiさんはTwitterを使っています: 「PJ管理ツールと同盟を組んだ #redminet https://t.co/OY0bUqbf3Q」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チケット管理ツールの同盟を組んで、想いを実現したい #redmineT https://t.co/e9sCIQZWCt」 / Twitter

今は色んなチケット管理ツールが有償・無償であり、それらの機能を比較して考えていくと、ああそういう使い方がしたかったのか、そんな利用シーンがあったのか、と気づく時がある。
プロジェクト管理の手法はまだまだ枯れておらず、色んなやり方を試せると思う。

| | コメント (0)

2022/12/17

「Redmineハンドブック」は良い本です

9月に出版された「逆引きでわかる! Redmineハンドブック バージョン5.0対応」を@agilekawabataさんから献本して頂きました。ありがとうございます。
読みどころを書きます。

【1】「Redmineハンドブック」の一番良い点は、こういうことがしたいんだけどRedmineの機能は何だっけ?と疑問に思った時に、逆引きで探せること。

たとえば、期日が切れたチケットを表示したり、放置されたチケットを表示したり、チケット同士を関連付けたり、チケットに先行後続の関係を付けるとか、探す時に便利。
Redmineのようなチケット管理ツールに慣れていれば、すぐに分かるけれど、初心者や慣れていない人にとっては、知らないことがすごくストレスになる。
たぶん、目次や索引から探すようになるだろう。

【2】「Redmineハンドブック」では細かいノウハウが紹介されている点も良いと思う。
たとえば、親子チケットの設定では、大日程だけで概算見積して親チケットの開始日・期日を設定した後、小日程計画で小チケットに細かくブレイクダウンして期間を設定すると、親チケットの開始日・期日が消えてしまう。
なぜなら、Redmineの初期設定では、親チケットの情報は子チケットをロールアップされる仕様だから。
よって、管理画面で、親チケットの開始日・期日を独立させるような設定をする必要がある。

また、大人数のユーザや多数のユーザグループを作った場合、細かくロール設定するのが面倒だ。
そんな場合、JAXAのロール設定の事例の話が「Redmineハンドブックで紹介されている。

CODA チケット管理システム | JSS@JAXA
「CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント」

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

【3】「Redmineハンドブック」では、WF型開発やアジャイル開発の運用方法が紹介されている点も良い。
慣れていない人にとっては、やはり実際にどのように運用できるのか、イメージが湧きやすいと思う。

WF型開発では、WBSをチケットに落とし込んで、ガントチャートで管理するのが一般的だ。
ガントチャート画面にイナズマ線が表示される機能も紹介されている。

一方、アジャイル開発では、スプリントはバージョン、タスクはチケットに対応付けて、チケット一覧でスプリントごとにグルーピングしてタスク管理するのが一般的だ。
チケット一覧ではやりにくい場合は、かんばんプラグインを入れて、タスクボードをかんばんで見立てるとよりアジャイルな雰囲気が出てくるだろう。
たとえば、アジャイルウェア社のLycheeかんばんもあるし、フリーでいくつかのプラグインがある。

チケットパネル (Redmineプラグイン) - ファーエンドテクノロジー株式会社

[Redmine] チケットをかんばん表示にするプラグイン | 適当に書き連ねるネタ帳のようなもの

GitHub - happy-se-life/kanban: Kanban plugin for redmine

【4】「Redmineハンドブック」で面白いと思った点は、最終章にGTDのタスク管理が紹介されている点だ。
やっぱりチケット管理はGTDのようなライフハック的なタスク管理のほうが向いていると思う。
Redmineにガントチャートはあるが、タスクをチケットでサクサク登録して更新してCloseしていく方が開発のリズムが生まれる。
すると、粒度の小さいチケットをたくさん作り、バックログとして一列に並べて、上から順にチケットをこなしていったり、溜まったチケットは定期的に棚卸しして作業しやすくする、といった運用方法になってくる。
つまり、自然にGTDのようなタスク管理に近づくわけだ。

さらに「Redmineハンドブック」では、仕事に追われない仕事術 マニャーナの法則 完全版 | マーク・フォースター, 青木 高夫 |本 | 通販 | Amazonをもとにいくつかの役立つ概念を紹介している。

タスクチケットは期日や重要度、優先度、ステータスによって種類がいくつかある。
それらをリストに分類し、リストに名前付けして管理するわけだ。
たとえば、オープンリストとクローズリスト、マスターリストとフィルターリスト、いつややることリスト、ペンディングリストなど。
初歩的なやり方ではあるが、割と使える方法だと思う。

というわけで、手元に1冊あると役立つ本だと思います。

| | コメント (0)

2022/11/06

第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

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

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か?
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査 事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね? #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか?
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ!という話。
チケット駆動が楽しい!
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

| | コメント (0)

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)

より以前の記事一覧