「入門Redmine第5版」が出版されました

「入門Redmine第5版」を@g_maedaさんから頂いたので、感想をメモ。

【参考】
「入門Redmine第4版」が出版されました: プログラマの思索

入門Redmine 第2版: プログラマの思索

入門Redmine 第5版｜書籍情報｜秀和システム

【1】数あるRedmine本の中で、Redmineのバージョンに追随して最新化されている本は「入門Redmine」くらいだろう。
最新版を購入しておけば、逆引きリファレンスとして使えるのが便利。
チームや会社に1冊あれば、引き継ぎや説明会で使えるだろう。

【2】「入門Redmine第5版」で興味深い点は、いくつかある。

【2-1】Redmine利用事例のトップに、JAXAの事例「スーパーコンピュータ「JSS2」の運用チームを支えるRedmine（JAXA）」がある点だろう。

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

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

JAXAスーパーコンピュータ活用課における業務で、実際に新規登録中のチケットの画面キャプチャがあるのが非常に面白い。
ISO9001監査にも使えるように、カスタムフィールドを準備したり、説明欄に記入すべき事項を記載したりしている。

また、藤田課長が「もっと楽に管理できるツールはないか」という質問を投げた時に、木元研究員がRedmineエバンジェリストとして振る舞った場面も興味深い。
社内にRedmineエバンジェリストがいたおかげで、即座に利用環境が整い、初期設定や利用者への説明なども上手く進んだらしい。

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

そんな内容を読むと、まさに先日の東京Redmine勉強会の講演と同様に、社内のRedmineエバンジェリストという存在がすごく大きかったのだろうと思う。
そして、そういう役割の人達がごく稀ではなく、多少だろうが生まれてきつつあるように思える。

チケット管理はRedmineでなくても、JiraでもTracでも同様に扱える運用ノウハウだから、そういう人達が増える背景なのかもしれない。

【2-2】もう一つは、Redmineの機能をレイヤ構造で表現していることだろう。
分かってみれば当たり前の構造だろうが、利用者観点で機能が上手く分割されている。

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

また、Redmineエバンジェリストの木元さんいわく、Redmineの機能のうち「文書」「ファイル」はあまり力を入れていないように思えるため、使いにくい。
そこで、DMSFプラグインを導入して、文書管理の機能拡張を行った。
そのおかげで、運用がかなり楽になった、と。

DMSFプラグインはごく一部のユーザは熱烈に使っているが、Redmineのバージョンアップに追随できるか、検討が必要かな。

そういう話を読むと、Redmineの機能と運用を非常に研究しているように思える。
今後も、どんどんこういうノウハウが情報共有されていければいいなと思う。

アジャイルな組織構成の記事のリンク

最近の平鍋さんのBlog記事がすごく面白いので、リンクしておく。
アジャイルな組織構成とは何か、すごく考えさせられる。
特に主張はなし。

【参考1】
Technology Radar mentions Team Structure | an Agile Way

(引用開始)
今回の大きなテーマは（超訳すると）、

1.Docker as process, PaaS as machine, microservices architecture as programming model

Dockerを「プロセス」、PaaSを「マシン」、microservices architectureを「プログラミングモデル」とみようじゃないの。それに合わせて疎結合の小さなサービスの集合としてアプリケーションを作れるし、合わせて疎結合の小さなチーム構成が作れる。

2.Intelligent empowerment

AIやDeep Learning使った差別化が可能になった。ずっと研究分野のものだった AI や Machine Learning が急激に実用になってきた！

3.The holistic effect of team structure

チームにまかせる構造。スタートアップだけでなく企業の中でも、プロジェクト指向からプロダクト指向へと変わってきた。自分たちで作って自分たちで運用。
(中略)
特に、前のブログでも書いたが、Docker/PaaS/Microservices のおかげで逆コーンウェイ戦略が取れるようになり、組織の構造とソフトウェアの構造を「戦略的に」合わせていく作戦が、1と3に出てくる。
(引用終了)

【参考2】
デジタルビジネスとアジャイル(Mary Poppendieck on Digitization) | an Agile Way

(引用開始)
“Software is eating the world”

2011のマーク・アンドリーセンのコラムからの言葉だと思う。「あらゆる産業がデジタル化し、すべての企業はソフトウェア企業になる」という強烈なデジタル革命宣言だった。

Maryの主張は、その中では、もっとも大事なのは有能な人を集めて、その人たちに権限をあたえ、自分で動けるようにするリーダーシップなんだ、というのがメッセージです。

GE のCEO、Jeff Immelt のページあたり、講演の途中でTom が立ち上がって、次のように一言放ったのが印象的でした。

“The most important resource for today’s companies is not capital, but talented and passionate people.”

「今日企業にもっとも重要な資源は、資本ではない。有能で情熱をもった人だ。」
(中略)
この人の組織の仕方が変わってくる話は、「シリコンバレーから始まった小さいチームに権限を与える手法は、企業の情報システム開発にも影響を与え始めている」という言い方で、Technology Radar にも登場します(つまりアジャイルのこと)。
(引用終了)

【参考3】
SPI Japan 2016 で基調講演しました | an Agile Way

(引用開始)
“新製品開発としてのnonakaスクラムの源流は８０年代の日本の製造業にあり、それがソフトウェア開発の文脈で欧米から再発見されたものがアジャイルと理解しています。

現在の欧米型企業経営が、必ずしも国民生活の質の向上に寄与していないことを鑑みると、私たち日本人が、過去の知恵と若者の活力の両方を活かす形で、新しい日本の持続的イノベーションのやり方をつむぎ出す必要があります。

その力の源泉は、高い志を持った経営と、いきいきと働くことができる現場環境にあるのではないでしょうか。
日本に適したアジャイル、スクラムの形を、描き出そうではありませんか。
そのためにはまず、経営、ミドルマネジメント、現場が話す場を作り、お互いに共感することから始めなくてはなりません。”

平成24年4月16日
一橋大学名誉教授　野中郁次郎
(引用終了)

【参考4】
Visiting Ikujiro Nonaka, Grandfather of Scrum | an Agile Way

(引用開始)
こんな会話をしながら、僕が考えた事。もちろん先生のフォーカスは、組織論にある。僕はアジャイルなソフトウェア開発チーム、が中心課題だ。

アジャイルはチームとソフトウエアが射程。「よいソフトウエア作りは、よいチーム作り」という拡張コーンウエイ則。さらに、ソフトウェアとチームの関係は、Jim McKarthy の Core Protocol なんかともつながる。

アジャイルが発展したのは、ミクロレベル(個人)でなくマクロレベル(組織)でなく、メソレベル(チーム)である。アジャイルのスイートスポット。これを現構造の組織にそのまま持ち込む活動はそもそもうまくないのでないか？

むしろ、メソレベル（チーム）が重要であることを、再認識し、メソレベルこそが、全体のクオリティの決定要因であることを認めること。

野中先生が「日本には中間管理職というのがキーになり、トップダウンでなく、ボトムアップでなく、ミドルアップダウンだ」という話をしていたのが、現在のエンタープライズアジャイル導入と符号するように思えて来ています。
(引用終了)

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

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

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

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

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

第11回東京Redmine勉強会のアンケート公開　#redmineT from akipii Oga

【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万件以上、ワークフローの遷移が６万以上という野良Redmineをデータ移行して、一つのRedmineに統合できたとは恐れ入る。
しかも、統合作業をプラグイン化したらしい。

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

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

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

あきこさんのツイート: "２ヶ月くらいかけ休日を中心に調整。最大のものは48時間くらいで統合できた。統合後のRedmineの規模がものすごいことに！プロジェクトは1400件以上、履歴は100万件以上。ワークフローの遷移が６万以上。。。でも、一元管理することで見えてきたものがある。#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 は多分日本人好みのツールなのだろうと感じた。自分達の現場で業務改善したい時に手元にフリーでそれなりに使えるツールがあって、現場に部分最適するのは日本人の得意技。"

【今日の資料はコチラ】

ある工場はこれて?Redmineハ?ーシ?ョンアッフ?を決意した from Kohei Nakamura

あなたのコードに ハナマルを。- ? ぼっち開発でも出来る?プラグインテスト初めの一歩(仮) - from akiko_pusu

Redmineのバージョンアップに追従していくための一工夫 from Go Maeda

Unofficial Redmine Cookingの紹介 from Yuuki Nara

開発環境の認証を改善して Redmineを社内標準にした話 from Ryou Soda

講演1 redmineの簡易crmとしての活用事例r2 from Hidehisa Matsutani

RedmineとElectronで新人の育成状況を可視化した話 from Aita Keiji

第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+１＝３のようなシナジー効果を発揮できるのか？

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

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

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

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

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

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

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

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

たとえば、当初は３人で使っていたRedmineが１００人以上に使われて、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さんも来られるので、もしかしたら、最新の出版の状況も披露してくれるかもしれません。
お楽しみに。

日本の品質管理がISO9001やシックスシグマに変わっていった歴史

最近、日本の製造業の品質管理に興味を持って、色々あさっている。
「TQM品質管理入門」を読んだら、日本の品質管理がISO9001やシックスシグマに変わっていった経緯が書かれていて分かりやすかった。
以下、自分の理解でラフなメモ書き。
メモなのでロジカルでない。

【参考１】
今、あらためて、日本自動車産業の「ものづくり」について考えよう | 住商アビーム自動車総合研究所 自動車業界コンサルティング

(引用開始)
日本型ものづくりの基礎に貢献したのはW・エドワード・デミング博士だろう。
彼は統計学者として戦後初の1951年国勢調査計画立案に携わる傍ら、品質管理技術の専門家として日本科学技術連盟の招待を受け、日本の製造業経営者に対し統合的品質経営（TQM）を説いて歩いた。こうして日本のものづくりは体系化され、力を付けた。

1980年代、日本の製造業、特に自動車産業が勢いを増す中、米国マサチューセッツ工科大学（MIT）が中心となり、日本の自動車産業における生産方式を研究し、その成果を再体系化・一般化し、「リーン（＝痩せぎす）生産方式」（LPS）と命名した。その後、LPSの概念は欧米製造業に浸透し、ゆくゆくは日本本国に逆輸入された。

1990年代末、日本にてバブル経済、金融不況と苦境が続いた後、再度、自動車産業を中心に日本の製造業が徐々に復活を見せた。この時、日本は、単なる製造を超えた日本古来に由来する日本の強みと伝統の象徴とすべく「ものづくり」と命名し、「ジャパンブランド」の一つの軸に位置付けた。

斯様な歴史を経て、「ものづくり」の概念は今日に至ったが、特にリーマンショック以降、それを取り巻く環境諸般が著しく変化する中、またもや、大きな転機に差し掛かっているものと考える。

リーマンショック前後より電機関連領域における日本の製造業の地盤沈下が起こった。
続いて2010年以降、自動車産業においても大規模なリコールが発生し元来の「品質神話」に疑問符が付いた。
更に昨今では、消費者の「モノ離れ」とか、「モノからコトへ」とまで言われる。「モノ＝所有文化＝時代遅れ」という感じすらある。
一方で、欧米では、IoTとか、インダストリー4.0とか新しい概念が生まれ、GEをはじめ「製造業の復活」と言われている。

こうした一連を見るに、「『ものづくり』とは一体何だろう」と改めて問題提起をし、皆様と一緒に考える契機を作りたい。(後略)
(引用終了)

【１】引用元のURLを忘れたが、下記のような解説があった。

(引用開始)
　品質管理のさまざまな新しい方法の開発によって、統計学は大量生産時代の必須の技術として定着していきます。第二次大戦後の日本の品質向上は、米国ではミラクルと考えられた時期がありますが、１９８０年代のＭＩＴのレポートでは、日本の産業界が統計的方法を活用していることを一つの原因としています。
　これについては、デミングが１９５０年に日本で行った講義以来、石川馨（特性要因図）、田口玄一（ロバストパラメータ設計）、赤尾洋二（品質機能展開）、狩野紀昭（狩野モデル）といった新たな管理技術を開発した日本の先生方の貢献が大ということができるでしょう。
(引用終了)

(引用開始)
品質管理は管理図に始まり、管理図に終わる
(引用終了)

つまり、製造業の品質管理は、大量生産する時に製品の品質のバラつきをなくすために、管理図や特性要因図などのQC7つ道具を編み出し、それら技法を洗練させてきたのだ。
品質管理の技法の背後には、統計学、特に検定や回帰分析の理論がある。
だから、品質管理の技法は、統計学の理論がバックにあるので、廃れないし、理論的に強固なのだと思う。

そして、日本の「品質管理の総本山」は「日科技連」。
高校生の頃に日科技連の数学の本を読んだら、普通の数学と違うなあ、と思っていたが、その理由は、僕が統計学を知らなかったので、違和感があったのだろうと思う。

しかし、今ではこういう製造業の品質管理の技法が普及しているとはあまり思えないのは何故だろうか？

【２】「TQM品質管理入門」を読んだら、日本の品質管理がISO9001やシックスシグマに変わっていった経緯が書かれていた。
どうやら1980年代のアメリカで、日本の製造業の品質管理を徹底的に研究し、アメリカ独自の理論に発展させていったみたい。
それが、シックスシグマらしい。

「TQM品質管理入門」を読むと、アメリカのシックスシグマと日本のTQMの違いは、アメリカはトップダウンによる標準化であり、日本はボトムアップによる教育。
たとえば、品質管理の技術者をグリーンベルト～ブラックベルトのようにレベル分けする点は、CMMIに似ている。
「特性要因図の目的の一つは教育」と言われるように、日本企業ではOJTによる社員教育を重視してきたが、昨今の成果主義制度のために、OJTが機能しなくなっているように思える。

最近、職場で「OJT」が機能しないのはなぜなのか？(中原淳) - 個人 - Yahoo!ニュース

もう一つの流れはISO9000シリーズ。
品質管理をきちんとやっています、という国際的な免許が公開され、グローバルスタンダードになってしまったために、日本の製造業も取得せざるを得なくなった。
ISO9001の中身はTQMと同じだが、日本企業では、ISO9001の維持のために膨大な管理人員が割かれているデメリットが大きいのではないか。

【３】一方、欧米では、日本の製造業の品質管理を徹底的に研究し、シックスシグマやISO9000シリーズを生み出しただけでなく、ソフトウェア開発においても「アジャイル開発」という概念を編み出した。

アジャイル開発の源流には、日本の製造業の品質管理があると聞くが、その理由が知りたくて、今も品質管理の文献をあさっている。
個人的には、製造業の発想とソフトウェア開発の発想は全く違うと思っているので、どうしてもそれが密接に関連しているという理由が腑に落ちないからだ。
欧米人がどのように文脈を変えてきたのか、という観点で今も読んでいる。

要因と原因の意味は違う

最近、日本の製造業の品質管理に興味を持って、色々あさっている。
「要因と原因の意味は違う」という記事が分かりやすかったのでメモ。
メモ書きなので主張なし。

【参考】
「要因と原因の意味の違い」 「要因と原因の使い分け」について:時間管理術研究所　□□　仕事と生き方、幸せの研究所　□□

正しい「なぜなぜ分析」と、だましの「なぜなぜ」：（と「要因と原因」の違い）:時間管理術研究所　□□　仕事と生き方、幸せの研究所　□□

特性要因図 - Wikipedia

特性要因図～品質管理の知識

【1】日本の製造業の品質管理で、問題の原因分析をする時、なぜなぜ分析がよく使われる。
なぜを5回も繰り返して、問題の真因を見つけ出す。

テスト管理のコミュニティで聞いた所では、なぜなぜ分析をやるとすごく疲れるらしい。
なぜの5段階目は「油断」「不注意」など人の心理まで行き着くので、精神的にしんどいらしい。

そんな「なぜなぜ分析」では、症状→要因１→要因２→・・・のように三角形のように広がっていく。
症状→要因が一直線になることはほとんどない。

普通は、問題の症状に対し、数多くの要因が考えられるからだ。
なぜなぜ分析は、数多くの要因を網羅するようにあぶり出し、その「要因」を検証していって、真の「原因」を見つけ出すという点が重要なポイントになる。
つまり、たくさんの要因があったとしても、問題を改善・解決させる場合、とても効果が上がる原因はかなり限定されるわけだ。
問題と要因が一直線になる場合、分析の能力不足と言える。

この辺りはパレートの法則を暗示させる。

【2】このような問題分析の手法の一つとして、特性要因図が使われる。
僕のイメージでは、マインドマップみたいなものだ。

特性＝問題となる事象として、問題を発生させる要因を魚の骨のようにどんどん書き出す。
それら要因の中で、問題の真因となる要因が「原因」となるわけだ。

【3】国語辞典では「要因＝主要な原因」と解釈しているらしいが、製造業の品質管理では、「要因」と「原因」は上記のように明確に区別されている。
このように、日本の製造業の品質管理では、「要因」と「原因」の区別を厳しく指導されるらしい。

【4】そういう話を聞くと、日本人も品質管理という技法を知識体系として洗練させてきたのだ、と感じる。
しかし、今ではこういう製造業の品質管理の技法が普及しているとはあまり思えないのは何故だろうか？

日本のアジャイルは導入部分ばかりで終わっている

はてぶがすごく多い牛尾さんの記事を改めて読んでみた。
「日本のアジャイルは導入部分ばかりで終わっている」という主張に共感した。
以下は自分の理解のラフなメモ書き。
特に主張はなし。

【参考】
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ

僕もアジャイルコミュニティでずっと活動していて、コミュニティイベントでアジャイル開発の事例紹介のために講師をお願いしたり、自分達の事例紹介をやったり色々してきた。
そんな経験をもう10年近くやっているけれど、何となく腑に落ちない部分もあった。

アジャイル開発の事例の講演は、ほとんどが、アジャイル開発の導入で終わっていて、それから先の発展系があまりにも少ない。
チームのメンバー、上司をどう巻き込んで、アジャイルなチームを作ったのか、それをどう定着させたのか、どのようにアジャイル開発を標準化プロセスに組み込んだのか、という話ばかりを、10年も同じようなレイヤーでずっと話し続けている場合が多い。

そんなモヤモヤ感を持っていた時に、牛尾さんの記事を読んで、ああこれが原因なのかな、と思ったりした。

日本では、ソフトウェア開発案件はビル建築や製品製造のような一括請負契約が基本であり、契約時のスコープ固定、検収による支払いという制約のために、スコープ変更の開発がとてもやりにくい。
また、日本のソフトウェア文化として、製造業の成功経験が大きすぎるために、標準化・専門化によるプロセス改善に偏りがち。

そんな組織風土、組織構成の中でアジャイル開発を実践しようとすると、牛尾さんの言う通り、アジャイルの知識うんぬんよりも、「日本の商習慣の中で如何にアジャイルの能力を最大限に発揮できるよう「調整」したり足りないところを「埋めたり」する能力」の方が重要になってくる。
つまり、アジャイルの深い知識よりも、組織内の根回しの方が、日本のアジャイルな現場で重要なキーポイントの一つだ。

つまり、「アジャイルの本質を掴んだまま、日本の請負発注形式や、品質監査などに対応できる」かという問題に対し、日本の商環境の制約条件の中で、色々苦労した経験事例も多い。
だが、牛尾さんの言う通り、「しかし、請負発注や、正直、アジャイルにおいては意味のないような品質監査に適応することで、本来のアジャイルの実力を引き出せたとは言えなかった」と思う。

さらに、「第二世代のアジャイルブーム」であるScrumによって、「自分のところでリスクをかぶって、アジャイルが生む本当のビジネス価値を取ろう」とする開発手法を試す現場も現れた。
このScrumに関する事例はとても有意義なものが多いと感じる。
今までのアジャイル開発で暗黙知とされてきたノウハウが、言葉やプラクティス、プロセスフレームワークとして定義されたように思えるからだ。

一方、アジャイル開発を組織に導入するための根回しに関するお話の事例がとても多くて、そのような傾向の講演は僕はあまり好きではなかった。
つまり、平鍋さんの言う「アジャイルのレフトウイング、ライトウイング」の絵で言えば、レフトウイングの「チームマネジメント」や「組織マネジメント」に関わる話はあまり好きではなかった。

アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ

むしろ、アジャイル開発が好きであり、アジャイル開発を実践したいと思うならば、もっと技術にこだわって、技術重視で活動すべきではないか、と思っていた。
たぶん僕の興味は、開発プロセスを支援するツール群、本来のシステムを作るためのモデリング技法にあるからだろうと思う。

そして世界の潮流では、アジャイル開発の導入が一段落した後、DevOps、マイクロサービスアーキテクチャなどの技術が注目されている。
いつまでもアジャイル導入で停滞しているわけではない。

「マイクロサービスアーキテクチャ」や鈴木雄介さんの本「Cloud First Architecture 設計ガイド」を読むと、従来のシステム設計技法が大きく変わりつつある印象を受ける。

ソフトウェア工学は未成熟なプラクティスによって重大な阻害を受けている

平鍋さんの資料にある「ソフトウェア工学は未成熟なプラクティスによって、重大な阻害を受けている」の文言にビビッときた。
以下は思いつきのメモ。
特に主張はなし。

【参考】

Agile, Software Engineering, Process Kaizen. They mix like oil and water ? from Kenji Hiranabe

SPI Japan 2016 | イベント | 日本SPIコンソーシアム

現場から始めるアジャイルの技術プラクティス

ソフトウェア工学の方法論と理論 1. 目的とスコープ(Purpose and scope)

SEMAT “Call for Action” の日本語訳 - とあるソフトの開発記録

アジャイルは”再び"死んだ

(引用開始)
ソフトウェア工学についての後悔
Tom Demarco ソフトウェア工学、そのときは去った。
Ed Yourdon ソフトウェア工学に大切なことは？
Barry Boehm あの指数曲線は間違いだった。
Ivar Jacobson ソフトウェア業界は、ファッション業界のようだ。
Tom Gilb ソフトウェア工学は定義を間違った。
(引用終了)

(引用開始)
Ivar Jacobson
ソフトウェア工学は未成熟なプラクティス(immature practices)によって、重大な阻害(gravely hampered) を今日受けている。
例えば、具体的には以下のように：
言葉の流行が、工学の一分野というよりファッション業界のようだ。
しっかりした広く受け入れられた、理論的基礎の欠如。
非常に多くの方法論(methods)とその派生。
またそれらの違いがほとんど理解されずに作為的に強調されている。
信頼できる実験的評価(experimental evaluation) と妥当性確認(validation)の欠如。
産業界の実践(industry practice)と学界の研究 (academic research)の乖離。

私たちは、ソフトウェア工学を堅固な理論および検証された原則とベストプラクティスを基礎として、再建するプロセスを支援する。そのプロセスは、以下の特徴を備えている。
広く合意された要素からなる、特定用途に拡張可能なカーネルを含み、技術の問題と人の問題の両方を扱い、産業界、学界、研究者そして、ユーザに支援され、要求とテクノロジの変化に応じて追随できるような拡張性を備えている。
(引用終了)

「ソフトウェア工学」という言葉は、たぶん、IT技術者ならば、愛憎の両面を持つ言葉だろうと思う。
いつも現場で混乱していて、その解決の手がかりになるような、厚い雲から差し込む光のように感じるけれど、実際に使おうとしたら、そう簡単に結果は出ないし、使いにくい。

個人的には、ソフトウェア工学は、製造業の品質管理やPMBOKのように、汎用化された知識体系として提示したいけれど、問題解決の適用領域が時代と技術に依存するために、その範囲がとても狭い。
そして、技術の陳腐化が激しいために、使える期間がとても短いがゆえに、工学と言いづらいのだろうと思う。
工学として使える手法は、夏日のアイスクリームのように、一瞬だけ使えて、溶けて無くなる、みたいな。

それから「プロセス」という言葉がいつも引っかかる。
普通の感覚では、「プロセス」は業務フローや業務のワークフローのような、ある定型的な手順を指す。
しかし、ソフトウェア開発をプロセスとして定義しようとすると、各案件の開発手順は、環境・組織・技術・要件などによって異なり、それらを統一ないし標準化することがとても難しい。
むしろ、標準化しても、すぐに陳腐化してしまい、使えなくなる。
誰でもいつでも使える「プロセス」という発想自体がおかしいのかもしれない。

つまり、物理の法則や数学の公理系、製造業の品質管理、製造業のIEとは違い、ソフトウェア工学は、汎用的な工学として成立できていないように思う。
その根本問題には、問題解決の領域が狭すぎる、問題解決の鍵となるアイデアの生存期間が極端に短すぎる、ということがあるのではないか。

でも、矛盾しているが、ソフトウェア工学やプロセス改善について、自分なりに考えて試行錯誤することには意味があると思う。
そして、その問題の解決の糸口に、オープンソースやアジャイル開発があるように直感的に思う。

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

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

セル生産方式 - Wikipedia

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

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

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

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

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

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

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

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