コミュニティ

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)

2016/12/06

Unofficial Redmine CookingプロジェクトでRedmineカスタマイズのノウハウを皆で集めてみよう

第11回東京Redmine勉強会で告知した通り、Unofficial Redmine Cookingプロジェクトが始まった。
これは、熱いRedmineユーザによる、Redmineをカスタマイズする非公式プロジェクト。
下記のサイトで見れる。

【参考】
概要 - Unofficial Redmine Cooking - redmine.tokyo

第11回勉強会 - redmine.tokyo

【Unofficial Redmine Cookingの目的】
@akiko_pusuさんの解説が分かりやすい。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

(引用開始)
Redmineを運用されている方は、少なからず公式サイトでは載っていないような一部改造・カスタマイズするといった経験はお持ちではないかと思います。そういったノウハウを蓄積して、各自がRedmineをより効率的に活用できることを目指したサイトになります。

この記事は、上記サイトのアドベントカレンダー企画への参加として書かせていただきました。

過去の経験を元にしていますので、今ではもっと便利な方法があったり、クラウド環境だから気にしないという方も多いと思います。
「わたしの環境ではこういう方法を取っていますよ!」というのもあれば、ぜひコメントなどいただけると幸いです!
(札束で解決、というのももちろんOK!)
(引用終了)

【興味深い内容】
いくつかのチケットは興味深い。

【1】QA #252: メンテナンス / 移行 / バージョンアップのためRedmineを読み取り専用にしたい - Unofficial Redmine Cooking - redmine.tokyo

「サーバの移転・移行により新サーバにデータを同期させる間、データの整合性を担保するため、Redmineの参照は許可するけれど、更新は全て止めたい」ような運用をしたい。
Redmineを普通のミッションクリティカルなWebシステムと同様に運用したいわけですね。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

【2】QA #246: Redmine 管理-「トラッカー」-「サマリー」の表示枠を固定にしたい。 - Unofficial Redmine Cooking - redmine.tokyo

サマリ画面のトラッカー・標準フィールド・カスタムフィールドの表示(ヘッダ行)を固定するように、Excelのウィンドウ固定機能を実現させたい。
確かに、この機能があれば、Excelライクに扱えるので便利。

Redmine本家には既にパッチがあるらしい。

Patch #20287: Administration: Using grids instead of tables - Redmine

【3】QA #254: ガントチャートの画面上で直接編集したい - Unofficial Redmine Cooking - redmine.tokyo

この要望はすごく多い。
MSProjectに慣れているほど、似たような機能が欲しくなる。

この改善要望は、Ver0.8の頃から、一部ユーザがパッチを提供していたが、今の最新バージョンにパッチはない。
たぶん、RubyよりもJavaScriptのプログラミングがすごく必要。

Feature #2024: gantt chart editing - Redmine

最終的には、有償プラグインを入れるしかないと思う。

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

社内に野良Redmineがたくさんあって、統合したい機運が高まった時、このノウハウは参考にしたい。
但し、野良Redmineの数が多くなると移行リスクが高くなるので、アジャイルウェアさんに依頼することになるのかな?

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

【5】QA #237: Redmineカスタムフィールド表示改善(CF1列表示、項目見出し、表示調整) - Unofficial Redmine Cooking - redmine.tokyo

QA #231: チェックボックスのカスタムフィールドを2列で表示したい - Unofficial Redmine Cooking - redmine.tokyo

チケットにカスタムフィールドをたくさん追加すると、レイアウトを色々変えたくなってくる。
テキストエリア欄を広くしたり、チェックボックスの配列を変えたり、とか。
ソース修正パッチ以外にも、ViewCustomizeプラグインで対応する方法もあるだろう。

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え!: プログラマの思索

【6】QA #241: カテゴリをサブプロジェクトで継承利用したい(バージョン同様) - Unofficial Redmine Cooking - redmine.tokyo

この要望は随分前からあがっていた。
この要望が実現されていないために、カテゴリ機能はほとんど使われない組織も多いのではないか。
そろそろRedmine本体でも実現して欲しい。

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

【7】QA #251: チケットにユーザ情報の値を表示させたい - Unofficial Redmine Cooking - redmine.tokyo

REST API経由でTableauに読み込ませる運用をしているので、Redmine本体のチケットの属性(カスタムフィールド)に作出属性を保持させた方が運用が楽、という意図らしい。
確かに、Redmine本体のカスタムフィールドで作出属性を保持できれば、外部システムで集計する処理が楽になるだろう。

そんな機能を実現するcomputed_custom_fieldプラグインが使えるといいが、上記のコメントを見ると上手く使えないみたい。

Redmineのカスタムフィールドを導出属性にしてしまうプラグインredmine_plugin_computed_custom_field: プログラマの思索

【8】いくつかのチケットには、Redmine本家のコントリビュータである@g_maedaさんのコメントも見られる。
こういう場で蓄積されたアイデアやパッチが、Redmine本家に届けられたらいいなと思う。
もし気に入った機能改善があれば、Redmine本家のチケットに「+1」を追記して、その思いをJPLに届けてほしいと思う。

| | コメント (0)

2016/12/05

AgileTourOsaka2016の感想

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

| | コメント (0)

2016/11/27

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT

第11回東京Redmine勉強会が無事終了しました。
60名以上の参加者、10人の講演者、10人のスタッフの皆さん、お疲れ様でした。
感想をラフなメモ書き。

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

第11回勉強会 - redmine.tokyo ~「Redmineの多用性とその進化」(2016/11/26) - Togetterまとめ

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

【1】今回の勉強会では、LTを含めて10人の講演があって盛り沢山でした。
Redmineの運用事例や技術事例がこれだけたくさんあること、参加者も多いことを考えると、Redmineのマーケットはかなり広がっているのだろう。

グループディスカッションで参加者の属性を聞いてみると、Rubyエンジニアは少なく、情報システム部門でRedmineのシステム管理者、Redmineのインフラ運用担当者、自社内の部署にRedmineの運用を啓蒙活動している人達が多いように感じた。
他に、Redmineプラグイン作者、Redmine本を出版した経験のある人、Redmineのサービスやカスタマイズを行なっているベンダーの方もいるので、多用な属性を持つ人達がいるおかげで、場がとても盛りがったと思う。

もちろん、これから社内にRedmineの利用普及を考えている参加者もいたので、今回のテーマ「Redmineの多用性とその進化」は参考になったのではないだろうか?

kazuphさんのツイート: "Redmine Plugin開発者と本体のチケットをいじれる人、本を出版した人がいる会場。ものすごくRedmine偏差値高い。 #redmineT"

kuniさんのツイート: "redmine勉強会行って来ました。自分はこれから社内で広めていく立場なので、色んなシステムを構築している人達がいて励みになりました。次も参加したいです(*^^*)"

【2】@kazuphさんのIOT企業におけるRedmine運用事例で面白いと思った点は二つ。

【2-1】一つは、ソフト屋とハード屋では、チケット管理の観点や粒度が異なること。

ソフト屋のチケットの粒度はせいぜい数時間単位のものが多く、小さい。
だから、チケットもすぐにCloseされて、毎日の進捗もすぐに見えやすく、はかどっている感じが分かりやすい。

したがって、カンバンLikeなチケット管理の運用の方が回りやすい。
だから、Agileプラグインのように、カンバンボードのようなRedmineプラグインが重宝される。

一方、ハード屋はガントチャートが大好き。
ガントチャートでスケジュール管理を見たい。
その動機にも理由はある。

なぜなら、仕入→設計→製造→品質チェック→出荷の生産プロセスでは、どうしても各工程で作業待ちのリードタイムが発生しがちなので、チケットの粒度は大きくなりやすい。
たとえば、部品や原材料を発注して入荷するまでに、数日間のリードタイムが発生するので、設計や生産プロセスのチケットはすぐに着手できず、チケットの粒度は数日~数週間のレベルになりやすい。

したがって、ガントチャートで見る方が、作業予定やクリティカルパスを把握しやすい。
むしろ、かんばんで作業を管理すると、毎日のチケットの動きが少なく見えるために、経営者から見ると、作業が遅れているように見えて問題になるらしい。
つまり、リードタイムの長いチケットが滞留してしまって、目立ってしまうらしい。

すなわち、ソフト屋はアジャイル開発、ハード屋はWF型開発にどうしてもなりやすい。
特に、ハードウェアの作業は、特殊部品の納入がなければ生産できないとか、高価な機械が1台しかないので生産の稼働率が限定されてしまう、などの問題がどうしても出てくる。
すなわち、各工程の作業でリードタイムという作業待ち時間がどうしても発生する。
したがって、ハード屋のチケット管理では、事前にチケットで先行・後続関係を設計して、各工程のリードタイムが長くならないように、ボトルネックが発生しないように、生産計画の精度を高める必要が出てくる。

その観点が、チケットの粒度やガントチャート重視につながってくるわけだ。
そう考えると、チケット管理にTOCの発想を取り入れて、ボトルネックの稼働率を高めるようにチケット管理できないか、とか、CCPMのプラグインがあれば、とか思ったりする。

【2-2】もう一つは、社内にRedmineに相当詳しい人がいたおかげで、Redmineの運用がスムーズに進められたこと。
社内のRedmineエバンジェリストである彼がすぐにAWSにサーバーを立ち上げて、すぐにRedmineのワークフローなどを初期設定してくれて、すぐに運用可能な状態になった。
そして、Redmineエバンジェリストが勝手に動いて、Redmineのベストプラクティスはこうなんです!と強く主張して、社内のサポート部隊や事務員に説明会を開催して、Redmineの啓蒙活動をしてくれたらしい。

お話を聞くと、中途入社されたSEがRedmineに相当詳しかったそうで、Redmineの立ち上げ、設定、運用、プロセス標準化、ベストプラクティスのノウハウを既に持っていたらしい。
だから、Redmineの使い勝手に関する改善要望もそのエバンジェリストが受け付けて対応してくれたらしく、Redmineの利用度も上がっていったらしい。
以前はSlackに課題が上がっていて、Slackの内容をチケットに転記していたが、現在は、Redmineのチケットに直接記入する運用に自然に定着したらしい。

その話を聞くと、Redmineの啓蒙活動を行うRedmineエバンジェリストが社内に必要なのだ、と思う。
そういう人がいるので、サポートデスクの作業管理や課題管理などで困っている、という話があっても、すぐにRedmineを立ち上げてくれて、その日のうちから運用を開始できる手軽さがある。
しかも、チケット駆動のベストプラクティスはこれだ!というノウハウもネット上に溢れているので、自分なりに運用手順をWikiにまとめておけば、すぐに社内メンバに説明会を開いて普及を促進することもできる。

IT技術者なら問題無いだろうが、工場の作業員やサポートデスク、事務員の人はチケット管理にそんなに慣れていないだろうから、そういう説明会などのフォローは重要だ。
この辺りはいわゆるERP導入時に、ユーザ説明会によるフォロー作業と同じ。

【3】@mattaniさんの講演は、Redmineを簡易CRMとして使う話も面白い。
Redmineをカード型データベースとみなし、チケットをサーバー情報や問合せ情報のマスタとみなす。
つまり、チケットでマスタ管理している。

また、「チケット in チケット」というアイデアで、チケットの説明欄にWikiListプラグインを用いて、特定のチケット集計をサマリ表示させることで、カード型DBとして使っている。
さらに、ViewCustomizeプラグインを使って、カスタムフィールドを説明欄の下部に配置したり、プロジェクトメニューでプロジェクトを選択したタイミングでチケット一覧に遷移するように工夫している。

あくまでもCRMの簡易版の利用事例だが、ViewCustomizeプラグインを駆使したり、運用ルールを工夫すれば、CRMの代替機能としてRedmineを使うこともできるだろう。

【4】アジャイルウェアの堂端さんの講演では、20数個の野良Redmineを1個のRedmineに統合した事例。
プロジェクトは1400件以上、履歴は100万件以上、ワークフローの遷移が6万以上という野良Redmineをデータ移行して、一つのRedmineに統合できたとは恐れ入る。
しかも、統合作業をプラグイン化したらしい。

あきこさんのツイート: "お客様の現場を舞台にした複数Redmineの統合のお話。20台以上乱立してて管理者も別。プロジェクト単位でRedmineインスタンスが立ち上がっている。でも実際は1台の物理サーバに乗っかっている!Oh! #redmineT"

松谷 秀久さんのツイート: "20台のRedmineサーバを統合するのはけっこう骨が折れそう/心も折れそう #redmineT"

あきこさんのツイート: "2ヶ月くらいかけ休日を中心に調整。最大のものは48時間くらいで統合できた。統合後のRedmineの規模がものすごいことに!プロジェクトは1400件以上、履歴は100万件以上。ワークフローの遷移が6万以上。。。でも、一元管理することで見えてきたものがある。#redmineT"

野良Redmineをデータ移行して統合するポイントはいくつかあるらしい。
話を聞くと、SQLiteの中間DB上で、それぞれの野良RedmineのチケットIDを変換して、統合Redmineへデータ移行するように設計したらしい。
確かに、ERPのマスタ移行でも、中間テーブルでユーザCDや商品CDを変換するバッチプログラムをよく作ったりする。

あきこさんのツイート: "統合の苦労話スタート!課題1: IssueIDがDBの自動採番に基づくため番号が重複する。課題2: トラッカーが色々。賢いエンジニアさんが統合用のツールを作った!!(すばらしいー)IssueIDが記載されているあらゆるテーブル、フィールドを検索して書き換え。#redminet"

但し、Redmineでは特有の課題がいくつかある。
たとえば、チケットIDがWikiやコミットログなどに散在しているので、それらも一括置換する必要がある。
たとえば、添付ファイルは別ディレクトリに保存されているので、それらも考慮する必要がある。
たとえば、Wikiの記法がTextileやMarkdownなどで混じっていた場合はどうするのか?
たとえば、Redmineプラグインが多数使われていた場合は、大丈夫なのか?

やっさんさんのツイート: "tail -f pinzo.log: RedmineでMarkdownに切り替えやすくするプラグインを作った これで任意にMarkdownとTextile切り替える出来ますよ #redmineT https://t.co/t4fJGRTbR0"

話を聞くと、野良Redmineは、最初に作られたRedmineをベースに各部署で作られたのでどれもバージョンが同じだったので、マシだった、とのこと。
また、野良Redmineを統合するRedmineプラグインとして作成したが、Redmineのバージョンに依存するので、他のバージョンで使うにはカスタマイズが必要であるらしい。

おそらく、統合プラグインは、データ移行処理をrakeによるバッチ処理で実装しておき、プラグイン設定画面で初期設定して、移行作業をキックする仕組みではないかと想像する。
実際、MantisやTracからRedmineへ移行するrakeタスクがRedmineにあるので、それを参考にして流用できるはずだ。

RedmineMigrate - Redmine

また、RedmineRake - Redmineには、添付ファイルを移行するrakeタスクもある。

野良Redmineをデータ移行できる統合プラグインは、有償プラグインであってもニーズはすごくあるだろう。
アジャイルウェアで販売しないのかな?

【5】Redmineのバージョンアップに関して、@g_maedaさんと@netazoneさんの事例があった。
やはりRedmineプラグインを入れていると、Redmine本体のバージョンアップに追随できなくなるらしい。

あきこさんのツイート: "プラグイン大量死の歴史!!!1.3系でルーティング変更、1.4系でbundler, 2系でRails...., jQueryへの変更.... #redmineT"

マサユキ@C91 2日目(金)東ア25bさんのツイート: "2011年、2012年を乗り越えたて現存するプラグインは歴戦の勇士ということか。redmine公式にあるプラグイン紹介で登録日が4年前とか #redmineT"

過去の歴史を振り返ると、Railsのバージョンアップ、Prototipe.jsからJQueryへの変更など、プラグインが大量死するタイミングが4回以上もあった。
最近は、RedmineでScrumを運用できるBacklogsプラグインがついに放置された。

個人的には、プラグインを使う時は、Redmine勉強会に参加しているプラグイン作者のプラグインに限定するようにできるだけしている笑。

1点気になったのは、@netazoneさんの事例で、@akahane92さんのチューニング手順を元に、@clearcodeさんの全文検索プラグインを入れた所、全文検索がかなり高速化されたらしい。
Redmineに残された弱点の一つが、検索ボックスからの全文検索が遅い点なので、ますます@clearcodeさんの全文検索プラグインは使いたくなってくる。

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

【6】@akiko_pusuさんのRedmineプラグインのテスト方法の事例も興味深かった。
testunitでRedmineプラグインのテストを自動化した動機は、OSSと言えども問合せが多いので、それを削減したい。
たとえば、プラグインのインストールで詰まった、とか、バージョン依存で動かない、とか。
プラグインと言えども、テストの自動化は、ソフトウェアの品質を高めるのに役立った、と。

@akiko_pusuさんの事例で参考になった点は、OSSのアプリであれば、フリーで使える開発基盤のWebサービスがたくさんあることだ。
CIツールwerkerや静的コード解析SideCIなど、色々あるらしい。
そういうのを聞くと、趣味で開発するOSSツールは、これらフリーの開発基盤を使いまくる方が、作業も効率化できるし、品質も向上できるメリットがある。

【7】グループディスカッションや懇親会で参加者と話をすると、自社でRedmineを普及させる役職の人たちが多く、既にその活動を行なっていて、数多くのノウハウを蓄積しているように見受けられた。
つまり、彼らはRedmineエバンジェリストとして、社内でRedmineを利用しやすくしたり、プロセスの標準化や作業の効率化、プロジェクトの見える化を実現するように活動しているみたい。
たとえば、自社の各地方にある事業所へRedmine説明会を毎回開催するとか、各部署にRedmine説明会を開いている、みたいな話が出ていた。

その活動を通しているうちに、Redmine特有の癖、いろんな業務におけるチケット管理のノウハウなどの知見がたまり、その内容を経験事例として発表されている人達もいる。
そういう話を聞くと、Redmineが日本のSIの現場で普及するにつれて、日本各地でRedmineエバンジェリストが出現しているように見受けられる。

そういうRedmineエバンジェリストが社内にいると、Redmineの立ち上げや社内説明会のコストが低いので、非常に運用しやすくなるだろう。
また、チケット管理はRedmineでなくても、JiraやTrelloにもノウハウを流用できるだろうから、チケット駆動開発という概念をより普及しやすくできるだろう。

個人的には、各地でRedmineエバンジェリストがバラバラに活動してノウハウが閉じこもっている状況を打破して、勉強会のようなオープンなコミュニティで、それらノウハウを情報共有できるようにしたい。
そうすれば、今からRedmineを使う初心者も参考になるし、既に運用中の経験者にも参考にできる情報を提供できるだろう。
つまり、現場の業務改善のツールの一つとしてRedmineがあるので、Redmineの運用で蓄積された皆のノウハウをベストプラクティスとしてまとめてみたいのだ。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。皆様ありがとうございました。改めてRedmine は多分日本人好みのツールなのだろうと感じた。自分達の現場で業務改善したい時に手元にフリーでそれなりに使えるツールがあって、現場に部分最適するのは日本人の得意技。"

【今日の資料はコチラ】

| | コメント (2)

2016/11/20

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

11/26土に開催される第11回東京Redmine勉強会の見所についてメモ。

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

redmine.tokyo 第11回勉強会 - connpass

【1】10月下旬にこっそり告知したら、あっという間に満員御礼になりました。
いつもながら東京では、Redmineユーザが多い事実を感じます。

【2】今回の勉強会の主なテーマは「Redmineの「多用」性とその進化」です。
テーマに関しては、スタッフ内で議論が色々ありました。

【2-1】Redmineや「チケット駆動」という概念が日本ではかなり普及しています。
実際の現場では、IT業界だけでなく、多方面の業界で、色んな職種を持つ人達がRedmineを利用している。

すると、本来のタスク管理という使い方だけでなく、インシデント管理やヘルプデスクのサポートなどにも使われていて、色んな問題点や課題が発生している。
そこで、「どんな使われ方がされているのか?」という観点で、@kazuphさんのIOT企業の事例、@mattaniさんの簡易CRM利用事例の講演を用意しました。

個人的には、@kazuphさんのIOT企業の事例はとても興味があります。
以前Blogで紹介しました。

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

Blogの内容を読むと、ポイントは、ハード部隊やソフト部隊、カスタマーサポートのような気質も技能も異なるチーム間連携にRedmineが有効であった、という点でしょう。
利用ユーザが増えて、利用する組織が増えると、チームごとの組織文化も異なってきます。

その場合、そういうチームと作業や情報を連携して、いかにシナジー効果を生み出すか?
そして、どのような開発基盤や運用ルールがあれば、スムーズにチーム間連携ができて、1+1=3のようなシナジー効果を発揮できるのか?

また、「導入にはRedmineエバンジェリストみたいな人が必要」という指摘も興味深い点です。
Redmine特有の癖をいかに生かすのか、あるいは、組織にマッチさせたのか?

実際の現場でRedmineを運用して駆使されているだけに、その経験談を聞いてみたい所です。

【2-2】大規模な組織へRedmineの運用を拡大した時、どのような問題点や課題が出てくるのか?という問題意識から、今年は大阪と東京で過去3回のRedmine勉強会がありました。

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

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

Redmineと組織構造の関係性については、第15回RxTstudy 『大規模組織や 多様な業務における Redmineの課題』で発表しましたが、他の課題もあります。

スタッフからあがったテーマは「Redmineのバージョンアップやデータ移行で留意点はあるか」という点です。
Redmineも誕生してから既に10年経ち、Redmineを運用している現場でも3~8年くらい使っているところもあるでしょう。

たとえば、当初は3人で使っていたRedmineが100人以上に使われて、SIの現場で勤務時間中はフル稼働している状況になると、バージョンアップ作業や保守作業がやりにくくなってきます。
特に、バージョンアップやデータ移行作業は、RedmineがSIの事実上の基幹業務システムになった状態では非常に神経質にならざるをえないでしょう。

その場合、どんな点に留意して、バージョンアップやデータ移行をすべきなのか?

ファーエンドテクノロジーの@g_maedaさんにRedmineバージョンアップの注意点、アジャイルウェアの堂端さんに「乱立してるRedmineを一つにまとめる話」について講演してもらいます。

特に、「乱立してるRedmineを一つにまとめる話」の内容は、十数個のRedmineインスタンスが部署ごとに別々に存在していたが、プロセス標準化の機運が盛り上がって、1個のRedmineインスタンスに統合した時の経緯と苦労話になります。
データ移行をどこまで行なっているのかは聞いていませんが、各部署のRedmineインスタンスのワークフローを抽出し、社内の標準ワークフローを策定する方向に持っていった、と聞いています。

Redmineのデータ移行と言えば、奈良さんの講演「Redmineサーバ統合事例」が真っ先に思い出されますが、単純なデータ移行だけでなく、標準プロセスの策定作業に、Redmineのワークフローデータが使われたこと、その標準プロセスがトップダウンではなく、散在したRedmineから抽出してボトムアップに作っていった、という点が面白いのだろうと思います。

【2-3】また、「Unofficial Redmine Cooking」というプロジェクトを開始して、東京Redmine勉強会のスタッフやユーザを中心に、Redmineの改善要望やパッチの情報を交換しよう、という要望もスタッフからあがりました。

たとえば、Redmineユーザメーリングリストでも、Redmineの画面UIの改善要望が非常に多いです。
Redmine利用者が増えてきたので、現場ごとにRedmineをもっと使いやすくしたい、という声が多く上がっているのでしょう。

そういう質問を実際にやり取りできる場を設けて、Redmine本家に情報提供ができたらいいな、と思います。

Redmine Users (japanese) - Google グループ

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え!: プログラマの思索

【3】他にも、最近公開されたRedmineのサービス「Planio」の紹介、会場を提供して頂いたテクマトリクス様における「RedmineとElectronで新人の育成状況を可視化した事例」などがあります。

さらに、@ryouma_nagareさんのLT「開発環境の認証を改善してRedmineを社内標準にした話」は、RedmineのLDAP設定に関する話なので、とても興味があります。
Redmineのログイン認証を社内のLDAPサーバーと連携させることで、Redmineユーザ管理や保守をかなり楽に出来ます。
実際、Redmineを外部に公開している場合、退職したユーザをRedmineから削除する運用作業は、ユーザ数が増えるほど非常に面倒になってくるので、LDAP認証をかませれば、LDAPサーバーの方でユーザ管理してもらい、その情報を同期するだけでいい。

しかし、実際に運用した人の話を聞くと、色んな留意点やノウハウがあります。

たとえば、ユーザが退職した場合、Redmineユーザに登録されたメーリングリストのメールアドレスから削除しないと、通知に失敗する。
たとえば、自社の社員のLDAPサーバーと協力会社の常駐メンバーのLDAPサーバーが異なる場合、どのように設定して注意すべきか?
実際、Redmine本家にも下記チケットで要望が上がっているが未対応のまま。

Feature #9216: Support of multiple LDAP servers for authorization - Redmine

この辺りのノウハウも、もっと聞いてみたい。

【4】講演LTを含めては10本近くあって盛りだくさんですが、グループディスカッションの場ももうけています。
テーブルごとにざっくばらんに話してみながら、お互いの苦労話や知見、ノウハウを情報交換してもらえればと思います。

【追記】そういえば、「入門Redmine第5版」が公開されていました。
出版日は2016/12/1だそうです。
作者の@g_maedaさんも来られるので、もしかしたら、最新の出版の状況も披露してくれるかもしれません。
お楽しみに。


| | コメント (0)

2016/07/31

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

JAXAのRedmine利用事例に関する講演会が無事に終了。
多数の参加者の皆さんも満足できたと思います。
スタッフとしても、講演者と参加者の方に感謝です。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

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

第65回 SEA関西プロセス分科会&RxTStudy15 「チケット管理システムによるプロセス支援と今後の課題」 #RxTStudy - 日々の御伽噺

MAEDA, Goさんのツイート: "JAXAのRedmine利用事例の論文( https://t.co/xcay83LGeB )の英語訳が公開されています。 https://t.co/3pt5OnnPXe"

【1】JAXA様のRedmine利用事例の講演では、実際の画面の一部も見せてもらうことができて、JAXAの運用ルールが非常に理解できた。
JAXAの動機としては、マネージャの観点では、経営層に、投資対効果のメリットをアピールするために、Redmineでデータを収集して、定量データを報告したい、ということがあったらしい。

だから、カスタムフィールドを増やして、カスタムフィールドで集計しやすくする運用は必須だった。
しかし、ワークフローを複雑にしたくなかったので、トラッカーとロールを増やさないようにしたかった。
そこで、ロール設定のORルールやカスタムフィールドのANDルールを生み出した、と。

僕の疑問は、カスタムフィールドを増やしたがるのはマネージャの観点であり、入力項目が多いと億劫になりがち。
そのようなデメリットはないかと思ったが、JAXAの回答としては、過去のお手製BTSでは、入力項目がテキストボックスでデータの揺らぎがあり、集計しづらかった。
だから、Redmineのカスタムフィールドで入力項目の書式を定型化して、集計しやすくするルールは必須だった。

また、カスタムフィールドのANDルールによって、各プロジェクトごとにカスタムフィールドのON/OFFを制御しているので、ユーザにとっては必要なカスタムフィールドしか表示されていないので、あまり気にならないメリットもあると理解できた。

【2】パネルディスカッションでは、ISO9001やIT内部統制をRedmineで実現して、実際にコストを削減できるか、という点も質問してみた。
ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索にも書いたけれど、日本のメーカーではISO9001の導入は必須の会社が多い。
しかし、ISO9001のプロセスが重荷になり、逆にコスト増になっているのではないか、という現状が多いのではないか。

JAXAの回答では、ISO9001をRedmineで運用するのはうまく回っている。
ISO9001は指針をしめしているだけであり、QMSの実装は現場ごとに実現して良い。
ISO9001やQMSの目的を十分に理解できていれば、その手段をRedmineで実現してもいいし、実際にそれで運用を上手く回す事ができる、と。
逆に、そんな質問は、ISO9001の目的と手段を取り違えて運用しているのではないか、という指摘を頂いた笑。

僕の感触としては、RedmineでISO9001で運用する場合の課題は、チケットの全文検索と、証憑などのエビデンスというOfficeファイルのファイル検索にあると思っている。
監査の時に、必要な情報をRedmineの全文検索からチケットを抽出できるか、その証憑となるExcelファイルを共有ファイルサーバーから取り出せるのか。

JAXAの方や@akahane92さんの話を聞くと、Redmineチケットに情報を集約し、チケットの関連付けや構成管理ツールのリポジトリ連携によって、トレーサビリティは実現できるし、検索もできる。
また、JAXAの運用では、DMSFプラグインを入れることで、ファイル検索と必要な情報の分類もできている、とのこと。
たしかに、DMSFプラグインでその課題はクリアしているわけだ。

【3】僕の発表資料「大規模組織や多様な業務におけるRedmineの課題」では、僕が理解しているJAXAの運用ルールの紹介と、組織構造がRedmineに与える影響事例としてPJ分割ルールについて話してみた。
JAXA運用ルールの噛み砕いた紹介は、参考になったという声があって、良かった。
また、機能別組織・事業部制組織・PJ型組織・マトリクス型組織という4つの組織構造に対し、Redmineが有効に使える部分の提示、そして、Redmineプロジェクトと組織構造の関連の説明も、一部の人にとっては、すごく参考になった、という声も聞いて、作った甲斐があった。

個人的には、組織構造がプロセスやツールに影響を大きく与えているのは確かだし、日本では、自社の組織構造や組織のルールに、プロセスやツールを従わせるようにしたい欲求が強い。
そういう状況において、Redmineの機能の柔軟さ、豊富さがメリットになっている部分を感じている。

【4】他の資料はコチラ。

| | コメント (0)

より以前の記事一覧