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/28

チケット駆動の罠~複雑さはチケットの粒度に関連している

チケット駆動の罠の記事をメモ。

【参考】
JIRAに死を | TechCrunch Japan

(引用開始)
ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。
ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。
JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。
ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。
(引用終了)

tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex via @jptechcrunch"

akipiiさんのツイート: "チケット駆動の罠か。なるほど。RT @arichika: 派手なタイトルの割にちゃんと読めば、チケット駆動が陥りやすいミスが書かれていると思う。プロダクト・サービスの全体像が見えにくくなる、という事。... https://t.co/TB8O1uTEA6"

宮乃ぺこ@木曜東ア34bさんのツイート: "JIRAに関してというより、システム全体をみようねって話 JIRAに死を | TechCrunch Japan https://t.co/Nk3mms8Ryg @jptechcrunchから"

Takeo Hashimotoさんのツイート: "煽りタイトル良くない。そのようにデザインされていない道具をそのようにデザインされていない目的に無理やり当てはめようとしてもうまくいかないのは、ある意味当たり前。原文見たら本当に death って書いてあって呆れた。/ JIRAに死を https://t.co/iEXy4qUFUm"

Mass Kanekoさんのツイート: "「ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。」 少なくともAtlassianはそれを推奨していないのでは。 JIRAに死を | TechCrunch Japan https://t.co/YfCfN4F9GW"

akipiiさんのツイート: "Redmineのチケットも同じ。「デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

akipiiさんのツイート: "「ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元するという考え方」「ソフトウェアプロジェクトをチケットの集合で表すという考え方」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

Takafumi Ikedaさんのツイート: "分かるよ。優れた要求仕様はエッセイのようになってるべきだと思う。ジョエルスポルスキーが言うみたいに。でもそうするといつ出来上がるのか予想できないプロジェクトになりやすいけど。経験上。 / “JIRAに死を | TechCrunc…” https://t.co/vzLYSENUZB"

Yamamoto hiroyukiさんのツイート: "ストーリーやタスクは完成しているかしていないかのいずれかと考えるのはアジャイルマネジメントのベストプラクティスだ。著者はそれに異論があるようだ。 | TechCrunch Japan https://t.co/9LjDHX09fI"

【感想】
Redmineのチケット機能はとても優秀だと思う。
理由は、チケット構造をツリー上に展開できるおかげで、WBSやタスクカードなどのような構造をチケットの関連として実現できるからだ。
WBSをチケットに一度登録できれば、ガントチャートであれ、ロードマップであれ、サマリであれ、好きなようにチケット集計のビューで色んな角度で分析できる。

しかし、チケット管理をやりすぎると、思ったほどの効果が出ない場合がある。
@arclampさんが以前、下記の記事を記載されていたのを思い出す。

チケット駆動開発で作業管理はしないほうがいい - arclamp

また、第11回東京Redmine勉強会のアンケート結果でも、「全てチケット化するのは非経済となるシーンもある点です」という声もあった。
たぶん、数多くの人たちが試行錯誤しながら、Redmineのチケット管理の可能性を試している。

個人的には、上記の記事のような指摘から発生する問題の根本には、チケットの粒度があると直感する。
WBSであれ、ソフトウェアやマスタの構造であれ、さほど複雑でなければ、少ないチケットの枚数で表現できる。
チケットの枚数が少ないならば、外部環境からの影響でチケットの構造に変化が発生したとしても、その修正コストはさほど大きくないし、受け入れられる。

しかし、WBSやソフトウェアの構造が複雑になり、チケットの枚数が非常に多くなれば、その構造を実現して、最新の現状と連動させるように同期し続けるのは非常にコストが大きくなる。
チケット保守のコストが大きくなってくるからだ。

ソフトウェア設計では、ソフトウェアの複雑さを複数のレイヤーで分割し、粒度や抽象度を上げることで、その複雑さを軽減しようとする。
チケット管理でも、チケットの親子関係や親子プロジェクト、バージョンなどの機能によって、大量のチケットをレイヤーで分割して、枚数を制限することで、チケット管理の保守コストを受け入れ可能なレベルまで落とす。

つまり、チケット管理が駄目なのではなく、複雑さをどのように手なづけるか、ということが本来の問題なのだと思う。
それは、ソフトウェア工学の古くからの問題であり、あちこちの場面で出てくる。

但し、Redmineのチケット管理では、複雑さを軽減するためのレイヤーとなる機能が限られている。
たとえば、親子チケット、関連チケット、親子プロジェクト、バージョン、カテゴリなどしかない。
それらの機能を増やした方が良いのか、それとも、それらの機能の使い方をもっと工夫すべきなのか。

今の僕の考えは、Redmineの既存の機能を使って、チケット管理の可能性をもっと研究してみたい。
まだまだ色んな可能性を秘めているはずだ、と思う。

| | コメント (0)

2016/12/23

Windows上でJRuby9+Redmine3.3.1を構築した時のメモ

Windows上でJRuby9+Redmine3.3をインストールした時のメモを残す。
自分用の参照。

【環境】
jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) 64-Bit Server VM 25.10
2-b14 on 1.8.0_102-b14 +jit [mswin32-x86_64]

Windows7+XAMPP

Redmine 3.3.1

【参考】
RedmineInstall - Redmine

Redmine本家の説明では「Redmine does not support JRuby because some gems do not support Rails 4.2」と記載されているので、Own your Riskということで。

【インストール】
C:\xampp\mysql\bin\mysql.exe -uroot -p
create database redmine331 character set utf8;

show databases;

cd redmineのルートディレクトリ

jgem install bundler --no-rdoc --no-ri

jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install activerecord-jdbcpostgresql-adapter

jruby -S bundle install --without test development sqlite3

jruby -S bundle exec rake generate_secret_token

jruby -S rake db:migrate RAILS_ENV=production

jruby -S bundle exec rake redmine:load_default_data REDMINE_LANG=ja RAILS_ENV=production

jruby bin/rails server webrick -e production

adminでログイン

環境は以下の通り。

Environment:
Redmine version 3.3.1.stable
Ruby version 2.3.1-p0 (2016-11-09) [java]
Rails version 4.2.7.1
Environment production
Database adapter MySQL
SCM:
Filesystem
Redmine plugins:
no plugin installed

個人のPCで使う場合は特に問題無さそう。
画面は通常に遷移できる。
但し、ログを見ると、Warningが数多く出ている。

Redmine3.3.1を構築したかったのは、DMSFプラグインを入れて、RedmineでISO9001のような運用が可能かどうか考えてみたかったから。

DMSF - Plugins - Redmine

danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

また後で色々書く。

| | コメント (0)

2016/12/18

Pythonの記事のリンク~道具が理論にようやく追いついてきた

最近のバズワード「ビッグデータ」「機械学習」が知りたくて、Pythonの記事のリンクをメモ。
自分用の参照記事。
ラフなメモ書き。

【参考1】
Pythonでプログラミングを始めよう:新刊ピックアップ|技術評論社

(引用開始)
「もしコンピュータ言語をひとつも知らないのなら,まずPythonを学ぶことを勧める」。これは『How to become a hacker』(Eric S. Raymond著)の一節です。なぜ,Pythonを勧めるのか,それには様々な理由がありますが,筆者の経験や,世の中の動向を踏まえて説明してみます。
(中略)
工学系のエンジニアにとっても,プログラミングのスキルは設計作業に必要不可欠です。筆者もメーカーに勤務するエンジニアですが,入社以来様々な言語を使ってきました。シェルスクリプト,sed,Perl,C言語,C++,MATLAB/Simulink,Octave,Scilab,Mathematicaなど,作業内容に応じて使い分けています。テキストデータの整形をsedで行ったのち,C言語のプログラムから読み込んで処理し,その結果をMATLABで解析・可視化する,といった具合です。
(中略)
このような状況を変えつつあるのがPythonです。Pythonは,テキストデータの整形も,数値計算とその結果の可視化も得意です。すべての作業でPythonを使えば事足りる,という場面が多いのです。そのため,Pythonを使って設計をする機会が,日増しに増えています。

また,エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです。その点,MATLABのような有償のソフトを使うと,ライブラリのソースコードが公開されていないことが問題になる場合があります。Pythonと,Pythonの主要なライブラリの場合は,ほとんどがオープンソースプロジェクトです。そのため,すべてを自分のコントロール下に置いて,開発を進めることが可能です。
(引用終了)

(引用開始)
ディープ・ラーニングとビッグデータ解析での活用

次に,Pythonが実際に活用されている場面を見ていきます。

AlphaGoの快挙を支えたPython
ぶつからない車もPython!?
ビッグデータ解析でもPython
(引用終了)

【感想1】
R言語を色々触ってみたが、何か使いづらい。
たぶん関数型言語の特有の考え方に僕が慣れていなからだろう。
Pythonなら、RubyやJavaにも似ているので書きやすそう。

データの統計処理だけでなく、ファイル読み込み、グラフ表示、正規表現も一つの言語で処理できるのは便利。
プログラミングは歴史や英語のような暗記は不要だけど、APIの使い方とかテクニックは最終的には覚えるしか無い部分がある。

「エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです」という指摘は同意する。
「すべてを自分のコントロール下に置いて,開発を進める」ことが重要だから。
自分が使っている道具の特徴、癖を知っておかないと、自分が解決したい問題に適用する時に、落とし穴に落ちる時があるから。

道具の制約が、問題解決の可能性を制限する。
道具の制約が、問題解決の発想、アイデアの範囲や質を制限するから。

【参考2】
akipiiさんのツイート: "「断片的な情報を地図にまとめて大局的な視点を持つ」「人に何かやって貰いたい時は具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがストーリーに織り込まれています。ルビィのぼうけんhttps://t.co/OaZHqw2E0w"

ルビィのぼうけん」のAmazon書評コメント欄に、下記のコメントがあってすごく納得した。

Amazon.co.jp: ルビィのぼうけん こんにちは! プログラミングの deko-papaさんのレビュー

(引用開始)
翔泳社の特設サイトで見つけて、帰宅途中で書店にて購入。10歳の娘に買って読ませてみました。
 夢中になって読んで、あっという間に前半のストーリー部分は読破。後半の練習問題は、夜遅かったので翌日へ。さらに寝るまでお母さんに読み聞かせを強請っていました。

 私はさわりの部分しかまだ読んでいませんが、それでも「断片的な情報を『地図』にまとめて、大局的な視点を持つ」「人に何かやって貰いたい時は、具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがさりげなくストーリーに織り込まれているのが分かります。

 さらに、絵の中にさらっとプログラミング言語のキーワードが描かれています。もちろんそれについての説明は一切ありませんが、将来プログラミングに触れたとき、「あ!見たことある!」とこの絵を思い出す子どもが大勢いることでしょう。
(引用終了)

【感想2】
「プログラミングは実現したいことの手段に過ぎない」意見もあるが、僕はむしろ、プログラミングという道具が思考方法を規定してしまう側面の方を強く感じる。
既に確立した理論はあり、その理論の内容を実現したいのに、プログラミング言語やそのライブラリが貧弱であれば、やりたいことを表現するのにすごく手間がかかって、イライラしてしまう。

たとえば、配列やハッシュにデータを一時的に退避するとか、ファイルを読み込んで文字列を正規表現でマッチする部分を抽出するとか、そういうコンピュータの基盤に近い部分の処理は手短に書きたい。
そして、理論が本来言いたい部分をプログラミング言語で的確に表現したいのだ。

プログラミングにおいて、「断片的な情報を地図にまとめて大局的な視点を持つ」考え方は、理論で本来実現したい結果を得るための登山ルートを詳細に具体化する能力に対応するのではないか。
「今あるものを工夫して新しい道具を作り出す」考え方は、プログラミング言語とライブラリという「道具」で工夫して、理論で実現したい結果を得るためのアルゴリズムを作りだすのに使う、ことに相当するのではないか。

つまり、今ある道具を工夫する手間が少ないほど、コンピュータレベルではなく、もっと高次のレベルで物事を思考することが容易になるはず。

たとえば、統計学の理論は基礎数学で確立しているけれど、経済学者や心理学者は「大数の法則」「中心極限定理」「正規分布」などの定理や概念を数学的に証明するのに使いたいわけではない。
それらの定理や概念という道具を使って、経済現象や人間の心理現象を分析して、問題を解決したり、新たな観点をもたらしたいのだ。
昔は計算能力が貧弱だったので、統計処理はいかに簡便な手計算でやるか、という技術の説明をする本ばかりだったけれど、今は、優れたプログラミング言語やライブラリは揃っているから、計算処理はコンピュータに任せることが楽になった。

すると、理論がどのプログラミングのモデルに適用できるか、理論をどのプログラミングのモデルに適用すると手短にたどり着けるか、という考え方に発展するだろう。
つまり、問題のレベルが、単にプログラムが書ける、というレベルではなく、プログラムが表現するモデルが理論や現象を上手く説明できているか、というレベルに上がるだろう。
そこが面白くなってくる。

【参考3】
いまさら聞けないDeep Learning超入門(1):ニューラルネットワーク、Deep Learning、Convolutional Neural Netの基礎知識と活用例、主なDeep Learningフレームワーク6選 (1/2) - @IT

(引用開始)
 筆者がデータ解析に従事し始めた2010年ごろ、Deep Learningという言葉は一部のアカデミックな分野では流行していましたが、ユーザー企業でその言葉を聞くことはあまりありませんでした。

 今あらためて、Deep Learningの歴史をひも解いてみると、その歴史は決して明るいものではなかったことが分かります。Deep Learningの構成要素である、ニューラルネットワークとそれを単純に多層に組み合わせたものに関しては、それこそ1980~1990年代前後から盛んに研究されていました。しかし、その精度や処理量の問題から、同じく分類推定モデル構築によく利用される機械学習ロジックである「ベイジアンネットワーク」「サポートベクターマシン」の裏に隠れてしまい、冬の時代が長く続くことになったのです。

 再び脚光を浴びるようになったのは2000年代に入ってから。2006年にDeep Learningが発表され、その後2012年にトロント大学のHinton氏が「ImageNet」と呼ばれる画像セットを用いた画像識別コンペティションでDeep Learningを用いて2位以下を大きく引き離す精度を記録したことがきっかけです。このあたりからグーグルをはじめ、マイクロソフトやフェイスブックなどが注目し、ビッグデータのブームやGPUサーバーなどのハードウエア面の進化も伴ってDeep Learningは広くデータ解析者に広がっていきました。

 Deep Learningの最大のウリは何といっても、「人手で特徴量を抽出する必要がない」という点です。
(引用終了)

深層学習(ディープラーニング)を素人向けに解説(前編)―基礎となるニューラルネットワークについて

(引用開始)
ディープラーニングとは、適切な特徴抽出能力を持つ教師なしニューラルネットワークを多層にして構築したものです。
(中略)
まず、ディープラーニングを理解するためには、ニューラルネットワークを理解しなければなりません。逆に、ニューラルネットワークを理解してしまえば、ディープラーニングの概要自体はかなり分かりやすくなります。

ニューラルネットワークと言うのは、人の神経を模したネットワーク構造のことです。それを踏まえて、そう言う構造を持った人工知能のこともそう呼びます。このニューラルネットワークでは、神経細胞を模したパーセプトロンと言う小さな計算機をたくさん用意し、一つの計算を協力して行わせるように作られています。
(引用終了)

【感想3】
最近、囲碁でコンピュータが人間に勝ったニュースが流れたが、Deep Learningのアルゴリズムはニューラルネットワークであることは初めて知った。
30年以上前にニューラルネットワークは流行したけど、なかなか実用に至らなかった、という話は随分聞いた。
僕は、Deep Learningのアルゴリズムはベイズ統計かなと思っていたので、意外だった。

そんな話を聞くと、昔に確立した理論が、ようやく時代に追いついて花開いた、と感じる。
今ようやく、プログラミング言語の科学技術ライブラリ、統計処理ライブラリ、クラウドなどの開発基盤がそろってきたから、ニューラルネットワークのような理論が実際にプログラム上で実現できたわけだ。

ニューラルネットワークの理論は僕も詳細は知らないけど、古くから研究されて確立している理論なので、その理論をバックにした技術はそう簡単には廃れないだろうと直感する。
今後も、たくさんの応用用途も見つかるだろう。

実際、Deep Learningは、車の自動運転、顔認証システムなどにも使われている。
アイデアさえあれば、もっといろんなことが出来るはず。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

【感想4】
僕は「新しいアイデアとは、古いアイデアを新しい場所に置いたアイデアのこと」という言葉が好き。
既に知られた理論や知見(例:統計学、ニューラルネットワーク)は、新しい場所(例:人工知能、深層学習、自動運転、顔認証)で使われると、新たな発見を呼び起こす。
そういうことをやってみたい。

| | コメント (0)

«WindowsのRubyのバージョン管理はuruを使う