コミュニティ

2018/11/11

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

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

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

Redmineでやってみた - うさぎまんじゅう - BOOTH

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニースが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

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

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事: プログラマの思索

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

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

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

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

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。

| | コメント (0)

2018/11/09

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について

第15回redmine.tokyo勉強会のLT資料を事前公開しておく。

【参考】
日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回勉強会 - redmine.tokyo

【1】Redmineには2つの顔がある。

一つは、ソフトウェア工学の理論を実験できるメトリクス収集集計基盤/開発プロセスの運用基盤である顔。
Agile開発もWF型開発も運用可能であり、ワークフロー設定できるならば、全ての開発プロセスをRedmineで一元管理できる。
そこから、Redmineは開発プロセスの運用基盤になり、ソフトウェア工学やプロジェクト管理に関するメトリクス収集・集計基盤になりうる。
つまり、定量的なプロジェクト管理の手段をRedmineによってようやく手に入れられることになる。

もう一つは、汎用的なプロジェクト管理ツールの開発基盤である顔。
RubyとRailsの基盤のおかげで、機能のカスタマイズがやりやすい。
REST APIやrakeなどの外部接続I/Fもあるので、システム連携もやりやすい。

そのおかげで、Redmineに不足する機能をプラグインで実現できるので、プラグイン開発者が多い。
特に日本では、ガチガチの縦割りの組織や自社の開発プロセスに合うように、Redmineをカスタマイズしやすいので、ニーズが多い。

また、Redmineが柔軟な開発基盤を持つおかげで、Redmineコミュニティ自体が活発化している事象もある。
柔軟なソフトウェア設計は、OSSコミュニティを活発化させるメリットがある。
他方、OSSコミュニティの活発化は、ソフトウェアをさらに進化させる、という双方向のメリットがある。
その考察は以下に書いた。

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

【2】言いたいことは2つ。

Redmineコミュニティの参加者の多様化を図ること。
もう一つは、Redmineのエコシステムを作ること。

Redmineコミュニティの参加者層は2種類あると思う。
一つは、プロジェクトマネージャなどのマネージャ層。
もう一つは、プラグイン開発者などのRuby開発者層。

つまり、プロジェクトマネージャかつRuby開発者である層は非常に少ないだろうから、コミュニティで相互の交流を図ることで、斬新なアイデアが出てきて、Redmineを更に進化させる余地がたくさんあるだろう。

マネージャのニーズはRuby開発者にとって、新たなプログラミング体験のチャンス。
Ruby開発者が提供するRedmineの新機能やプラグインは、マネージャのニーズをさらに刺激して、より良いものへ発展させるだろう。

その場合、Redmineベンダーも実はコミュニティのステークホルダーの一人なのだ。
彼らも有償ツールではあるが、Redmineのマーケット拡大に寄与している部分がある。
最終的には、彼らも含めて、Redmineコミュニティが熱気を維持し続ける方向へ持っていきたい。

そういう活発な議論を提供する場をコミュニティで実現したいと思う。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。


| | コメント (0)

2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

【追記】
大雨のため、9/8土曜に順延となりました。

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

| | コメント (0)

2018/05/27

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

第14回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
感想をラフなメモ書き。

【参考】
2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter

第14回勉強会 - redmine.tokyo

redmine.tokyo 14 で登壇してみた – アカベコマイリ

【1】グループディスカッションで話を聞くと、最近Redmineを運用し始めた、という人から、10年近く触っている人まで幅広いユーザ層でした。

また、1年前から参加者の女子率が上がっているように感じてます。
女性陣もデザイナー、品質保証部、PMO、インフラ管理者など幅広い分野で活躍しており、Redmineに関する問題意識も当然高い。
以前は、40代のおっさんばかりがRedmineコミュニティにたむろしていたのを振り返れば、感慨深い。

ゆえに、参加者層が幅広くなったおかげで、ユーザコミュニティの雰囲気は、毎回開催するにつれて良くなっていると思う。

【2】個人的には、Twitterでやり取りしている人と対面できたのも嬉しい。
講演してくれた@akabekobeko さん、@nekosanz1 さん、グループディスカッションでお話できた@endo_5501 さん、@kabukawaさんを認識することができた。
もちろん、@kaorabeさん、@MadoWindaheadさん、@acha_821さん、@aj15_aj15さん達ともお話できたのも楽しかった。
また、Redmineコミュニティが縁で結婚されたカップルも居る。

コミュニティを通じて、輪が広がるのも楽しい。

【3】山崎さんの講演では、Redmineとツール連携する例として、MSProjectからRedmineへインポートするプラグイン、RedmineとSlackを同期するプラグインが紹介されていた。
(たぶん、山崎さんの会社でプラグインを作成されているだろう)

プロジェクトマネージャの要望としては、立上げ時にMSProjectで作ったプロジェクト計画をRedmineへインポートしたい要望が多い。
ざっくりしたスケジュールを引いてクリティカルパスを表示させるのは、やはりMSProjectの方が楽だから。

しかし、予定はMSProjectで作ったとしても、その後の実績管理はRedmineの方がはるかに運用しやすい。
日々の進捗はどんどん変わるし、複数人が編集して最新化する手間を考えると、MSProjectに拘る必要はないと思う。

このプラグインで面白いのは、親子チケットの構造をRedmineでも再現できる点。
現状のRedmineのREST APIでは、ツリー上のWBSを作る時、どうしても2回発行しなければならない。
なぜなら、親チケットが決まった後で、子チケットをぶら下げる更新処理が必要だから。
ゆえに、1回の更新で、しかもチケット番号を昇順に採番して更新するような仕組みがあると便利だろう。

【3-1】また、Slack連携では、Redmineの活動ログをSlackに流すだけでなく、SlackからRedmineへチケット登録する運用が紹介されていた。
仕組みとしては、Slack上で、「タイトル:~、内容:~」のようにコメントすれば、RedmineのREST API経由で登録される仕掛け。

Slackからチケット登録できるメリットは、Slack上で障害を見つけたやり取りをしている時に、Slackから即座にチケット登録したい時もあるだろう。
すなわち、Slackの運用が既に定着していて、Redmineに情報を集約して記録して残したい場合に、有効に使えるだろう。

【3-2】似たような例として、@netazoneさんがGoogle Homeで、ボイス入力した内容をRedmineにチケット登録する利用事例のLTがあった。
仕組みとしては、Google HomeからIFTTT(IF This Then That)・GMail経由で、Redmineへチケット登録メールを送って、メールによるチケット登録機能を使っていた。
Google HomeからRedmineのチケット登録ができるメリットは、PC操作無しで会話するだけでチケット登録できること。
たとえば、カスタマーサポートや事務担当者などの非エンジニアが使う利用シーンが考えられる。

このように、Redmineの優れた外部I/Fを上手く使えば、チケット管理のコストを下げることが出来るだろう。
また、現場の利用シーンを考えながら、Redmineと連携する設計を考えるのも楽しい。

【4】@akabekobekoさんの「なじむ Redmine」も面白かった。

個人的には「Redmineを浸透させるために、故意に「活況を演出する」」という考え方が面白かった。
つまり、流行っているレストランは、流行っているから更に新規顧客も増える、という現象と同じ。
特に日本人は、皆がやっている雰囲気に弱いので、故意にRedmineの活況を演出し、Redmineに触らざるをえない雰囲気に持っていく。

事例としては、Wikiで議事録や設計メモをまとめることから入り、その後チケットの運用に入っていく。
どうやら、初心者にとって、チケットを登録するのはハードルが高いらしい。
チケットのUIはボタンが多いし、ちょっとの更新でも履歴が残ってしまうので、変な更新ができない、完璧に書かないといけない、という心理が働くらしい。
几帳面で完璧主義の古き良き日本人にありがちな行動だろう。
だから、そんな時は、周囲がサポートする。
たぶん、Redmine警察とか、Redmine職人、とか、Redmineエバンジェリストの出番なのだろう。

【5】実は、今回の勉強会では、RedmineのGit連携が最大のテーマだったと思う。
パネルディスカッションで取り上げられた。
@akabekobekoさんの講演でも、最後の課題にあげられていた。

(引用開始)
最近、日本のRedmine 界隈で話題?になった記事
Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索
↑で挙げられている内容はRedmine 運用していて強く 実感させられる課題です。
私的には環境面の運用が厳しい。インストール、更新、プラグインやテーマの配布と互換性など。
(引用終了)

【5-1】パネルディスカッションで、パネラーや参加者の声を聞く限り、RedmineユーザはSVNとRedmineの連携はよく使っているが、Git連携を使っている人は少ない印象を持った。
つまり、SVNの知見は皆良く知っているが、Gitの知見を持つ人は少ない。

話を聞いた印象としては、プロジェクトマネージャやPMOとしてRedmineでチケット管理している人たちは、そもそもGitを運用する利用シーンがそもそも無い。
彼らのモチベーションはチケット管理による作業の進捗管理やリソース管理がメインだから。

【5-2】一方、RedmineとGitを連携して運用する場合、2つのパターンの事例があった。

1つ目は、RedmineとGitlab、Gitoliteと連携して、Redmineではチケット管理、Gitlab側ではブランチ管理で分けている。

Redmineサーバー側にGitのBareリポジトリをクローンし、Redmineのリポジトリ画面と連動させる運用をしている。
もちろん、Redmineのチケット番号をGitのコミットログに埋め込むので、トレーサビリティは維持できている。

しかし、Gitlabのプルリクは使えていない。
あくまでも、Gitのブランチ管理とマージ作業だけに限定されている。
よって、昨今のGitHubで最も優れている運用方法「プルリク時点のコードレビュー」が仕組みとして提供されていないデメリットがある。

2つ目は、Redmineのチケット管理とGitHubのソース管理は明示的に連携せず、Redmineではプロダクトバックログや障害チケットの管理を行い、GitHubではマージやプルリクを使う、と運用を分けている。

すると、GitHubでは活発なプルリクが行われるので、プルリクのタイミングで必ずコードレビューが行われて、masterの品質は維持される仕組みになる。
このプルリクとコードレビューが密接に関係することで、エンジニア同士のコミュニケーションが促進され、お互いの理解も進み、ソースの品質も維持される仕組みが作られた点にあると思う。

しかし、Redmineのチケット管理と連動していないので、チケット管理ツールの最大のメリットの一つであるトレーサビリティ機能が使えていない。
結局、Redmineのチケット単位にトピックブランチを手動で作り、トピックブランチをプルリクする時点で、Redmineチケットを更新するという手動の運用ルールでカバーしている。

すなわち、現状のRedmineのGit連携には、昨今のGitHubのプルリクという優れた機能を埋込できていない。
よって、Gitの恩恵を最大限活用できているとは言えない。

MAEDA Goさんのツイート: "https://t.co/9GswyYgo4P にコミットするときいつもすごく緊張する。コミットログをスペルチェッカーにかけ直したり、diff見直したり。 #redmineT"

【5-3】RedmineのGit連携の機能が不十分である、という課題は、おそらく有識者は皆知っていて、何とか解決を図ろうと色々試されている、と思う。

@agilekawabataさんは、RedmineのBareリポジトリを作成するプラグインを作ったら欲しい人はいるか、という質問を投げかけていた。
初心者にとって、GitのBareリポジトリを作成する作業はハードルが高いので、プラグインがあれば、その部分のハードルは下がるだろう。

onozatyさんのツイート: "Bareリポジトリを画面側からクローンできると確かに楽だなぁ。 (回数がそこまで多くないので耐えられているけど、、)… "

onozatyさんのツイート: "そですね、きつすぎますね。 GitLab+Redmineで使っているのですが、新規プロジェクト立ち上げる時の手間がそれなりにかかるので、そのあたりもう少し便利になるといいですね。 画面からBareリポジトリ作れるようになると、画面操作だけで完結するので敷居も下がるかなと。… https://t.co/tJVZYxcff5"

また、maeda-m さんのredmine_git_work_in_progress プラグインでは、作業ブランチとマージ先のブランチのDiffやブランチの状況を可視化する機能を紹介されていた。

matsukei/redmine_git_work_in_progress: This is a plugin that provides Reduine's Issue like "Work In Progress Pull Request" and makes it easy to share knowledge.

あるいは、RedmineとGitlabを連携したり、RedmineとGitHubを連携する方法で運用をカバーするやり方もある。

akipiiさんのツイート: "#redmineT Gitlab からベアリポジトリを作ってRedmineと連携してるのね。では同期はどうしてる?"

taikiixさんのツイート: "(会場で結論が出ているかもしれませんが)私はこのプラグイン使っています。 https://t.co/C0DQ7APwxL… "

koppen/redmine_github_hook: Allow your Redmine installation to be notified when changes have been pushed to a Github repository.

たむさんのツイート: "うちは、gitlabとredmineは独立したインスタンスなので、nfsマウントしていますよ… "

MAEDA Goさんのツイート: "mod_perlがRHEL 7から標準ではなくなったので、https://t.co/YqxU0tFwwx のインストールめんどくさそう。 #redmineT"

【5-4】RedmineとGitlabの連携で最大の問題となるのは、GitのプルリクとRedmineチケットが密接に連携できない点がある、と思う。

例えば、プルリクを作る前に、その作業のチケットがない場合、Redmineにチケットを書いて、Gitにチケット番号を書いてコミットしてプルリクを送る、という面倒な作業が発生しないか。

あるいは、トピックブランチの作業とチケットが連動できていても、プルリクを送りたい場合、プルリクに相当するリビジョンをチケットに明示的に書いて、チケットを「プルリク」ステータスに変更して、作業するのは面倒ではないか?

akipiiさんのツイート: "#redmineT @tkusukawa さんの質問はとても重要。そもそもソース修正の発端、変更管理はどこでやるの?GitHub のプルリクでやるとしても、発端のチケットが登録されてから、ソース修正が発生する。プルリクは発生チケットの後になる。ではどうやって紐づけるの?"

門屋浩文@redmineエバンジェリストの会さんのツイート: "修正変更の出発点と完了条件を決めるツールによるということか? #redmineT… "

おそらく一般の運用ルールでは、GitのトピックブランチとRedimneチケットは1対1に対応させるはず。
たとえば、Redmineチケットを発行後、チケット番号をGitブランチ名に明示的にSuffixとして入れて、対応付けて運用するだろう。
たとえば、#12ブランチみたいな感じ。
すると、masterにマージしたい時に、プルリクしたい、というステータスをRedmineチケット上に設けざるをえない。
つまり、Redmineチケット上のステータス変更でプルリクを検知し、コードレビューが行われ、OKならば、マージされてチケットもCloseされる運用になるだろう。

本来はこの運用がRedmineの機能として、手軽に操作できるように実現できたらいい。
現状は、Git上でマージ作業を行い、Redmineのチケットを別途更新する、といった作業が2つのシステムで発生するので、正直面倒に感じやすい。
実際、GitHubでは一つの画面で操作できているから、尚更そう感じてしまう。

一方、Redmine本家のPatchチケットのように、パッチファイルとRedmineチケットが1対1の場合もある。
つまり、Redmineチケットが発行されないまま、トピックブランチが作られ、マージして欲しいなと思う時点でパッチファイルを出力して、Redmineチケットにパッチファイルを添付する運用スタイル。

この運用では、trunkが成長するにつれて、パッチファイルが古くなってしまい、マージされるタイミングを逸失されがちになる。
昨今のように、ビジネスレベルでもアジャイルが求められる時代では、このパッチ主導の運用は正直、時代に合っていないと思う。

よって、今後のRedmineのGit連携の機能改善としては、下記3点が必須になるのではないか。

(1)GitのBareリポジトリ作成を画面上の操作で行える。
さらに、GitのBareリポジトリはリアルタイムに同期される。
(2)GitのトピックブランチとRedmineのチケットを1対1に明示的に対応付ける操作を画面上で行える
(3)GitHubのようなプルリク機能をRedmineにも取り入れて、GitのマージをRedmine画面上で操作できるだけでなく、チケットCloseも自動更新できるようにする

【6】参加者に聞いてみたら、東京Redmine勉強会ではいつも講演が盛り沢山なので、たとえば午前10時から午後17時までRedmineカンファレンスを開催する、とか、限定されたテーマでRedmine勉強会を開催してはどうか、という意見があった。

Rubyカンファレンスには及ばないけれども、Redmineカンファレンスみたいなイベントがいつか開催できるといいな。

| | コメント (0)

2018/05/25

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


第14回東京Redmine勉強会の見所についてラフなメモ。
そして、今後のRedmineコミュニティの方向性について、最近個人的に考えていることをラフなメモ書き。

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

第14回redmine.tokyo勉強会 - connpass

【1】今回の勉強会では、講演者もLTを含めて11人と豪勢な内容になった。
また、Git連携に関するパネルディスカッションを入れたり、グループディスカッションも入れているので、相当盛りだくさんの内容になっている。

【1-1】今回のテーマは『Redmineとその周辺ツール活用事例』。
REST APIやGit連携、他システムの連動に関する事例がある。

僕は、Redmineの醍醐味は外部ツールと色んな手段で連携できるI/Fを持つことではないか、と思っている。
なぜなら、Redmine単体で不足している機能は、Redmine標準で用意しているI/Fを使って外部ツールに任せることができるから。
そういうシステム設計や運用を考えるのも楽しい。

また、Redmineは構成管理ツール連携が当初から標準だったので、この機能を使ってトレーサビリティがどんな性質を持つものなのか、実体験できたのも良かった。

但し、今後はGit連携の強化がRedmineの鍵になると思っている。
その内容に関する議論は、パネルディスカッションで盛り上がるだろうと期待している。

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

【1-2】個人的には、@akabekobekoさんに講演して頂けることがとても嬉しい。
以前から、下記の記事は参考にしていた。

Redmine 運用について 1/3 ? はじめに ? アカベコマイリ

Redmine 運用について 2/3 ? 運用ルールと諸設定 ? アカベコマイリ

Redmine 運用について 3/3 ? 普及の施策と課題 ? アカベコマイリ

(引用開始)
つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索はてブの反応はよい刺激になった。
Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。
幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。
(引用終了)

既存のExcel中心の組織文化の中で、いかにRedmineを浸透させて効果を上げていくか。
そんな組織の中で、現実的で実現可能な方法やレベルはどこにあるのか。
その辺りも聞いてみたいと思う。

【2】今後のRedmineコミュニティの方向性について、最近色々考える点はある。

一つは、Redmineユーザのレベル感や興味に関するセグメント別に、Redmine勉強会を定期的に開けたらいいな、と思うこと。
理由は、東京Redmine勉強会はいつもすぐに満席になってしまうので、せっかくRedmineに興味を持っている人達を取りこぼしてしまっているのが残念だから。

最近の勉強会に参加する人達とグループディスカッションで話を聞いてみると、長年の経験者もいれば、今から触ってみたいと思いますという初心者まで幅広かった。

そんな状況をふりかえると、経験者や初心者というレベル別に向けた勉強会を別の日程で開催してみる、とか、ViewCustomizeプラグインの使い方や効果的な事例のような特別テーマに関する勉強会を開催してみる、とか、もっとバリエーションを増やしてもいいかなあ、と思う。
既に、Redmineエバンジェリスト会のように、組織とRedmineをテーマにした勉強会も運営されているので、もっと増えたらいいな、と思っている。

もう一つは、Redmineコミュニティを東京や大阪だけでなく、各地でも開催できたらいいな、と思うこと。
なぜなら、東京でも大阪でも、福岡や福井、名古屋などの遠方からの参加者が意外に多いからだ。
今の自分のパワーでは東京と大阪ぐらいしかタッチできないけれど、Redmineユーザが各地にいるならば、各地で開催できるといいなあ、と思う。

こういうオープンソースのコミュニティ活動に好きで関わっているけれど、じきに、こういうコミュニティを半永久的に維持していければいいなあ、とぼんやりと思っている。
どんな実現方法があるのか、正直分からないけれど、いつか実現できるといいな。

| | コメント (0)

2018/02/04

第18回Redmine大阪の感想 #RedmineOsaka

第18回Redmine大阪の感想をメモ。
疲れているので、ラフなメモ書き。
書きかけなので、また後で書く。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

2018/2/3 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - Togetter

第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス!

【1】気象庁のRedmine利用事例の話は、本当に面白かった。
JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

気象庁内のシステムには、天気の予測シミュレーション、PM2.5やら色んな気象データのデータ収集と分析、シミュレーションなどがある。
それらのシステムは、全て内製化されている。
つまり、気象庁の研究者がプログラマとなり、実際に開発している。
この点は、JAXAなど他の官公庁とは全く違う。

だから、気象庁では、数値予報官という役職だけでなく、「プログラマ」という名前の役職も公式に存在する。
この点も他と大きく異なるのだろう。

【1-1】気象庁内では、Fortran、シェル、Rubyが一般的なプログラミング言語。
数値予測などの科学計算は過去の開発資産があるので、Fortranが使われている。
一方、仮想サーバー構築、バッチ処理、インフラ構築などは、シェルとRubyがよく使われている。

【1-2】気象庁では、部署もあるが、開発はシステムごとに、各部署を横断してプログラマや研究者が集まって担当する。
そのシステムに携わる集団を開発コミュニティと呼ぶらしい。
僕の理解では、マトリクス型組織のように思えた。
つまり、研究者やプログラマは部署に所属するが、天気予報、シミュレーション、共通基盤などの各システムの開発に携わるので、クロスファンクショナルなチーム構成になる。

但し、プログラマはどこか一つのコミュニティに属する運用になっているので、複数のコミュニティに所属することはほとんどない。
つまり、各開発コミュニティは縦割り組織に似たような雰囲気になっているみたい。

【1-3】最近は、欧米の気象庁ではPythonを使って数値予測プログラムを書く事例が多くなってきたので、彼らから、なぜまだFortranを使っているの、Pythonなら他言語のライブラリや資産も簡単に呼び出して使えるので、Pythonがいいよ、と言われているため、Pythonをこっそり試し始めている、とのこと。

この辺りの話を聞くと、海外の研究動向にも追随しながら、最先端の技術を導入しようという雰囲気が既にあるのだろう。

【2】気象庁では、各開発コミュニティごとに「あえて」Redmineインスタンスを複数個立ち上げた意図

バージョン管理は、2000年代からCVS、Subversion、Gitへ移行してきた。
2008年頃から、各コミュニティが独自にTracやRedmineを使い始めた。
原さんが海外の動向を踏まえて、各開発コミュニティがバラバラな開発基盤を持つのではなく、共通の開発基盤で運用すべきだ、と提案して、2014年頃から、RedmineとSubversion、Gitを共通の開発基盤として各コミュニティに提供する運用になったらしい。

その時、1台の物理サーバーに1個のRedmineインスタンスで運用する案も考えられたが、一つのRedmineの運用ルールに縛ることを目的とすると、各開発コミュニティから反発が起きるかもしれないことと、各開発コミュニティの組織文化を尊重することも考慮して、複数個のRedmineインスタンスを各開発コミュニティごとに立ち上げることになったらしい。

【3】2段階コードレビューの意図

【3-0】Redmineを導入した動機

そもそも、RedmineやSVNを開発基盤として導入しようという契機になったのは、コードレビューをしっかりやるべきだ、という考え方が、原さんだけでなく、各開発コミュニティでもそのような気運が盛り上がっていたから。

たとえば、天気予報の数値予測シミュレーションのようなプログラム開発では、理論物理や流体力学など科学理論から導かれる機能要件から、それに基づくプログラム実装が行われる。
しかし、かつてはバージョン管理すらなかった時代では、なぜそのような機能が実装されたのか、なぜそんなソースコードになったのか、記録が残っていない。
しかも、科学理論の発展やソフト・ハードの進化に伴うプログラム修正の履歴やその変更理由も残されていない。
だから、システムのリリース後に障害が発生して、トラブルが起きることがあったから。

【3-1】2段階コードレビューの意図

Redmineではコードレビューのプロセスはワークフローの一部として運用されている。

興味深い点は、気象庁のコードレビューでは、2段階レビューが踏まれていること。
まず、サイエンティフィック・レビューでは、科学者の観点で、数値シミュレーションが物理法則や物理の理論に基いた要件でコードが実装されているか、レビューされる。
おそらく、研究者同士の議論に近い雰囲気なのかもしれない。

次に、ソースコードがプログラミングの観点できちんと書かれているか、という立場でコードレビューされる。
Fortranのコーディング規則に従っているか、エラー処理、とか、この部分は我々のコードレビューと同じだろう。
また、物理法則の要件に従って実装されたプログラムを、実際に膨大な気象データに基いてシミュレーションするテストも行う。
このテストには、半日で終わることもあれば、数週間かかることもあるらしい。

たとえば、そこで性能が出なかったりすることが分かれば、その要件の実装はソフトウェア的に実現可能性が低いので、別の代替案を考える、などのフィードバックがコードレビューで行われる。

つまり、単なるコーディング規約のチェックだけでなく、たとえば性能要件を満たすかテストしてみた結果をフィードバックする、などの作業も行われている。

この辺りは、アーキテクチャのフィージビリティ・スタディ、つまり、アーキテクチャ実装のコスト・品質・納期のトレードオフを評価しているのと同じように思える。

これら2段階レビューは、既に欧米の気象庁では行われているので、日本でもやるべきだ、という提案があり、徐々に浸透しているらしい。
そういう内容を聞くと、Redmineチケットにコードレビューの結果を記録し蓄積していくことは非常に有意義な作業であることが理解できる。

【3-2】そして、git-flowによる並行開発とコードレビューが組み合わされて、上手く運用されるようになっているらしい。
つまり、ある要件を開発する場合、trunkからブランチを派生し、そのブランチ上で修正して、コードレビューが完了になれば、trunkにマージされる。
そのブランチはRedmineチケットと対応付けられて、Redmineチケットに要件や仕様、コードレビューの結果などが全て記録される。

【3-3】気象庁のRedmineでは、チケットのカスタムフィールドは使わないし、複雑なワークフローも設定されていないし、プラグインもほぼない。
Redmineのチケットに、コードレビューの指摘、結果、対応の記録を残すことに注力している。
そのおかげで、海外派遣で2年間、気象庁から離れた研究者も、帰国した後、Redmineのチケットを検索するだけで、すぐにプログラム開発の仕事に復帰できた、と言っていたらしい。

つまり、気象庁のRedmineは、進捗管理用のRedmineではなく、ナレッジ資産の為のRedmineなのだ。

【4】複数個のRedmineインスタンスで運用されるデメリットは、原さんによれば特に感じていない、と言われていた。
もし、他コミュニティのRedmineを参照したい場合、RedmineにはRSS機能があるので、RSSをフィードすれば、リアルタイムにチケット更新の状況を把握できる。

【4-1】また、Redmineという開発基盤が普及した後、Redmineの副次効果がいくつかあったらしい。
たとえば、あるコミュニティで、コードレビューはプログラム実装後に行うのではなく、プログラム実装前に関係者が集まって事前に内容を協議する運用を始めた所、他コミュニティでも、その運用はもっともだ、という意見があり、他コミュニティにも徐々に反映されたらしい。

つまり、あるコミュニティのRedmineのベストプラクティスが他コミュニティにも自然に横展開された、という事実を示唆している。

また、気象庁がいくら先進的な官公庁であっても、やはり役所なので縦割り組織の雰囲気がある部分はある。
しかし、Redmineを利用することで、コミュニティ内では、チケット経由のやり取りによって、研究者の知見やソース修正の履歴が記録されて、メンバー間の情報共有がスムーズになったらしい。

【4-2】さらに、データ処理など共通の処理を行う基盤担当のコミュニティがあり、そのコミュニティは気象庁の各コミュニティと関係するが、そのコミュニティのメンバーは、各コミュニティのRedmineにログインできる。
すると、各コミュニティでRedmineやコードレビューの運用ルールが微妙に違うので、同じように運用したい、という声が上がっているらしい。

つまり、現状はあえてコミュニティ単位の複数Redmineインスタンスで運用しているけれど、現場から、ボトムアップでRedmineの標準化を図るべきだ、という声が上がっているわけだ。
将来は分からないけれど、いつか、単一の標準Redmineにサーバー統合される可能性があるかもしれない。

【4-3】この点に関して、参加者からは、Redmineではトラッカーやカスタムフィールドがグローバル変数のような性質のために、使いづらくなっている。
Redmineにも、サイトのような機能を持たせて、各プロジェクトごとのトラッカーやワークフローを定義できるようにすれば、一つのRedmineインスタンスで、各プロジェクトごとにトラッカーやワークフローの自由裁量の権限を与えて運用できるのではないか、という指摘があった。
この意見は全くその通り。

以前も、東京Redmineでも似たような議論があった。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

【4】個人的には、Redmineは単一インスタンスの運用だけでなく、複数インスタンスの運用もベストプラクティスの一つになりうる、という発見があって、改めて深く考えさせられた。
この点はまたまとめる。

akipiiさんのツイート: "#RedmineOsaka #seakansai 気象庁の事例ではRedmineをナレッジ基盤として使う運用を目的としたら、色んな副次的効果も出てきた。単一の標準Redmineがベストの先入観があったけど、Redmine の複数インスタンスでも成功事例があるのは改めて衝撃を受けた。奥が深いね。"

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

【追記】
今回のRedmine大阪で、気象庁における開発管理の取り組みの公開資料に基いて、Redmineのチケット管理やGitによるブランチ管理やコードレビューについて数多く質問したのだが、「テストハーネスを用いたテスト自動化」の内容は聞き漏らしてしまった。
おそらく、Fortranプログラムをシェルからバッチで起動して、入力データと出力データを差分比較するようなテストを自動化する仕組みを取り入れていると思われる。
この部分のノウハウも聞きたかった。

気象庁における開発管理の取り組みの公開資料のP.52で下記の引用がある。

(引用開始)
asuca については、トランクへの変更がなかった場合も含めて、テストハーネスと呼ばれる仕組みを毎日自動で実行している。
これは
・ 理想実験
・ 石田ほか (2014) で述べられている、2 次元定常山岳波、周期境界条件における重力波、暖気塊のテスト、重力流、St-MIP
・ 静止大気実験
・ 2 次元スカラー移流
・ 3 次元モデル 3 による狭領域実データ実験
・ 局地解析
・ 接線形モデルチェック
・ 随伴モデルチェック
・ 局地予報
・ メソ予報
といった様々なケースについての実験 4 が、最新のトランクを用いて行われる。
入力データは毎日同じものを用いるため、入出力システムの変更等、予報結果を本質的に変える変更でない場合には、結果はビットレベルで一致する。
自動実行されたテストハーネスの結果は毎日メールで報告され、結果が前日とビットレベルで合わない場合にはそのようなメッセージが付加され、開発者が覚知することができる。
このため、トランクへのマージを行う改変については、テストの段階で開発者が自らテストハーネスを実行し、その結果についてもチケットに記録する。
また、変更の前後で結果が一致しない場合には、その理由や差の妥当性(分布図で見た場合の評価等)も含めて、記録を行う。
(引用終了)

| | コメント (0)

2017/12/26

第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」

来年2月3日に開催予定の第66回 SEA関西プロセス分科会&第18回 Redmine大阪の見所を書いておく。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

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

【1】(引用開始)
テーマ~「チケット管理システムによるソフトウェア開発支援と今後の課題」

今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。

気象庁|数値予報課報告・別冊 第63号(平成28年度) 数値予報モデル開発のための基盤整備および開発管理

気象庁におけるソフトウェア開発プロセスの事例で興味深い点は3つあります。

まず、一つのサーバー上で複数のRedmineインスタンスが運用されていて、各部署がそれぞれのRedmineインスタンスで異なる運用ルールを実施している点です。

次に、Redmineの特徴を十分に理解した上で下記のような運用ルールを展開している事が挙げられます。

(1)チケットの粒度は最初は気にせず、まずはチケットを作成して試行錯誤することを勧める事
(2)「No Ticket, No Commit!」ルールを徹底周知し、開発成果の信頼性向上や情報共有に役立てる事
(3)親子チケットによる進捗管理では、子チケットを五月雨式に作成しない点に留意する事

さらに、RedmineとGitを連携してgit-flowの開発プロセスを利用されているように、並行開発やコードレビューの仕組みを取り入れている点です。

以上のように、気象庁の事例報告を読むと、数値予報モデルの開発基盤と開発管理に、昨今のOSS開発では普通に行われているモダンな開発プロセスを上手く取り込んで運用されていることがよく分かります。

気象庁の担当者の方の事例講演を次回も聞くチャンスはそうありませんので、Redmineの初心者から、ソフトウェア開発プロセスに興味のある方まで、ぜひお越しください。

講演1
「気象庁の数値予報モデル開発における開発管理ツールの活用」

講演者:原旅人 様(はら たびと・気象庁予報部数値予報課予報官)

概要:
現在の天気予報は、スーパーコンピュータによる気象シミュレーション(数値予報)の
結果をもとに作られていて、そのためのソフトウェアのほとんどを気象庁の職員が
自らプログラムを作って開発しています。これらのソフトウェア開発は気象庁内で
組織横断的に、そして継続的に長いスパンで行われることが多いため、情報共有、
議論や作業の記録が大変重要であり、その支援ツールとして Redmine やバージョン
管理ツールを活用しています。

本講演では、気象庁の業務を簡単に紹介したのちに、気象庁におけるソフトウェア開発、
Redmine やバージョン管理ツールの利用の背景と経緯、およびその活用などについて
紹介します。
(引用終了)

【2】このたび、気象庁のRedmine利用事例を講演して頂けることになった。
個人的に聞きたかった内容ばかりなので、とても嬉しい。

上記の参考資料の通り、気象庁の開発プロセスでは、RedmineやGitなどの開発支援ツールを積極的に取り入れて、コードレビューや複数ブランチの並行開発、進捗管理などを効率化し、最近のオープンソース開発で主流となっている開発スタイルを実践されている。
気象庁というお硬い役所でも、モダンな開発スタイルを実践されているのに、未だにExcel主導のWF型開発に囚われた古い開発スタイルをやっているSIの方が多くて、時代遅れに感じてしまう時がないだろうか。

また、実際の開発業務では、気象庁の担当者自らがプログラミングして、天気予報の予測などの業務に役立てているのを読むと、自分たちの業務系システム開発とは違った別の側面が見えてきて、とても面白い。

たとえば、「Rubyは数値予報ルーチン関連のツールでも利用されている言語であり、管理者育成でも比較的少ない人的教育コストで管理可能という面を持ち合わせている」という記載から、気象庁にRedmineを導入しようとする壁は低かったのだろう、と推測する。
他に、欧米の気象庁に相当する官庁では数値計算にPythonを使うのが普及している、という事例を参考にして、Pythonスクリプトを記載していたりして、昨今の開発トレンドを積極的に取り入れようとする姿勢がよく伺える。

【3】そんな内容を考えると、気象庁では、先進的な技術を積極的に取り入れるという先取り精神が旺盛なのではないか、と思える。
実際、RedmineやGit等の先進的な開発支援ツール、RubyやPython等のプログラミング言語やライブラリを積極的に取り入れて、天気の数値シミュレーション等の業務に役立てているからだ。

Redmineコミュニティに関わるスタッフの立場としては、JAXAや気象庁という日本の大手官公庁でもRedmineを相当研究して利用されている、という事例が公開されることで、より普及が促進される効果もあるだろうと思う。

当日は、資料に記載されているRedmineやGitの開発ワークフローの背景、実際の気象庁の業務についても、色々詳しく聞いてみたいと思っている。

【追記】
ツイートした感想。

akipiiさんのツイート: "気象庁のRedmine 事例報告書を読み直してるけど、非常によく、Redmine によるチケット駆動の特徴を生かしてると思う"

akipiiさんのツイート: "Redmine チケットの粒度は最初は気にせず、チケット作成に躊躇せず、まずは試行錯誤してみたらいい。そのうち、チーム毎に運用は固まる、と。だから、あえてRedmine インスタンスを部署毎に立てて、運用とプロセスを任せている。"

akipiiさんのツイート: "気象庁では、チケット無しのコミット不可のルールを徹底周知して、Redmine とGitを連携し、さらにgit-flowに似たモダンな開発プロセスで運用されてる。お堅い官公庁の開発部署の方が民間企業より最先端かもしれない笑"

akipiiさんのツイート: "気象庁では、Redmine の親子チケットかんりでは、むやみに子チケットを五月雨式に作らない事に留意するよう促してる。そりゃそうだ。進捗率が90%になったのに安易に追加して50%に下がったり、仕様変更によるスコープ増大のチケットがどれか分からなくなる。アンチパターンでありそう"

| | コメント (0)

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を利用している事例でした。
実際のRedmine画面を見ることができて大変貴重でした。

(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のプロジェクトリーダー、Redmineのパッチを作ったりプラグインを開発する人達、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の運用パターン集~私に聞くな、チケットシステムに聞け」

SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」

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

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

すなわち、Redmineの利用者層は、前者の観点では、プロジェクトリーダーやPMO、品質保証部のような立場でプロセスを構築し運用する人達である一方、後者の観点では、プラグインを開発したりRedmineをカスタマイズする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に追随できるようにプラグインの修正が必ず発生する。
過去のRedmineのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古い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)

より以前の記事一覧