« 2019年6月 | トップページ

2019年7月

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)

« 2019年6月 | トップページ