コミュニティ

2017/12/09

日本のRedmineコミュニティの活動報告と今後の抱負

Redmine Advent Calendar 2017 - Qiitaに初参加です。
日本のRedmineコミュニティの活動報告と今後の抱負を書きます。

私が書くのは恐れ多いと思いますが、改めて、Redmine大阪スタッフとredmine.tokyoスタッフの皆さんに大変感謝です。

【参考】 Redmine Advent Calendar 2017 - Qiita

【1】日本のRedmineコミュニティ

現在活動中の日本のRedmineコミュニティは、Redmine大阪とredmine.tokyoの二つがあります。
Redmineは誕生して11年も経ちますが、どちらのRedmineコミュニティも2011年に創立されたので割と浅いです。

Redmineの9年間の歩みを振り返ってみる

Redmine 10周年記念 10年ふりかえり

私はその二つのコミュニティでスタッフとして関わっているので、その立場から生い立ちとその歴史を簡単に振り返ります。

【2】Redmine大阪

Redmine大阪 - connpass

RxTstudy

過去のイベント - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【2-1】勉強会の発端は、2011年6月に、@pinkmacさんが「【緩募】関西でRedmineをタスク管理に使いたい勉強会を開催したら参加/発表してみたいという方!」というTwitterが流れたことです。
あっという間にスタッフや講演者、参加者が集まり、「RxTStudy~Redmineとタスクマネジメントに関する勉強会」というコミュニティとして発足しました。
「RxTStudy」は「Redmineとタスクマネジメント(Task)に関する勉強会(Study)」という意味です。

その後、Redmineが日本で知名度が上がる中、「RxTStudy」という名前では分かりにくいという声があったため、2016年に地域名を付けた「Redmine大阪」にコミュニティ名を変更して、今に至っています。

【2-2】第1回目の経緯は下記に書いています。

【告知】Redmineでのタスク管理を考える勉強会@大阪で発表します #RxTstudy: プログラマの思索

記念の1回目の勉強会は、その頃にRedmine本を出版した前田剛さん、倉貫さん、阪井さんと僕が講演したこともあって、定員50人があっという間に埋まり、当日の模様がUStreamで中継されてたいへん盛り上がったことを覚えています。
また、僕が講演した内容「RedmineのFAQとアンチパターン集」は、当時はすごく反響が大きかったことを覚えてます。

それから、最近は年2回ペースで開催され、現在は17回まで続いています。

【2-3】勉強会の内容は、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)@daipresentsさんの「チームにRedmineを適用せよ! #RxTstudy」では、楽天における1000人という当時は大規模なRedmine利用事例でした。

(2)@akahane92さんの「情報システム部門のタスク管理とIT全般統制 ~ Excel管理からの脱却 ~ (ITS Redmine #RxTstudy #5)」では、島津製作所の基幹系業務システムのタスク管理とIT全般統制にRedmineを導入して運用して効果を上げている事例でした。
その後、JaSSTやSQIPなどでも講演されて一躍有名になりましたね。

(3)陸野さんの「Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用」では、パナソニックにおける組込みソフトウェア開発にRedmineを導入運用した事例でした。
従来まで数多くのプロジェクト管理のパッケージ製品を導入してきたけれど、パッケージ製品には販売元の会社のプロセスが埋め込まれていて、自分たちの組織に合わない、という指摘に改めて刺激を受けたことを思い出します。

(4)JAXAの藤田さんの「JAXAスパコン"JSS2"の運用を支えるチケット管理システム"CODA"」では、JAXAスーパーコンピュータ活用課にて、業務の管理にRedmineを利用している事例でした。
実際のRemdine画面を見ることができて大変貴重でした。

(5)@ktouさんの「全文検索でRedmineをさらに活用!」では、Redmineの全文検索の機能強化と今後の可能性に関する事例でした。
Redmineに機械学習や人工知能などの技術を組み込むと、新たな可能性が広がる、というワクワク感が満載でした。

【3】redmine.tokyo

概要 - redmine.tokyo

【3-1】勉強会の発端は、僕がちょうど東京にいた頃、東京にいる熱心なRedmineユーザが集まって、勉強会を開こう、という話があがったことでした。
2011年当時は、@nobiinu_andさん曰く「東のTrac、西のRedmine」と言われるぐらい、東京ではTracコミュニティが活発だったので、Redmineもコミュニティが欲しいなあ、という雰囲気があったためです。

Shibuya.trac Wiki - Shibuya.trac - OSDN

nobiinu_andさんのツイート: "ですね! USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会@大阪で議論できると思います。http://t.co/X2o1jPF #RxTstudy"

たしか、キックオフ飲み会が暑い8月に行われた時、当時はRedmineで唯一の日本人コミッタである@marutosijpさんも来られて、Redmineを話題に盛り上がったのを思い出します。

記念の第1回目の勉強会は、IPAで場所をお借りして開催されました。
第1回目の内容は、下記に書いています。

【告知】第1回品川Redmine勉強会を開催します #47redmine: プログラマの思索

当初は「品川Redmine」という名称でしたが、参加者から限定的なコミュニティのイメージを持たれることもあり、2014年から地域名を付けた「redmine.tokyo」にコミュニティ名を変更して、今に至っています。

それから、ほぼ年2回ペースで開催され、現在は13回まで続いています。

【3-2】勉強会の内容は主に、講演が数本、ライトニングトークスやグループディスカッションです。

redmine.tokyoの最大の特徴は、参加者がすごく多い点でしょう。
@naitohさんがまとめてくれているアンケート資料「Redmine.tokyo 13 questionnaire」を見ると、過去は参加者が100名超えの時もありました。
よって、いつも大変盛り上がっているのが印象的です。

また、@tkusukawaさんたちがボランティアで、UstreamやYoutubeで講演をリアル放映してくれています。
そのおかげで、いつも満員御礼になっているにも関わらず、参加できなかった人や東京以外の地方のRedmineユーザも視聴できます。
いつもありがとうございます。

【3-3】勉強会の内容はRedmine大阪と同じく、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)Takashi Okamotoさんの講演「RedmineとGitとスクラム」では、当時最新の使い方であったRedmineとGit連携の事例でした。

(2)@akahane92さんの講演「Redmineチューニングの実際と限界 - Redmine performance tuning」では、100万チケットでも耐えれるRedmineのチューニングノウハウの紹介でした。

(3)@netazoneさんの講演「ある工場のRedmine +(Plus)」では、製造業におけるRedmineの運用事例でした。
当時の環境では、プラグインが23個もあるのが驚異的でした。

(4)@onozatyさんの講演「View customize pluginを使いこなす」では、View customize pluginによるRedmineのカスタマイズ事例でした。
この発表後、View customize pluginの利用が広まったように思います。

(5)@kazuphさんの講演「IoT企業とRedmine // Speaker Deck」では、IOT企業のハード製造部門とソフト開発部門、サポートデスクの3部門におけるRedmine利用事例でした。
かんばんとガントチャートを使い分けている点が興味深ったです。

(6)JAXA木元さんの講演「CODAの定義・運用の現在 - 2017年版 -」では、JAXAにおけるRedmineのノウハウを惜しみなく公開した事例でした。

【4】参加している人たち

【4-1】参加者は、実際にRedmineを使ってプロジェクト運営しているSIのプロジェクトリーダー、Remdineのパッチを作ったりプラグインを開発する人達、SIでRedmineのサーバーのインフラを管理する人、などが多いです。
さらに、参加者層を分析すると、開発プロセスに興味がある人たちだけでなく、Redmineのパッチを作ったり、プラグイン開発者が割と多いことが特徴的だろうと思います。

つまり、素のRedmineを運用してみて不足している機能はプラグインで開発して、それをGithubで公開されている人が多いように感じます。
たとえば、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちです。
また、@naitohさんのように、PDFの日本語化Gemを開発して貢献されている方もいます。

【4-2】Redmineコミュニティに携わるスタッフの立場では、プロジェクト管理や開発プロセスに興味を持つ人たちだけでなく、Redmineの機能強化につながるプラグイン開発者は非常に重要と思います。
なぜなら、Redmineの不足機能をプラグインで代替できるようにオープンソースで提供してくれているからです。

そのおかげで、ユーザはRedmineを自社の組織文化に合わせてカスタマイズすることが容易になります。
つまり、ユーザ自身が設計したプロセスへツールを合わせるように運用しやすくすることで、自然にプロセス改善の雰囲気がチーム内に発生し、チーム自身で問題解決していくという自律化の雰囲気を醸し出すメリットもあるのだろう、と感じるからです。

【4-3】最近は、勉強会の参加者層は幅広くなったように感じています。

グループディスカッションで聞いてみると、IT業界に限らず、製造業やゲーム業界、Webデザイン業界、など幅広い業界の人たちが参加しているようです。
また、Redmineを長年使っている人たちだけでなく、PMOや品質保証部に在籍する上層部の人や、興味があるから来てみたという初心者も増えているようです。

背景には、Redmineが日本でかなり知名度が上がり、実際に使われている場面が多くなっているからでしょう。
実際、日本国内におけるGoogleトレンドを見ると、現時点ではTracやJiraよりもRedmineが上位に上がるケースが多いようです。

Redmine 10周年記念 10年ふりかえり

【5】今後の抱負

Redmineコミュニティに携わるスタッフとして、今後の個人的な抱負は2つあります。

【5-1】一つ目は、Redmineコミュニティの参加者の多様化を図る事です。

Redmineが持つ特徴として、二つの側面があります。
まず、プロジェクト管理を柔軟に運用できるプロセス基盤または、ソフトウェア工学の理論を実験できるメトリクス収集・集計基盤であること。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

次に、汎用的なプロジェクト管理ツールの開発基盤であること。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

すなわち、Redmineの利用者層は、前者の観点では、プロジェクトリーダーやPMO、品質保証部のような立場でプロセスを構築し運用する人達である一方、後者の観点では、プラグインを開発したりRemdineをカスタマイズするRuby開発者という二つの側面があるのです。
そして、その両方に詳しい技能を持つ人は非常に少ないでしょう。

よって、全く異なる技能を持つ人達が集まることで、プロジェクト管理やソフトウェア工学で困っている問題がプラグインやカスタマイズで解決できたり、新たなプラグイン提供によってプロジェクト管理の新たな使い方が生み出されることもあるでしょう。
つまり、プラグイン開発者とプロセス管理者がお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展できるはずと考えます。

そういう化学反応、シナジー効果を提供する場を構築したいと考えてます。

【5-2】2つ目は、Redmineのエコシステムを作る事です。

日本の企業でRedmineがかなり普及している現在、Redmineは日本のSIにおける事実上の基幹業務システムではないか、と思います。
すると、Redmineは今後も安定的に機能改善されて保守されて欲しい。

幸いなことに、Redmineの歴史をたどると、自動テストが整備されたおかげで、RubyやRailsのバージョンアップにも追随しており、セキュリティパッチも早急に対処されています。
そのおかげで、Redmineの品質は割と高いのではないか、と思います。

Redmine build status

Redmine code coverage

また、性能面でも、Redmine大阪第17回勉強会に参加した - Basicに記載あるように「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」ように進化しています。

しかし、現在のRedmineのコミッタはJPLを含めて3人しかいない。

今後の夢としては、オープンソースの成功事例であるLinuxやRubyのような永続的なオープンソースとして確立して欲しい、と思っています。

たとえば、LinuxやRubyも当初は、開発者のおもちゃと見なされて、エンタープライズでは使えない、と思われた時期もありました。
しかし、コミュニティが発展してマーケットが広がっていくうちに、エンタープライズ界隈にも広がり、今ではむしろ、オープンソースで無いと保守され続けなくなるリスクがあるように見受けられます。
そして、LinuxやRubyも、コミッタと熱心なユーザだけでなく、ベンダーもユーザの一部として加わり、マーケットが拡大する方向へ成長している状況があります。

よって、RedmineもLinuxやRubyのように、コミッタ・ユーザ・ベンダーの三者が良好な関係を保ち、成長のらせん構造を昇っていけるような環境をいつか作りたい、と思っています。

| | コメント (0)

2017/11/19

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT

昨日の勉強会は参加者、スタッフの皆さん、お疲れ様でした。
あいにくの雨にもかかわらず、参加率が約90%で大変盛り上がりました。
楽しかった余韻が冷めないうちに、感想をラフなメモ書き。

【参考】
第13回勉強会 - redmine.tokyo

第13回勉強会 - redmine.tokyo ~『Redmineの今と未来』(2017/11/18) #redmineT - Togetterまとめ

redmine.tokyo 第13回勉強会 - connpass

“CODA” チケット管理システム | JSS2@JAXA

【1】数多くの参加者に感想を聞いた所、JAXA様の講演が聞きたかった、という話もあったが、LTも含めて運用事例からプラグイン開発などの技術、最新バージョンの紹介、ちょっとしたプラグインの利用事例、家庭内のRedmine利用事例など、幅広いテーマで面白かった、という話があった。
また、参加者層も初心者から10年近い利用者まで、年代層も20歳から40代まで幅広かった。

akipiiさんのツイート: "#redminet 今日も参加率90%で驚異的でした。利用事例から技術まで幅広いテーマで面白かったと言う声をたくさん聞けてスタッフ一同嬉しいです。参加者層も初心者より数年経験者の人が半数以上いた。Redmineコミュニティが今後も長続きできるといいなと思う。"

さらに、女子の参加が10名を超えたのも初めてではないかと思う。(正確に数えてない)

akipiiさんのツイート: "#redminet 今日の東京Redmine 勉強会は過去最高で女子率が高くて華やかだったと思う。以前、@agilekawabata さんが、Redmine はおっさんのツールだから若い人や女子は少ないんですよ、と言ってたが、時代が変わった?"

第7回Redmine.tokyoの感想 #redmineT: プログラマの思索

そんなことを振り返ると、多種多様な年齢層や女性という人口的変数、プロジェクトリーダーだけでなくSEPG等の品質保証部の人からプラグイン開発者までの心理的変数というセグメントが幅広くて、たくさんの化学反応があって面白かったと思う。
幅広い利用者が集まるコミュニティになれば、ある人はRedmineを使っているなら常識と思っていても、他の人にとっては新鮮な内容であることも多いだろうから、そういう数多くの議論が発生して、さらに理解が深まるだろうと思う。

たとえば、Redmineのそんな所でつまずくのか、という質問が、実はRedmineというツールではなく、プロセス保証やプロジェクトマネジメントの根本的な問題に触れていたり、とか。
僕も色々気づきがあった。

【2】JAXA様の利用事例で、興味深い点は二つある。

“CODA” チケット管理システム | JSS2@JAXA

【2-1】一つは、フローの管理とストックの管理を明確に別々に分けていること。

akipiiさんのツイート: "#redmineT JAXAでは、議事録はチケット、構成管理すべき文書は、文書管理機能、実際はDMSFプラグインで管理を区別してる。フローの管理はチケット管理、ストックの管理は構成管理ツールでなく文書管理プラグインで制御してる。全文検索プラグインで文書も全文検索できると、かなり良… https://t.co/AVf8WAHtsc"

Redmine本来の設計思想では、日々流れるフローのような管理対象はチケットにする。
タスク、かんばん、ISOの変更依頼書のように、作業指示書のようなレベルのものは、ステータス管理の方が重要だ。
つまり、日々のフローで管理する時、担当者とステータスに着目する。

一方、ストックのような管理対象は基本は、GitやSubversionのような構成管理ツール、あるいはWikiに蓄積する。
たとえば、ソースコードやExcel設計書は構成管理ツールの配下で履歴管理したり、技術や共有情報などのナレッジはWikiに蓄積する。
あるいは、チケットそのものを議事録にしたり、障害管理票のようにチケットに障害の発生原因や修正履歴を追記して、チケットそのものをナレッジにしてもいい。

Redmineのメリットは、フローとストックの管理を一つのツールで一元管理できるので、フローとストックの間で相互リンクを貼ることにより、トレーサビリティを実現できることだ。
よって、成果物から要件の発端まで前方追跡して変更理由を探したり、発端となった要件から成果物まで後方追跡して仕様変更の影響範囲を探る、といった使い方ができる。
この運用ルールが「No Ticket, No Commit」であり、他のプロジェクト管理ツールにないチケット管理ツール特有の最大の特徴でもある。

しかし、JAXA様の運用では、ストックの管理はRedmineの文書管理にDMSFプラグインを入れて活用されている。
この点がRedmine本来の設計思想と大きく異なる。

その理由を推測すると、成果物の対象がExcelであるため、構成管理ツールだけでは文書の変更の権限制御がやりにくい点があるのだろう。
そこで、DMSFプラグインを入れることで、Excel文書の変更履歴を残したり、Excel文書の参照・更新の細かな権限制御を付けることで、より使いやすくしているわけだ。

たとえば、外部委託したベンダーには特定のExcel文書は参照権限はあるが、更新権限は与えない、といった使い方をしたい場面があるのだろう。

【2-2】もう一つは、Redmineではボトムアップで運用ルールを柔軟に変更して、より良くしていく手法がある点。
Redmineは管理画面にあるワークフロー、ロール、トラッカー、カスタムフィールドを細かく制御できるので、運用しながら標準プロセスを固めていくことも可能だし、そういうやり方の方が普通なのではないか。

akipiiさんのツイート: "#redmineT Redmine の良さは、管理機能をフレキシブルに変更できる点。実際の運用は、かなり試行錯誤した、とのこと。プロセス標準化は一夜にしてならず、ですね"

akipiiさんのツイート: "#RedmineT 更新ロールと参照ロールに分ける。基本ワークフローは、全般トラッカーと名付けて、プロジェクトごとでカスタムフィールドを切り替えて利用する。つまり多様なプロジェクトの構造を管理画面の機能で制御するわけだ"

たとえば、Redmineの基本ロールは「PJ管理者」「開発者」「報告者」だけだが、実際に運用してくると、PJ管理者とシステム管理者の間のロールが欲しくなってくる。
その場合、「ロールのORルール」を用いて、「システム管理者でない管理者」のロールを新規作成し、各プロジェクトで各ユーザにそのロールを追加付与すればいい。
すると、既存のロールをいじることなく、既存ロールにパッチを当てる感じで、権限を細かく制御できるようになる。
たとえば、基本ロールと追加ロール、参照ロールと更新ロールのようにロールを細かく作っておけば、ロールのORルールを適用して、数多くのバリエーションで権限制御できるようになる。

すなわち、運用で試行錯誤しながら、ロールやワークフローを再定義したい時に、Redmineではパッチを当てる感じで既存の運用フローを修正していくことが可能なのだ。
こういう運用が可能な理由は、Redmineの管理画面の機能が豊富で柔軟であるからだろう。
換言すれば、Redmineの豊富で柔軟な機能をもっと理解しておけば、最初からトップダウンで完璧な運用を目指すのではなく、運用しながら標準プロセスを固めていく、といった、アジャイル的な発想を取り込めるはずだ。

僕はアジャイル開発が好きなので、ソース修正だけでなくプロセス構築にもアジャイル的なやり方を組み込むことは、実現不可能と思っていないし、むしろ、トップダウンでガチガチに固めてしまってメンバーのやる気を失わせるよりも、メンバーのより良い意見を取り入れながらチーム一丸でRedmineをより良く使いやすくしていくことは可能だと思っている。

【3】前田剛さん、堂端さんからRedmineの次期バージョン4.0に関する講演があり、興味深かった。

Redmineウォッチャーとしては、Railsの最新バージョンに追随する形でRedmineもどんどん最新化して欲しい。
性能面、セキュリティ面、今後の機能追加のしやすさ、を考慮すれば、開発基盤の最新バージョンに追随して欲しいから。
講演によれば、Ver4.0は早めにリリースしたい、とJPLが言っていた、とのこと。

Ver4.0で問題になってくるのは、既存プラグインがそのままでは、ほぼ使えなくなることだろう、とのこと。
Rails5に追随できるようにプラグインの修正が必ず発生する。
過去のRedmneのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古いRedmineはあらかじめVer3.4へVerUpしておくべきこと。
理由は、Rails5ではRuby2.2.1未満は切り捨てられるので、Ruby2.2.1に対応済みのVer3.4のRedmineで動作できるようにしておくと事前に検証できるから。

【4】他の講演も面白かった。
Redmineの利用が深まる中で、色んな問題意識があげられていて、興味深かった。

RedmineとSlackなどのコミュニケーションツールは、どのように使い分けた方がいいのか?

お子さんの宿題管理にRedmineを適用し、EVMや分析を行ったが結局使いこなせなかった、とのこと。
このLTも、普段のRedmineとは違う観点で面白い、という別の参加者の感想もあった。
個人的には、Redmineが使いこなせなかった理由には、Redmineが見れるPCをお父さん部屋しか置かず、子供の導線上で見える化しなかった点もあるのでは、と思った笑。

akipiiさんのツイート: "お母さんの反省点はRedmineが見れる端末を廊下と子供部屋に置くことかな笑。RT @agilekawabata: お母さんの反省会で導線が大事だったということで、JAXAの事例にもあったように、ホーム画面に担当者が必要となる導線を置くことはとてもいいと思う #redmineT"

【5】Redmineの面白さは、プロジェクトリーダーや品質保証部の観点でプロセスを自分で構築できて運用を試せる一方、プログラマの観点で不足機能をカスタマイズしたりプラグイン開発してより使いやすくできる、という両面があることだろうと思う。

すなわち、前者の観点では、Redmineは標準プロセスの運用基盤またはメトリクス収集・集計のプロセス基盤である一方、後者の観点では、Redmineはプロジェクト管理ツールの汎用的な開発基盤とみなせることだ。
つまり、ソフトウェア工学の観点とRuby開発の観点の両面からRedmineをいじくり倒せる点が、面白い点なのだろうと思う。
そして、その両方に詳しい人はほとんどいないので、Redmineコミュニティで多種多様な人達が集まることで色んなメリットが出てくる。

僕もRubyやRailsをちょっとずつ勉強しなくては、ね。。

他の資料はコチラ。

| | コメント (0)

2017/11/11

第13回東京Redmine勉強会の見所 #redmineT

@madowindaheadさんが第13回東京Redmine勉強会の見所を公開されていたので、自分も書いておく。
以下、ラフなメモ書き。

【参考】
第13回勉強会 - redmine.tokyo

門屋 浩文さんのツイート: "来週の第13回https://t.co/EeqCzge6c7の見どころ! #redmineT https://t.co/7T2RrBBjUb @madowindaheadさんから"

第13回redmine.tokyoの見どころ! | MadosanPlace 新しい風をプラス!

【1】今回のテーマは『Redmineの今と未来』。
スタッフと企画した時に、Redmineの運用や管理面の講演は現時点の話、次期バージョン4.0に伴う技術面の講演は未来の話だね、という意見が出て、このテーマに決まった。

【1-1】運用面の話は、見える化の話とJAXAの利用事例のお話。
Redmineのチケット集計結果を見える化する内容は、特に、プロジェクトリーダー層が興味を持つだろう。
彼らから改善要望として出てくる意見のほとんどが、このテーマに関わる内容だからだ。

また、JAXAのRedmine利用事例をようやく東京でも講演頂けるようになった。
昨年夏にRedmine大阪で講演して頂きましたが、その時の内容からブラッシュアップされている、とのこと。

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JAXAのRedmine利用事例で興味深いのは、Redmineの機能を論理モデルの観点で階層構造でモデル化していること、その分析内容を元に「ロールのORルール」「カスタムフィールドのANDルール」などのプラクティスを生み出して、利用プロジェクトの多様性をRedmineの機能で制御しようとしている点だ。

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

これは、アナリシスパターンにおける「知識レベル・操作レベル」に相当する、という指摘もあった。
その後、他にどのようなプラクティスを研究されているのか、楽しみ。

【1-2】Redmineの次期バージョン4.0では、Rails5に対応が予定されているので、アーキテクチャが大幅に変わることになる。
特に、既存のRedmineのプラグインは、現状のままでは全く動かなくなる、という指摘があった。

そこで、Rails5におけるプラグイン開発の内容、さらに初心者向けにRedmineプラグイン開発のお話も合わせて、アジャイルウェアの堂端さんに講演を依頼することになった。
日本では、OSSのプラグイン開発者が多いし、スタッフにもプラグイン開発者がいるので、直接的に役立つだろうと思う。

【1-3】LTでは、数多くの方に講演していただくことになった。

特に、ファーエンドテクノロジーの石川さんのお話が個人的に興味がある。
理由は、Redmine本家にガントチャートの改善パッチを送られているからだ。

Redmineのガントチャート改善パッチに注目している: プログラマの思索でも書いたけれど、Redmine標準のガントチャートは正直使いにくい。
チケットタイトル欄の枠を広げたい、担当者を表示したい、ガントチャート画面上で編集したい、などの改善要望は2010年頃からずっと、Redmine本家にも要望があがっていたのに、ずっと改善されて来なかった。
しかし、ようやく、石川さんがパッチを送ってくれて実現可能性が上がった。
今は、Ver4.1のターゲットバージョンで設定されている。

Redmineを改善するパッチを書いて、OSSへの貢献もする仕事 - ファーエンドテクノロジー株式会社

また、日本ではRedmineの利用度合いが高いのに、Redmine本家へのフィードバックが少ない状況に対し、石川さん他幾人から、Redmine本家へのパッチが最近あげられている。
まだ少ないけれど、利用ユーザだけでなく開発者として日本人も貢献できればいいな、と思う。
(自分もやらねば、ね。。)

| | コメント (0)

2017/10/14

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係

@t_wadaさんのBlogを読んでいたら、「プラグイン機構はソフトウェアの構造がコミュニティの構造に及ぼす事例に相当する」という重要な指摘があった。
考えたことをラフなメモ書き。

【参考】
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

akipiiさんのツイート: "「ソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方である」 https://t.co/07wYG0M7yf"

akipiiさんのツイート: "Redmineもプラグイン機構を持ちカスマイズしやすい特徴もここに理由があるのかな?「組織構造がソフトウェアの構造に影響を及ぼす(Conwayの法則)と同じように、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうる」 https://t.co/07wYG0M7yf"

【1】上記の記事では、「良い OSS 開発と良いソフトウェア設計の間には緊張関係があると思いますか?」という質問が発端になっている。
意図としては、OSSが良い設計であるには、ユーザからの多数の要望を五月雨式に取り入れると、アーキテクチャとしてもUIとしても一貫性がなくなり、複雑化するだけなので、取り入れないべき。
一方、OSSが活発に活動を維持するには、熱心なユーザがフィードバックやパッチをどんどん送り、ソフトウェアをバージョンアップしながらどんどん機能改善していくミッションがあるべき。

(引用開始)
しかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。
もし活発さを志向する OSS 開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。
(引用終了)

つまり、OSSコミュニティの活発さとより良いソフトウェア設計の間には、トレードオフがある。
では、どうやってその折り合いを採るべきなのか?

一つの解決策としては、OSSにプラグイン機構を設けて、「ソフトウェアを汚さずに、ソフトウェアを拡張する機構」というI/Fを用意しておくことだ。

(引用開始)
プラグイン機構による開発者コミュニティへの質的な転換

その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。
組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが(コンウェイの法則)、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。

OSS プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。
大きめの OSS プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。
(引用終了)

つまり、プラグイン機構とは、ユーザコミュニティが単に、ソフトウェアを使用するだけの受動的立場から脱却して、自ら必要な機能はプラグインで実装するように、誘導するためのソフトウェア設計機構なのだ。

よって、プラグイン機構は、「ソフトウェアは組織構造に従う」というConwayの法則の逆パターンのコミュニティ版と言えるのではないか。
つまり、「より良いソフトウェア設計はOSSコミュニティという組織を活発化させる」。

【2】上記の記事を読んで、改めてRedmineについて思いを巡らせた。

【2-1】RedmineはRailsを開発基盤としているので、ソースも読みやすいし、プラグイン機構でユーザが機能拡張することも容易だ。
実際、Railsのプラグインの作成手順は、ネット上にいくらでも転がっている。

日本では、自分たちの組織に合った開発プロセスや業務プロセスに、Redmineを従わせて、Redmineを自由に使いたい、という要望が多い。
日本人はパッケージ製品をそのまま導入するのは嫌で、自分達なりにカスタマイズしたがる、という特徴が、Redmineにも出てくるわけだ。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

その時、Redmine本体を修正するのではなく、プラグイン機構を使えば、Redmine本体の影響を最低限に抑えて、カスタマイズすることが可能だ。
そうすれば、Redmine本体のVerUPに追随しながら、カスタマイズした機能の保守コストを下げることができる。

【2-2】では、なぜ、「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」がRedmineにあえて必要なのか?

以前、Redmine勉強会では、JPLのRedmineの開発スタイルは非常に保守的である、という話があった。
実際、大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100%になるまでリリースしない。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

JPLの美的感覚、設計思想が、熱心なユーザの機能改善要望を全て実現するのではなく、Redmineの発展に必要な機能、さらに、Redmineの品質低下を起こさないような機能だけに絞り込んでいるのだろう。

すると、確かにRedmine本体はVerUpしても安定しているだろうが、ユーザにとっては、標準機能だけでは機能不足と感じる場面も多くなる。

そんな時に、Redmineのプラグイン機構を用いて、Redmine本体に手を加えずに、自分たちの組織やプロセスに見合った機能を追加するわけだ。

換言すれば、プラグイン機構という柔軟なソフトウェア設計が、OSSアプリの標準機能では物足りないと感じるユーザに、自分達でカスタマイズできる余地を残しておき、それを利用させるような雰囲気を奨励している、とも言えるだろう。
それによって、Redmineは標準単体で安定した品質を保ちながら、ユーザはプラグインを入れて、自分達の環境に合ったプロセスを実現できる。
つまり、Redmineの柔軟なプラグイン機構が、ユーザにプラグイン開発を促進させ、多様なプロセスを実現することを促進させているわけだ。

【2-3】だから、Redmineのように、自由に機能拡張できるI/Fを持つOSSソフトウェアは、日本人向きなのだろう。

実際、Redmineはプラグイン機構以外にもREST APIやメールによるチケット登録、rakeコマンドなどの数多くのI/Fがあり、それらを適材適所に当てはめれば、機能をカスタマイズしやすい特徴がある。
以前、この辺りの事情は分析していた。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

但し、この特徴はRedmineに限らず、SAPなどの著名なERPにおいても、パッチ当てをプラグインのような機構で実現しているので、そんなに特別なわけではない。

【2-4】一方、Redmineは「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」の特徴を持つことで、Redmineコミュニティ自身が活発になりやすいこともあるだろう。

日本のRedmineコミュニティではプラグイン開発者が多い、という特徴を以前、@agilekawabataさんが指摘していた。

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

この意味は、日本企業はRedmineを自分たちの組織にあわせてカスマイズしたがるので、プラグイン開発者を必要としていることだ。
そして、そういうプラグイン開発者が日本のRedmineコミュニティには結構多い。

OSSの日本人Redmineプラグイン開発者として、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

そういうプラグイン開発者や開発ベンダーは、RedmineというOSSコミュニティの活動にとても貴重な人達だ。
なぜなら、彼らはRedmine本体に取り込まれなかった機能を無償・有償でプラグインを公開してくれており、ユーザも恩恵を受けられるからだ。

また、彼らはRedmineの機能改善や利用事例に関するニーズも多数保持しているだろう。
そこで得られた知見も多いに違いない。
そして、実際、そういう知見をRedmineコミュニティで発表して、ユーザと共有してくれている。

そんな事を考えると、プラグイン機構というソフトウェア設計は、OSSソフトウェア本体を汚さずにOSSコミュニティを活発化させていくために必要な特性と言えるのだろうと思う。

つまり、柔軟なソフトウェア設計は逆に、OSSコミュニティという組織構造に良い影響を与えているわけだ。

【3】「Redmineは組織構造に従う」「柔軟なソフトウェア設計はOSSコミュニティを活発化させる」という二つの経験則は、正直面白い。

似たような経験則として、逆コンウェイ戦略「望ましいアーキテクチャに合わせて、アジャイルな開発チームを作る」という話もあった。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

これ以外にも、Redmineインスタンスとプロセスの密接な関係もある。
「唯一のRedmineインスタンスで、組織内の多種多様な状況に合わせた標準プロセスを実現する」という観点と、「それぞれの開発チームの組織文化や開発プロセスに合わせて、あえて、Redmineインスタンスを複数個立てて運用する」という観点の二つのやり方がある。

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

どちらが正しい、というのではなく、それぞれの前提条件、組織の状況に応じて、コンテキストは変わる。

今の僕の興味は、Redmineのような柔軟なOSSソフトウェア、それを運用する組織構造やプロセスとの間に、どんな関係があり、どのようなコンテキストが発生しているのか、を経験則として抽出して、その本質を探ってみたい、と思っている。

| | コメント (0)

2017/07/01

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い

@agilekawabataさんが「Redmineが日本人好みのツールである」意見を述べていて、なるほどと思ったのでメモ。

【参考】
Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

【1】Rubyアソシエーション - 株式会社アジャイルウェア

(引用開始)
川端氏はOSSの活動にも力を入れている。
Ruby、Redmineどちらもコミュニティによる開発が中心となっており、OSS活動がビジネスに直結しているからだ。

「RxT Study(現 Redmine大阪)でRedmineプラグインの作り方という発表をしたこともありました。
アジャイル、Ruby、Redmineいずれのコミュニティでも私自身が楽しみながら活動しています。
コミュニティの特徴をつかんでおくとビジネスに活用できることも多いです」

啓蒙普及活動を通じてユーザー数の増加を目指すことは分かりやすいコミュニティ活動の一例と言えるが、その他にも活動を通じて面白い発見があるようだ。
例えば、日本のRedmine開発コミュニティは、どちらかといえば本体よりもプラグインを開発する開発者が多くいるとのこと。

「他のオープンソースタスク管理ソフトウェアや商用のソフトウェアと比較して、Redmineはアジャイル、ウォーターフォールのどちらでも上手く適用できます。
それにカスタマイズも容易にできます。
日本企業ではその組織に合うように、導入ツールをカスタマイズして使うことを好む文化があります。
それが、Redmineが日本で多くの人に受け入れられている理由であり、Redmineのプラグイン開発が盛んな理由もそこに関係があると思ってます」
(引用終了)

【2】Redmine以外にも数多くの有名なOSSツールはいくらでもある。

たとえば、Rubyは日本人のコミュニティがすごく活発だ。
RubyコミュニティはRuby自身のコミッタという開発者が関わっているように、たいていのコミュニティは開発者自身が積極的に関わって、コミュニティを形成する場合が多い。
まつもとさんを中心として、数多くに日本人コミッタがRubyを積極的に開発し、かつ、Ruby会議のようなコミュニティ活動も積極的に行なっている。

しかし、日本のRedmineコミュニティは少し違う側面がある。

Redmine本体の開発者はフランス人のJPLだけであり、まるやまさんもコミッタと言いながらも、多言語化やテストコード整備などに徹しており、役割分担されている。
前田剛さんもコントリビュータとして、リリース計画に携わっているが、現状はRedmine本体のソースにコミットできるわけではない。
つまり、Redmine本体のソースを修正できる人は事実上JPLただ1人だけだ。

一方、東京RedmineやRedmine大阪に参加する人達の属性を振り返ると、Redmineプラグイン開発者やRedmineサーバー管理者のセグメントが非常に多い。

思いつく日本人のプラグイン作者は、@akiko_pusuさん、@two_packさん、@haru_iidaさん、@onozatyさんなど。
彼らが提供するOSSのプラグインは、正直なくては運用できないレベルがある。
たとえば、Issue Template、Excelエクスポート、SideBarやWikiExtensionsなど。

また、堂端さん(アジャイルウェア)や@y503unavailableさんのRedmineのデータ移行、@akahane92さんの性能チューニングなどの利用事例も数多く発表されている。

乱立してるRedmineを一つにまとめる話・ GitHub

QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

【3】Redmineの開発基盤であるRailsは、DBのスキーマ構造、CoCによる設計、JavaScriptの各種フレームワークとの相性の良さによる今風のリッチなUI、プラグインによる機能拡張のしやすさ、REST APIなどの外部接続IF、など数多くの利点を持つ。
Railsの長所が、カスタマイズに向いているように思える。

実際、新しい機能を追加したいと思う時、プラグインで製品本体に依存せずに機能開発できる。
また、テーブル構造も、機能追加で必要なテーブルを新規作成しておけば、製品本体のVerUpの影響も受けにくくなる。
さらに、Redmineは、REST APIでXMLやJSONでチケットデータを取得・更新できる外部接続IFがあるので、それを使うようにすれば、製品本体のVerUpを受けにくいような設計にできる。
他にも、rakeやメールによるチケット自動登録などの機能もあるので、状況に応じて設計を変えれば良い。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索

Redmineの外部接続、データ移行の機能: プログラマの思索

昨今は、ViewCustomizeプラグインを使えば、Redmineのソースを触らずに、画面のUIを自由に修正できる方法も公開されている。
たとえば、ちょっとした画面のUIの配置、デザイン変更、初期表示や画面遷移の変更を行いたい時は、ViewCustomizeプラグインを使った方がいいだろう。

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

【4】彼らのようなプラグイン開発者が日本には多い、という背景には、川端さんの指摘の通り、Redmine本体のVerUPに追随しながらも、自分たちの組織に合った運用ルールにRedmineをフィットさせたい、という場合に、プラグインで機能拡張しているのだろう。
つまり、日本企業は自分の組織文化に合うようにツールをカスタマイズしたい、という要望がすごく強いのだろう。

実際、Redmineを利用する企業の業種を聞くと、本来はIT業界のうち、受託開発がメインと僕は思っていたが、デザイナーやゲーム業界、製造業、サービス業など、多種多様な業界でも使われている。
利用事例は、ソフトウェア開発という特殊な業態だけではないのだ。

また、日本の大企業での事例(メーカーが多い)、JAXAや気象庁の事例もWebで公開されている。
つまり、企業の規模も問わず、日本では中小企業から大企業までRedmineが幅広く利用されているようだ。

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JAXAのRedmine利用事例の講演資料がWeb公開されました: プログラマの思索

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

そうすると、それらの業態に合うような画面UIや機能が欲しい、という要望が増えるのも、割と自然に理解しやすい。

【5】そういう背景を考えると、下記のツイートのように、ERPのパッケージ製品SAPは仕事そのものだ、というような製品は日本企業には合わないのだろうと思う。
なぜなら、自分たちのやり方にあわせてカスマイズできないからだ。

Takanori Sekiさんのツイート: "SAP役員の弁「SAPはパッケージソフトではありません。それは仕事のやり方そのものです」つまりERPを買うということは仕事のやり方を買うってこと。その意識で買ったところはどれだけあるか…"

無理してカスタマイズすれば、保守費用が大きくなるし、製品本体のVerUP追随のための保守費用が更に増えてしまう。
かと言って、製品本体のVerUpができなくなると、セキュリティパッチなどの重要なパッチが当たらないリスクが増えてしまう。
半ば惰性的にERPを使い続けている所が多いのではないか。

つまり、日本のビジネス文化、日本の市場の特性、日本の組織の特性を考えると、自社の特徴を活かすようなシステム構築の方が、日本企業には向いているのではないだろうか。

【6】日本では多種多様な業態でRedmineが使われている、という事実は、Redmineをよりカスタマイズしたい要望が多くなる原因の1つであろうと思う。

すると、本来の発端の機能であった障害管理だけではなく、ITSやチケット駆動へ発展し、さらに、BPMや事務処理ワークフロー、勤怠管理、ISO9001などへの利用シーンも増えているのだろう。

そして、その利用シーンに必要な機能をRedmineのプラグインやRedmineの外部で運用基盤を整えるなどの手法も必要になってくるだろうと思う。

Redmineは事務処理の申請承認ワークフローに使えるか?: プログラマの思索

RedmineをBPMツールとして使うアイデア: プログラマの思索

ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索

Redmineを勤怠管理システムで運用するアイデア: プログラマの思索

Redmineを帳票ワークフローツールとして強化するstatus_buttonプラグインが面白い: プログラマの思索

この辺りのアイデアは、実現可能性も含めて、もっと探ってみたい。

| | コメント (0)

2017/06/11

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai

astah関西 第1回勉強会を7/14金に開催します。

【参加申込み】
astah関西 第1回勉強会 - connpass

astah*Professionalファーストインプレッション: プログラマの思索

Enterprise Architectの使い方のリンクとメモ: プログラマの思索

astahによるモデリングのメモ: プログラマの思索

(引用開始)
関西圏でモデリングツールastahを使ったモデリング技法と実践事例に関する勉強会を開催します。

astahを使っている人、モデリング大好きな人が集まって、より良いモデリング技法や実践事例を共有する場として設けます。

モデリングの対象は、astah製品を使った設計技法が中心なので、UMLに限らず、ER図やDFDなどのデータモデリング、SysMLなどの組込ソフトウェア設計なども含む予定です。

興味のある方は、ふるってご参加ください。

<テーマ>
キックオフを兼ねた第1回勉強会を開催します。

チェンジビジョン(株)の方にも来阪して頂いて、astah製品の紹介と実際のモデリング技法について講演して頂きます。

次回の参加希望者が多ければ、勉強会スタッフを募集して継続します。
(引用終了)

【開催の発端】
僕自身は、Judeの頃から使い始めて、astah Professionalを2009年から使い続けています。
主な使い道は、UMLのお勉強が発端で、その後は、システム提案や要件定義の時のラフスケッチ、開発プロセスの運用ルール策定やプロセス分析です。

過去に、RationalRoseやEnterprise Architectを開発案件で使用した経験はありますが、正直使いづらかった。
2000年代中頃は、UMLがブームで、設計フェーズをUMLのダイヤグラムで代用する思想が多かったけれど、たくさんの修正が発生したら、ダイヤグラムのマージが面倒で、複数人でダイヤグラムを共有して作業するのも難しい。
結局、astahでも、個人で使用する場面が多いです。

astah Professionalの良い所は、頭の中にあるモヤモヤした内容をUMLの各種ダイアグラムでラフスケッチを即座に描ける点。
1つの問題や事象を、複数の観点の動的・静的ダイヤグラムで描いて、整合性や詳細を詰めていくことが自然にできる点が良かったと思います。
絵で描くと、このI/Fの仕様が甘い、とか、このプロセスは意外に複雑だな、とか、色々気づきが得られやすい。

また、Redmineの運用ルールを説明する時、運用フローをアクティビティ図やステートマシン図で描くと、他人に説明しやすい。
誰とキャッチボールするのか、何がトリガーになるのか、が明確になる点が良いです。

さらに、過去にアジャイル開発やRedmineコミュニティで数多くの発表を行った時、astahで事前に書き溜めたラフスケッチがとても役立ちました。
そういう経験をしてきて、astahによるモデリング技法を周囲の人達と共有したいという気持ちが以前からあって、周囲の後押しを元に、ようやく実現する運びになりました。

僕の周囲ではそもそも、astahを使っている人がいないので、この勉強会が継続できるか分かりません。
関西で、astahを使っている人、astahに興味がある人、UMLやDOAや組込ソフトウェアのモデリング技法に興味がある人が集まるといいな、と思います。


| | コメント (0)

2017/05/14

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

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

【参考】
第12回勉強会 - redmine.tokyo

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

2017/04/28

第12回東京Redmine勉強会の見所

来たる5月の第12回東京Redmine勉強会の見所をメモ。

【参考】
第12回勉強会 - redmine.tokyo

redmine.tokyo 第12回勉強会 - connpass

【1】今回のテーマは『みんなでRedmineプラクティスをシェアしよう』。

最近、IT業界にかぎらず、メーカーなどの他の業界でも、Redmineという言葉を聞く機会が多くなってきた。
チケット管理の適用シーンが増えていて、そのメリットを感じられる利用シーンも増えているのだろう。

そこで、Redmineの導入や運用の観点と、Redmineを支える技術面の観点の二つから、Redmineの利用事例を紹介できることになった。

【2】Redmineの導入や運用の観点では、まず、@Madowindaheadさんの「Redmineを活用したプロジェクトマネジメント技術向上について」がある。
@Madowindaheadさんは、PMOの立場として、プロジェクト管理の標準化や運用推進を担当されているとのことで、Redmineをベースにしたプロジェクト管理の社内説明会を過去2年以上実施されている、とのこと。
社内でRedmineの利用を推進して展開していくためのノウハウや、落とし穴に関するお話が聞けることを楽しみにしている。

過去のRedmine勉強会の参加者からも、社内でRedmineを使ってもらうにはどうすればいいか、という初歩的な質問も多い。
だから、Redmineを実際に導入したものの、全社的に展開していくためにはどんな手順やノウハウが必要なのか、という観点で聞けば、参考になるものが多いのではないか、と期待している。
3月のRedmine大阪のLT資料がダイジェスト版らしいので、参考にしたらと思う。

Redmineを活用したプロジェクトマネジメント教育について(ダイジェスト版)

【3】次に、宮本 陽一さん の「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」の講演がある。

「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JDMF2016講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になる: プログラマの思索

ソフトウェア開発における派生開発やプロダクトライン開発にRedmineが有効に使えるのではないか、というアイデアについては、僕も過去に色々考えてきた。
たぶん、同じように感じている人達も多いと思う。

派生開発やプロダクトライン開発については、昔から沢山の人が開発プロセスは考えられてきたけれど、そのプロセスの実装が非常に煩雑、という問題があると思う。
その問題点は、複数の開発ブランチを並行開発できる構成管理と、要件からソース修正に至るまでのトレーサビリティの2点をいかにプロセスとして実装するか、という点で置き換えられると思う。

つまり、その2つの問題点は、Redmineの構成管理ツール連携と、チケット管理のトレーサビリティというRedmineの特徴を活かせば、たぶん解決できるはず、と直感している。

また、派生開発やプロダクトライン開発の別の観点では、複数の組織をまたがったプロジェクト管理をどのようにプロセスとして実装すべきか、という問題もある。
たとえば、複数の製品開発チームとコア基盤の開発チームがいかにスムーズに連携しながら、並行開発しながら、順次リリースしていくべきか。
たぶん、たとえアジャイル開発であったとしても、そのプロセスの実装はそう簡単ではないはずだ。

なぜなら、派生開発やプロダクトライン開発では、マトリクス型組織になりやすいため、ワンマンツーボスシステムの組織になりがちで、メンバーの観点では二人のボスの指揮命令系統に従わざるを得ず、混乱しがちだから。

この問題点に対しても、Redmineの複数プロジェクト機能を組織構造と上手く対応付ければ、運用するプロセスの実装はかなり楽になるはずだ、と直感する。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

すなわち、Redmineの柔軟な機能を上手くプロセスと組み合わせれば、プロセスの運用ルールをガチガチに固めなくても、自然に運用できるような雰囲気を作れるだろう、と直感している。
そういうことを考えながら、講演を聞いてみたいと思う。

【3】次に、須藤功平(@ktou)さんの「GroongaでRedmineを高速全文検索」の講演がある。
Redmineの全部検索を高速化するプラグインを実装公開されているので、利用者の観点でお話して頂く予定。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

下記でも書いたけれど、Redmineのようなナレッジを蓄積するシステムでは、全文検索機能は他のシステム以上に重要な機能であると考える。
なぜなら、チケットやWikiにどんどん過去の作業の経緯や技術情報が記録されて蓄積されたとしても、その内容を即座に検索できなければ、過去の知見を有効活用できないからだ。
たとえば、3年前の障害に関連する情報を全文検索しようとして、3分以上も待たされたら、正直使いものにならない。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

よって、このRedmineの全部検索プラグインは、Redmineをナレッジシステムとして有効活用するために、またそう感じることで利用ユーザのモチベーションを高めるためにも重要な機能であると思う。

また、@ktouさんは、Rubyコミッタの方でもある。
そして、Ruby本家もバグ管理をRedmineで運用されている。
色々お話が聞けるのでは、と楽しみにしている。

kou (Kouhei Sutou) - Ruby Issue Tracking System

OOエンジニアの輪! ~ 第 39 回 須藤 功平さんの巻 ~ | オブジェクトの広場

Rubyist Magazine - Rubyist Hotlinks 【第 36 回】 須藤功平さん

【4】その他にも、@g_maedaさんの講演やLT7本もあるので、盛りだくさん過ぎるほどだ。
参加者も既に定員オーバーで、静かに盛り上がっている。
当日の勉強会が盛り上がるのを楽しみにしている。

【追記】@ktouさん、@Madowindaheadさんの資料が既に公開されている。

| | コメント (0)

2017/02/05

第53回IT勉強宴会「深層学習の概要とドメインモデル」の感想

第53回IT勉強宴会で、能見さんの「深層学習の概要とドメインモデル」を聞いてきた。
すごくワクワクして、面白かった。
自分は初心者なので、理解できたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
深層学習の概要とドメインモデル<第53回IT勉強宴会> : ATND

深層学習の概要とドメインモデル<第53回IT勉強宴会> | IT勉強宴会blog

【1】昔流行したニューラルネットワーク理論と深層学習の深い関係

僕の一世代上の人たちから見ると、ニューラルネットワークがすごく流行して冬の時代になったのを知っているので、理論は既に知っているが、本当に使い物になるのか、という思いがあるみたい。

単純パーセプトロンで、0または1に分類するのは、回帰直線による相関分析。
でも、そのままでは当然解けない問題もある。

多層パーセプトロンにすれば、非線形な問題は活性化関数を用いて線形分離できるように変換すればいい。
シグモイド関数が有名だし、それ以外にも色々ある。

多層パーセプトロンのボトルネックは、学習コストを最小化する関数を求める時、真の極小解ではない極小解に落ち込んでしまって、そこから脱出できなくなる点。
誤差逆伝播法で、勾配を少しずつ計算して、誤差をフィードバックして、鞍点にはまらないように学習していく。

でも、過学習の問題も出てくる。
この辺りは、人間が、スポーツや勉強をあるパターンだけで進んでいくと頭打ちになり、いくら努力してもそれ以上伸びない、という症状によく似ている。
他にも、教師あり学習とか、強化学習は子供の躾、ペットの躾に似ているとか、すごくアナロジーしやすい。

そういう時代を過ぎて、2012年に深層学習が画像認識の精度を大きく上げるブレイクスルーが起きて、深層学習が流行し始めた。

講演で最も興味深かった点の一つは、「なぜ、学習の構造はDeep(深層)なのか」。
「なぜディープラーニングが、これほど世の中の多くの問題にうまく適用(特に認識)できるのか?」
「Linの仮説」というものが説明しようとしているが、その理由は、まだ理論として結果は出せていないらしい。

深層学習は 世界をどのように変えられるのか - IBISML

能見さんの「直観的な理解:対象の階層的な構造をうまく取り込めるから」という話を聞くと、人が物事や現象を理解しようとする時、ツリー構造で概念を分解して理解しようとする方法と上手くマッチしているから、と理解している。
たぶん、深層学習の仕組みは、人間の脳の仕組み、人間が物事を考える仕組みの本質に触れているからこそ、プログラムで実装してその威力を発揮できているのだろうと推測する。

【2】深層学習はどこまで知性に近づいているのか

深層学習はニューラルネットワークをプログラムで実現しているので、まさに人の脳の神経回路のシミューレションに近い。
では、深層学習はどこまで人間の知性に近づいているのか?

話を聞く限り、2017年始め時点では、画像認識などの分野で人よりも認識の精度は高いが、全ての分野で置き換えられているわけではない。
まだ知性まで追いついていない。

渡部幸三さんが質問したように、深層学習が画像認識の処理をした後で、「美しさとは何か」という問いに対して、その特徴量、その評価基準が知りたい。
しかし、現時点の深層学習のフレームワークでは、中間パーセプトロンの中身はいちおうトレースできるが、「美しさ」の特徴が何であるか、明示しているわけではない。
深層学習の処理結果として、入力した画像を犬か、猫か、ゴッホの作品なのか、とフィルタリングしているだけ。

深層学習による画像処理において、ある風景写真をゴッホ風にアレンジする、というシミュレーションした絵があって面白かった。
ちょうど、昔のセピア風、プリクラ風の写真の加工に似ている。
では、ゴッホの絵の美しさの特徴は何なのか、と抽象的な概念で言い表して欲しいが、それは明確ではない。

なぜ、美しさの特徴を知りたいのか?
やはり、人間なので、その結果に至る道筋、ロジック、原因が知りたい。
もしそれが完全に判明したとしたら、プラトンのイデア論を立証できることになる気がする。
つまり、美しさの本質はこれこれです、と明確に言えるならば、全ての人の心にはそれが宿っているので、お互いに理解し合えるのだ、というロジックで言いたい。
最終的には哲学の性善説に行き着く気がするが、現時点の深層学習はそこまで人間の心理の本質まで迫っているわけではない。

現在、深層学習をベースとした人工知能の研究は、アメリカと中国で相当激しく進んでいるらしい。
また、東京での人工知能や機械学習の勉強会は、すぐに定員いっぱいになるぐらい人気があるらしい。
今はブームが始まったばかりで、深層学習のどのフレームワークが生き延びて集約されるのか、分からない状態なので、面白いみたい。

| | コメント (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)

より以前の記事一覧