« 2018年5月 | トップページ | 2018年7月 »

2018年6月

2018/06/27

Redmineにも「いいね」機能が欲しい

先日の東京Redmine勉強会のLTで「気遣いが大事」という内容に関する記事があったのでメモ。

【参考】
はじめてのredmine.tokyo勉強会参加と『エモい』Redmine - ファーエンドテクノロジー株式会社

(引用開始)
『エモい』Redmine #とは
後日、マーケティンググループのメンバーと会って話した際に、私がライトニングトークのスライドで記載していた「気遣いが大事」という点が話題になりました。

遠藤「事前にライトニングトークのスライドを見て、気遣いが足りなかったと反省したんです」

財部「逆ですよ!遠藤さんの気遣いがあるコメントを頂いて、私のほうが学んだんです」

石原「前はチケットのコメントに『ありがとうございます』とか書かなかったけど遠藤さんが書くようになって書かなきゃ!と思うようになりました」

財部「これだけでも勉強会のネタになりそうですよ、『エモい』Redmine」

例えばチケットのコメントに「◯◯してくれてありがとうございます。」と書くか否か。メールじゃないんだから、と簡潔に済ませるのか。
(引用終了)

チケットに作業ログを残すだけでなく、対応してくれた人に感謝の気持ちを伝えたくなる時もある。

Facebookなら「いいね」ボタンでその機能を実現している。
Twitterならリツイートボタンでその機能を実現している。
この機能は、マズローの欲求5段解説の承認欲求、ハーズバーグの動機づけ・衛生理論を連想させる。

すると、Redmineにも同様に、「いいね」機能が欲しくなる。
コメントに「ありがとうございます」と文字で書くのが面倒でも、ワンクリックで、感謝の気持ちを表現できるなら、そちらの機能を使いたい。

Redmineにもそういうプラグインはあるみたい。
以前、GoodJobプラグインもあったな。

Redmineに「応援する」リンクをつける: プログラマの思索

Redmineに入れたプラグイン一覧part3: プログラマの思索

akipiiさんのツイート: いいねボタンが欲しい時がある RT @hito_asa: 社内Redmine、Backlogと違って味気ないというか、スターつける仕組みもないしなんだかコミットしてて寂しくなってくるのです。スター重要。

システム構築の立場から見れば、たかが「いいね」ボタンという一つの機能に過ぎないのに、たった一つの機能「いいね」ボタンが感謝の気持ちを気軽に表現してくれることで、メンバーの貢献意欲を引き出し、チーム内のコミュニケーションを促進し、チームの一体感や使命感を醸し出す。

これまた人間の心理の不思議の一つかな。

| | コメント (1)

2018/06/21

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている

@g_maedaさんが、Redmineの「トラッカー」を「チケット種別」へ変更するチケットを提案されている。
些細な内容だが、Redmineの初心者向けユーザにさらに使いやすくする重要な提案と思うので、メモしておく。

【参考】
Patch #29045: Change Japanese translation for Tracker - Redmine

【1】Redmineのチケットで最も重要な概念は「トラッカー」だ。
なぜなら、トラッカーはワークフローと表裏一体であるので、業務フローと対応付けられるからだ。
よって、トラッカーによってRedmineチケットの状態遷移が制御される。

また、トラッカーはカスタムフィールドなど、チケットのテンプレートそのものでもあるからだ。
よって、トラッカーごとに、チケットのテンプレートを設定する思想にもなる。

たとえば、トラッカーは、ソフトウェア開発のプロセス、申請承認ワークフローの業務などに対応付けられる。
それらは、特有のワークフローがあり、特有のデータ項目(カスタムフィールド)が保持されている。

【2】しかし、従来から、「Redmineのトラッカーとは何ですか?」という問合せが非常に多い問題があった。
日本人には「トラッカー」を和訳せずにそのままの名前にしたので、イメージしにくいのが根本原因にあるのだろう。

よって、「チケット種別」にする提案が@g_maedaさんから起票された。
おそらくRedmineを知らない日本人にとって、「チケット種別」という概念の方が理解しやすいだろう、と個人的に思う。
このパッチが反映されれば、日本におけるRedmineの普及促進に重要な良い影響を及ぼすだろう。
よって、パッチは些細なものだが、非常に重要な内容だ。

【3】なお、コメントでは、「ワークフロー種別」の方が良いのでは、等の意見もある。

@g_maedaさんの言う通り、トラッカーはワークフローかつチケットテンプレートの2種類の設計思想を持つので、「チケット種別」の方がその2つの概念を包含しやすいだろう、と思う。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳にて引用開始)
松本Gohさんはこう書いた:

私の意見では、トラッカーはワークフローの名前またはタイプを表しています。
だから、私は "ワークフロー"または "ワークフロータイプ別"を提案します。

ご意見ありがとうございます。でも、私はまだ「ワークフロー種別」よりも「チケット種別」が好きです。その理由は次のとおりです。

トラッカーは、ワークフローだけでなく一連のフィールドも定義します。「ワークフロー種別」(ワークフロータイプ)という言葉は、そのうちの一つしか表現しておらず、ワークフローを強調しすぎています。私は "チケット種別"(問題の種類)は両方の意味を含んでいると思います。
「ワークフロー種別」(ワークフロータイプ)はかなり長いです。問題リストを表示すると、トラッカーフィールドが広くなります。
しかし、ユーザーのために「チケット種別」(問題の種類)と「カテゴリ」(カテゴリ)を区別するのは少し難しいとのご意見に同意できます。
(引用終了)

【4】また、 Masakazu IZUIさんのメモの絵が素晴らしい。
メモでは、チケット種別(トラッカー)のチケット群を「カテゴリ」に仕分けするイメージが描かれている。

Patch #29045: Change Japanese translation for Tracker - Redmine 「「仕分け」はどう?」

このメモが素晴らしいと思う理由は、トラッカーとカテゴリの設計思想が明確に区別されているからだ。
トラッカーは全てのPJで使われる汎用テンプレートかつワークフロー設定なので、各トラッカーの各種チケットは、各PJで、PJ特有のカテゴリで「仕分け」される。

RedmineのカテゴリはPJで自由に設定できる点がミソだ。
つまり、汎用設定であるトラッカーによる分類だけでなく、PJ特有の分類方法はカテゴリを使って分類すればいい。
そうすれば、チケット集計時に、色んな観点で集計しやすくなる。

つまり、「チケット群を仕分ける」作業は、プロジェクトマネージャが従来行っていた進捗報告作りの作業である。
その手作業は、Redmineのチケット集計機能で全てシステム化、自動化できることを示唆しているのだ。

【5】なお、カテゴリ機能については、親子PJでカテゴリを継承して使えるような機能改善が下記チケットで提案されている。
最近、Yuuki NARAさんがGitHubで試されている。

Patch #11898: Inheritable issue categories - Redmine

Feature #5358: Share Issues Categories for sub-projects - Redmine

実は、Redmineのカテゴリは重要な機能でありながら、その使い道の有用性を説明することが難しかった。
カテゴリを親子PJで継承できるようになれば、親PJのカテゴリを流用できるので使いやすくなる。

個人的には、カテゴリ機能はもっと改善して欲しい、と思っている。
そうすれば、チケット種別(トラッカー)でチケットを分類する方法ではなく、カテゴリで固有のPJで分類する運用がもっと馴染むようになるだろう、と思っている。

僕はRedmineをもう10年以上使っているけれど、まだまだ機能改善したい気持ちがあるし、色んな可能性を考えるのがすごく楽しい、と感じてる。

【追記】
Toru Takahashiさんから、「トラッカー」を「チケット種別」に変更する提案に反対意見が表明されている。
その反対意見の理由を読むと、確かにもっともだ。
なぜなら、「トラッカー」には「問題や課題、障害等を追跡する」意味が含まれているので、その意味が失われるリスクもあるからだ。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳による引用開始)
私はこの翻訳提案に同意しません。

「トラッカー」には、問題のステータス変更を追跡する意味が含まれます。
「種別」には含まれていません。
さらに、「タイプ」という単語は「カテゴリ」という単語に非常によく似ています。

「トラッカー」に適した日本語を見つけるのは難しいかもしれません。
翻訳に適した単語が見つかるまで、
現在の翻訳された単語「トラッカー」は、トラッカーの代名詞を表しています。
(引用終了)

高橋 徹さんのツイート: "Redmineトラッカーをチケット種別と表記する変更案がありますが、trackerの語に含まれる追跡管理の意味が失われるのはどうかなぁ?トラッカーが解りにくいのは同意、しかし元の意味が失われる訳語には賛同しかねるなぁと。 https://t.co/bsa9AJVobj"

Kuniharu AKAHANEさんのツイート: "同じ思いです。Issue Tracking Systemの根幹要素を欠くと思っています。その一方で、Redmineの利用領域は本当に幅広いのでOSSを使う皆さんがわかりやすいというならそのまま受け入れて、自分の環境では ja.ymlの15ヵ所をを書き換えようと思っています。… https://t.co/8qxMMCao8a"

やっさん🍶さんのツイート: "#redmine 私も同様に慎重派です。 そもそもなぜTrackerとしたのか?に関してJPLには考えがあるはずなので、そこを確認してからじゃないと「トラッカー」→「チケット種別」とするのはどうかなぁと考えています。 私は@akabekobekoさんの案が良いかなぁと(話大きくなるけど)。 https://t.co/oQpoUxpCji… https://t.co/s1XppYjKZr"

| | コメント (0)

2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

【追記】
大雨のため、9/8土曜に順延となりました。

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

| | コメント (0)

« 2018年5月 | トップページ | 2018年7月 »