チケット駆動開発

2016/12/28

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

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

【参考】
JIRAに死を | TechCrunch Japan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2016/12/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/11/03

セル生産方式の発想はRedmineによるチケット駆動開発に似ている

セル生産方式の発想はRedmineによるチケット駆動開発に似ているのではないか、というアイデアのメモ書き。

セル生産方式 - Wikipedia

Q288.セル生産方式で生産性を向上させるための留意点について教えてください。|ビジネスQ&A|J-Net21[中小企業ビジネス支援サイト]

究極の「一人屋台生産方式」 | 長老の智慧 | 東洋経済オンライン | 経済ニュースの新基準

情報システム用語事典:セル生産方式(せるせいさんほうしき) - ITmedia エンタープライズ

製造業の「セル生産」は「1人屋台生産方式」と言われる。
部品や工具をU字型などに配置したセルと呼ばれるライン(作業台、屋台)で作業を行う。

元来、セル生産方式の目的は、多額の設備投資を必要とせず、従業員の創意工夫を生かして、手持ちの道具を使って、作業の効率化を目指す。
一人が複数工程の作業を兼任できるならば、一つの製品の完成に至るまでの作業人数を減らせる。
また、従業員も自発的に作業の効率化について考えて試行するので、モチベーションも上がる。
特に、多品種少量生産や受注生産に向いている生産管理手法だと思う。

そのような発想を活かせば、Redmineによるチケット駆動開発も製造業のセル生産方式の目的に似ている。
余ったPCやサーバーがあれば、オープンソースの管理ツールを導入して、作業の効率化について色々試せる。
プログラマ上がりのプロジェクトリーダーならば、集計マクロや集計プラグインなどを自作して、報告作りや管理作業を楽にしようと手を動かすはず。

たぶん、Redmineは日本人好みのツールなのではないかと思う。
開発基盤に設備投資しようという発想が会社になかったとしても、自分たちで手元にある無料の道具を使いこなして、プロジェクト管理に生かす。
お金がなくても、自分のちょっとした管理工数を使えば、即座にRedmineを導入してガントチャートですぐに進捗管理できる。
そこから、自分の現場で役立てるためのツールを自作したりして、自分たちでプロセス改善していく。

そういう創意工夫を促す仕組みがRedmineにはあるのだ。

| | コメント (0)

2016/10/19

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

JISA Digital Masters Forum2016 「~Digital Business in Action~いまこそ、ソフトウェアで「!(革命)」を~」というフォーラムが10/21金に東京で開かれるらしい。
その中の講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になるのでメモ。

【参考】
JISA Digital Masters Forum2016 「~Digital Business in Action~いまこそ、ソフトウェアで「!(革命)」を~」

JISA Digital Masters Forum 「JDMF2016」タイムスケジュール

JDMF2016プログラム詳細~ 『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』

JDMF2016プログラム詳細PDF

(引用開始)
22 経験報告
『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』
宮本 陽一(三菱スペース・ソフトウエア株式会社 鎌倉事業部 宇宙第一技術部)

当社既製品の派生開発では、非効率な再利用(場当たり的な再利用)という課題に直面している。
再利用性の効率を上げるアプローチとしてプロダクトライン型開発への早期移行を試みる中、当社の開発を支える開発手法や環境(チケット駆動開発基盤)にプロダクトライン型開発を融合させる方法(Feature on TiDD)を見出した。
本報告は、その融合方法と評価実験を行った結果に関する事例報告である。
(引用終了)

【1】チケット駆動開発基盤で使われるツールがRedmineであると仮定した時、プロダクトライン型開発とは、仕様が微妙に違うが似通っている多数の組込ソフトウェア製品の開発であろうと推測する。
チケット駆動開発とプロダクトライン型開発の相性が良いだろう、という考えは以前たくさん書いた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか: プログラマの思索

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

【2】チケット駆動開発とプロダクトライン型開発の相性が良い理由はいくつかある。
一つは、開発チームの組織構成とRedmineのプロジェクト構造が密接に関連すること。
むしろ、Redmineを導入することで、プロダクトライン型開発に向いた組織構造が目に見えるようになり、チーム形成が促進されるメリットがあると思う。

「Conwayの法則」「逆Conway戦略」なる言葉があるように、ソフトウェア工学的にはとても面白い部分。

【3】もう一つは、プロダクトライン型開発を支える開発基盤に構成管理が重要な要素を占めていること。
たとえば、プロダクトライン型開発の一番わかりやすい例は、iPod/iPhone/iPadのようなAppleの製品ファミリー群だろう。

製品は違うが、コアとなるOSや部品のほとんどは共有化されており、再利用が促進されるメリットがある。
しかし、製品仕様はほとんど同じだが微妙に異なるプログラムをそれぞれできちんと構成管理していくのは、実は非常に難しい、という経験はソフトウェア開発者ならば誰でも知っているはずだ。

メインラインモデル、Git-flowモデルのようなブランチモデルで製品系列ごとのプログラムを構成管理し、マージ作業していく必要があるだろう。

ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係: プログラマの思索

アジャイル開発とソフトウェアプロダクトラインの関係: プログラマの思索

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索

ソフトウェア再利用の概念: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

【4】一方、部品や共通ライブラリが共有化されているために、一つのバグが他製品にも影響し、マージするのも大変だし、それぞれの製品のリリース日にも影響してくる。

つまり、マージ作業だけでなく、リリース計画の整合性を取るのが管理作業として大変なのだ。
その部分は、Redmineのチケット管理のコピー機能を上手く使えば、一つのチケットから派生したタスクに対し、製品ごとにリリース日が異なっても、作業チケットは漏れ無く管理することはできるだろう。
しかし、それ以外の運用ノウハウも色いろあるはず。

つまり、メインラインモデルのような構成管理だけでなく、複数の製品系列のリリース計画の管理という部分も考慮に入れる必要があるだろう。
この辺りは組織や製品や案件ごとに制約条件が違うので、細かなノウハウを聞いてみたい。

| | コメント (0)

2016/09/23

ソフトウェア開発でバグ管理はなぜ必要なのか

「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。

【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)|teratail

BTSを制する者がソフトウェア開発を制する: プログラマの思索

akipiiさんのツイート: "数人の回答が面白い。僕なら「BTSを制する者がソフトウェア開発を制する」という言葉で回答するかな。「品質・バグ管理の必要性についてご意見をお聞かせください。故障票などに記載(Redmine的なものです)」 https://t.co/L5LKK7hDEd #teratail"

【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない!」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか?
(中略)

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
1.なぜバグが起きたのか?
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか?
→設計書から見落とした
3.なぜ見落としたのか?
→凡ミス
4.なぜ凡ミスが起きたか?
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか?
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)

ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。

BTSを制する者がソフトウェア開発を制する: プログラマの思索

Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。

【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。

製造業の品質管理が知りたいなら、たぶん、QC検定2級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。

QC検定とは? | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。

一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。

とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。

大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。

akipiiさんのツイート: "アジャイル開発はソフトウェア開発特有の考え方。製造業とは全く違う。 @koshian: アジャイルもスクラムも日本の製造業から来たものなのになぜ日本始めアジアで普及しないと言われてしまうのか。アジャイルはなぜアジアで普及しないか” https://t.co/2UtpidH2zo"

akipiiさんのツイート: "アジャイル開発が日本で普及しない原因の一つは、予算取りや設備投資の発想にあると思う。製造業は、工場への設備投資で、規模の生産性を生かして、大量に安く作り、市場を独占して先行者利益を得たい。政府も、設備投資は不景気のカンフル剤として有効だから、金利を下げて煽る。"

一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。

そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。

【4】個人的には、製造業で言われる5S活動(整理・整頓・清掃・清潔・躾)とか、3S(単純化、標準化、 専門化)という概念や活動は、ソフトウェア開発には適さないと思う。

たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

そもそも、メーカーと無関係のソフトウェア企業で、5S活動を社内で推進している所はあるのだろうか?
5Sの順番にも意味がある、とか、3Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか?
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか?
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。

| | コメント (0)

2016/09/15

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

Redmineが日本人好みのツールであるという仮説について、考えていることをラフなメモ書き。

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

akipiiさんのツイート: "@makopy_inside 分かります。Redmineのようなチケット管理ツール は本来はアジャイル開発に向いているのに、日本ではWF型開発の仕組みに取り入れられてる。原因を調べたい。"

akipiiさんのツイート: "@makopy_inside 発注者、受注側元請け企業、下請けPGの観点でそれぞれの事情がよく分かります。ソフトウェア開発がコモディティ化した現在、Redmineのようなチケット管理ツールで作業内容をやり取りしたい動機が多くなっている状況なのでしょう。そこにWF型開発があるみたい"

【1】Redmineが日本で普及しているのはなぜなのだろうか?
実際、世界で見れば、RedmineはTracの人気度にも及ばないらしい。
世界では、日本以外に、ロシア、韓国、台湾、チェコなど世界の東側でよく使われているらしい。

【1-1】「Redmineが日本人好みのツールである」という仮説については、以前書いた。

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

理由は下記の3つがあると思う。

(1)Redmineはライセンスが無料であり、導入や設置が簡単で、保守工数だけで十分であること
 日本のIT企業やソフトウェア開発の現場では、開発基盤にコストを払ってもいいという認識はないから。

(2)パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれていて、自社の開発プロセスにフィットしないから。
 「Redmineは組織の戦略に従う」「Redmineを組織構造や開発プロセスに従わせる」ことがやりやすいから。
 日本人は、ERPにせよ業務システムにせよ、自社の組織や業務に沿った仕様へカスタマイズしたい動機が強すぎる。
 特に、日本人の帳票レイアウトへのこだわりは尋常ではない。

(3)自分たちで機能拡張していく機運が生まれて、現場主導で業務を効率化していこうとする動機づけを強化してくれること。
 つまり「カイゼン」が自主的に生まれやすいこと。
 日本人はラディカルイノベーションよりもプロセス・イノベーション、持続的イノベーションの方が得意であり、Redmineはその気質に向いているツールである。

【2】Twitterでのやり取りでもう一つの仮説を思いついた。
それは「Redmineはアジャイル開発よりもWF型開発に向いているツールだから、日本の現場で適用しやすいのではないか」という仮説。

akipiiさんのツイート: "「JiraよりもRedmineの方がWF型開発に向いている」という仮説があるのか。 https://t.co/JLeLaXVYX7"

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

僕はそもそも、Redmineはアジャイル開発の作業管理に非常に向いていると気付いて、その裏にはチケット駆動開発という開発プロセスがあるのではないか、と思っていた。
しかし、日本の実際の開発現場は、ほとんどがWF型開発が主流のはずだ。

色んな人の話を聞くと、Redmineを使ってみたい理由は、いくつかある。

【2-1】一つは、ガントチャートがデフォルト機能であること、チケットの階層化でWBSを表現できることにあるみたい。
つまり、MSProjectやExcelのガントチャートをRedmineでWebで表現して共有できることにメリットを感じているみたい。

以前は、チケットを階層化した場合、親チケットの開始日・期日・進捗率・予定工数は、子チケットの属性値を自動で集計してしまうために使いづらい、という声があった。
本来は、WBSの100%ルールにより、親チケットは子チケットをロールアップすべきなのだが、実際の運用では、試行錯誤しながら階層化したい場合が多く、当初入力していた予定期間や予定工数が、子チケットを作った時点で消えてしまうのが使いづらい、と言われていた。
しかし、Ver3以後では、親チケットは「子チケットから独立」の設定が可能になったので、この点もクリアされている。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

特に昨今、オフショア開発やニアショア開発が普通になってきているので、オフショアチームや社外のベンダーと障害だけでなく、課題や作業の情報を共有したい場合、Webアプリでやりたい動機がある。
その時に、Redmineを導入すれば、ライセンスが無料だし、仮想サーバーにBitnamiを入れればすぐに稼働でき、ガントチャート画面上で進捗状況を即座に把握できる。
その時に、WBSの修正や操作は、直感的に気軽にやりたいニーズがある。

SIだけでなくメーカーでも、そのようなニーズがあるのだから、日本でもRedmineが相当に使われているのではないか、と思う。

【2-2】もう一つは、複数プロジェクト機能があるので、大規模な作業管理にも適用しやすく、派生開発やプロダクトラインのような製品ファミリーの並行開発にも向いている点だろう。

プロジェクトの階層化によって、複数プロジェクトの案件を横串で集計できるし、一つの案件で複数チームの作業管理を子プロジェクトで分割統治できる。
Redmineは本来は少人数のタスク管理に向いたツールだが、プロジェクトの階層化機能を使えば、100人月規模のタスク管理にも使えるだろうと思う。

SIで大規模な開発案件でタスク管理を共有したい場合はあるし、最近は新規開発よりもソフトウェア保守や派生開発の方が案件が多い。
だからこそ、気軽にプロジェクトをたくさん作れて、作業規模が大きくなっても管理したいニーズがあるのだろう。

その場合、Redmine上の組織構造としてはマトリクス型組織になるだろう。
すなわち、製品ラインと機能・職種というラインのマトリクスで、タスクと作業者が各プロジェクトにアサインされるので、メンバーは作業の役割を認識しやすくなるし、作業負荷も担当チケット数で把握しやすくなるメリットが出てくる。

【3】他には、日本企業の組織構造が機能別組織に偏っているため、Redmineを取り入れるとプロジェクト型組織の雰囲気が出てきて、組織が活性化するという点があるのではないか、と思う。

日本ではWF型開発が主流である理由の一つは、組織体制がWF型開発に最適化している環境になっていて、おそらく機能別組織のような縦割り組織が主流だからではないか、と思う。
しかし、機能別組織でも、Redmineを導入すると、体制上はPJ型チームになり、一つの有機的なチームが形成されやすい利点がある。

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

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

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

他に、IOT案件のように、ハードウェアチーム・ソフトウェアチーム・サポートチームのように気質が違う複数チームでやり取りしたい場合もある。
その場合、機能別組織に複数プロジェクト機能を対応付けて、それぞれのレイヤーで作業をチケット化して、管理する方がチケットの粒度もまとめやすいし、プロジェクトごとにチケット管理の特徴を出しやすい。

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

すなわち、古い日本企業の組織構造にRedmineを取り入れると、当初は想定しなかったメリット、つまりPJ型組織やマトリクス型組織の雰囲気が出てくる点があるのではないか。
一方、既にアジャイルな開発組織の場合、PJ型組織やマトリクス型組織をツール上に作る必然性はないので、Redmineを使うメリットがそう感じられないという点もあるのではないか。

つまり、Redmineにガントチャート機能があるから、という単純な理由よりも、日本の硬い組織構造をRedmineが柔らかくしてくれる所にメリットがあるような気がしている。
そうであれば、Redmineを組織変革のためのツールとして使えないか、と思ったりもする。
色々考えてみたい。

【追記】こんな意見もあり。

まいく@定時に帰りたいさんのツイート: "時代はScrumだJIRA使うぞー!って感じでJIRA導入したけど我々が本当にやりたかったのはマルチプロジェクトのWFだということが分かりRedmineにしたい"

| | コメント (0)

GitHubにかんばんライクなチケット管理機能が付いたらしい

GitHubにかんばんライクなチケット管理機能が付いたらしいのでメモ。

【参考】
[速報]GitHub、かんばんライクな新機能「Projects」発表。GitHub Universe 2016 - Publickey

[速報]GitHub、コードレビューのための新機能を発表。コードの行ごとや課題ごとにコメント可能。GitHub Universe 2016 - Publickey

Chrome Extension - GitHub をより便利にしてくれる『ZenHub』の使い方 | phiary

akipiiさんのツイート: "プルリクできる構成管理とカンバンが使えるタスク管理で十分かもしれない。RT @kyon_mm: なんかわからないけど、RedmineでできることをどんどんGitHubがやっていくのをみていて、おもしろい。そんなもんなんだろうなぁ。みたいな。"

Kさんのツイート: "GitHubにカンバンができたことで、ソフトウェア開発のみに特化した小規模なチームは、RedmineやJIRAやTracやTrelloなどの他のツールで管理する必要がより無くなるのかもしれないなぁ。"

Kさんのツイート: "@Will_meaning インフラ周りやプロジェクト管理としてのRedmineやJIRAなどの利用はまだまだ残ると思います。"

【1】GitHubはやっぱりプルリクエストが気軽にできるのがすごくいい。
ソース管理がソーシャルなやり取りになっているのがいい。
Wikiも使いやすい。

しかし、GitHubはIssue管理がしょぼかった。
タスクがどんどん出てくると、Issueが埋もれてしまうし、タスクのステータスが見えづらい。
チケットのワークフロー、チケット一覧のビュー、チケットの階層化などをやりたくなってくる。
チケット管理で全てのタスクの見通しを良くしたいと思うと、Redmineのチケット管理のような機能が欲しくなってくる。

プルリクエストが使える構成管理と強力なチケット管理の連携機能が欲しいのだ。

GitHubにかんばんのようなIssue管理機能が付けば、Redmineほどの厳格なチケット管理が不要ならば、十分だろうと思う。
今、プロジェクトがどの程度のタスクが滞留していて、今誰がどのIssueを担当しているか、見えれば十分と思う。

【2】チケット駆動開発が当たり前の環境になるまで普及した現在、チケット管理は今後どの方向に進化していくべきか?
僕の直観では、一つはアジャイル開発に適したビューの提供、もう一つは大規模な作業管理に向いたビューの提供だろうと思う。

アジャイル開発に適したビューとして、タスクかんばんとプロダクトバックログの2つがあり、スプリント管理ができて、アジャイル開発で使うメトリクスをリアルタイムに出力する。

一方、大規模な作業管理に向いたビューとしては、MSProjectのように、ガントチャート・リソースヒストグラム・EVMの3つのビューを交互に切り替えて操作できるような機能が欲しい。
さらに、PMBOKやITIL、ソフトウェア工学の観点のビューが付属していればなお良い。

その他に、サポートデスクのCRM、BPMのような事務処理ワークフロー管理の観点のビューもあれば、より汎用的に使えるだろう。
実装上は、入力されたチケットに対し、チケットのビューをRedmineプラグイン化するだけのことだ。

チケットのビューを誰がどんな時に、どんな目的で利用したいのか?

【3】実はRedmineは、日本の利用シーンとしては、アジャイル開発よりもWF型開発に向いているから、日本で普及しているのではないか、という仮説がある。
他の理由については下記に書いた。

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

その仮説とも合わせて考えてみたい。

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

より以前の記事一覧