2016/12/06

品質保証部はソフトウェア組織のボトルネックなのか、ソフトウェアチームに同化すべきなのか

平鍋さんの記事を読んで、品質保証部はアジャイル開発のボトルネックなのか、必要な組織なのか、いろいろ考えてしまった。
主張のないラフなメモ書き。殴り書き。

【参考】
QA to AQ: Quality Assurance から Agile Quality へ - Qiita

HARADA Kiroさんのツイート: "明後日開催です。英語で開催ですが、ゆっくり質問の時間はありますので、ぜひ。/ "品質保証からアジャイル品質へ入門コースー品質もアジャイルになるための価値、プラクティス、パターンー" https://t.co/m9eXSwIExq @Eventbriteさんから"

(引用開始)
よくアジャイル開発についての質問で、「品質保証はどうするのですか?」と聞かれることがあります。
日本の大企業の中には「品質保証部」という組織があり、そこが出荷判定をしたり、最終的な製品のQA(Quality Assurance)についての責任を持つことがあります。
その部署が、現場のアジャイル開発にどのように関わるのがよいのか、という質問です。
ひいては、メトリクスの取り方(既存の品質のメトリクスや、バグ収束曲線が当てはまらない)にはじまり、「どのタイミングで」、「どういった体制で」関わるのか、という質問です。
日本でアジャイル開発の導入が進まない、もしくは懐疑的に考える人が多いのは、この部分にあると思います。
(引用終了)

上記の指摘は、現場でよく感じる。
メーカーのソフトウェア子会社、メーカーの情報システム部門からスピンアウトしたSIであれば、品質保証部という組織が普通はある。

製造業では、品質保証部という部門はとても存在意義があるし、ものづくり日本の品質管理技法を発展させてきた輝かしい歴史があった。
しかし、ソフトウェア開発で品質保証部が絡むと、あまり良い話を聞かない。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

製造業では、3S活動によって、生産プロセスを単純化→標準化→専門化して、製品や生産工程の品質のばらつきを無くす。
そして、その活動をQCストーリーに落とし込んで、PDCAサイクルに組み込んでいく。

製造業の生産プロセスでは、品質が安定した製品を大量生産するために、プロセスを標準化する。
標準プロセスを作るために、各工程の作業へ細分化して、各工程の仕掛品の品質をチェックして、品質のばらつきを原因特定して解決していく。

しかし、ソフトウェア開発では「プロセスの標準化」という活動が有効に活用できない。
正直、効果が出ているとは思えない。
システムのインフラ、開発環境、プログラミング技術が日進月歩で変わるために、その変化に標準化活動が追いつかないのだ。
むしろ、古くなった開発プロセスを現場に押し付けるような立場になっていると思う。

では、ソフトウェア開発では品質保証という部門は不要なのか、と言われるとそうでもない。
SIにいると、形骸化した品質保証部の代わりに、開発案件の受注時の見積りレビューやリリース判定を行う役割をPMOのような組織が肩代わりしている場合が多い。
たとえば、見積りやプロジェクト計画が甘くないか、リリースしてクレーム対応に追われるリスクがないか、などを精査する。
つまり、製品の出荷判定を品質保証部がチェックするように、PMOがリリース判定を行っている。

そのPMOは、製造業のISOシリーズのように、CMMIなどの標準プロセスを策定して、ソフトウェア品質を確保しようとするが、実際はなかなか上手くいかない。

では何が違うのか?
ぼんやりしていて、その理由ははっきり分からない。

但し、上記の記事を読むと、「品質保証部」対「開発チーム」という牽制の関係ではなく、2つの組織をばらして、品質保証部メンバーが開発チームに混じって作業する方が上手くいく、という指摘をしているように思える。

つまり、運用チームと開発チームが組織的に分割され、チームが牽制し合うことで不正な作業をチェックする仕組みではなく、昨今のDevOpsのように、チームをシャッフルして、ペアプロのように共同作業していく方向性が良いと示唆しているように思える。

日本人も日本の組織も、QCサークルのような文化があったのだから、本来はペアプロのような共同作業は、日本人にフィットしているはずだと思う。
日本人は本来、トップダウンによる変革よりも、ボトムアップによる改善の方が向いているのだろうと思う。

しかしながら、そのやり方は、IT全般統制のような法律があるがゆえに、日本ではなかなか浸透できない現実もある。

ITに係る全般統制とDevOpsの緊張関係: プログラマの思索

昨今は、組織的不正を行わないように、組織が互いに牽制し合うように組織構造を作ることを勧められているために、日本の現場にそのような風潮を取り込むと、各組織の意思決定が部分最適化しすぎてしまい、全くうまくいってない。
なんだかな~と思ったりもする。

少なくとも、IT業界における世界の潮流は、サイロ型の組織構造をばらして、小さなチームに編成し直し、アジャイルに行動する方向へ進化している。

組織構成の考え方を変えれば、その潮流に乗れば、日本のソフトウェア組織も適応できるのではないか?
品質保証部はソフトウェア組織のボトルネックではなく、ソフトウェアチームの一部分に同化できるのではないか?
すると、ソフトウェア開発では、品質保証部は解体されて、ソフトウェアチームに同化されるべきではないか。
たぶん、DevOpsもその流れ。

この妄想をいろいろ考えてみる。

| | コメント (0)

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

Redmine3.1のプラグイン一覧が参考になる

Redmine3.1のプラグイン一覧の記事がとても参考になるのでメモ。

【参考】
Redmineを3年間使い続けてお世話になったプラグインたち - Qiita

【1】Ver3.1.1で、下記のプラグインをインストールしたらしい。
少なくとも、これらプラグインは正常に動作したみたい。

clipboard_image_paste
easy_gantt
progressive_projects_list
redmine_absolute_dates
redmine_agile
redmine_backlogs
redmine_banner
redmine_checklists
redmine_code_review
redmine_default_custom_query
redmine_gantt_with_date
redmine_issue_templates
redmine_issues_summary_graph
redmine_issues_tree
redmine_japanese_help
redmine_maintenance
redmine_pivot_table
redmine_slack
redmine_wiki_extensions
redmine_wiki_lists
redmine_work_time
sidebar_hide

【2】いくつかのプラグインは、Ver3.3ではデフォルト機能に含まれているので、不要になる。
たとえば、redmine_gantt_with_date, redmine_default_custom_query とか。
また、farend_fancyテーマを入れれば、redmine_absolute_dates は不要になる。

【3】幾つか参考になる点がある。

【3-1】まず、redmine_backlogsプラグインは、「feature/redmine3」ブランチであれば、3.xでも動作したらしい。
この情報はありがたい。

(引用開始)
(redmine_backlogsは)
↓↓↓Redmine 3.xの場合は、「feature/redmine3」ブランチのものでないと動かないです。
https://github.com/backlogs/redmine_backlogs/tree/feature/redmine3
(引用終了)

【3-2】有償プラグインを提供しているベンダーの無償プラグインeasy_gantt、redmine_agileの感想も参考になる。
ガントチャート画面上で編集できるだけでもありがたいし、かんばんがRedmine上で使えるのも便利だ。

とはいえ、ガントチャートにMSProject並の操作感や、もっと高機能なかんばんが欲しくなれば、Lycheeなどの有償プラグインが必要になるだろう。

【4】「あとがき&ふりかえり」の文章が、とても心遣いが溢れている。

(引用開始)
プラグインを入れると実現したいことが叶います。
一方で、Redmine管理者の保守工数は増え、利用者には覚えてもらう操作が増えます。
プラグインを入れるだけでなく、プラグインを削除することも時には大事だと思います。
 
誰のためのプラグインなのかを考えることは重要です。
経営層やマネジメント層の声の力は強いかもしれませんが、週1や月1でしか使われないような目的のためよりも、毎日Redmineを使っている現場の人の声を大事にしたほうがいろいろと幸せになれます。
 
何のためのプラグインなのか、何のためのRedmineなのかを忘れてはいけません。
Redmineを使い始める以前のやり方を堅持するために、さまざまなプラグインを駆使するのはオススメしません。
可能ならば、人や業務にシステムを合わせるよりも、システムに人や業務を合わせることをオススメします。
(引用終了)

Redmineのようなツールに触れると、それにのめり込んでしまう。

たとえば、様々な人達の要望を取り入れて、プラグインを入れて、どんどん高機能化したくなる。
あるいは、組織やチームのワークフローを己の考えに従わせたくなる。
自分の理想のプロセスを実現すべく、Redmineをどんどんカスタマイズしたくなる。
Redmineのシステム管理者の保守工数もバカにならなくなる。

そんな時に、ふと足元を振り返って、Redmineの目的を思い出すのも大切なのだろう。

| | コメント (0)

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/30

「入門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の機能と運用を非常に研究しているように思える。
今後も、どんどんこういうノウハウが情報共有されていければいいなと思う。

| | コメント (0)

2016/11/28

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

最近の平鍋さんの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スクラムの源流は80年代の日本の製造業にあり、それがソフトウェア開発の文脈で欧米から再発見されたものがアジャイルと理解しています。

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

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

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

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

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

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

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

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

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

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

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