2018/07/05

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアというものがあるという前提で、従来から研究されている信頼度成長曲線の理論を適用した論文が非常に面白い。
もし、この論文の指摘内容が実際のソフトウェア開発の現場に適用できるならば、そんなソフトウェアはアジャイル開発こそ向いている、と言えるし、アジャイル開発の有効性の範囲が特に最近は広がっている、という事実を補強できるのではないか、と思う。
ちなみに、この論文は@sakaba37さんから教えてもらった。

以下は、浅はかな理解の元でのラフなメモ書き。

【参考】
ソフトウェア・シンポジウム 2018 表彰論文

ソフトウェア・シンポジウム 2018 最優秀論文賞 [研究論文]バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察

【1】研究論文の内容は、正直難しいです。
僕も細かな内容は分かってない。
しかし、言わんとする内容は、とても刺激的。

【2】従来のWF型ソフトウェア開発では、「バグ発見時間が遅いほど、バグ修正時間も長くなる」という前提で、いかにバグを早く発見して修正するか、さらに、バグを作り込まないように予防対策を行うか、という考え方が主流だった。

この発想は、製造業の源流管理ともマッチするので、日本のWF型開発では、上流工程や超上流工程でいかにバグを作り込まないように、漏れなく高品質なものを作って後工程に流すことばかり、考えるように仕向けられていた。

つまり、「バグ発見時間が遅いほど、バグ修正時間も長くなる」は正の相関関係を意味している。

【2-1】しかし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが存在するとしたら、どうなるのか?

もし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが世の中の大半を占めていたとしたら、今までの品質予防の対策ノウハウは無意味になるのではないか?
むしろ、バグなんか気にせずにいち早く作ってリリースして、ユーザの反応を見ながら修正していく方が効率的ではないのか?

つまり、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアとは、アジャイル開発が適用できるソフトウェアと同一視できるならば、ソフトウェア開発はアジャイル開発に特化してしまえばいいのではないか?

すなわち、「バグ発見時間が遅いほど、バグ修正時間が短くなる」は負の相関関係を意味している。

【3】この論文では、信頼度成長曲線という古典的理論を使って、「修正時間を考慮した最適リリース問題」として置き直して、モデル上で理論的な計算を行っている。
確率分布を使った計算なので、細かい内容はきちんと追わないと理解したとは言えないので、僕はすぐには分かってないが、下記の結果は理解できた。

【3-1】「バグ発見時間とバグ修正時間の相関関係」について、いくつかの前提をおいた上で、モデル上で計算を行った結果は、4ページの「表 1. 最適リリース時刻と最小総期待費用」で説明されている。

ここで、α:相関関数なので、
α=+1:完全な正の相関
α=-1:完全な負の相関
になる。

また、総期待費用 C(T) 、最小総期待費用 C(T*)である。

その結果、αが+1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が増えていくので、「バグを放置していたら、修正コストは増えていくよ」というメッセージなのだと常識的に理解できる。

一方、αが0から-1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が小さくなっている。
つまり、このモデルでは、「バグを故意に放置した方が、修正コストは最小になるよ」というメッセージを伝えている。
これは、従来のWF型開発における品質の源流管理という常識とは異なる結果だ。

【3-3】この結果は、反常識的で面白いが、「バグ発見時間とバグ修正時間の相関関係」の観点で読み直せば、ストーリーはよく分かる。
つまり、従来の源流管理重視の品質管理では、「バグ発見時間とバグ修正時間は正の相関関係」の前提で語っていたけれど、それはWF型開発しか頭にない人がそういう前提で語っているだけ、とみなせる。
「負の相関関係」の前提となるソフトウェアもあるのではないか?

常識で考えると「バグ発見時間とバグ修正時間は負の相関関係にある」ソフトウェアはすごく変だ。
なぜなら、バグを放置した方がバグを速く直せる、と言っているのだから。

しかし、MTBFを高めることに注力するよりも、MTTRを短くする方に注力するソフトウェア開発プロセスがあるように、「負の相関関係」の前提となるソフトウェアもあるはずだ。
たぶん、そのようなソフトウェアはアジャイル開発に向いているソフトウェアなのだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

実際、昨今のWebサービス開発では、いち早くリリースして、頻繁にリリースしながら品質向上していく開発プロセスが主流だ。
何年もかけて品質を作り込んで、ドカンと一発リリースするソフトウェアとは全く違う。

もちろん、そういうコストを掛けて品質を高く保つソフトウェアもあるし、従来はそういうソフトウェアばかりだったように思う。
今でも、航空宇宙や組込みソフトウェア、業務システムはそういう部類に属するだろう。

しかし、従来は周辺的な位置付けに過ぎなかったWebサービスのマーケットが広がり、皆が24時間スマホを触っているのが普通な現代では、アジャイル開発に向いているソフトウェアが多くなった。

とすれば、アジャイル開発に向いているソフトウェアでは、「バグ発見時間とバグ修正時間は負の相関関係にある」という事実と表裏一体なのではないか。

【4】但し、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張は、僕個人の意見に過ぎない。
上記の研究論文でも、そこまで触れられてはいない。
しかし、上記の研究論文では、理論上そういうソフトウェアが存在する前提で、モデルから何が言えるのか、を示唆している。

自分のラフなイメージとしては、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張が、上記の研究論文の発展形で保証できれば、アジャイル開発の有用性を証明できた、ということになる、と思う。

そのためには、実際のアジャイル開発の現場で、そのようなソフトウェアメトリクスを採取して、上記の研究論文の理論的検証が正しかった、という体験論文ないし実験論文が続編になればいいだろうな、と思う。

【5】信頼度成長曲線の理論は1970年代からずっと研究し尽くされていて、かなり枯れた理論と聞いているが、この研究論文では、アジャイル開発の要素を取り入れたモデルで考え直すと、古典的な理論から新たな知見が生まれる、という可能性を示唆している、と思う。
そういう意味では、久しぶりに自分の中ですごくホットになって、面白かった。

個人的には、「アジャイル開発はソフトウェ開発ですごく有効である」と証明できるソフトウェア工学の学術論文をもっと読んでみたいし、そういう論文集があると面白いだろうな、とも思う。


| | コメント (0)

2018/07/04

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグイン

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグインを見つけたのでメモ。

【参考】
【担当者さん必見】メンバーみんなで日程調整ができる「Scheduling Poll」プラグイン登場!

cat-in-136/redmine_scheduling_poll: a plugin to provide the simple way to schedule appointments on Redmine

QA #824: チケットやニュース、フォーラム、Wikiなどで選択式のアンケートを実施したい - Unofficial Redmine Cooking - redmine.tokyo

画面を見てみると、調整さんのように複数のチェックリストに○△Xを記入した後、入力結果を自動集計してくれるみたい。

選択できるチェックリストには、日付以外にテキストが入力できるので、他のアンケート項目にも流用できるだろう。

時々、アンケート機能がRedmineにも欲しい、という声があがる時があるので、このプラグインを使えばいいかもしれない。

下記のLineの機能にインスパイアされて、Redmineプラグインを作成された、とのこと。

【幹事さん必見】友だちみんなで日程調整ができる「LINE スケジュール」機能登場! : LINE公式ブログ

こういう投票機能は、Redmineを単なるタスク管理、課題管理、障害管理だけでなく、チーム内のコミュニケーションを活性化させるためのツールへ進化させる為の機能と言い換えられる。

Rails開発の技術力があれば、自分のアイデアやプロジェクトリーダーの提案を元に、Redmineをカスタマイズすることにより、チームの一体感を生み出す機能をいくらでも作り出せる。

そういうアイデアを実現する機能とチーム内のコミュニケーションとの相関関係や影響度合いを実際に分析してみたいものだ。

| | コメント (0)

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と違って味気ないというか、スターつける仕組みもないしなんだかコミットしてて寂しくなってくるのです。スター重要。

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

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

| | コメント (0)

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回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

| | コメント (0)

2018/05/27

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

第14回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
感想をラフなメモ書き。

【参考】
2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter

第14回勉強会 - redmine.tokyo

redmine.tokyo 14 で登壇してみた – アカベコマイリ

【1】グループディスカッションで話を聞くと、最近Redmineを運用し始めた、という人から、10年近く触っている人まで幅広いユーザ層でした。

また、1年前から参加者の女子率が上がっているように感じてます。
女性陣もデザイナー、品質保証部、PMO、インフラ管理者など幅広い分野で活躍しており、Redmineに関する問題意識も当然高い。
以前は、40代のおっさんばかりがRedmineコミュニティにたむろしていたのを振り返れば、感慨深い。

ゆえに、参加者層が幅広くなったおかげで、ユーザコミュニティの雰囲気は、毎回開催するにつれて良くなっていると思う。

【2】個人的には、Twitterでやり取りしている人と対面できたのも嬉しい。
講演してくれた@akabekobeko さん、@nekosanz1 さん、グループディスカッションでお話できた@endo_5501 さん、@kabukawaさんを認識することができた。
もちろん、@kaorabeさん、@MadoWindaheadさん、@acha_821さん、@aj15_aj15さん達ともお話できたのも楽しかった。
また、Redmineコミュニティが縁で結婚されたカップルも居る。

コミュニティを通じて、輪が広がるのも楽しい。

【3】山崎さんの講演では、Redmineとツール連携する例として、MSProjectからRedmineへインポートするプラグイン、RedmineとSlackを同期するプラグインが紹介されていた。
(たぶん、山崎さんの会社でプラグインを作成されているだろう)

プロジェクトマネージャの要望としては、立上げ時にMSProjectで作ったプロジェクト計画をRedmineへインポートしたい要望が多い。
ざっくりしたスケジュールを引いてクリティカルパスを表示させるのは、やはりMSProjectの方が楽だから。

しかし、予定はMSProjectで作ったとしても、その後の実績管理はRedmineの方がはるかに運用しやすい。
日々の進捗はどんどん変わるし、複数人が編集して最新化する手間を考えると、MSProjectに拘る必要はないと思う。

このプラグインで面白いのは、親子チケットの構造をRedmineでも再現できる点。
現状のRedmineのREST APIでは、ツリー上のWBSを作る時、どうしても2回発行しなければならない。
なぜなら、親チケットが決まった後で、子チケットをぶら下げる更新処理が必要だから。
ゆえに、1回の更新で、しかもチケット番号を昇順に採番して更新するような仕組みがあると便利だろう。

【3-1】また、Slack連携では、Redmineの活動ログをSlackに流すだけでなく、SlackからRedmineへチケット登録する運用が紹介されていた。
仕組みとしては、Slack上で、「タイトル:~、内容:~」のようにコメントすれば、RedmineのREST API経由で登録される仕掛け。

Slackからチケット登録できるメリットは、Slack上で障害を見つけたやり取りをしている時に、Slackから即座にチケット登録したい時もあるだろう。
すなわち、Slackの運用が既に定着していて、Redmineに情報を集約して記録して残したい場合に、有効に使えるだろう。

【3-2】似たような例として、@netazoneさんがGoogle Homeで、ボイス入力した内容をRedmineにチケット登録する利用事例のLTがあった。
仕組みとしては、Google HomeからIFTTT(IF This Then That)・GMail経由で、Redmineへチケット登録メールを送って、メールによるチケット登録機能を使っていた。
Google HomeからRedmineのチケット登録ができるメリットは、PC操作無しで会話するだけでチケット登録できること。
たとえば、カスタマーサポートや事務担当者などの非エンジニアが使う利用シーンが考えられる。

このように、Redmineの優れた外部I/Fを上手く使えば、チケット管理のコストを下げることが出来るだろう。
また、現場の利用シーンを考えながら、Redmineと連携する設計を考えるのも楽しい。

【4】@akabekobekoさんの「なじむ Redmine」も面白かった。

個人的には「Redmineを浸透させるために、故意に「活況を演出する」」という考え方が面白かった。
つまり、流行っているレストランは、流行っているから更に新規顧客も増える、という現象と同じ。
特に日本人は、皆がやっている雰囲気に弱いので、故意にRedmineの活況を演出し、Redmineに触らざるをえない雰囲気に持っていく。

事例としては、Wikiで議事録や設計メモをまとめることから入り、その後チケットの運用に入っていく。
どうやら、初心者にとって、チケットを登録するのはハードルが高いらしい。
チケットのUIはボタンが多いし、ちょっとの更新でも履歴が残ってしまうので、変な更新ができない、完璧に書かないといけない、という心理が働くらしい。
几帳面で完璧主義の古き良き日本人にありがちな行動だろう。
だから、そんな時は、周囲がサポートする。
たぶん、Redmine警察とか、Redmine職人、とか、Redmineエバンジェリストの出番なのだろう。

【5】実は、今回の勉強会では、RedmineのGit連携が最大のテーマだったと思う。
パネルディスカッションで取り上げられた。
@akabekobekoさんの講演でも、最後の課題にあげられていた。

(引用開始)
最近、日本のRedmine 界隈で話題?になった記事
Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索
↑で挙げられている内容はRedmine 運用していて強く 実感させられる課題です。
私的には環境面の運用が厳しい。インストール、更新、プラグインやテーマの配布と互換性など。
(引用終了)

【5-1】パネルディスカッションで、パネラーや参加者の声を聞く限り、RedmineユーザはSVNとRedmineの連携はよく使っているが、Git連携を使っている人は少ない印象を持った。
つまり、SVNの知見は皆良く知っているが、Gitの知見を持つ人は少ない。

話を聞いた印象としては、プロジェクトマネージャやPMOとしてRedmineでチケット管理している人たちは、そもそもGitを運用する利用シーンがそもそも無い。
彼らのモチベーションはチケット管理による作業の進捗管理やリソース管理がメインだから。

【5-2】一方、RedmineとGitを連携して運用する場合、2つのパターンの事例があった。

1つ目は、RedmineとGitlab、Gitoliteと連携して、Redmineではチケット管理、Gitlab側ではブランチ管理で分けている。

Redmineサーバー側にGitのBareリポジトリをクローンし、Redmineのリポジトリ画面と連動させる運用をしている。
もちろん、Redmineのチケット番号をGitのコミットログに埋め込むので、トレーサビリティは維持できている。

しかし、Gitlabのプルリクは使えていない。
あくまでも、Gitのブランチ管理とマージ作業だけに限定されている。
よって、昨今のGitHubで最も優れている運用方法「プルリク時点のコードレビュー」が仕組みとして提供されていないデメリットがある。

2つ目は、Redmineのチケット管理とGitHubのソース管理は明示的に連携せず、Redmineではプロダクトバックログや障害チケットの管理を行い、GitHubではマージやプルリクを使う、と運用を分けている。

すると、GitHubでは活発なプルリクが行われるので、プルリクのタイミングで必ずコードレビューが行われて、masterの品質は維持される仕組みになる。
このプルリクとコードレビューが密接に関係することで、エンジニア同士のコミュニケーションが促進され、お互いの理解も進み、ソースの品質も維持される仕組みが作られた点にあると思う。

しかし、Redmineのチケット管理と連動していないので、チケット管理ツールの最大のメリットの一つであるトレーサビリティ機能が使えていない。
結局、Redmineのチケット単位にトピックブランチを手動で作り、トピックブランチをプルリクする時点で、Redmineチケットを更新するという手動の運用ルールでカバーしている。

すなわち、現状のRedmineのGit連携には、昨今のGitHubのプルリクという優れた機能を埋込できていない。
よって、Gitの恩恵を最大限活用できているとは言えない。

MAEDA Goさんのツイート: "https://t.co/9GswyYgo4P にコミットするときいつもすごく緊張する。コミットログをスペルチェッカーにかけ直したり、diff見直したり。 #redmineT"

【5-3】RedmineのGit連携の機能が不十分である、という課題は、おそらく有識者は皆知っていて、何とか解決を図ろうと色々試されている、と思う。

@agilekawabataさんは、RedmineのBareリポジトリを作成するプラグインを作ったら欲しい人はいるか、という質問を投げかけていた。
初心者にとって、GitのBareリポジトリを作成する作業はハードルが高いので、プラグインがあれば、その部分のハードルは下がるだろう。

onozatyさんのツイート: "Bareリポジトリを画面側からクローンできると確かに楽だなぁ。 (回数がそこまで多くないので耐えられているけど、、)… "

onozatyさんのツイート: "そですね、きつすぎますね。 GitLab+Redmineで使っているのですが、新規プロジェクト立ち上げる時の手間がそれなりにかかるので、そのあたりもう少し便利になるといいですね。 画面からBareリポジトリ作れるようになると、画面操作だけで完結するので敷居も下がるかなと。… https://t.co/tJVZYxcff5"

また、maeda-m さんのredmine_git_work_in_progress プラグインでは、作業ブランチとマージ先のブランチのDiffやブランチの状況を可視化する機能を紹介されていた。

matsukei/redmine_git_work_in_progress: This is a plugin that provides Reduine's Issue like "Work In Progress Pull Request" and makes it easy to share knowledge.

あるいは、RedmineとGitlabを連携したり、RedmineとGitHubを連携する方法で運用をカバーするやり方もある。

akipiiさんのツイート: "#redmineT Gitlab からベアリポジトリを作ってRedmineと連携してるのね。では同期はどうしてる?"

taikiixさんのツイート: "(会場で結論が出ているかもしれませんが)私はこのプラグイン使っています。 https://t.co/C0DQ7APwxL… "

koppen/redmine_github_hook: Allow your Redmine installation to be notified when changes have been pushed to a Github repository.

たむさんのツイート: "うちは、gitlabとredmineは独立したインスタンスなので、nfsマウントしていますよ… "

MAEDA Goさんのツイート: "mod_perlがRHEL 7から標準ではなくなったので、https://t.co/YqxU0tFwwx のインストールめんどくさそう。 #redmineT"

【5-4】RedmineとGitlabの連携で最大の問題となるのは、GitのプルリクとRedmineチケットが密接に連携できない点がある、と思う。

例えば、プルリクを作る前に、その作業のチケットがない場合、Redmineにチケットを書いて、Gitにチケット番号を書いてコミットしてプルリクを送る、という面倒な作業が発生しないか。

あるいは、トピックブランチの作業とチケットが連動できていても、プルリクを送りたい場合、プルリクに相当するリビジョンをチケットに明示的に書いて、チケットを「プルリク」ステータスに変更して、作業するのは面倒ではないか?

akipiiさんのツイート: "#redmineT @tkusukawa さんの質問はとても重要。そもそもソース修正の発端、変更管理はどこでやるの?GitHub のプルリクでやるとしても、発端のチケットが登録されてから、ソース修正が発生する。プルリクは発生チケットの後になる。ではどうやって紐づけるの?"

門屋浩文@redmineエバンジェリストの会さんのツイート: "修正変更の出発点と完了条件を決めるツールによるということか? #redmineT… "

おそらく一般の運用ルールでは、GitのトピックブランチとRedimneチケットは1対1に対応させるはず。
たとえば、Redmineチケットを発行後、チケット番号をGitブランチ名に明示的にSuffixとして入れて、対応付けて運用するだろう。
たとえば、#12ブランチみたいな感じ。
すると、masterにマージしたい時に、プルリクしたい、というステータスをRedmineチケット上に設けざるをえない。
つまり、Redmineチケット上のステータス変更でプルリクを検知し、コードレビューが行われ、OKならば、マージされてチケットもCloseされる運用になるだろう。

本来はこの運用がRedmineの機能として、手軽に操作できるように実現できたらいい。
現状は、Git上でマージ作業を行い、Redmineのチケットを別途更新する、といった作業が2つのシステムで発生するので、正直面倒に感じやすい。
実際、GitHubでは一つの画面で操作できているから、尚更そう感じてしまう。

一方、Redmine本家のPatchチケットのように、パッチファイルとRedmineチケットが1対1の場合もある。
つまり、Redmineチケットが発行されないまま、トピックブランチが作られ、マージして欲しいなと思う時点でパッチファイルを出力して、Redmineチケットにパッチファイルを添付する運用スタイル。

この運用では、trunkが成長するにつれて、パッチファイルが古くなってしまい、マージされるタイミングを逸失されがちになる。
昨今のように、ビジネスレベルでもアジャイルが求められる時代では、このパッチ主導の運用は正直、時代に合っていないと思う。

よって、今後のRedmineのGit連携の機能改善としては、下記3点が必須になるのではないか。

(1)GitのBareリポジトリ作成を画面上の操作で行える。
さらに、GitのBareリポジトリはリアルタイムに同期される。
(2)GitのトピックブランチとRedmineのチケットを1対1に明示的に対応付ける操作を画面上で行える
(3)GitHubのようなプルリク機能をRedmineにも取り入れて、GitのマージをRedmine画面上で操作できるだけでなく、チケットCloseも自動更新できるようにする

【6】参加者に聞いてみたら、東京Redmine勉強会ではいつも講演が盛り沢山なので、たとえば午前10時から午後17時までRedmineカンファレンスを開催する、とか、限定されたテーマでRedmine勉強会を開催してはどうか、という意見があった。

Rubyカンファレンスには及ばないけれども、Redmineカンファレンスみたいなイベントがいつか開催できるといいな。

| | コメント (0)

2018/05/25

「大学生・社会人のための言語技術トレーニング」の感想

「大学生・社会人のための言語技術トレーニング」の本がとても良かったので、感じたこと、考えたことをラフなメモ書き。
自分の考えと感想を混ぜて書いているので、ロジカルでない。

大学生・社会人のための言語技術トレーニング - 発声練習

医学書院/週刊医学界新聞(第3054号 2013年12月02日)

7月の言語技術教室: タイガ日記

言語技術の有効性 三森ゆりかさん | 女王様のブログ

【0】書店に行くと、ロジカルシンキングや論理的思考の書籍がたくさん並んでいるし、たくさん売れている。
なぜ、そんな本が売れるのだろうか?

「大学生・社会人のための言語技術トレーニング」を読んだ後、たぶん、日本人は小学校から大学まで論理的思考の訓練を習得しないまま就職して、実際のビジネスで数多くの論理的思考を使う場面に遭遇するので、慌てて勉強し直す必要があると感じているから、と思った。

【1】ロジカルシンキングとかクリティカルシンキングとか、色んな本を読んできたけれど、「大学生・社会人のための言語技術トレーニング」を読んで、ようやく、日本語での思考と英語での思考では方法が違うのだ、という事がよく分かった。
もちろん、英語でも日本語でも、言語を使うのだから、論理的な思考を行う方法は双方とも適用できるし、同じ結果も得られる。

しかし、日本語というツールは、その内包する弱点を特に意識しなければ、たぶん、論理的に思考する時に数多くの落とし穴にはまってしまいがちなのだろう、と感じた。

【2】日本語の最大の弱点は、主語なしでも書けること。

【2-1】「私は」「あなたは」「彼が」という言葉を使わなくても、自分の主張を公表できる。
むしろ、日本語では、「私は~と考えます」といつも使っていたら、自己主張が強すぎ、のように思われて、引いてしまう雰囲気になる。

しかし、英語だろうが他の言語では「I think~, because~」という表現は普通だ。
そういう構造が言語に埋め込まれていれば、自然な発言が自己主張につながるし、自分の立場を明確に公表する、という言動につながっていく。

日本の小学校・中学校の国語の試験問題を見ると、「この文章の主語は誰でしょう?」みたいな問題があったりする。
こういう主語探しの問題は、英語ではありえない。

日本の文学では、主語なしの文章で、故意に複数の解釈を埋め込む技法もある。
例えば、川端康成の「雪国」の最初では、トンネルを抜けたら雪だった、という文章の主語を故意に省略し、後で、主人公の発言であったかのようにストーリーが進む。
しかし、こういう文学的技法は、政治やビジネスのように交渉する場面では全く不要。

日本人は自己主張が弱い、という理由は、たぶん、「私は~と思います。理由は~だからです」という文章が日本語の構造として形式的すぎて、日常会話で話すと不自然に感じてしまう、という弱点があるからだろう。
よって、「主張→根拠→結論」という一般の3段階論法を、日本語で自然に話すのが、上手くフィットしない雰囲気を感じてしまうからだろう。

【2-2】「大学生・社会人のための言語技術トレーニング」で興味を惹いた点は、中学生向けのドイツ語の小説で、文章の主語が3人称→1人称→3人称に変遷する時に、読者である中学生がその文章の主人公に意識を挿入しやすいことがある、という指摘。

実は、その小説で男の心理を3人称で語っている文章は、第三者的視点で客観的に語っているのだが、1人称で語っている場面では、男の心の中の動きであり、主観的であり、実は狂気な言動、という仕掛けになっている。
つまり、中学生は、日常生活ではありえない狂気の男性の心の中に入り込むことで、小説内で疑似体験しているわけだ。
そういうテクニックもあるらしい。

【2-3】他の日本語の弱点として、時制がないという点もある。

「大学生・社会人のための言語技術トレーニング」の一節では、ドイツの小説には過去形の文章が続いた後で、現在形の文章に急に変わった場面がある。
実は、過去形の文章は他人事だが、現在形になることで読者がその状況に入り込むことで、小説内で疑似体験するように仕向けている、と言う。

しかし、そういう技法を日本語で翻訳しようとすると、変な日本語になってしまって読みづらい、という事もあるのだろう。

【3】「大学生・社会人のための言語技術トレーニング」で「説明の黄金律」というものが紹介されている。
空間配列、時系列、重要度(度合い)の3つだ。
この考え方をドイツでは小学生低学年から叩き込まれるのに、日本の小学生は国語でも習わない。

【3-1】特に、空間配列(Spacial Order)という考え方を日本人は意識していない。
これは構造の順序そのもの。
説明の順序は、外から内へ、大から小へ流れる。

しかし、日本人のよくある説明は、空間配列の順序で整理して話さないために、あちこちの論点に散在する説明になってしまい、主張や結論が曖昧に聞こえてしまう。

「大学生・社会人のための言語技術トレーニング」では、フランスの国旗の説明で空間配列を説明せよ、という問題があり、良い回答と悪い解答の比較が非常に面白い。

また、「大学生・社会人のための言語技術トレーニング」によれば、絵の分析は、空間配列の考え方の強化に最適らしい。
絵の分析は、事実と意見の違いを明確に区別する訓練にもなるらしい。

たとえば「偉大な物理学者アインシュタイン」という文章では、どこまでが事実で、どれが意見解釈なのか?
それを即座に読み取れるか?

【3-2】空間配列=構造の順序、時系列=時間の順序、重要度=比較の順序。
実はこの考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」にも記載されていた。
彼女の本には、この考え方は小学生頃から知っているから、という一節が書かれているが、実は、日本の小学校の国語ではこんな考え方を僕は習って来なかった。
だから、論理的に思考する、論理的に話す、という手法に苦労してきたのかもしれない。

【3-3】「大学生・社会人のための言語技術トレーニング」では、物語の構造についても詳しく説明してくれている。
簡単な具体例は、桃太郎。
物語の構造は、英語であれ日本語であれ、古今東西同じ。

物語の構造は、状況→複雑化→疑問→答え、という流れになる。
しかし、英語圏ではこの物語の構造という考え方を明確に小学生の頃から教わっているのに、日本の小学校では明確に教えられていない。
実は「状況→複雑化→疑問→答え」という考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」の最初に記載されている。

「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」では、プレゼンのイントロ部分では、古典的な技術であるストーリー形式(物語形式)で始めると聴衆を引き込みやすい、という一節がある。
その一節で、「状況→複雑化→疑問→答え」という考え方が紹介されていた。

僕が、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」を最初に読んだ時、とても堅苦しくて読みにくい本だ、どこが名著なのか分からない、と感じていたが、「大学生・社会人のための言語技術トレーニング」を読んで理解した後で読み直すと、なるほど、そういう背景があったのか、とようやく理解することができた。

【4】パラグラフ・ライティングという技法も、日本の国語の授業で習わない。

トピック・センテンス→サポーティング・センテンス→コンクルーディング・センテンスという流れ。
トピックセンテンスには、コントローリングアイデアが必要。

パラグラフ・ライティングには5つのルールがある。
・各段落に話題(テーマ)は一つ。
 →日本語なら、意味段落に相当する。
  「意味段落◆----形式段落」のような構造。
  日本語の文章は、形式段落がむやみに多すぎるので、意味段落にまとめる作業が別途発生する。
  「形式段落を意味段落にまとめよ」という国語の試験問題もあるらしい。

・話題文(トピックセンテンス)は段落の先頭に置く。
・話題文だけで話を成立させる
 →コントローリングアイデアに相当。

・不用意に接続詞を置かない。
・論理を整理しておく。

パラグラフ・ライティングを発展させると、「序論→本論→結論」という学術論文の基本構成になる。
つまり、小学生が習うパラグラフ・ライティングを起点として、10年かけて論理的思考を徹底的に訓練した後、大学生の卒業論文という結果になる。

【4-1】日本人の文書が分かりにくい、と言われる原因のうち、最大の原因は、起承転結のスタイルで書いているからだろう。

起承転結のスタイルでは、前置きが長く、結論が一番最後になるので、すぐに結論を判別できない。
だから、エレベータートークで話すように訓練しろ、と、新人社員はよく言われるわけだ。
日本語の文章は、結論が後回しになりやすい。

他にも原因がある。
一つは、空間配列の技法を習得できていないために、情報を構造として整理できていないこと。
情報を外から内へ、大から小へ、という構造で整理していないので、情報の粒度がバラバラで、論点が分かりづらい。
ちょうど、外部設計から内部設計へ、というソフトウェア設計の考え方と同じ。
いきなり、プログラムの詳細設計レベルの話をされても、そのシステムは結局何ができるのか分からない、という問題と同じ。

もう一つは、日本語特有の論理スタイルが悪いこと。
たとえば、主語なし文章のようなゾンビ文。
時制が曖昧。
形式段落が多すぎて、意味段落としてまとめられていない。

【4-2】日本でオブジェクト指向が普及しなかった、という理由の一つは、オブジェクト指向の日本語の文章が感覚的に変、という事もあるだろう。

「オブジェクトが~する」という文章は、まるでモノが人のように振る舞う点が日本語として感覚的でない。
むしろ日本語としては、「オブジェクトは~される」という受動態で表現する方が感覚的に読みやすい。
つまり、逐次実行的な受動態の文章スタイルの方が、詳細設計の文章は肌感覚で合う。

【4-3】「空間配列・時系列・重要度」という考え方は、チケット管理にも即座に適用できる。

空間配列は、チケットの粒度そのもの。
WBSのように、工程→作業→成果物のように粒度を詳細化していく考え方と同じ。

時系列は、チケット登録日、更新日の順序と同じ。
重要度は、チケットの優先度、チケットの並び順、リリース順、と同じ。

【5】「大学生・社会人のための言語技術トレーニング」では、自分の意見を立証するための構造として「トゥールミンモデル」が紹介されている。
たとえば、絵の分析で、こういう人物が描かれているので、私はこう考えた、と主張する時、その証拠とその論拠を明確にして、主張を支える技法だ。

この技法を発展させると、クリティカルシンキング、クリティカルリーディング、批判的思考につながっていく。

トゥールミンモデルの考え方は、ゴール思考モデル(GSN)につながるし、昨今の自動車業界における機能安全規格の要件適合やシステム適合性にもつながる。
つまり、なぜこの自動運転システムは機能安全といえるのか、という主張を支えるための証拠や論拠を揃えて、論理的に組み立てる必要性があるわけだ。

【6】「大学生・社会人のための言語技術トレーニング」に書かれている素材は、小学生の国語の内容と同じ。
しかし、ロジカルに読む・書く・考えるという技法は、実は日本人は意識していないのかもしれない。
僕自身も明確に意識していなかったので、改めて、理解できた部分は書き残してみた。

| | コメント (0)

«第14回東京Redmine勉強会の見所