2019/08/31

第20回Redmine大阪の感想 #RedmineOsaka

今日のRedmine大阪が無事に終わりました。
参加者、スタッフの皆さん、ありがとうございました。
疲れているのでラフなメモ書き。

Redmine-osaka-020 - Redmine.Osaka

2019/8/31 第20回Redmine大阪 - Togetter

第20回 Redmine大阪 - connpass

redmine大阪勉強会 コアなメンバーが集まる madowindahead

redmine Osaka の感想|makoto0119|note

【1】今回の勉強会では、会場が大阪にも関わらず、遠方からたくさんの参加者が来られた。
東京、名古屋、松江、福岡、神戸など。
いつもの@MadoWindaheadさん、@ryouma_nagareさんだけでなく、@akiko_pusuさんまで東京から参加してもらって、非常に盛り上がったと思います。
また、大阪でも20代から40代までと幅広い年齢層で女性も割と参加されていた。
参加者層が多様であることは、勉強会の活気にも繋がり、とても良い雰囲気であるように感じた。

DirectPollの投票結果では、Redmine歴が4年以上が参加者の半数以上。
バージョンも3.x以上が多い。
つまり、Redmineを長年かなり使いこなしている人たちが多い。
よって、講演内容も細かい技術の話だけでなく、導入や運用、開発プロセスの話もあるので、内容が非常に幅広くなっている。
その分、いつ聞いても、新鮮な感じを受けるので飽きない。

たくさんの講演があったので、興味を引いた内容だけメモしておく。

【2】@g_maedaさんのRedmineのVer4.1の紹介を聞くと、「今回のバージョンでは攻めている」。
つまり、Ver4.0ではRailsのバージョンアップを重視していたので大幅な機能追加はできなかったが、Ver4.1では割と数多くの機能改善がなされている、とのこと。

履歴タブ、通知メールやリマインダメール、インポート時に親チケットの仮IDを付与して親子チケットの関係を保持する機能改善、など、Redmineをより使いやすくする機能改善がたくさんあった。
RedmineはUIが使いにくい、という話もよく聞くが、頻繁に機能改善が取り込まれている現状を見ると、最新版に追随した方が恩恵を受けやすい。

実際、@ryouma_nagareさんのLTでは、RedmineをVer4.xへバージョンアップしてPostgresSQLへ変更したことで、AWS上のログを解析すると性能が大きく改善された、とのこと。

akipiiさんはTwitterを使っています: 「#RedmineOsaka Redmine 4にバージョンアップしたら、ログ解析すると、圧倒的に高速になった報告。Postgresなら、サブクエリもインデックスが働くのでMySQLよりも速い。」 / Twitter

また、@netazoneさんのLTでも、Ver4へバージョンアップしても、数多くの日本人作者のRedmineプラグインは互換性を維持でき、より使いやすくなった、とのこと。

よって、Redmineの機能改善してどんどん機能が肥大化したとしても、RubyやRailsのバージョンアップに伴う高速化により、Redmine本体の性能は良くなっている。
RedmineがRubyやRailsの相性がとても良い、という事例でもあるのだろう。

【3】「とあるメーカーのRedmine 活用事例 RedmineとTableau」の講演も面白かった。
この会社では、情シスが部門ごとにRedmineインスタンスを配布しているので、30個以上のRedmineが社内にある。
社内はVM、社外はAWS。

Redmineのポリシーは、各部署にお任せ。
その理由は、各部署で自由に使いたい、という意見が強かったらしい。
実際にRedmineを使っている部署では、リーダーとその部下が頻繁にRedmineを使っているが、管理職や役員はほとんどRedmineに触れておらず、そもそもRedmineを知らないらしい。
そういう話を聞くと、日本ではあるある、だなと思う。

akipiiさんはTwitterを使っています: 「そこがすごいですよねー。RT @kazuhito_m: 「全社同一Redmine」じゃなくて「データは全然分かれてるインスタンスを多く立ててる」のかな? #redmineosaka」 / Twitter

そこで、Tableuが有効活用できる。
RedmineのデータをTableuで集計して、上司に見せるビューを作るわけだ。

Tableu連携では3パターンある。
RedmineのDBに直接連携、REST API経由でデータを取り込む、カスタムクエリで出力したCSVを取り込む。
話を聞くと、RedmineのDBのミラーリポジトリを作り、そこでTableuで集計しているらしい。

デモでは、CSVを取り込んでTableuで集計ビューを見せていた。
話を聞くと、Redmine導入以前は、Excelでガントチャートを計算・表示させるマクロまで作り込んでいたらしいので、このやり方が一番使いやすいらしい。

つまり、従来はExcelによる開発プロセスは既に出来上がっていたので、Redmineで運用するプロセスに乗り換えるだけでよい。
すなわち、Redmineの導入は非常に楽だったのだろう、と想像する。
そこに足りない集計機能の部分は、Tableuでフォローするというやり方は洗練されていると思う。

akipiiさんはTwitterを使っています: 「既にエクセルでガントチャートのマクロも作り込んでいた話がありましたね。運用プロセスはあったので、Redmine 乗り換えはスムーズかも。@saito0119: すごく斬新な話で驚きました。開発用ではなくいわゆる今まで ITメーカーのやってきた「基幹システム」を手作りしているような話でした #redmineOsaka」 / Twitter

【4】@akahane92さんの「Redmine全文検索システムの実際」では、全文検索の性能要件の話だけでなく、機能強化にも興味があった。

akipiiさんはTwitterを使っています: 「Redmine 全文検索プラグインでついに、添付ファイルもリポジトリ内の文書も検索が可能になった。Redmine に全てのデータを集約すれば、いつでも即座に探し出せる意義は大きい。Redmine はナレッジシステムに近づいてきたかな。検索機能はトレーサビリティの代替にもなりうる可能性がある。 https://t.co/0dUz1GAHEq」 / Twitter

つまり、Redmineのチケットがストック型で、たくさんの情報を埋め込む運用プロセスの場合、Redmineの全文検索プラグインは非常に有用な機能になるだろう。
いつでも簡単に有用な情報が検索できるだけでなく、情報のトレーサビリティをより強化してくれるからだ。
添付ファイルやリポジトリ内のソースや設計書も検索できることで、成果物のトレーサビリティを優れた検索機能で支援してくれるわけだ。

akipiiさんはTwitterを使っています: 「#RedmineOsaka GitHub のソースにクリアコードさんと島津製作所の名前が記載されて、オープンソースで公開されてるのは、製造業の人ならすごいなと分かるのではないか。知財管理などをクリアされて、みんなが共有できるのが有難いですね。」 / Twitter

製造業では、知財部が必ずあり、知的財産は特許などで守り、ビジネスにしていく。
あるいは、不正競争防止法の営業秘密として、知的財産を盗まれないようにひた隠しにする。
にも関わらず、開発したプラグインをオープンソース化して公開できたことは、非常にすごいと思う。

僕の考えでは、特許や不正競争防止法の営業秘密のような知財を防御するような手法は、ソフトウェア開発ではあまり馴染まないだろうと思う。
むしろ、OSSコミュニティと密接に関係する方が、今後の保守もやりやすいし、優れたソフトウェア技術者も確保しやすくなるメリットの方が大きい。

【5】懇親会で話をしながら、Redmineコミュニティの参加者層に関するヒントを教えてもらった。
どうやら、Redmineのユーザ経験はあるがシステム管理者の経験がない人達がRedmineでプロジェクト管理したくて、Redmineに興味を持ち始めている、というセグメントがあるらしい。

akipiiさんはTwitterを使っています: 「#RedmineOsaka 懇親会から離脱しました。参加者、スタッフの皆さん、ありがとうこざいました。飲みながら議論して気づいた事は、以前Redmineのユーザーで使用経験あるが今の職場ではエクセルで不自由なので自らRedmineシステム管理者になったが詳しく知らない。そこで勉強会に来てみた層が割といる」 / Twitter

akipiiさんはTwitterを使っています: 「#RedmineOsaka つまり、Redmine ユーザーの経験はあるがシステム管理者の経験がないがプロジェクト管理がしたい人というセグメントがRedmine 勉強会のターゲット層になってる。ちょうど、プログラマ上がりの新米リーダーがRedmine でプロジェクト管理を始めたという自分の経験と既視感あるのが面白い。」 / Twitter

以前、@MadoWindaheadのPMxTMマトリクスの話の通り、上記のセグメントの参加者は、Redmine力をつけることでPJ管理力を身に付けやすい。
支援するだけで、彼らは自身の力だけで、問題解決できるはず。

そんなことを思うと、Redmineコミュニティは非常にニッチなマーケットにも関わらず、非常に良いユーザ層を持っているなあ、と思う。
ユーザが成長している場面をコミュニティが共有できるのは、活気があってすごく楽しいから。

そんな気付きがあった。

【追記】
redmine Osaka の感想|makoto0119|note (引用開始)
 ユーザディスカッションで聞いた話で、心に残ったのは以下。
「こうやって勉強会に来る人はそう考えないと思いますが...」「現場に理解のない管理職が...」などなど。
そうなんですよね、勉強会に来る段階でフィルターがかかっていて、そこでの「他人の芝生」はかなりバイアスがかかっているということ。
良い意味での「意識の高い人」が「自分の悩みを他の人はどう考えているのか」を聞きに来ているような状況。
実際、redmine の利用経験は「4年以上」の人が多数で、驚きました。
 一般的な OSS とは違い、redmine Osaka はソフトそのものの使い方やバージョンアップ情報を共有するコミュニティではなく、日頃現場で戦っている「同士の懇親会」の様相なのです。
(引用終了)

【追記2】

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「本編・懇親会一次・二次…すべてで「すごく有用なことを教えてもらった」気がします。なんというか…勉強会に「行き始めた」頃の感覚を思い出しました。一緒に話して頂いた方、質問に答えていただいた方、多くの人にありがとうです。 #redmineosaka」 / Twitter

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「ちょっと抽象的な表現になっているのは「いっぱい”これは聞いて良いのか?"なことにも快くお話してくれた方」が多かったからです。そういう意味でもありがとうです。」 / Twitter

(3) akipiiさんはTwitterを使っています: 「@kazuhito_m 行き始めた頃の感覚とは、どんな感じなんでしょうか?」 / Twitter

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「@akipii 「すごい人々がいるな憧れるわ」「有用な情報やな」「学んで帰らな」というような、そんな気持ちです。」 / Twitter

| | コメント (0)

2019/08/30

Redmineインスタンスを分割したい状況の考察

@nekosanzさんから、Redmineインスタンスを分割したいつぶやきがあって、色々考えさせられたのでメモ。 論理的でないラフなメモ書き。

【参考】 かるね@nekosanzさんはTwitterを使っています: 「Redmineの今後について、やはり複数に分ける方向に進んだほうが幸せかも。なやましー」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 そんな感じです。お客さんによって規模と契約が極端に違うせいか、同じ部門でも求められる成果や粒度が違います。大企業向けのチームはロールや作業時間、カスタムフィールドに対する要望も多くなってます。サーバーのEOSLの兼ね合いもあるので、方針決めを楽しんでます。」 / Twitter

りょうま@Redmine大阪LTするよさんはTwitterを使っています: 「@nekosanz1 @netazone @yassan168 多分、利用者同士は各Redmineの中で話するので困らないと思いますが、nekosanzが「どのインスタンスの?」と聞く手間が増えますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 組織とRedmine の間がどれだけ密結合なのか、という基準になると思います。一人のユーザーが複数のRedmine インスタンスに関わるような組織、つまり組織とRedmine が疎結合ならば、運用は煩雑になるでしょうね。」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @netazone 複数あるとめんどい部分もありますね。ただ、それなりの組織の活用レベルを上げる(密な状態になっていく)と特定のビジネスに合わせて特化してくような感じです。トラッカーやカスタムフィールド、作業時間、インターフェイスとか。今の環境見直しだけでも出来そうですが、他への影響を考慮してます」 / Twitter

neta@ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@nekosanz1 @yassan168 @akipii @kam1nchu 1人 1 Redmine と正しくスコープ設計ができるならいいと思います。私は失敗した。顧客共有用 Redmine が開発から保守フェーズに入った際に社内用分離→内緒話を不適切な方に書く事故多発。 ワークフローやロール数は増えるかもしれないけど、分割しないと解決できないケースはなんだろう?外部共有?」 / Twitter

黄巻紙さんはTwitterを使っています: 「@netazone @nekosanz1 @yassan168 @akipii 「分割しないと解決できない」とはちょっと違いますが、例えば「特定の部署ではものすごく欲しいけど、ほかの部署では不要なプラグイン」を入れたとして、そのプラグインが原因でバージョンが上げられなくて迷惑するみたいなケースは想像してました。実際の運用経験からのものではないですが…」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@kam1nchu @netazone @yassan168 @akipii まさしくそんな感じです。かなり特殊な事例ですが、特定対象(うちだと顧客)において、1番でかくて複雑な運用を大人数で回してるプロジェクト群を「根本見直し」するケースですね。トラッカーやロール、時間管理、プラグイン、諸々変えるのですが、他の部門には関係ないですし、既存運用もあるので。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 なるほど、Redmine に対して、部署ごとに要求が違うのに真因があるわけですね。単一の標準Redmine では、多種多様な社内のニーズに耐えきれなくなる事例。面白いですね。」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 Redmineというか無償なOSSあるある問題な気がします。管理者コストを代償にフレキシブル&ニッチオブニッチに対応し、それらの影響でVer.UP出来ないとか、運用が複雑になってしまって、構築した人しか扱えないものになってしまうとか、割とアンチパターンに成り易いので注意がいるパターンです??」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 とは言え、何でもかんでも断るのも、良い関係性保てないし、そもそも改善出来ないので、改善の本質を考えたり、とてもバランス感覚が必要なところじゃないかなぁと思います。」 / Twitter

neta@ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @nekosanz1 以前はノリでプラグイン入れてたけど、全社利用になったので「安定、信頼、長期利用」に方針転換した。 バランス大事なのほんとにそう。ウチは幸にもヘビーな要望がないので、コミュニティの知恵を借りることで結構なんとかなってる感謝。 Redmine 管理者レベルが上がると思って楽しんでます(まだ)」 / Twitter

akipiiさんはTwitterを使っています: 「@netazone @yassan168 @kam1nchu @nekosanz1 みんなの意見が参考になります。Redmine はカスタマイズしやすい特徴があるが、組織が大規模になり、高品質な運用が求められてくると、安易なカスタマイズが仇になるわけか。組織構造よりも組織文化とRedmine の間の課題かもしれない。」 / Twitter

【感想と考察】 【1】会社標準の単一Redmineインスタンスから複数のインスタンスを立ち上げたい時、どんな考え方が判断基準になるだろうか?

僕は、組織とRedmineの間でどれだけ密結合になっているか、という基準で区別できるだろう、と考えている。

たとえば、組織とRedmineが疎結合の場合、Redmineインスタンスは所属部署に関係しないので、一人のユーザは複数のRedmineにログインする運用になる。 よって、ユーザは各Redmineのログインパスワードを別途記憶せざるを得ないし、Redmineに書き込んでいる時に自分が今どのRedmineインスタンスにいるのか、逐一存在確認する状況が発生してしまう。 特に、システムごとにRedmineが乱立していると、作業日報や障害・問い合わせの記録をする時に、複数のRedmineチケットに記入する時の入り口の判断にパワーを取られるのが、あまり楽しいものではない。

一方、組織とRedmineが密結合の場合、Redmineインスタンスは所属部署に強く関係づけられているので、一人のユーザは所属部署が持つ単一Redmineだけの運用になる。 ユーザの作業全ては単一Redmineのチケットに起票するだけなので、ブラウザでどのRedmineだっけ?と考える手間は全く無い。 たぶん、ユーザにとっては入り口が楽な分、運用も定着しやすいだろう。

【2】では、Redmineと組織の関係にはどんなパターンがあるのか?

たぶん2種類ある。 組織を単一Redmineインスタンスに標準化するパターンと、組織ごとに複数のRedmineインスタンスが混在するパターン。

前者では、単一RedmineのRedmineプロジェクトに組織構造の情報が埋め込まれているはずだ。 しかし、Redmineの設定は標準化されているので、部署単位の文化はあまり埋め込まれていないだろう。

ただし、組織とRedmineの関係は密結合になっている。 Redmineで実現された標準プロセスに埋め込まれたワークフローや諸々の運用ルールに、組織に属する全ての人達が規定されられているはずだ。 何となく窮屈な気もする。

後者では、Redmineインスタンスごとに組織(部署)が対応付けられているはずだ。 よって、Redmineには組織の情報だけでなく、部署単位の組織文化がふんだんに埋め込まれているだろう。 たとえば、ワークフローやカスタムフィールドに、業務やシステムの特徴がもろに出ていたり、部署の管理職が欲しがる情報がカスタマイズして埋め込まれているだろう。

ただし、組織とRedmineの関係は疎結合になっている。 一人のユーザは、こちらのRedmineに入ればその組織文化を受け入れ、あちらのRedmineに入れば別の組織文化を受け入れる。 たとえば、ある組織のレビュープロセスが普通と思っていても、別の組織のレビュープロセスが違っていれば、Redmineのワークフローは大きく異なっているはずだ。 おそらく、新規加入した委託契約の開発者は、乱立したRedmineごとの開発プロセスの違いで混乱してしまうのでは、という気がする。

だから、複数のRedmineの集計ビューを一つのRedmineで見たい、という要望も発生しがちだ。 特に、PMOのように複数の組織やPJを横断する情報が欲しい場合、複数のRedmineのビューを手軽に見たくなる。

複数Redmineの内容を一つのRedmineに集約して見る方法: プログラマの思索

【3】とはいえ、会社標準の単一のRedmineインスタンスで運用を始めて全社に展開していくと、ユーザから細かな改善要望が結構出てくる。 Redmineの良さは、カスタマイズのしやすさなので、割と簡単に要求を受け入れて、その会社特有の業務に使いやすくできる。 しかし、カスタマイズしすぎると、Redmine本体が複雑になってしまい、ユーザの多様なニーズに添えなくなる時がある。

つまり、単一の標準Redmineでは窮屈すぎて、組織内にある多種多様なニーズを実現できなくなる臨界点が現れるわけだ。

上記の議論の通り、Redmineのカスタマイズのしやすさが、逆にRedmineの普及や浸透に制限をかけてしまう場合がある。 そう言えば、Jenkinsでも同様な話があった気がする。 例えば、Jenkinsでデプロイ作業やデプロイのパイプラインをどんどん作り込んでいくと、どんどん複雑になってしまい、Jenkins職人と言われる属人化した人しか触れなくなる、みたいな。 たぶん、Redmineでも、Redmine職人しか会社のRedmineをカスタマイズできない、と言った症状が出てくるかもしれない。

では、単一Redmineが複数のRedmineに分離したくなる臨界点とは、どんな条件があるのだろうか? その臨界点では、組織とRedmineの間に、どんな緊張関係が出てくるのだろうか?

実際、単一Redmineでは使いにくい、という不満が大きければ、その不満を発する組織と単一Redmineには大きなコンフリクトが発生しているからだ。

たぶん、いろんな状況や理由があると思うので、色々聞いてみたい。

» 続きを読む

| | コメント (0)

2019/07/20

Redmineの口コミ評判の記事のリンク

Redmineの口コミ評判の記事を見つけたのでリンクしておく。読んでいると面白い。ラフなメモ。

【参考】プロジェクト管理ツール「Redmine」の評判と実態|徹底した比較・調査結果をご紹介! | 発注業者比較なら【アイミツ】

Redmineのレビュー(口コミ・評判) |【ITreview】IT製品のレビュー・比較サイト

【1】口コミ評判記事のユーザを見ると、メーカー・営業・事務など、IT系以外の人が多い。そういう人達までRedmineが利用されているのが面白いと思った。

RedmineはRuby製なので、WordpressのようなPHPアプリに比べると、IT初心者にとってセットアップが難しいのではないか、と思う為だ。でも、そういう心配も無関係に広がっているみたい。

やはり、Redmineでオンラインのタスク管理、コミュニケーション、情報共有を期待して成果を出しているみたい。

【2】最も興味がある内容は「改善してほしいポイントは何でしょうか?」の箇所だ。最も多い内容は「古臭いと思われるUI改善」だが、それ以外の箇所も気になった。

(一部引用開始)スレッドが続くと、個人の意見と複数関係者の意見の区別が仕分けづらくなるケースがあり、再度スレッドを立てるケースがある。

チケットのリマインダー機能を標準で実装して欲しい。例えばチケットの期日●日前にリマインドする機能や、チケットの期日が●日過ぎた場合にリマインドする機能が欲しい。(引用終了)

リマインダー機能はrakeバッチで付属しているが、IT初心者にとってハードルは高いだろう。画面上からリマインダー機能が使えるようになれば、ユーザに優しいUIになるだろうと思う。

スレッドの件は、チケットが掲示板代わりになっているからだろう。チケットに全ての記録が残る点はメリットだが、たくさんの情報が散在したり、テーマが発散する場合もある。Redmineの機能よりも、運用ルールも考えた方がいいかもしれない。一方、Redmineの全文検索プラグインがあれば、散らばった情報であってもRedmineにデータが集約されていれば、いつでも検索できるので、気にしなくてもいいかもしれない。

(一部引用開始)ガントチャートをExcelへエクスポートできる機能が欲しい。PDFへExportできますが、資料として使用したい場面があるため、追記が容易なExcelにエクスポートする機能が欲しいです。

個々のタスクの依頼ややり取り管理のし易さの反面、プロジェクトマネジャー目線ではEVM等コストや全体がやや見えにくい印象。(引用終了)

Redmineは開発者の観点では十分すぎる機能があると思う。しかし、管理者の観点では、レポート出力の機能が物足りないだろう。報告書をもっと手軽に作りたい、コストやスケジュールを鳥瞰したり特殊な観点で見たい、など、いろんな要望があるはず。こういう要望に対しては、Redmineの標準機能ではなく、プラグインによるアドオンや外部連携ツールなどで対応すべきと考える。

(一部引用開始)メジャーバージョンアップ時の移行の手間を軽減してもらいたい。メジャーバージョンアップとなると、データや拡張機能の互換性に問題が発生しやすい。(引用終了)

Redmineのバージョンアップやデータ移行に関する要望は割と多い。RedmineはOSSの割には進化が速いので、バージョンアップに追随することはIT初心者にとってハードルは高いだろうと思う。以前から、@acha_821 さんが「RedmineもJenkinsみたいに自動アップデートする仕組みが欲しい」と要望を出していたが、他のユーザも同じように思っているのだろう。

2018年初頭におけるRedmineの動向に関するメモ: プログラマの思索

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

現時点では、おそらくBitnamiのVMイメージやDockerなどがその解決策の一つになるだろうと思う。最終的には、Redmine本体で自動更新機能ができるといいのだろうと思う。

| | コメント (0)

2019/07/10

前処理大全の良いところ~SQLとRとPythonで対比できる

「前処理大全」の感想をラフなメモ書き。自分のための参考記事をリンクしておく。

【参考】前処理大全[データ分析のためのSQL/R/Python実践テクニック]:書籍案内|技術評論社

『前処理大全』のサンプルコード

Community Blog - 『仕事ではじめる機械学習』&『前処理大全』著者対談(Part 1)

Community Blog - 『仕事ではじめる機械学習』&『前処理大全』著者対談(Part 2)

Community Blog - 『仕事ではじめる機械学習』&『前処理大全』著者対談(Part 3)

Community Blog - 『仕事ではじめる機械学習』&『前処理大全』著者対談(Part 4)

データ分析初心者は「前処理大全」でデータ前処理を学べ | リーマンエンジニアのブログ

前処理大全は機械学習に関わる人の必需品 | Tamanyan.me | たまにゃんのエンジニアブログ

RとSQLを対応付けてみた - あらびき日記

R初心者はこれを見ろ!便利なパッケージまとめ!入門編 - Qiita

dplyrを使いこなす!基礎編 - Qiita

「前処理大全」はサラリと読んだだけのレベル。Rで少しずつ書きながら、こんな使い方をするのか、と初心者レベルから理解している。

R言語は以前からやりたい、と思っていたが、なかなか慣れなかった。SQLは分かるので、「前処理大全」のおかげでSQLと比較することで、R言語の書き方を覚えられる。「前処理大全」には、RよりもSQLの方が短く書ける場合もある、という事例が新鮮だった。

dplyrライブラリのおかげで、SQLのようなデータ操作をUnixパイプみたいに書けるのが快適。データ加工をバラし、試行錯誤しながら、データの特徴を分析できるのが楽しい。ggplotも使えば、データ分析結果をいろんなグラフで表示できるのもいい。

「前処理大全」の面白さは、SQLとRとPythonのプログラムを比較できる点にある。SQLのメリット、Rのメリットがどんな利用シーンであるのかよく分かる。

ちょうど、古代に書かれた聖書で、古代ギリシャ語とラテン語、コプト語を対比した書物みたいな感じ。SQLとRで、ニュアンスの微妙な違いが面白い。

但し、「前処理大全」はあくまでも、機械学習やデータ分析の前処理だけに特化しているので、それだけでは十分でないことは分かっている。本当の面白さはその先にあるから。

| | コメント (0)

2019/07/03

Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか

バリューストリームマップを使う機会があったので、ラフなメモ書き。

【参考】
VSM (Value Stream Mapping) のススメ?開発プロセス可視化? - Qiita

バリュー・ストリーム・マップを作る 22 のステップ ? リーンシックスシグマの現場

バリューストリームマップを描く時のポイント - Togetter

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

【1】バリューストリームマップを使ってみて、Redmineのプロセス改善に使える感触を持った。
特に、Redmineのワークフローを見直す時に有効だろうと思う。

一般に、Redmineのワークフローは既存業務のワークフローをそのままマッピングする場合が多い。
すると、ToBeでなくAsIsの業務フローをそのままマッピングしてしまうので、既存の問題点を残したままRedmineに実現してしまう。
その問題点はRedmineで可視化されるので、改善すべきだという意識改革にはつながるが、改善の方向性はすぐには決まらない。
問題点のどこに着目すればよいか、観点が発散してしまいがちだからだ。

そこで、バリューストリームマップでワークフローを見える化し、問題点を明確にしてみるやり方が有効のように感じた。

一般に、日本企業は縦割り組織なので、業務フローも縦割りで分断されてしまう為に、ワークフローが非常に長くなりがちだ。
そういう部分をバリューストリームマップで描くと、タスクは必ず担当する組織・部門で表現され、そのタスクごとにステータスが割り当てられる。
いわゆる官僚制組織になりがち。

バリューストリームマップでは、ステータスが切り替えられるタイミングで、リードタイム(経過時間)とプロセスタイム(作業時間)、作業人数を必ず書く。
この点が非常に重要だ。
なぜなら、リードタイム-プロセスタイムに当たる待ち時間が長い部分こそが、このワークフローのボトルネックだからだ。
そのボトルネックをいかになくすか、という観点がプロセス改善策につながるからだ。

【2】実際にやってみると、ワークフローの最初から最後までのリードタイムに対し、待ち時間は80%を超える場合が意外に多い。
その原因は様々だ。
たとえば、プロマネの承認、レビューアのレビュー承認、顧客の仕様変更の承認など、第三者の承認で待ち時間が長期間発生する。
あるいは、並行タスクで忙しいために、本来着手すべきタスクを放置してしまった、とか。
あるいは、IT全般統制の成約のために、開発部門とインフラ部門の間で無駄にキャッチボールしている、とか。

実際、放置チケットで、新規から完了ステータスまでの日数と、チケットで実際に作業した稼働日数を比べると、チケットの稼働率は10%とかひどい数字になりがちだ。
そういう状況は、バリューストリームマップで一目で表現できるので、どこに問題があるのか、分かりやすいメリットがある。

【3】バリューストリームマップをワークショップで描いてみて面白いと感じる部分は、全体のワークフローを知る人が実はその会社にはいない、という事実が判明した時だ。
各担当者は担当する業務だけに閉じていて、タコツボ状態になっている。
実は、ワークフロー全体を統括するプロマネがいないわけだ。
だからこそ、既存の業務フローに問題が発生しているわけだ。

Redmineで放置チケットが発生しやすい問題も、実は、チケット管理のワークフローの全体に責任を持つ人がいないことが最大の原因だろうと思う。
チケットを完了ステータスへ持っていく、という責任感をチームのメンバー全員が認識していなければ、当然、チケットが放置されても、自分は関知しない態度に落ち着くからだ。

その解決手段として、その責任感を自然に生み出す仕組みとして自己組織化が使われていたり、その責任感の重さを感じさせないような仕組みとして心理的安全性が生み出されたりしたのだろうとも思う。

アジャイル開発からDevOps、自己組織化、心理的安全性へつながる昨今のマネジメント技術の流れは、そういう一連の流れから捉えると理解しやすいと思う。

一方、Redmineによるチケット管理の観点では、チケット管理のプロセスを守る守護神は、Redmineエバンジェリスト、Redmine警察やRedmineマイスターになるのだろう。

【4】バリューストリームマップでは、LT(リードタイム)、PT(プロセスタイム)だけでなく、手戻り率や直行率を求めている点が面白かった。
そこまで計算しているのか、と。

自動車メーカーに勤務しているんですが、合格率と直行率の求め方(計算式)、... - Yahoo!知恵袋

直行率(%)=一発合格数÷製造実績数×100

たとえば、手戻り率が10%ならば、直行率=90%になる。

実際にソフトウェア開発の業務フローで計算してみると、各タスクの手戻り率を合計していくと、直行率は50%を切る場合が多かった。
つまり、完成品の中身の半分は、手戻り作業で作られたことになる。
一般の現場は知らないが、この事実を悪いと見るかどうか?

【5】バリューストリームマップをRedmineの一機能として実現できると面白いと思う。
具体的には、Redmineのワークフローにおけるステータス間の稼働日数(プロセスタイム)と滞留日数(放置日数)がグラフィックに表現されると良い。
例えば、レビュー待ち→レビュー完了のステータス間では、稼働日数は1日以下なのに、滞留日数が5日以上とか普通にありがちだ。

あるいは、1チケットのサイクルタイム(新規~完了までの日数)と稼働日数の割合を各プロジェクト、各バージョン単位で集計する、とか。
つまり、プロセスサイクル効率(=作業日数/経過日数)を表現したいわけだ。

【6】実は、この概念は「プロセスサイクル効率」として、既に「リーン開発の現場」で既に紹介されている。

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

プロセスサイクル効率=作業日数/経過日数

・作業日数=実際に開発(作業)していた日数。
 ⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数=サイクルタイム。
 ⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

「リーン開発の現場」では、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10~15%程度だろうと言っている。
つまり、一般企業では、1チケットのサイクルタイムのうち、85~90%は待ち時間であり、真の稼働時間(プロセスタイム)はわずか10~15%に過ぎない事実を示している。
すなわち、チケット管理の計画を立てた時点で、チケットの予定期間の9割は無駄な時間を消費しているわけだ。

この事実が自分のRedmineに当てはまるのか、実際に試してみればいい。
Redmineでは予実の全情報が蓄積されているので、プロセスサイクル効率の検証は可能なはずだ。
もしその事実が自分のRedmineに当てはまるならば、改善すべき点が山ほどあることを示している。

Redmineエバンジェリストは、まさにそのボトルネックを改善すべき役割を担っているのだろう。

| | コメント (0)

«RedmineのUserPrefernceにはシリアライズしたデータを格納している