« 2016年12月 | トップページ | 2017年2月 »

2017年1月

2017/01/22

Elastic Search+Logstash+Kibana+TimelionでRedmineのBIを実現する記事のリンク

フューチャアーキテクトさんの記事で、Elastic Search+Logstash+Kibana+TimelionでRedmineのデータマイニングニングを行う記事があったのでメモ。
全てOSSのツールで、RedmineのBIを実現できるのは素晴らしい。

【参考】
マネージャーがうれしいRedmineデータのグラフ表示方法を公開します!! | Tech Blog - Future Architect

マネージャーがうれしいRedmineデータのEVM表示方法を公開します!! | Tech Blog - Future Architect

QLIKVIEWでの分析方法 - Google グループ

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索

仕組みとしては、下記の流れになる。
JDBCドライバを通じて、RedmineのDBにSQLを直接発行して、データを取得し、グラフィカルに表示するらしい。

(引用開始)
大まかな流れ

下記の手順でグラフを表示します。

1.ELKのインストール
2.RedmineデータをELKに取り込む
3.グラフ表示

1.ELKのインストール

はじめに、ELKの説明です。
ELKはelastic社が提供する、データ可視化OSSの総称。
Elastic Search+Logstash+Kibanaそれぞれの頭文字をとって、ELKと呼びます。
今回、ELKを利用して、Redmineデータの可視化環境を構築します。
(引用終了)

LinuxだけでなくWindows上でも簡単に実現できるのはありがたい。
また、集計した結果を保存でき、集計グラフをブラウザ上で閲覧できるのも良い。

毎日、集計バッチを動かすようにしておけば、上司や開発者も好きな時に見れるし、チームの開発状況を自然に見える化できるようになる。
また、チケット集計の内容だけでなく、ソースの品質情報なども公開すれば、開発者の品質意識の向上にも役立つ。

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索にも書いたが、Redmineのデフォルトのチケット集計機能が弱くても、今は、OSSで簡単にRedmineのBI機能を実現できる。
つまり、自分達が欲しい観点の集計ビューを、OSSのBIツールを駆使して作っていけばいい。

むしろ、自分達で、Redmineに不足した機能を実現していく、というプロセスの方が重要だ。
なぜなら、Redmineを通じて、自分達のソフトウェア開発プロセスをより良くしていくモチベーションの向上に役立つからだ。
上からのお仕着せのプロセス改善ではなく、メンバーが自主的に行うボトムアップ型のプロセス改善の方がはるかに意義があると思う。

Redmineの運用や集計ビューを通じて、自分達の開発プロセスのボトルネックは何なのか、どうすればより良いソフトウェア開発ができるのか、という行動を促していくわけだ。
Redmineが面白い部分はそんな所にあると思う。

| | コメント (0)

2017/01/15

Redmine本家未取込チケットで人気のあるチケット情報

@y503Unavailableさんの力作「Redmine本家未取込チケットで人気のあるチケット情報」が公開されていたのでメモ。
読んでみると、結構面白い。
@y503Unavailableさんが、幾つかのカテゴリで「+1」を集計してくれているので、感想をラフなメモ書き。

【参考】
QA #270: 本家未取込チケットを巡る(仮) - Unofficial Redmine Cooking - redmine.tokyo

気づき #280: 未完了全部(2017/01/09現在) - Unofficial Redmine Cooking - redmine.tokyo

(引用開始)
Redmine本家には、多数の未取込チケットが点在する。

+1が多いチケットには、それなりの内容がある筈だが、埋もれているのが現状。

標準に取り込まれなくとも、参考になる点は多々あるだろうし、必要な人もいる筈。
作者の思いもある。

そんなチケットに陽を当てたい。
(引用終了)

【1】気づき #271: issue編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #1448: Add tags to issues - Redmine

Feature #1176: Recurring Tasks - Redmine

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

【1-1】1番多いのは、Redmineのニュース、ドキュメント、フォーラム、Wikiなどにタグ機能を追加したい要望。
チケット機能でも同様の要望が多い。
ハッシュタグみたいに、Redmineのあらゆる情報をタグ付けできると、検索しやすくなる。

【1-2】2番目はRedmineで定期的なタスクをチケット自動生成したい要望。
たとえば、毎月の報告書作成、ログの定期採取と集計作業、サーバーメンテナンスなど、定期的な作業は手動登録でなく、自動登録できれば、忘れることもない。
日本人だけでなく、世界中の開発者も同様に考えているんだね。

@netazoneさんが、Cron+Shellの実行方法を公開してくれているので参考になる。

QA #273: 定期的作業をチケットで作業管理したい - Unofficial Redmine Cooking - redmine.tokyo

他にも、Redmineのプラグインもあるらしい。
見た目はこちらの方が、一般受けしそう。

やっさんさんのツイート: "@netazone これやでー>Redmine Periodictask plugin https://t.co/pwFiPPayl9 入れるとメニューに「Periodic Task」が追加されて、こんな感じでタスクを追加できるよ。 #redmine https://t.co/zXQm8AyOSG"

jperelli/Redmine-Periodic-Task: A redmine plugin that lets you schedule an issue to fire every x days/weeks/months

【1-3】3番目は、カテゴリのサブプロジェクトへ継承したい要望。
似たようなチケットはたくさんある。
世界中の開発者も、同様に思っているみたい。

Patch #11898: Inheritable issue categories - Redmine

Redmineは親子プロジェクトを気軽に作れるために、カテゴリを逐一登録し直すのが面倒。
親プロジェクトのカテゴリを自動継承できれば、その後、自由に修正するなどできれば、もっと便利になるのに。

【2】気づき #274: customfield編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #685: New Custom Field "Found in Version" - Redmine

Feature #3543: Improve 'long text' custom fields - Redmine

Feature #11361: Custom Field Groups, and User Specific Fields - Redmine

【2-1】1番多い機能は、バージョンとマイルストーンを区別したい要望。
下記チケットと重複しているらしい。

Feature #18560: Show issues with custom field of type Version as related issues in the Roadmap - Redmine

もし実現するとなると、マイルストーンとバージョンを多対1にするなどの関係が必要になるだろう。
僕としては、バージョンとマイルストーンを同一視するというRedmineの運用はアジャイル開発とマッチしているので、実装不要と思う。

【2-2】他には、「長いテキスト」カスタムフィールドを2列化したい、とか、カスタムフィールドをグルーピングしたい、という改善要望。
たとえば、障害チケットはカスタムフィールドが多くなりがちなので、テキストエリアを広くしたり、配置を自由に変えたり、グルーピングして操作しやすいUIにしたい。

カスタムフィールドのレイアウト変更は、ViewCustomizeプラグインで個別で対応可能だが、Redmineの基本機能に盛り込んだ方が確かに使い勝手は上がるだろう。

【3】気づき #275: ui編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #1040: Global wiki - Redmine

Feature #2117: Alternative view for "Projects" page - Redmine

Feature #8417: per tracker configurable issue form layout with preview - Redmine

【3-1】「メインのホームページはグローバルなwikiでなければならないのでは」という改善要望が1番多い。
色んな権限を持つユーザで管理されていたとしても、Redmineを操作する時には、FAQサイトやユーザガイド、手順などをWikiにまとめておき、誰でも参照できるようにしておきたい。
そうすれば、Redmineの運用が楽になる。

小規模チームのRedmineなら、グローバルWikiは不要だが、数百人~数千人が使う場合、Redmineの権限が複雑になり、誰もがアクセスできるプロジェクトは作りにくくなる。
たとえば、社員だけ見れるWiki、パートナー社員も含めたユーザが見れるWikiなどのように、複雑に管理したくなってくる。

【3-2】2番目は、「プロジェクト」ページが使いにくい、という要望。
一般に、Redmineで複数のプロジェクトを作っていくことになり、数百~数千個作る場合もあるだろう。
すると、プロジェクト一覧ページにプロジェクトが大量に並んで表示されるが、非常に見づらい。

プロジェクト一覧ページのUIはもっと改善できる余地がある。
特に、PMOや経営層など、部署ごとに複数プロジェクトを横断して見たい場合、現状のプロジェクト一覧ページでは状況を把握しづらい。

3番目は、カスタムフィールドや基本フィールドの配置を自由に変更したい要望。

【4】気づき #277: カテゴリ未設定分 - Unofficial Redmine Cooking - redmine.tokyo

Feature #2897: Tagging in Redmine - Redmine

Feature #3995: Upgrade to "Files" module - Redmine

Feature #10121: Watchers - Add Group / Role - Redmine

【4-1】1番目に多いのは、タグ付け機能。

【4-2】2番目は、ファイル管理機能の強化。
チケットでは、チケットやWikiに添付されるファイルは、「ファイル」モジュールに表示され、"Related To:"というタイトルの列が追加されて、リンクされるようにする、という要望が届いている。
これは面白い。

Redmineのモジュールの中で、「文書」「ファイル」は最も使われていない機能の一つだろう。
「ファイル」にRedmineへアップロードされた添付ファイルの全リストが表示されるようになれば、添付ファイルを探したり、添付ファイルを管理するなどの操作もやりやすくなるだろう。

「文書」モジュールを拡張したプラグインとしては、DMSFプラグインが昔から知られていた。
RedmineへOffice文書をアップロードして、Redmine上でドキュメント管理ができるようになるプラグインだ。
このプラグインが必要になる状況は、ISO9000の監査やシステム監査などの場面で、Redmineに蓄積されたチケットだけでなく、障害や問合せ、是正対策などの文書もトレーサビリティを確保して、即座に必要な情報を取り出せるようにしたいからだ。

DMSF - Plugins - Redmine

danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

Redmine3.2でバージョン管理もできるドキュメント管理プラグイン「DMSF」 | 俺的備忘録 ?なんかいろいろ?

【4-3】3番目は、チケットのウォッチャーをユーザグループや役割などでも選択・検索できるようにしたい要望。
現場でRedmineを使っている人からは、ウォッチャーをもっと強化したい要望は多い。
彼らは、ウォッチャーをメールのCc代わりに使っているみたいだ。
Ver3.xに対応しているプラグインとして、下記があるみたい。

foton/redmine_watcher_groups

※追記:情報が錯綜しているので、まとめた。

QA #290: チケットのウォッチャーをユーザグループや役割などでも選択・検索できるようにしたい - Unofficial Redmine Cooking - redmine.tokyo

【5】以上のように見てみると、タグ付、カテゴリ継承、ファイル管理機能の強化、定期チケット自動作成など、日本人のRedmineユーザが欲しいと思っている機能は、世界中の開発者も同様に思っているように見える。

こういう埋もれたチケットを集計して発見してくれた、@y503Unavailableさんに感謝。

| | コメント (0)

2017/01/14

オープンソースのコミュニティの存在意義と知的財産権

OSSコミュニティの継続性の記事がとても素晴らしいので、自分の心の琴線に惹かれた部分だけ引用しておく。
以下、ラフなメモ書き。
特に主張はなし。

【参考】
OSSコミュニティの継続性

ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita

ゾンビOSSが危ない - [1]オープンソースソフトウエアにも寿命がある:ITpro

【1-1】(引用開始)
日経コンピュータがゾンビOSSと表現した記事を2014年に出している。
ここで根底にあるOSSに対する考え方は「無料で使えるソフトウェア資産」なのだと思う。
それを支える開発者コミュニティへの認知が欠落していて、そこには有用性を見出していないようだ。
(引用終了)

【1-2】(引用開始)
日本では開発者のコミュニティに直接参画しようという動きは少ないように思う。
また、「あるOSSプロジェクトを中心にゆるく連帯した開発者の集団が継続的に存在していること」は、市場における人材育成の点で非常の大きな効果があるという点は、あまり認識されていないように感じる。
(中略)

ソフトウェア技術者の人材流動性が非常に高い米国のような場所では、OSSプロジェクトを開発者資源として活用することで成果をあげている例が多い。
特にうまくOSSを活用しているのはAppleだ。
彼らは社内のビジネスに必要なソフトウェアを、OSSプロジェクトを支援することで得るという手法に長けている。

現在のmacOSの基盤になったRhapsodyが公開されたのは1997年のWWDCだった。Mach 3とFreeBSD 5系のコードを組み合わせてモノリシックカーネルにしたもので、ユーザランドのコンポーネントにもOSSが多く使われていた。現在もツールチェインとしてLLVM/Clangを使う、認証基盤としてHeimdal Kerberosを取り込むなど、開発に非常に大きな労力がかかる部分にOSSプロジェクトの成果を使っている。

また、彼らは単にコードを使うだけでなく、開発者コミュニティにいる開発者を雇用したり金銭的な援助を行なったりして、コミュニティを育てる努力を怠っていない。
OSSプロジェクトが持つソフトウェア資産だけでなく、開発者を資産として認識しているからだ。
差別化が必要な部分は社内で開発し、重要だが開発者コミュニティが存在するソフトウェアはそこに投資することで成果物を利用するという2つの方法のバランスをとって、開発を迅速に進めるとともにコストを低く抑えることに成功したわけだ。
(引用終了)

【1-3】(引用開始)
利用者のコミュニティの継続性は、開発者コミュニティに継続性が前提になっている。
開発者のコミュニティに継続性が欲しいなら、話は単純だ。何らかの形で支援すれば良い。少なくともOSSを理解している個人や企業は、みんなすでにそうしている。
「OSSプロジェクトのソフトウェア資産だけを使い、サポート会社にお金を払う」という関わり方は、開発者コミュニティの継続性に寄与しない。
(引用終了)

日本では、OSSを無料のソフトウェアとみなす考え方が強い。
だから、保守サポートを受けたければ、サポートのある会社に有償でお願いしたほうが安全だ、という方向へ行きやすい。
保守契約や請負契約を結べば、リスクを業者に転嫁できるから。

一方、AppleがOSSとOSSコミュニティを上手く利用している、という意見はとても参考になる。
OSSは単なる無料のツールではなく、優秀な開発者資源の集まりである、という考え方がある。
OSSコミュニティにいる優秀な開発者は、重要な資産なのだ。

コミッタを雇用することで、優秀な開発者を自社に取り込むこともできる。
コミッタを金銭的に援助することで、OSSのツールの継続性を後押しできる。

一点気になるのは、ベンダーという営利企業のステークホルダーがOSSコミュニティに関わることで、OSSの発展の方向性がベンダーの意のままになるリスクは無いのか、という点だ。
詳細は知らないが、Linuxのように、多数のベンダーが入り込んでいるOSSでは、そのようなリスクをどのように排除して、Linuxを発展させようとしているのか、調べてみたい。

【2】オープンソースに関わる内容として、もう一つ気になる点は、知的財産権との絡みだ。
オープンソースのライセンスはGNUが有名でよく使われている。
すると、営利企業のソースライセンスとオープンソースのライセンスの違いが気になってくる。

この辺りの情報もまとめたい。

【3】IT技術者にとって、オープンソースのコミュニティに関わるメリットは、とても大きいと感じている。
製造業の技術者に比べると、IT技術者は、アイデアや成果物の利用について、とても自由度が高い。
その分、活発な活動が行われている、と感じる。

技術士として、他の製造業の話を聞くと、メーカーの技術者は自分の能力をアピールする場が少ないと感じる。
彼らは、論文発表するか、特許や意匠、商標などの知的財産権を取得するか、どちらかを採用している。

特許を取れば、普通は職務発明になるから、会社が専用実施権を持つ場合が多いように見える。
会社の戦略としては、ライセンス戦略になる。
つまり、自分たちの技術を他者が使う場合、ライセンス供与によってライセンス料を得るわけだ。

メーカー技術者は、代わりに「相当の利益」として、金銭やストックオプションとか、他のもので代用する。
しかし、それは嬉しいのだろうか?
自分のアイデア、自分が作った成果物と実質上は言えるが、外向けには会社の知的財産権であり、公の場で詳細な技術の議論はしにくいはずだ。
その代わりに、学会で論文発表することで、意見交換しているみたい。

一方、特許ではなく営業秘密として技術を保持するとなると、公開不可になる。
不正競争防止法で規制される対象になる。
すると、自分のアイデア、自分の成果物を世の中に公表することすら認められない。
会社の戦略としては、いわゆるブラックボックス戦略を取るわけだ。
たとえば、コカ・コーラ、天一など。

技術者にとって、お金も重要だろうが、むしろ、自分のアイデアを世に出して、色んな人達のフィードバックを得たり、技術者と知的議論をしていく方が重要だ、と思うはずだ。
そうでなければ、一発ものの技術で終わってしまうから。

でも、メーカーの技術者は、特許や営業秘密というツールで自分のアイデアや成果物が縛られやすい。
何となく可哀想な気もする。

一方、IT技術者はオープンソースで、自分の成果物を公開することで、他ユーザのフィードバックを得たり、他の技術者からプルリクエストで改善要望をもらえたり、自分の能力をアピールできたりする。
つまり、IT技術者はかなり自由だ。
むしろ、自分の成果物をクローズドにするのはあまり価値がない。
沢山の人に知ってもらい、使ってもらう方が価値が上がる。

「GitHubでソーシャルコーディング」という言葉は、たぶんそんな意味が込められていると思う。

すると、会社の経営戦略としては、プラットフォーム戦略になる。
つまり、ネットワークの経済の概念。
たくさんの人に使ってもらうことで、自分たちの技術をデファクトスタンダード化し、マーケットシェアを上げる。

その戦略を取り続ける場合、Appleの話のように、企業はOSSコミュニティを支援する場合が多くなるのだろう。
OSSコミュニティは、OSS利用者の多いマーケットだけでなく、優秀な開発者という資源がある場所、と捉えるわけだ。
それによって、OSSが長持ちする。

その場合、コミュニティの活発度がOSSが生きている証になる。
普通、ソフトウェアの活発度合いは、バージョンアップの頻度として現れる。
バージョンアップされないソフトウェアは死んだも同じだ。

数多くの利用ユーザのフィードバック、優秀な開発者によるセキュリティパッチや機能改善パッチの迅速なマージなどで、OSSソフトウェアは進化していく。

【4】そんなことを考えてしまったのは、Redmineもそういう意見がチラホラ見受けられるからだ。
Redmineコミュニティもちょっとずつ変わろうとしているのかもしれない。

akipiiさんのツイート: "Mischa The Evilのコメントを読むと、僕も同じような意識を持っている。Redmineはもはや単なる無料のツールではなく、OSSのコミュニティとして大きな影響力を持ち始めている。だからこそ永続的な開発の基盤を求めている。https://t.co/0wmfbPNu4V"

| | コメント (0)

2017/01/08

「ワーク・ルールズ」の感想

Googleの人事施策に関する本「ワーク・ルールズ」が面白かったので、感想をメモ。
ラフなメモ書き。
書きなぐりなので論理的整合性は無視。

【1】Googleという世界で一番優れたIT企業の人事施策はすごく興味はある。
博士課程ばかりの出身のプログラマが多くて、大学の研究室のような雰囲気で、仕事はプログラミングに没頭できる環境。
そういう人と環境がいる場所で、業績管理や報酬制度、動機付けはどのようにコントロールされているのか?

Googleが他の企業と比べて面白い点は、自社の人事施策においても、アンケートなどのデータを収集し、検定や相関関係を調べることで因果律を見出し、その結果を次の人事施策に反映して、どんどん改善している点だ。
実際に、本の中にも、報酬の数値、相関関係の数値などもあり、非常に興味がそそられる。

僕が興味を持った部分は第7章の業績評価制度、第8章の能力評価制度、第10章の報酬制度、そして第13章。

特に第13章では、高潔であろうと思われるGoogle社員ですらも、無料カフェテリアが既得権益と見なされて、醜い行動をする社員もいる、という事実をはっきり書いている所は、非常に真摯に感じた。

知的に優れている人であっても、無料カフェテリアが当たり前の権利になってしまうと、食べ物を容器に詰めて持ち帰ったり、土曜日のハイキングのために水のボトルやお菓子を大量にバックパックに詰め込んだりする行動を取る人もいる。
もちろん、その後、社内にその状況がフィードバックされて、問題も解消されたらしいが、そういう話を読んで、逆に、Google社員も人の子なのだ、と改めて、ホッと感じる。

当たり前の権利は、知的に優れている人も慣れてしまって、既得権益となり、逆に発展の阻害要因になる。

【2】業績管理と人材育成は明確に分ける。
業績によって昇進や昇給を提示する時期、その人のスキル向上やOJTなどを計画・評価する時期は明確に分ける。
昇進や昇給を約束する外発的動機を導入すると、学ぶ意志や能力が低下してしまうから。

これは、ハーズバーグの衛生要因・動機づけ要因を思い出させる。

チームには2個の尻尾(テール)がある。
ごく一部の優れた最高の社員であるトップテール、最低の社員であるボトムテール。
人間の能力の分布は、正規分布ではなく、「べき分布」で考えるべきだ。

普通の企業は正規分布を使って社員を管理する。
現実の個人別成績は正規分布とみなす。
すると、ほとんどの社員は平均に分類されてしまう。

しかし、実際は、組織で人が発揮するパフォーマンスは、べき分布になる。
ごく一部の優れた優秀な社員が、圧倒的な業績を上げることで影響力を行使する。

但し、べき分布は、正規分布の一種。
正規分布が古いというわけではない。

【3】プロジェクトにマネージャは必要か?
Googleでは、良いマネージャであっても、技術面に疎すぎる中高年の応募者を落とすことが多かったらしい。

しかし、良いマネージャは重要である、と。
そして、その職務特性は8つあった。
そして、チェックリストを作ったり、育成プログラムを作ったりした、と。

【4】googleで面白いのは、人事施策の良し悪しを自社のアンケート結果を元に統計処理して、その相関関係などを調査分析している点だ。
「世界中の情報を整理する」ミッションを自社の人事施策にも生かしている。

この本に書かれている内容が貴重であると思うのは、まさにその実験データと結果が記載されているからだ。
ここまで赤裸々に書いた本はないはず。

学習する組織、最高の人材を集める、など、それらのやり方を逐一実施した内容を全て統計処理している。
その分析と改善策が面白い。

もちろん、彼らは、統計データがアンケートという質問形式に依存しているために、バイアスがかかっていないか、相当気にして対処している。


| | コメント (0)

« 2016年12月 | トップページ | 2017年2月 »