Redmine

2020/11/16

情報はハイパーリンクでつながることで一つの知識体系になる~Scrapbox情報整理術の感想~Scrapboxはカード型のビジュアルWiki

Scrapbox情報整理術の本を読んで、こういうWikiの機能をRedmineにも取りれられられたらいいのにな、と思った。
ラフなメモ書き。

Scrapboxの使い方 - Scrapbox ヘルプ

「Scrapboxはカード型のビジュアルWiki」が言いたいメッセージ。
単なるWikiではなく、入力のしやすさ、使いやすさが埋め込まれている。

Scrapboxの特徴は2つある。
一つは、Tabキーを押しながら、箇条書きで書くのが基本なこと。

文章の基本はやっぱり、アウトラインプロセッサと同じ。
Wordのアウトライン機能のように、詳細なメッセージはツリー構造にする。

また、英語で習うパラグラフ・ライティングと同じ。
Topic sentence、Supporting sentence、Concluding sentenceで1個のメッセージをつくる。

パラグラフライティング 英語レポートの書き方・例文 トピックセンテンスとは? | 脱中級! 37歳からの英語学習

Scrapboxがいいのは、Web上のWikiなのでスマホやPCで気軽に書けるし、リファクタリングしやすいことだ。
思いついたことをどんどん書いておいて、後で読み直す時に書き直せばいい。

Wikiは「永遠の未完成」でいいのだ。

もう一つは、[]でページリンク、#でハッシュタグを付けながら、リンク先の未作成のページをどんどん作っていくこと。
たとえば、「[Redmineのチケット管理]」みたいにいったん書いて、後続の文章をどんどん書いていく。
すると、「[Redmineのチケット管理]」のリンクができるが、その先は未作成のWikiなので空っぽ。
後で気づいた時に、そこに、チケット管理の気づきを書き込めばいい。
つまり、リンクしながら文章をリファクタリングしている。

リンク先の空っぽのWikiは用語集みたいなもの。
そこに何かを埋めようと思って書き始めると、自分だけの用語集が出来上がる。

僕は、Scrapboxのリンク機能が上手いなと思った。
ページタイトルは自然にWiki新規ページになるが、タグにもなりうる。
つまり、「#Redmineのチケット管理」と同じなのだ。
思いつきを故意にリンクできるわけだ。

こういう用語集をたくさん作り出すことで、Scrapbox上のページは、ネットワーク構造でフラットな構造として構造化される。

元来、情報整理術は、梅棹 忠夫さんの知的生産の技術以来、日本人の文化人が連綿と引き継いできた。
平成に入る前までは、京大型カードみたいにアナログのカードに穴を開けて、図書館の本の目録を作ったり、研究者が自分のテーマをアナログのカード型データベースで集めて整理したりしていた。
彼らは、集めた情報を畳の上に広げたり、並べたり、ばらすことで、色んな発想を生み出していた。

では、情報整理術はどんな歴史で発展してきたのか?

Scrapbox情報整理術では、情報整理術にはバージョンが3つある。
Ver1.0は、情報はツリー構造で整理する。
情報の粒度で整理できるが、見通しは悪いし、色んな情報をひと目で見にくい。

Ver2.0は、時系列順に整理する。
重要な情報は、LIFO、スタックみたいな構造になっているものだ。
実際、頻繁に取り出される情報ほど上澄みにあり、使われない情報は深海に沈んでいく。
しかし、やはり情報から発想するのが難しい。

Ver3.0は、ハイパーリンクで情報を紐付けること。
これは、Webができたからこそ実現した仕組みだ。
GoogleはPagerankによって、ハイパーリンクの参照度合いで、情報の信用度をランキングすることまでやり遂げた。
ScrapboxやWikiは、情報のハイパーリンク化の産物だ。

では、ハイパーリンクの情報整理術はどんなメリットをもたらしたのか?

一つは、知識はネットワークであること。
情報がハイパーリンクでリンクされることで、一つの情報の連想先が明示される。
それらをたどっていくうちに、色んな情報を手に入れることができる。
つまり、情報はハイパーリンクでつながることで、一つの知識体系になる。

Scrapboxでは、ページリンクやハッシュタグでハイパーリンクが簡単に作れる点が一番のメリットだ。
Scrapboxはハイパーリンクをタグ書きする面倒さをなくしてくれる。

2つ目は、知識は再編され続けること。
Wikiページで書かれた内容は、いつでも編集できる。
間違っていれば直せばいいし、情報が古ければ更新すればいい。
あるいは、別の情報と関係することが分かれば、別のハイパーリンクを付ければいい。
つまり、ハイパーリンクでつながった知識は、常に更新され続ける。

知識はネットワーク構造だからこそ実現できる性質だ。
これは、知識は追加されず固定的な概念である、という一時代前の考え方に対する、一つのパラダイムシフト。

3つ目は、隠れた知識がある事。
哲学者のポランニーは「人は言葉にできるよりも多くの事を知ることができる」と言ったらしいが、まさに、Wikiページタイトルにある一つの言葉は、Wikiページの内容で説明されたたくさんの情報を表している。
同様に、哲学者ソシュールの「記号(言語、知識)とは概念(シニフィエ)と名前(シニフィアン)が表裏一体となって結びついたもの」と同じ意味合いだなと思う。

「人工知能は人間を超えるか ディープラーニングの先にあるもの」の感想: プログラマの思索

機械学習が抱える問題: プログラマの思索

Scrapbox情報整理術では、ここからさらに、野中郁次郎先生のSECIモデルに話を膨らませている。
知識という形式知と暗黙知はお互いに関連しあっていて、そこからさらに色んな情報を想起させてくれるわけだ。


知識は形式知で死ぬわけではない。
人間は一つの言葉の背後に数多くの暗黙知を持っていて、その時代背景やその一個人の価値観がさらに情報を膨らませていく。
昔使っていた言葉が、時代を経るごとにどんどん変わっていくのと同じ。

Redmineでも、こういう設計思想をWikiの機能に実現できないだろうか?
Wikiのリンクは、Wikiの新規ページタイトルになるのはよいが、どうように、ハッシュタグの機能も追加して欲しい。
そうすれば、自分たちで入力したナレッジのWikiは、自分たちだけの用語集として実現される。
それこそが本来のナレッジ資産であるはず。

| | コメント (0)

2020/11/14

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

第19回東京Redmine勉強会に久しぶりに出て楽しかった。
ラフなメモ書き。

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

2020/11/14 第19回勉強会 - redmine.tokyo #redmineT - Togetter

フルリモート開催2回めのredmine.tokyo 日々の悩みと笑いと感動あり #redmineT | マドびっ! Madosan's View

【1】@g_maedaさんのRedMicaの講演では、細やかな機能改善の紹介があった。
Wikiにテーブル挿入ボタン、Ctrol+Enterでフォームサブミット、ユーザマスタCSVインポート機能など。

akipiiさんはTwitterを使っています 「#redmineT 2要素認証の機能追加に伴い、ユーザリストCSVの項目追加、メール送信のドメイン制御などセキュリティ面の配慮がなされている。」 / Twitter

セキュリティ面の機能強化に意識されているのはいいね。

【2】2本のパネルディスカッションは面白かった。
各パネラーの体験談を元にした失敗談、成功談をショートストーリーで紹介し、それを他のパネラーが突っ込む。
そういう意見が出るのか、脱線した話もあっていい感じ。

【2-1】話を聞いていると、ツールでプロセスを実装するか、目的のあるプロセスをツールにフィットさせて実装するか、という議論がごちゃ混ぜで面白い。
@saitoさんと話ししていると、やっぱり僕も、やりたいプロセスが既にイメージできていて、そのプロセスをツールに当てはめて、ツールの設計思想に上手く組み込む感じ。
一方、ツールを使いながら、ああ、こういう機能はこういう時に使うのか、こういう時に役立つのか、と気づく時もある。
しかし、最初はスモールスタートで運用し始めていくと上手く行っても、他チームが相乗りしてどんどんRedmineが複雑化してコントロールしにくくなる話もあったな。

(1) akipiiさんはTwitterを使っています 「Redmineの話ではなく、社内のプロセス改善の話になってる。ツールにプロセスを乗せるか、プロセスにツールを合わせるか、どちらも混じって面白い。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ユーザディスカッションは、@saito0119 さんと2人で盛り上がる。Redmine の思想は分かって欲しい。トラッカーはチケット種別ではなく、ワークフロー管理が基本、は同意見。プロセスありきで設計しないと後で混乱するから。」 / Twitter

齋藤さんはTwitterを使っています 「@akipii プログラマって、アプリに納得できるかどうかは、設計思想で決まると思ってます。redmine の設計思想が理解できると、後は簡単な気がする。 #redmineT」 / Twitter

【2-2】心理的安全性のテーマはよく出る。
チケット駆動では、メンバーが自発的に登録して、タスクを他人に振って、自分でクローズする運用でないと効果的にならない。
しかし、日本の現場では、派遣契約や外部委託などの契約のために、上からの指示になり、変な忖度をしがち。
おそらく、心理的安全性が日本で盛り上がるのは、上意下達の組織に慣れすぎてしまって、自分からリーダーシップを発揮する訓練が不足しているのだろうと思う。

【2-3】TeamsとRedmineの話も個人的にはとてもヒットした。
GSuiteからTeamsに変わって、とても便利。
Teamsでチャットもできて、TV会議もできて、Googleドライブみたいにファイル管理できるし、Plannerでちょっとしたカンバンもあるし、SharepointでWikiみたいに使えるし、何でもできる。
すると、チーム内のコミュニケーションは全てTeamsでカバーできる。
しかし、課題管理やタスク管理はTeamsでは辛いので、Redmineを使いたくなる。

akipiiさんはTwitterを使っています 「#redmineT Teamsを使ってると、簡単なカンバンはPlanner、テレビ会議も2人だけのチャネルもあり。ExcelファイルやOneNoteもTeamsでGoogle ドライブみたいに共有できるし、Sharepointにもアクセスできて、確かに便利。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ただし、課題や日々のタスクはTeamsでは管理しにくい。当たり前だがRedmine の方が一括管理できて、履歴が残るので、やりやすい。他事例で、TeamsのPlannerとRedmine チケットをリンクさせてストーリーカードとタスクカードで運用してる話もあった」 / Twitter

チャットを使うことで、Redmineのチケットのコメントがきれいになった、というメリットは同意する。
コメントは掲示板みたいな機能かなと思うが、もっとリアルタイムに速くやり取りしたい時に、チケットのコメントは遅い気がする。

akipiiさんはTwitterを使っています 「これをメリットと思うかデメリットと思うか。コメントは掲示板みたいな機能だった。RT @juno_nishizaki: チャットが使えるようになってからチケットの注記に書くにはノイジーだなって思うような会話をチャットに移せるようになったのでチケットがスッキリするようになったかと感じています #redmineT」 / Twitter

Teamsでこれだけコミュニケーションができると、正直、メールは仕方ないから使っているだけ。
メールはFaxと同じレベル。いい意味でも悪い意味でも。

akipiiさんはTwitterを使っています 「“@saito0119 さん曰く、メールは仕方ないから使ってますよね。メールはFAXと同じですね。本当に同感。 #redmineT」 / Twitter

【2-4】@satioさんと話していて面白かったのは、リモートワークになって、新人や若手が苦労しているね、という話。
オフラインでOJTができないので、初めての設計、レビュー、プログラミングのデバッグなどがやりにくいらしい。
すると、困ったことを誰にも話せず、自分一人で困っていて、何も成果を出せない結果になりがち。
だから、頻繁なコミュニケーションを取りながら、逐一フォローできる仕組みや環境が必要みたい。
つまり、経験者だけでなく新人ですら、成果主義が求められている。
僕は会社から教育された経験がないので、自分一人で勉強してスキルを身に着けていくべきでは?と思っている。

akipiiさんはTwitterを使っています 「リモートワークでRedmineでタスク管理を強制導入しでて、リーダーは馴染めなくていつの間にか異動で消えた、なんてリアルすぎる笑。   #redmineT」 / Twitter

【2-5】Redmineでは、通知メールよりも活動タブをもっと使うべきだ、という意見は、ツイートでも賛成意見が多かった。
詳細が知りたいのではなく、PJの活発度合いを見たいのだ。

(1) akipiiさんはTwitterを使っています 「#redmineT 活動タブでなく、活躍!タブか?」 / Twitter

一方、PMOは特定の複数PJを全部見たい時があるが、活動タブでも親PJで全てのPJの活動履歴を見るしかない、みたいな意見もあった。
この辺りは、活動タブのフィルタリング機能だけでなく、プロジェクト階層構造など色々工夫が必要な感じ。

akipiiさんはTwitterを使っています 「活動タブが通知メールよりいいね、と議論が活発。ただし複数プロジェクト全般で見る管理者は、こまる時があった。特定プロジェクトだけ見る時は良かった。 #redmineT」 / Twitter

【2-6】また、ガントチャートのWBSチケットとチケット駆動のチケットは粒度が違うので、いつもミスマッチが発生してトラブルが起きる。

あいちゃん2号の代理人さんはTwitterを使っています 「だけど、 ガントチャートを描くのって、 結構難しいと思う。 いかに仕事の全体像と、 チーム力が試される。 #redmineT #redmine」 / Twitter

akipiiさんはTwitterを使っています 「#redminet ガントチャートのタスクの粒度と、チケット駆動のチケットの粒度はミスマッチな点に問題があると思います。ガントチャートは荒すぎて、毎日見ても、進捗が進んでないように見えてイライラする」 / Twitter

【2-7】RedmineのUIが機能改善されるのを見ていると、メンバーがもっと楽しく使えるような機能が欲しいと思ってくる。
どうしても、Redmineは管理ツールなので、管理者の観点で使ってしまいがち。
しかし、本来は、メンバーが自由に自分たちのために使って欲しい。
そういう時に、感謝の気持ちや同意する気持ちを簡単に表明できる機能が欲しい。

FacebookやTwitterはそういう機能が上手だし、Teamsでも、いいねアイコンが6個ぐらい追加されて、微妙なニュアンスが表現できるようになった。
ちょっとした機能に過ぎないだろうが、メンバーの貢献意欲を引き出し、PJのゴールに向けて一致団結していく雰囲気を醸し出す機能が欲しいのだ。

akipiiさんはTwitterを使っています 「#redmineT Redmine にメンバーの意欲を盛り上げる機能が欲しい。いいねボタン、GoodJobボタン、GitHubの草、とか、もっとあるはず。大した機能でないけど、楽しく運用したい」 / Twitter

【3】LTも個性的な講演ばかり。

Planioはカンバン機能もあるのは知っていたが、サポート用メルアドが既にあり、サポートデスクの機能は便利だな、と思った。

akipiiさんはTwitterを使っています 「#redmineT planioのサポートデスク機能は、メールによるチケット登録機能を使ってるわけか。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT planioでタスク管理、作業時間管理、サポートデスク、リポジトリなどを使って、便利に使ってる。確か、アジャイルのタスクカンバンもありましたね」 / Twitter

しんやさんのLTは、アンチパターンのお話。
2017年にリツイートした人だったのですね。
最後は退職をチケットに書いた、というオチ。
誰が承認するの、完了にするの、却下できるの?みたいな議論があった笑。

akipiiさんはTwitterを使っています 「面白すぎる。RT @NAGAYASU_Shinya: Redmineにて塩漬けチケットがしぬほどある部署にいたとき、ついカッとなってここ1ヶ月更新のないチケットを一気に却下にしたったことある ……すごい怒られた、そして別に業務になんの支障もなかった。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT アンチパターン。全員チケット全員ウォッチャー。通知メールが数千件?も届く!怖い」 / Twitter

JAXA木元さんのLTでは、親子チケットのアンチパターンの話があった。
確かに、親子チケットが使える場面は、WBSのようにあまり変化しないケースの方が向いている。
ツリー構造よりも、関連チケットで表現したい時が多くなる。

akipiiさんはTwitterを使っています 「JAXA木元さんの話。親子チケットでこうぞを見える化したいブームがあったが合わなかった。WBSのようにキッチリしたケースは良いが、課題管理のように関連チケットや親子チケットが混じるとエラーが出てフラストレーションが溜まる。 #redmineT」 / Twitter

Nishizakiさんが、Redmineの設計情報をまとめたいという心意気は同意する。
Redmineの設計思想は僕はとても優れていると思う。
オープンソースで10年以上も存続できて、RubyやRailsの激しいVerUpに耐えながら品質を保ってきたのはすごいと思う。
しかし、外部接続のAPI一覧やデータベースの知見などがもっと欲しい。
そういう設計思想を手動でWikiで集めるのも良いし、SwagarAPIみたいに、APIの仕様書とテスト環境を一緒に作ってしまう、とか、色々やり方があるので実現できるといいなと思う。

奈良さんの話では、複数のRedmineサーバーを建てる場合、マスターのRedmineサーバーにあるユーザ・グループなどの基本マスタをセカンダリーの他Redmineサーバーに同期させるやり方を紹介していた。
今はPoC段階です、と言っていたが、このやり方であれば、LDAPのユーザ情報だけ管理できれば、PJ等のその他のマスタは各Redmineインスタンスで自由に使ってもらえれば良い。

akipiiさんはTwitterを使っています 「#redmineT Redmine サーバーのマスターのユーザ、グループなどをセカンダリーのRedmine サーバーに同期させる運用のお話し。確かにこれなら、複数インスタンス管理は楽になりそう」 / Twitter

【4】Redmine勉強会のスタッフとして10年関わっているが、Redmineの面白さを改めて痛感した。
Redmineの面白さは、PJ管理や開発プロセスの実装というソフトウェア工学の観点、そして、Redmineの複数インスタンス制御とかRedmineのデータベース設計などのPJ管理ツールの開発基盤の観点の2つが議論できること。

だから、PJ管理などのマネジメントの話ばかりしていると飽きてしまうけど、飽きたら、Railsやデータベース設計、インフラ構築などの技術の話に行ってもいい。

僕のイメージでは、ソフトウェア工学の話をしている時はサイエンティスト、開発基板の話をしている時はエンジニアの気持ちになっている。
サイエンティストはあるべき姿の理想を延々と話すが現実は違うし、その理想を実装すると、性悪説に基づくPJ管理ツールになってしまう。
一方、エンジニアは、あるべき姿の理想を仕様に落とした時、現在の技術の範疇でどこまで実装できるか、技術や品質・コスト・納期のトレードオフを考えて、現実的な解を出す。
自分の中に2つの人格があって、心の中でお互いに議論しあって、衝突した結果、全く別のアイデアが生まれたりするのが楽しい。


| | コメント (0)

2020/11/11

「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド

今夜行われた「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた。
ラフなメモ書き。

【参考】
静岡ギルド(準備中)勉強会「製造業アジャイル、静岡での実践!」 - DevLOVE | Doorkeeper

詳細は上記ページの通り。
1回目は、POもSMも開発チームもScrumの初心者だった。
やる気はあったが、やはり色んなトラブルが出て、POや開発チームのコミュニケーションも悪くなり、進捗遅延で増員されるたびに開発案件がどんどん膨らんでしまう。
最後に、SMの役割を果たせず、案件から抜けてしまう。

再起を期した2回目はいろんな工夫をした。
その話を聞くと、ポイントは2つあると思う。
それは、組織構造と組織文化の2つ。

組織構造の面では、POを2人体制にしたり、開発チームに進捗報告担当のトラッカーを立てたり、SMも時には開発に入ったり課題管理に直接関わったりしたこと。
Scrumの本来の姿ではないかもしれないが、各人の役割と責任に対し、権限と責任が一致できていないならば、補佐を立てて強化したり、あるいは自ら作業に加わったりする。
目的は、Scrumを運用することではなく、開発案件を成功させることなのだから。

組織文化の面では、TeamsでPOと開発者が頻繁にコミュニケーションする。
コメントに、いいねやハートのアイコンをつけることで、ちょっとしたニュアンスを伝えられた。
TeamsのPlannerでPBIを書いて5つのステータス(ToDo、Ready、Doing、Reviewing、Done)でかんばん風に管理したり、TeamsのPlannerで書き足りない内容はRedmineのチケットに詳しい仕様や課題を管理し、Sprint計画はRedmine上でロードマップ画面を使った。
スプリントレビューのデモでは、Teamsのカメラ機能を使って、実際にスマホアプリの動作をステークホルダーに見せて、その場でフィードバックをもらえた。

最初は、TeamsのPlannerでストーリーカードをかんばん風に管理して、詳細化したタスクカードをRedmineのチケット管理で実現したと思っていたが、TeamsのPlannerにはたくさんの情報を書き込みできないなどの不便があったので、Plannerはステータス管理に注力し、Redmineチケットのリンクを書いておいて、課題や状況の管理はRedmineで行っていたらしい。
後で、Redmineのチケットパネルプラグインを入れたら、親チケットはチケットパネル機能でかんばんで管理し、詳細なタスク管理は子チケットで管理するといいのでは、と提案してみた。

そんな話を聞くと、RedmineやTeamsはコミュニケーション管理ツールなのだと感じた。
ガチガチの進捗管理をツールで実現するのはすぐに可能だが、実際はそう簡単には回らない。
一方で、チーム内のコミュニケーションを活性化するには、POやメンバー同士の信頼関係が前提条件だ。
そのために、デイリースクラムではSMはメンバーに進捗遅延を責めることはしないし、POは開発メンバーに見積もりが多すぎるのではとあえて口を挟む権限を付与したりする。
つまり、お互いに本音で言い合える関係をツールで実現することが重要だと感じた。

もちろん、ツールさえあれば開発案件が成功するわけではない。
自分の経験を振り返ってみると、結局は、ソフトウェア開発案件は開発者とリーダーの能力にすごく依存する。
開発者とリーダーの能力を最大限に発揮するには、プロジェクトの体制図という組織構造で権限と責任を明確にし、権限と責任を一致させて、各メンバーの意思決定を迅速させることが重要だし、メンバー全員が最終ゴールを認識していて、その実現のために目標達成意欲を高揚させる雰囲気作りが大事だ。
そして、コミュニケーションを円滑に進める基盤として、RedmineやTeamsのようなツールがあるわけだ。

組織構造を整える部分は、プロジェクトの体制図を決める時に決まるから、おそらくプロジェクトの立ち上げ時に既に決まっている。
組織文化を整備する部分も、RedmineやTeamsを事前に整備しておく必要があるから、プロジェクトの立ち上げ時に既に決まっている。
そんなことを考えていると、Scrum云々というよりも、プロジェクトマネジメントという基盤の考え方が使えるのかな、と思ったりもした。


| | コメント (0)

2020/11/01

Redmine の画面を2ペイン化する~Redmineを発散系のナレッジ基盤にするためには何が必要なのか

Redmine の画面を2ペイン化するツイートが流れていたのでメモ。

【参考1】
redmine-view-customize-scripts/2-pane_issue_list.md at master ・ sk-ys/redmine-view-customize-scripts

(引用開始)
説明
対象の画面を2ペイン化し,対象の画面とチケット詳細を1画面内に同時に表示します.
これにより,対象の画面を確認しながら,チケット詳細の確認と編集が可能になります.
また,チケット詳細画面で行った変更は都度対象の画面に反映されます.
現在,チケット一覧画面,ガントチャート画面に対応しています.
(引用終了)

【参考2】
YasakuさんはTwitterを使っています 「Redmine のチケット画面をリストとチケット詳細の2ペインにしたら判りやすいだろうか.公式のフォーラムにもあるが,特に発展している様子は無い様だ. https://t.co/VMcNAnHcLW https://t.co/7MRbUzjYZV」 / Twitter

YasakuさんはTwitterを使っています 「Redmine のチケット一覧画面2ペイン化を応用してガントチャートでも2ペイン化出来そう.ガントチャートはページ読み込み後に Javascript で色々描画されている事がわかった.勉強になった. https://t.co/xQniqJTnB0」 / Twitter

YasakuさんはTwitterを使っています 「改めて以下に公開.少し無理矢理感があり,更新処理時にテーブルをほぼ丸ごとJSで書き換えているため,他プラグインやテーマとの相性は要確認.パスのパターンの設定で,リストのみへの適用も可能です. https://t.co/Hd0i7CLDn2」 / Twitter

YasakuさんはTwitterを使っています 「通知バーに閉じるボタンを追加.2-Pane Mode と組み合わせると良い感じ. https://t.co/jsTn3WxjGW https://t.co/xapX7MMLFW」 / Twitter

YasakuさんはTwitterを使っています 「境界を強調させ,色々修正した.サイドバー関連の動作が安定した...と思う. https://t.co/6vxBJD4V0I https://t.co/tuJFSzVVoD」 / Twitter

YasakuさんはTwitterを使っています 「View customize plugin を使用した Redmine チケット一覧画面の2ペイン化.色々と考えていたらコードが長くなってしまった.何とかIEに対応した.ここまでするとプラグイン化した方が良いのだろうか. https://t.co/Hd0i7CLDn2 https://t.co/0TgXWcnIaP」 / Twitter

Redmineのチケット一覧画面やガントチャート画面の下部に、チケット画面も表示して2ペイン化する。
裏では、他プラグインとview-customize-scriptsを使っているらしい。

2ペイン化したい場面としては、大きなディスプレイ画面で、一覧とリンクした詳細情報の2つを表示したい時だろう。
最近のスマホやブラウザのUIを見ても、画面上部は詳細な記事があり、画面下部には被写体の画像や広告がスライドショーのように流れるようなパターンもある。
その方が、一つのモニタで大量の情報を即座に見ることもできる。

2ペイン化して一覧と詳細の情報を表示するツイートを見て、ふと、Scrapboxを思い出した。
Scrapboxでは、1ページに書いた記事は、一覧では並列に全てが表示される。
最初にScrapboxを見た時は、何かゴチャゴチャしているな、と思ったが、実は、タグやリンクによってページを絞り込み検索できるし、数多くの記事を時系列に眺めるだけで、色々なアイデアを連想するきっかけにもなる。
つまり、ツリー構造にこだわらず、ネットワーク構造で情報を配置することで、複数の既知の情報を組み合わせるだけで、色んなアイデアや発想が生まれる時も多い。

名著「アイデアのつくり方」には、「アイデアは新しい組み合わせである」という一節がある。
アイデアは何もない所から生まれるのではなく、既知のアイデアを組み合わせるだけで、今までにない常識に囚われない発想が生まれる。
他にも「新しいアイデアは古いアイデアを新しい場所に置いただけ」みたいな言葉もあったな。

2ペイン化を発展させて、チケットをタスクボードのように並べるだけでも、このチケットはあのチケットと関係していないか、などと気づきが得られるかもしれない。
そこから、メンバー同士でいろんな議論ができるかもしれない。

Redmineは単なるチケット集計ツールではなく、蓄積したデータを元に、アイデアを生み出すナレッジ基盤にもなりうるはずだ。
そういう発散系のナレッジ基盤になるにはRedmineには何が必要なのか、今一度考えてみたい。


| | コメント (0)

2020/10/28

チケット管理ツールの用途が変わってきている

チケット管理ツールのクラウドサービスAsanaの記事を読んで、チケット管理ツールの用途が変わってきていると感じたのでメモ。

【参考】
チームの仕事、プロジェクト、タスクをオンラインで管理 ・ Asana

Asanaが好きなもので。|なかやけんいち|note

Asana - Wikipedia

asanaの活用方法を徹底解剖!基本的な使い方から応用編までご紹介 |マケフリ

タスク管理ツールAsana(アサナ)とは?特徴や使い方を徹底解説

(引用開始)
人によって「使いやすい」の基点が違う
そして困ったことに「使いやすさ」「快適さ」は職種や人でそうとう異なるんですね。そもそもプロジェクト管理ツールに対する期待値や使う人の環境が違うという問題があります。

エンジニア系の人々は「プロジェクト」という生物を飼育するための運営連絡帳的な視野で利用しているようです。
飼育してる生き物(プロジェクト)が突然病気になったり死んでしまわないよう、チームみんなで協力して連絡帳つけましょう、やるべきことしっかりまとめましょう、とかなり几帳面に運用します。そして当然のように仕事の間ずっと目の前にPC画面があるので頻繁に丁寧にアクセスして記入してくれます。

非エンジニア系=管理・営業・マーケティング系の人々は「パーティ開催の準備リスト」的な視野で利用しているようです。
すべきことのリスト作りは直感的にスピーディにできるのが理想的。そして突発的なタスクの発生・変更にも対応し易く、メンバーが相互に確認できる手軽さが大事です。そして、打ち合わせなどの移動中などにスマホなどからさっと確認・処理できるのがうれしかったりします。
こうした違う種類の人たちが混在するプロジェクトのニーズを同時に満たすのは簡単ではありません。まさに今この瞬間にもうまくいかないと困ってるチームはあると思います。

あえて「エンジニア系」と「非エンジニア系」と書いてみましたが、細かいことを言い出すと、同じ職種でも人によって「快適」のツボは異なったりして、全員が満足するツールを見つけるのはなかなか大変です。
(引用終了)

自分はエンジニア系なので、ソフトウェア開発のプロジェクトを管理したい。
だから、プロジェクトが変な方向に行かないように、成果物とチケットの更新履歴を見ながら、頻繁にチケットを更新して、メンバー間のコミュニケーションを取るようにする。
朝顔に水をやり、変な虫を取り、こまめに手入れするみたいな感じ。
社内の定型業務や一般業務の管理も同じイメージだろう。
Scrumのバックログでチケットを登録して、それらを逐一細かく追跡したい。

一方、営業・マーケティング系の人たちは「パーティ開催の準備リスト的な視野で利用している」指摘が面白い。
確かに、エンジニア系の人でも、コミュニティでのイベント管理や日々の運用管理では、成果物とそれに紐づけた作業の2つを管理するよりも、今どれだけの課題やタスクがあって、抜け漏れはないよね、という点を確認したい。
もっと気軽にチケットを管理したい。
ToDo管理やGTDに近い感じで、サクサク閉じていきたい。

Redmineは良いツールと思うが、他のSaaSを見ていると、気軽に使えるな、と思う時がある。
そのあたりを色々考えてみる。


| | コメント (0)

2020/10/22

RedmineでGitのbareリポジトリにアクセスする方法

久しぶりにローカル環境のRedmineを構築してみた。
ローカル環境にあるGitリポジトリをRedmineに連携する設定をメモ。

【参考】
共有フォルダに Git 中央ベアリポジトリを置く - Qiita

既にGitリポジトリがローカル環境にある前提とする。

git-bashを開く。
bareリポジトリを作成する。

cd /c/home/ruby
mkdir bare

cd /c/home/ruby/bare
git init --bare --shared=true

初回のPush。
cd /c/home/project/repo
git remote add origin /c/home/ruby/bare
git push --set-upstream origin master

2回目のプッシュ
cd /c/home/project/repo
git push origin master

TortoiseHgやSourceTreeならば、2回目からコミットしてPushすればOK。

Redmineの設定画面でGitのBareリポジトリをセットすれば、リポジトリ画面に表示される。

Ver4.1のRedmineをローカル環境にセットアップして、Gitリポジトリも連携できたので、すごく快適。
課題管理も進捗管理も構成管理も、全てRedmineに集約すれば、作業が捗るのは嬉しい。

| | コメント (0)

2020/10/18

Scrapboxが使いやすい

別のコミュニティ活動でScrapboxを使っているのだが、割と使いやすい。
Scrapboxのリンクをメモしておく。

【参考】
Scrapboxの使い方!アウトプットの効率化におすすめ | Workship MAGAZINE(ワークシップマガジン)

Scrapboxを使い始める前に知ってもらいたい7つのこと|倉下忠憲|note

【お役立ち情報】Scrapboxのメリットから使い方まで一気に解説! | Pikawaka - ピカ1わかりやすいプログラミング用語サイト

議事録をマークダウンで書いているのだが、高速で自動保存されるので気にしなくていい。
普通の箇条書きでサクサク書けて、簡単な強調文字や色文字も使えるし、画像も貼れる。
基本は、ページ内でリンクを貼るだけ。
たくさんのページができても、Index用のページを1個作っておけば、いつでも辿れる。
ブラウザの印刷機能を使えば、そのままPDF出力できる。

また、ブラウザでどこでも表示できるので、PCで書いた後、外出中や通勤電車内でスマホで閲覧もできる。
隙間時間に、自分のアイデアやメモ、記録した内容を見れるのはありがたい。

Googleスプレッドシートを使っている時もあるが、やはりExcelライクなので、後で読みにくい。
やっぱり、Excelはよく使うけれど、あまり使いたくない。
テキストでサクサク書ける方がいい。
たぶん僕はWikiみたいな使い方が好きなんだろうと思う。

Scrapboxであえて弱点があるならば、表を書くことだろうが、「|」ではなく下記のような記法があるらしい。
今度試してみたい。

テーブルの書き方 - oystersjp

| | コメント (0)

2020/10/14

Redmine運用の基本を再確認する

Redmine運用の基本を再確認するために、@g_maedaさんの資料をもう一度読み込んだ。
ラフなメモ書き。

スポーツでも勉強でも仕事でも守破離がある。
慣れてくると、破離の段階に入っていくけれど、成長が頭打ちになる時がある。
そんな時に、もう一度原点に立ち戻り、守の部分からやり直すことには意味がある。
凡ミスが多くなる時は、基本を忘れて、基本を徹底していない時が多いものだ。

それはRedmineの運用でも同じように思う。
チケット管理の運用に慣れてきても、ちょっと運用から離れていたりして勘が鈍ると、割と忘れている。

上記の資料で、守の部分の箇所は下記だと思う。

(引用開始)
表計算ソフトで一覧表を作りたくなるような仕事をうまく使える。

難易度・低
課題管理、QA管理、インシデント管理
随時発生する課題を都度登録してどんどん処理していく形態の業務は適用が簡単。

難易度・高
プロジェクト管理
将来のタスクの洗い出しや、すぐには処理できない大量の課題の扱いには習熟が必要。

チケットは管理表の明細1行分に相当。
付箋と捉えてもよい

トラッカーは単なる分類ではない。項目やステータスを制御するもの。

トラッカーの設計=入力フォームの設計

1チケット=1課題

題名だけでも内容が伝わるように

説明欄では終了条件を明確に

担当者は、そのチケットに書かれた課題・仕事を任された人ではない
担当者は、現時点でそのチケットを対処すべき人

チケットの担当者は次々に変える方が良い

Redmineで仕事を進める考え方
仕事は原則チケット化
みんなでチケットを終了させて仕事を終わらせる
(引用終了)

つい最近、自分がミスしたな、と思った部分は、担当者を責任者に固定化してしまったこと。
本来は、担当者はボールを持っている人であり、キャッチボールでやり取りすべき。
責任者をチケットに持たせたいならば、カスタムフィールドで別で保持すればいい。

PJ計画でWBSを策定することばかりやっていると、そういうアンチパターンにはまってしまいやすい。

また、Redmineを運用する時に、チーム全員が積極的に利用する雰囲気を醸し出すことも大事だ。
プロジェクトリーダーは自分自身の管理を楽にするために使いたがるが、利用者の観点でもメリットが感じられるように、配慮すべき点はたくさんある。
もちろん、各メンバーがコミットする責任を持つ意識は必要だが、チーム全体でアウトプットを出すからには、メンバー全員で残チケットに積極的に対応して終わらせる、という意識も必要だ。

そういうメンバーの貢献意欲を引き出すための工夫もRedmine運用では必要だ。
いわゆるチームビルディングやファシリテーションのようなスキルも必要になってくるだろう。

| | コメント (1)

Redmineの二要素認証の利用イメージ資料のリンク

Redmineの二要素認証の利用イメージ資料をリンクしておく。
@g_maedaさんの説明なのでとても分かりやすい。

Redmineに2要素認証のパッチが提供されている: プログラマの思索

Redmine4.2に2要素認証機能が導入された: プログラマの思索

Redmineでワンタイムパスワードが使えるようになるので、スマホのAuthenticaterアプリを使う場合が多いだろう。
その時の手順が画面キャプチャ入りで説明されているので非常に役立つ。

注意点は、Redmineで二要素認証機能をONにしたときに、必ずバックアップコードを生成しておくことだろう。
あるいは初期登録直後の画面キャプチャを採取しておく。
そうしないと、もしもの場合にログインできなくなるなどが考えられる。

Redmineの二要素認証機能が使えることで、インターネット上で公開して運用する場合に、よりセキュアに利用できるメリットがある。
昨今のセキュリティ不備のニュースを見ているから、オープンソースのRedmineにも二要素認証機能が含まれたことはすごいと思うし、今後の発展に役立つだろうと思う。
今後のRedmineの機能改善に着目していく。

| | コメント (0)

2020/09/18

RedmineJapan2020が無事に終わりました #RedmineJapan

本日、RedmineJapan2020が無事に終わりました。
講演者と参加者の皆さん、スタッフの皆さん、ありがとうございました。
今日は本当に疲れたので、まずはメモしておく。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

今日は朝9時から19時半まで、自宅の机とPCに張り付いて、気づいたら外は真っ暗。
基調講演から最後まで、どの講演も素晴らしくて、興味を引いて、気が抜けなかった。

Matzさんの話は、Rubyのリモート開発と、開発をリードする立場の事情話。
自分の意見と自分が書いたソースコードは違う。
エゴレス。

みうら(あに)さんはTwitterを使っています 「(自分思い出し用)1) OSS→コミュニティベース開発→PdM:「よい」とは?⇒同じ方向見れるか?⇒求心力/哲学 2) ツールの支援:円滑な意思決定⇒分散SCMのよさ⇒Issueベース⇒フロー/ストック⇒Wikiの使い方 3) コンフリクト解決:コードより知見大事、エゴレス、ゆるやかにつながる #RedmineJapan」 / Twitter

東芝やNTTコムウェアの開発プロセス標準とRedmineをベースとした開発基盤の紹介。
大企業の内部事情が分かった感じ。

@akiko_pusuさんのLTは、朗読のようなナレーションで聞き入ってしまって、聴衆の皆さんも思わず泣きたくなったのではないか。

平鍋さんの話は、リモート時代でのアジャイル開発のコミュニケーションの取り方。

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんが最初に作ったastahも、平鍋さんが書いたソースコードはもうない。インターフェイスだけ残っている。そういう意味では、設計思想が優れていた、ということなんでしょうね。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんは工学部出身だから、場と言えば、電磁気学や量子力学を連想されたのかな?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 古典力学はコマンドコントロール。場の理論は、チームの空間から力が生まれる。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ティール組織は場がない。スクラムは場がある」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan リモートワークの場作り。リモートワークの基本の最初は、速いインターネット回線」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan デジタルでは表現者が優位。過剰な表現で十分」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ネットワークの7層モデルと、コミュニケーションモデルの比較。物理層は、信頼関係に対応するのでは、という仮説」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan タックマンモデルも、最初の混乱期までは合宿して、それからリモートに移行する。でも、コロナ時代はどうする?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan これからのチームビルディングは、合宿無しの継続的なチームビルディングへ。」 / Twitter

(1) kabukawaさんはTwitterを使っています 「#RedmineJapanA いまここ性 here-now-ness」 / Twitter

リモートワークの時代では、チームビルディングの手法はオフラインとは変わってくる。
五感のうち、見る・聞くしかチャネルがない。
だから、自己表現を派手にするぐらいでないと伝わらない。

すると、チームビルディングでは、タックマンモデルの形成期・混乱期がリモートワークでは難しくなる。
いかにそういう場をオンライン上で実現するか?

パターン言語を用いて、アジャイル開発の秘密基地のパターンを作っていた。
同様に、リモートワークのアジャイル開発のパターンが作れないか?
そのパターン言語を作ることで、リモート時代の特徴や本質が見えてこないか?

同時並行で見れなかったB会場では、RedmineのDBアーキテクチャの説明、RedmineのDockerのお話、ファーエンドさんのAWSでRedmineサービスを作った裏話、なども聞きたかった。
動画を準備しているので、ゆっくり見てみたい。

Redmineというテーマで、オンライン参加者が300人もいるイベントを実現できて本当に良かった。
Redmineは、開発プロセスの構築とそれを支えるPJ管理ツールの話と、実際にPJ管理ツールの開発基盤を構築するためのインフラ環境やRedmine本体の改善の話を同時に議論できて面白い。
そういう話をコミュニティで10年も継続できたことがすごいな、と思う。

| | コメント (0)

より以前の記事一覧