RedmineはCRMソフトとして使えるか？

RedmineをCRMソフトとして使うアイデアについてラフなメモ書き。
あとで直す。

【参考】
CRM機能リスト - NetSuite クラウドCRM

オープンソース・ソフトウェア活用のススメ（４）　－SugarCRM－ | JIPコンサルティング・サービス

【コラム】Yet Another 仕事のツール (89) SugarCRMの用語を理解する | エンタープライズ | マイナビニュース

SugarCRMで顧客にメールを一斉配信する方法 : THINK PINK

オープンソースSugarCRMの調査 | SEOプログラマーのまとめ

SugarCRMの運用サイクル: プログラマの思索

第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【1】RxTStudyや品川Redmine勉強会で、RedmineをCRMソフトとして使う事例を聞く時が多い。
顧客からのメール問合せや打合せをチケット管理に適用する事例が多い。

そもそもRedmineによるチケット管理に、CRMの機能を適用できるのか？
CRMの機能一覧を洗い出し、チケット管理に適用できるのか、以下考えてみる。

CRMの目的は、顧客とのやり取りを円滑に回すこと、そして、顧客の問合せ履歴や購買履歴を蓄積したデータからデータマイニング機能を使って、顧客と商品の因果関係などを導き出し、売れる方法を導くことだ。
基本は、リピート顧客を増やして顧客との関係を強化する方向性だが、最近はロングテールのように、薄利多売のやり方もIT技術革新のおかげで可能になり、顧客の購買履歴を分析する機能を強化する方向性もある。

CRMソフトの機能としては主に下記があげられるだろう。

・営業支援(担当：営業マン)
　～商談、取引先の重要度管理(ターゲット(セグメント)なのか、リード(見込み客)なのか、重要顧客なのか)

・コールセンター管理(担当：ヘルプデスク)
　～サポートデスクにおける問合せ管理
　　問合せメールの受付(インバウンドメール)
　　セミナーやイベントの告知などをメール一括送信(アウトバウンドメール)

・マーケティング(担当：経営企画部の担当者)
　～イベントやセミナーの開催におけるタスク管理
　　キャンペーン効果の追跡

・分析(全ての担当者)
　～いわゆるビッグデータ
　　顧客の購買履歴から、売れ筋商品と顧客の関係を分析する、など

CRMの機能は幅広い。
普通は、営業支援管理システムとして使う時が多く、営業マンを対象に業務システム化される。
しかし、営業支援だけでは足りない。
顧客に商品や製品を売れば、その製品に関する問合せが発生し、そのサポートを丁寧にかつ効率良く行わなければ、顧客は離れてしまう。
だから、ヘルプデスクが受付対応しているコールセンターの管理機能は、バックエンドの業務として重要だ。

また、新たな顧客を発掘するために、マーケティング機能もある。
普通は、イベントやセミナーなどのキャンペーンを開催し、顧客から名刺をもらったり、連絡を受けて、顧客の問い合わせ窓口を集める。
そして、その顧客へ営業訪問などでリーチし、製品を売り込んだら購入してくれる可能性があるか、判断する。

また、電子メールを顧客へ一括送信して、メールに書かれた一意に識別できるURLからの顧客のアクセスを履歴に残し、イベントやセミナーのキャンペーン効果を測定する機能もある。
つまり、反応が良ければ、興味を持ってくれている顧客である可能性があり、見込み客（いわゆるリード）と捉えることができる。

分析機能は、最近ならビッグデータと呼ばれる分野で、とても活発な箇所だ。
顧客の購買履歴から、因果関係を導き出した経験則としては、「郊外のディスカウントストアでは、ビールと紙おむつが一緒に売れるので、同じフロアに置いておく」話などがあるだろう。
他にも、Amazonのおすすめ商品のようなレコメンドエンジンもある。

【2】オープンソースのCRMにはSugarCRMがあり、以前下記でまとめた。
さらに、用語集、機能などのページも追加してみた。

営業支援ツールSugarCRM from akipii Oga

まず、新規顧客のリスト（ターゲットリスト）を作成して、どんなイベントを開催すると集客できるか考える。
そして、ターゲットリストを対象にイベントやセミナーなどのキャンペーンを作成して、イベント情報を一斉告知する。
普通はマーケティング担当者がキャンペーン管理しているだろう。
ここで、顧客へのメール一括送信機能がアウトバウンドメールと呼ばれる事に注意。

イベントを開催後、顧客から製品に関心を持ったなどの問合せがあれば、見込み客（リード）と見なして、営業マンをアサインして、顧客へ営業訪問したりする。
ここで、「リードがどこから来たか」という情報はリードソースと呼ばれ、アウトバウンドメールのURLからトラッキングすることで分析したりする。
集客の効率性を表すKPIとしても使えるだろう。

営業マンが顧客と打合せした内容は、商談として登録され商談ステータスで管理される。
電話の履歴は「コール」、打合せの履歴は「ミーティング」で別々に管理するのがSugarCRM流らしい。

商談が見積りステータスになれば、後もう一息になる。
そして、クロージングで、営業マンが発注書を受けて、契約が決まり、納品すれば、売掛金が回収される。
この辺りは普通の販売業務と同じ。

最後に、売れた製品に関して顧客から問合せがあれば、サポートデスクが受け付けて、フォローアップを行う。
普通は、support@～のような受付窓口メールに問い合わせてもらい、問合せを登録してワークフロー管理する。
ここで、support@～のような受付窓口メールはインバウンドメールと呼ばれ、CRM上で一括管理される。
理由は、メールは電話とは違って、誰が担当しているか分かりにくいことと、作業引き継ぎが曖昧になりやすいために、CRM上で一括管理するほうが便利だからだ。

また、CRMでは、顧客問合せは「ケース」という別の概念で呼ばれている。
このケースを分析して、顧客から頻繁に聞かれる内容はFAQサイトにまとめたりして、サポートデスクの作業負荷を下げるようにする手法が多いだろう。
但し、製品の障害管理も受け付けているため、「バグ」を発行して、チケット管理する時もある。

【3】CRMの機能一覧やSugarCRMの運用サイクルから、Redmineのチケット管理はどこに当てはめることができて、有効なのか？
そして不足している機能は何なのか？

・営業支援
　→一部だけ適用OK。
　　商談、打合せはチケットで一括管理が可能。
　　但し、CRMでは顧客というエンティティを基本として、潜在顧客(ターゲットリスト、セグメント)なのか重要顧客かどうかの基準(リード、ターゲットなど)や商談などのエンティティに関連が発生する。
　　基本は、1顧客に対し、複数の商談や案件があるのが普通なので、チケットを商談などのイベントに対応付けた場合、顧客はトラッカーに対応するしか無い。
　　トラッカーはまさにチケットの識別子、つまり種類に相当するからだ。
　　すると、潜在顧客も含めて数千もの顧客がいる場合、トラッカーは数千になってしまい、チケット管理は非現実的だ。
　　また、取引先管理のデータモデリングでは、1回限りの顧客を雑コードで故意にまとめてしまう場合もあるが、チケット管理に対応させると、「1回限りの顧客」というトラッカー一つにたくさんの顧客の商談や打合せのチケットが登録されることになる。
　　その運用で回るのか、まだ分からない。
　　
　　あくまでも、取引先(顧客)が10～30程度であまり変わらず、打合せの管理も簡単なステータス管理や、実績工数の集計管理に使う程度が現実的ではないか、という気がする。

・コールセンター管理
　→一部だけ適用OK。
　　ケース(顧客問合せ)をチケット管理に置き換えるならば、一括管理は可能。
　　@g_maedaさんの事例では、インバウンドメール(サポートデスクが受信する顧客問合せメール)からRedmineチケットへ自動登録する機能を使って、ケース(顧客問合せ)をチケット管理する。
　　チケット管理できる利点は、問合せのステータスをワークフロー管理できるので、対応漏れや対応状況をチェックしやすくなること、返信メールの履歴がチケットの履歴で置き換えられるので追跡しやすくなること、添付ファイルもチケットで集中管理できる点があげられていた。

Redmineによるメール対応管理の運用事例 from g_maeda

　但し、Redmineチケット管理の弱点は、サポートデスクから顧客へ最初に送信したメール(アウトバウンドメール)と顧客から受信したメール(インバウンドメール)で発行されるチケット番号が異なるので管理しにくいこと、発信元アドレス(From)の情報がチケットに反映されない点があげられる。
　利点と弱点を考えてみると、前者は、Redmineから顧客へメール送信できる機能(アウトバウンドメール)があれば解決できると考えられる。
　その時にチケット番号を振ってSubjectに追加してメール送信できればいい。

　後者については、下記のコメントが残されている。

(引用開始)
mail handlerの --unknown-user=create オプションを使えばRedmineのユーザーが作成されるのでメールアドレスを保持できる。要検討。
(引用終了)

　つまり、メールを検知してチケット登録する時に、メール送信者の顧客に相当するRedmineユーザを新規作成して登録する運用があるのではないか、と指摘している。
　おそらく、この機能はもう少し手を加える必要があると思う。
　例えば、メール送信者をRedmineユーザとして新規登録する場合、チケットの参照権限しかないようなユーザとして作成したほうが安全だ。
　また、問合せ顧客に相当するRedmineユーザだけのユーザグループを作っておき、そのユーザグループに即座に追加できるようにしておいた方がいいだろう。
　さらに、過去に登録されたメール送信者のRedmineユーザが存在するならば、2回目以降に受信したメールのチケット登録では、ユーザを新規登録するか否かを判別してチケット登録できるした方がいいだろう。
　
　だが、そもそも、メール送信者をRedmineユーザで登録して良いのか、という疑問もある。
　顧客リストはとても多いから、普通は数千程度にすぐに増えてしまう。
　すると、Redmineユーザに顧客とサポートデスクの担当者が入り交じってしまう。
　たとえRedmineユーザをユーザグループで分けたとしても、それが本当の解決なのか、という疑問はある。

　でも、僕は、メール送信者はRedmineユーザで代用する方法がベターだろうと思う。
　CRMで一番重要な機能は、顧客(取引先)の管理だ。
　Redmineのカスタムフィールド機能によってユーザにも属性を追加できるので、顧客の重要度(ターゲット、リード、重要顧客)のプルダウンを追加すればいいし、住所や電話番号などの顧客情報のテキストボックスも追加すればいい。
　また、顧客を管理する必要がなくなれば、Redmineユーザのステータスを「削除」にして修正不可にしてしまえばいい。

・マーケティング機能
　→適用NG。
　　イベントなどのキャンペーン管理、電子メールに書かれたトラッキングURLからアクセスした行動を追跡するチャネル分析、リードソース(見込み客がどのチャネルからアクセスしてきたのかという情報)の分析機能は、Redmineにはない。
　　そもそも、Redmineは障害管理から発生したのだから、CRMの機能を実装することは眼中にない。

・分析機能
　→ほんの一部だけ適用OK。
　　ケース(顧客問合せ)や商談、打合せの検索は、チケット集計機能で代用できる。
　　しかし、顧客の購買履歴から何らかの因果関係を見出す機能は、Redmineのデフォルトのチケット集計機能だけでは足りない。
　　CRMではデータウェアハウス、つまりスター型DB設計によって、色んな観点でデータを分析するが、チケット集計機能にはない。
　　最終的には、分析・集計処理のためのバッチ処理が必要になると思う。

以上のように考えると、RedmineをCRMソフトとして代用するのは難しい。
チケットはあくまでもプロセスないしトランザクションの管理に向いているのであり、CRMで一番大事な顧客というエンティティをRedmineにマッピングしたいけれど、その対象がはっきりしないからだ。

それは丁度、テスト管理はRedmineよりもTestLinkの方が向いている事実と重なるように思える。
テストケースはチケットで代用できそうで、やはりできない。

でも、メール受信のたびにチケットを自動登録したり、期限が来たチケット一覧をメールで自動送信する機能は、Redmineならではの特徴だ。
丁度、Excel管理から脱却するためにRedmineを導入するのと同じように、メール駆動のタスク管理からRedmineへ進化していく手法はもっと研究される余地があるだろうと思う。

第5回品川Redmine勉強会の感想 #47redmine

第5回品川Redmine勉強会にスタッフとして参加してきました。
盛り上がって楽しかったです。
資料をリンクしておきます。
感想をラフなメモ書き。

【参考】
第5回勉強会 - shinagawa.redmine

第5回品川Redmine勉強会 2013/6/29 - Togetter

【1】@sakaba37さんの資料。
共通結合、データ結合などのソフトウェア結合度の観点と業務フローの類似性のお話と、社内業務にRedmineを適用した事例のお話。
構造化設計のお話は、今では情報処理試験に出るくらいしか使わないから、ピンと来る開発者はいたのかな？
社内業務で、PC資産のタスク管理にRedmineを使った事例は興味深かった。
ある業務でタスクが発生して、そのタスクを管理したい時、チケット管理は有効であるように思う。

チケットシステムの可能性 - 開発から業務まで - from Makoto SAKAI

【2】その後、「マネージャ」「開発者」「運用担当者」「Redmineシステム管理者」の観点でワークショップ形式で議論した。

第5回品川Redmine勉強会～開発者がRedmineを使いこなすには？ from akipii Oga

第５回品川Redmine勉強会の資料 from Masanori Machii

運用業務でのRedmine from Tomohisa Kusukawa

Redmine admin from Jun Naitoh

いろんな議論が出てきた。
皆同じような問題を持っているのね、と共感している人も多かった。

僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。
顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。
トラッカー＝顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。
実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。

この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。
このアイデアは、第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理機能にも関連する。
この辺りのアイデアはあとでまとめる。

他には、@naitohさんのRedmineシステム管理者としてのノウハウや事例が面白かった。
RedmineのVerUp作業は結構面倒だ。
Redmineを導入すると、開発チームはRedmineなしでは作業できなくなるので、気軽に改造したりVerUpして正常動作しなくなるのが怖いので、VerUpするのが難しくなる。

@naitohさんの話では、Ver1.4からBundlerでRubyGemをインストールするようになったおかげで、インストールしたRedmineの単位でRubyGemを管理できるようになった。
だから、Ver1.4以降では、異なるバージョンのRedmineを併存するのも問題ないとのこと。
特にVerUpするための検証作業で、既存の古いバージョンのRedmineと、検証中の最新バージョンのRedmineを一つのサーバーに入れている時は、Ver1.4以降なら問題ないみたい。

但し、プラグインはRedmineのVerUpで動作しなくなるので要注意とのこと。
Redmineは2.1になるまでに、Rails2→3、Ruby1.8→1.9、Prototype→JQueryへアーキテクチャが変わったために、追いつけていないプラグインが多い。

第8回RxTStudy勉強会で@marutosijpさんが言っていたように、プラグインと言えどもテスト自動化して日々ビルドする環境がなければ、ミドルウェアやライブラリのバージョンアップ作業に追いつけずに破綻してしまう危険があるのだろう。
改めて、TDDとCIの強みを印象づけられた。

また、Redmineのバックアップはやってますか？という質問もあった。
@naitohさんは、SQLiteなのでファイルコピーでやってます、とのこと。
@akiko_pusuさんからは、MySQLならDMP出力、Redmineの添付ファイルはrsyncでお手軽にやっています、というお話もあった。
DBのDMP出力、ファイルの同期作業は、Cronで日次に夜間に実施するなどすればよいだろうと思う。

【3】@tkusukawaさんのテーマ説明やLTでは、ヘッダに電子公告のように流れるメッセージが面白かった。

Twitter / hiyoshism: 勉強会の真っ最中に上司から「Redmineの導入は見送ります」というメールが届いた俺が来たよ。 #47redmine

Yggdrasil（ゆぐどらしる） ～ サーバ運用のNo Ticket, No Work ～ from Tomohisa Kusukawa

【4】日経システムズの記者さんのLTでは、記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITproの記事の裏話を少しだけ聞くことができた。
読者アンケートを取った結果では、Redmineの読者評価が高いらしい。

Twitter / akiko_pusu: Redmineの特集は何回もやってます。なぜか読者評価が高いです。アンケートでは普及率22% #47redmine

日経システムズという雑誌は、IT業界でしか読まれないだろうし、日経の雑誌を購入する層を考えると、SIの中堅～大企業の30代以降のSEやPM層が多いだろうと思う。
20代の開発者はそもそも購入する人はかなり少ないのではないだろうか？
また、日本のSIではアジャイル開発を採用している会社はほとんどないだろうし、おそらくウォーターフォール型開発が主流の会社で、Redmineを使っている現場が多いのだろう。

そういう読者セグメントを考えると、Redmineは日本のSIの開発現場で好まれやすいツールなのではないか、という仮説が思いつく。
ウォーターフォール型開発が主流の中では、XPやScrumを実践できないけれども、それでも軽量かつ規律ある開発をやりたい現場にチケット駆動開発がマッチしているのではないか、と想像する。
その議論については、以前、本来のチケット駆動開発(TiDD)とは何なのか？ - Togetterでまとめた。

Twitter / quicy: あえて残念な言い方をすれば、チケット駆動開発は、XP/Scrumを実践できない現場、それでも規律的なライトウェイト開発をやりたい、という現場開発者のための、救済なんちゃってアジャイル手法だと思う。

Twitter / quicy: 自分がBugzillaでチケット駆動開発と呼ばれる以前のものをやっていた時には、チーム外からは「ツール使ってるのね」という認識だけで、そこにある軽量さと規律の両立の妙を、なかなか理解してもらうことができなかった。名前と体系化は重要ですね。

この辺りのアイデアも色々まとめてみたい。

チケット駆動開発を要求工学の品質特性の観点から考える～チケット駆動開発がAgile開発を必要とする理由

チケット駆動開発における「チケット」を要求とみなした時、要求工学の品質特性の観点から考えると理解しやすいように思えた。
ラフなメモ書き。

【参考】
要求仕様 - Wikipedia

要求の旅は終わらない――開発と並走する「要求管理」 － ＠IT自分戦略研究所

要求仕様（要求工学：第3回）

requirement-engineering

【1】ソフトウェアエンジニアリングの中で、要求定義の手順や要求事項を引き出す技法や概念を体系化し、整理したものが要求工学である。
ここで「要求」は「ソフトウェアやシステムを利用することで実現したいこと」、「要求仕様」（SRS：Software Requirements Specification）は「要求を実現するためのソフトウェアのインターフェイス、構造、機能」と呼ぶことにする。

要求を仕様化する時、どのように要求をまとめればよいのか？
この問題は古くからソフトウェア工学の課題として続いてきていて、今だに有用な解決法は見いだせていないのが現状。
あいまいな要求を仕様化する時、次から次へと矛盾や不明点が出てきて、なかなかFixできないのだ。

WF型開発では、要求仕様を厳密に定義して、仕様凍結してから開発を始める。
しかし、この手法は最近のようにビジネスの変化が激しい時代には正直マッチしない。
最近ならOOAならユースケース、アジャイル開発ならストーリーカードへ落として、反復的に開発す手法が多分有名だろう。
だが、要求から良いユースケースやストーリーカードを書くのはやはり難しく、そのノウハウもまだ足りない。
業務知識があるからといっても、システムの実現可能性を考えたり、性能要件や保守性などの品質要件を整合性が取れるように作るのは難しい。

【2】要求工学では、要求仕様の品質特性という概念があり、良い要求仕様を考える時にその観点として役立つように思う。
要求仕様の品質特性には、下記の8つがある。

* 妥当性(正当性、必要性)
　要求仕様に全ての要求が網羅されている
　ソフトウェアが持つべき要求仕様が要求に含まれており、かつ、それ以外の要求を要求仕様に含まないこと

* 非曖昧性(無曖昧性, 明確性)
　すべての要求が一意的に識別できる
　何通りにも解釈できる書き方をしない

* 完全性
　要求仕様に必要な情報がすべて記述されている

* 一貫性(無矛盾性)
　記述されている要求が互いに矛盾しない

* 順序付け
　要求が重要性や安定性について優先順位付けされている

* 検証可能性
　要求仕様に含まれる全ての要求に対し、有限のコストで評価可能な手続きが存在して検証できる

* 変更可能性
　要求の変更に対して、容易かつ完全で一貫性を保って修正可能である
　個々の要求が独立していることが必要

* 追跡可能性
　それぞれの要求について，その背景，理由，意図などが明確で容易に参照できる

要求仕様の品質特性は、ソフトウェアの品質特性(機能性、信頼性、効率性、使用性、保守性、移植性)の概念に似ている。
ソフトウェアアーキテクチャの実現可能性の評価の手法としてATAMがある。
ATAMは、ソフトウェア品質特性の観点からシナリオを作り、そのシナリオを詳細化して検証する方法なのだが、サーバー基盤構築やDB性能の検証など非機能要件の検証で結構有効であるように思う。

アーキテクチャではトレードオフは避けられない: プログラマの思索

同様に、要求の品質特性を使えば、それら要求から作られるソフトウェア製品について、その実現可能性や検証に役立てられるのではないかと思う。

【3】ここで、チケット駆動開発に要求工学の品質特性の観点を入れてみる。
チケット駆動開発は、チケットを起点として作業を開始し、テストしてビルドして順次リリースしていく開発スタイルだ。
基本は、ソフトウェア開発のプロジェクト管理をサポートするものである。

チケットには、ユーザから機能改善の要望、障害報告、問合せなどが起票されるし、開発チームからも保守性や移植性を高めるためにリファクタリングやテスト自動化の作業などが追加される。
つまり、チケットは単なるタスクだけではなく、そのタスクの発生源である要求事項も含まれているし、それら要求からチケットが発生する。
たくさんのチケットが完了するたびに、ソースや設計書などの成果物が作られて、ソフトウェア製品へマージされて反映されていく。
つまり、ソフトウェア製品は、チケットから発生したパッチを当てられていくたびに、機能改善や障害修正の要求が反映されて、成長していくものであるといえる。

すると、チケットを要求仕様とみなした場合、要求の品質特性から、チケットはどんな性質を持っているのか？

* 妥当性(正当性、必要性)

ユーザや開発チームからの要求が全てのチケットに反映されているか？
これはNo。
その保証はない。
チケットの登録漏れの可能性もあるから、手運用でカバーするしか無い。
リーダーにとって、タスク漏れは致命的なリスク要因なので、チーム内で誰も担当していない作業がないか、常に気にしている。

* 非曖昧性(無曖昧性, 明確性)

ユーザからの要求がチケットで一意に識別できるか？
これはYes。
チケット番号で、事象や要求を唯一に識別できる。
チケット駆動開発を実践すると、チーム内の会話には、「チケットXX番の作業は終わった？」「YYのチケットは顧客回答があった？」などのように、どんな人も話している内容を一意に識別できるような雰囲気が生まれる。

* 完全性

要求に必要な内容は、きちんと整理されて、チケットに反映されているか？
これはYes。
チケット駆動開発の基本ルールである「Ticket First」「No Ticket, No Work」のプラクティスでカバーしている。
つまり、チケットを起票する時に、他人が分かるようなチケット内容で記載するように、運用ルールで強制している。
チケットに作業する内容、作るべきアウトプットを明確に書いておかないと、開発者に作業を振りにくい。

逆に言えば、チケットはチーム内の誰でも担当できるように、作業内容をきちんと書いておくべき。
そうすれば、担当者が病欠したり、チーム内のリソースが足りない時に、外部メンバーをヘルプですぐに入ってもらいやすくなる。

* 一貫性(無矛盾性)

チケットの内容やチケット同士の関連に矛盾はないか？　整合性は取れているか？
これは半分Yes。
棚卸しというプラクティスでカバーしようとしている。
例えば、1週間おきに全チケットを整理するイベントをもうけて、重複したチケットは重複の関係で関連付けたり、作業不要となったチケットを却下したり、依存関係にあるチケットを関連付けたり、チケットの内容を最新化する。
でも、棚卸しだけのプラクティスだけでは弱い。
リーダーだけがチケットを最新化していたりして、棚卸しの役割が曖昧な時がある。

* 順序付け

チケットを重要度や安定度で並び替えしているか？
これはYes。
チケット集計機能を使えば、作業の優先度、ビジネス上の重要度だけでなく、色んな観点でチケットを順序付けできる。
例えば、プロダクトバックログは、ビジネスの重要度の観点で並び替えている。

ここで「安定度」とは、Coplienの生成的パターン・ランゲージ「パターン３１：名前が付けられた安定したバージョン」を意味していると思う。

パターン３１：名前が付けられた安定したバージョン

例えば、ある要求をソフトウェア製品に反映させたい時、該当する要求に依存関係や影響があり、既存の機能を大幅修正する必要があったりする。
すると、該当の要求をそのまま反映してしまうと、システムが不安定になってしまう。
例えば、ライブラリのVerUpに伴う変更要求、新規画面を作る追加要求など。

システムが安定するように該当の要求を反映するには、例えば、機能追加のように影響が大きい要求はメジャーバージョンで先に延ばし、障害修正や小さなユーザインターフェイス修正のように影響が小さい要求はマイナーバージョンで早めにリリースしていく戦略がある。
すると、要求を安定度の順序に並び替える作業は、要求のリリース計画を作っているのと同様になる。

安定度の話をチケットに適用した場合、チケットをリリースする単位でグループ化して、順次リリースしていく戦略と同等になる。
つまり、チケット駆動開発ではロードマップというViewでチケットをリリース日ごとに並び替えていることと同じだ。

* 検証可能性

チケットは、有限のコストで評価可能な手続きが存在して検証できているか？
これもYes。
チケットの完了条件によって、チケットに書かれた要求仕様や作業内容を評価・検証している。
アジャイル開発ならば、チケットの完了条件はDoneの定義と同様だ。
開発チームが形成された時、真っ先に決める運用ルールは、何を持って作業を完了とするか、というDoneの定義になる。
開発チームが未熟な場合、チームの開発能力は低いから、Doneの定義の範囲はとても小さい。
リリースを経るごとに開発チームが成長していけば、Doneの定義は広がり、Doneの定義のレベルも上がっていく。
つまり、検証可能となるチケットの枚数が増えていくことを意味している。

* 変更可能性

チケットの変更に対して、容易かつ完全で一貫性を保って修正可能であるか？
これもYes。
チケットは開発状況に応じて変更が簡単だ。
チケットのワークフローが変わればトラッカーを変更するし、チケットの作業内容が多すぎると分かればチケットを分割すればいい。
リリース日が変わるならチケットの対象バージョンを変更するだけでいい。

チケット駆動開発の大きな利点の一つは、開発状況の変化にチケットが適応しやすいこと。
そのおかげで、開発チームはチケットにとりあえず割り込み作業は書いておけば、今の作業に集中できる。

* 追跡可能性

それぞれのチケットについて，その背景，理由，意図などが明確で容易に参照できるか？
これもYes。
「No Ticket, No Commit」の基本プラクティスでトレーサビリティを保証している。
この運用ルールこそが、チケット駆動開発の最大の特徴であり利点になる。
また、チケットには履歴が残るので、最初の要求からどのように変化して現在の複雑な要求仕様に確定したのか、という変更理由を後から追跡しやすくなる。

さらに、Redmineのようなチケット駆動ツールでは、チケットを関連付けたり、チケットの親子関係によって階層化したり、横串で全文検索できるなど、追跡可能性を補強するような機能がふんだんにある。
「No Ticket, No Commit」の運用を徹底できれば、チケット経由で要求仕様からソース、ビルドモジュールに至るまでのトレーサビリティは保証される。

【4】チケット駆動開発を要求工学の品質特性の観点から考えると、8つの特性のうち、ほとんどを満たしていることが分かる。
特に「変更可能性」「追跡可能性」はチケット駆動の利点が生きる品質特性だ。
この部分は、従来の開発プロセスでは見落としがちの大きな特徴だと思う。
しかし、「妥当性」「一貫性」の2つの品質特性は、チケット駆動開発は満たしていないことが分かる。

ここで、チケット駆動開発を運用する場合、普通は、ロードマップをリリース計画として扱い、バージョンをXPのイテレーション、Scrumのスプリントと見なして、小規模リリースを実現する場合が多い。
何故、チケット駆動開発では小規模リリースを重視しやすいのか？

その理由は、イテレーションという期間に収まるようにチケットの枚数を減らし、チケットに書かれた作業や要求仕様の網羅性、整合性を取り計らうようにしているからだと思う。
つまり、チケットの取捨選択によって、チケットの「妥当性」「一貫性」を保証するように運用しているのだ。

逆に言えば、チケットの枚数が多すぎると、どうしても、チケットの「妥当性」「一貫性」を保証する作業に工数がかかるだけでなく、作業の品質そのものも落ちるだろう。
チケットは作業スコープそのものだから、リリース対象のチケットを減らすことで、スコープを狭めて、チケットの「妥当性」「一貫性」を解決しようとしているのだ。

チケット駆動開発を運用すると、どうしてもチケットは大量に発行され、チケットを保守するのがとても難しくなっていく。
いかにチケット管理していくか、という根本問題がいつもチケット駆動開発には存在する。
その解決法の一つは、アジャイル開発における小規模リリースを当てはめることで、作業スコープを狭めて、チケット管理しやすくすることなのだろうと思っている。

RedmineのREST APIは素晴らしい～ビッグデータの手法をRedmineにも活用する

RedmineのREST APIを実際に試してみたら、とても素晴らしい。
分かったことをメモ書き。

【元ネタ】
Rest api - Redmine

Redmine REST API - r-labs

Rest Issues - Redmine

コマンドラインとブラウザで JSON API を手軽に試す | COLOPL Engineers' Blog | 株式会社コロプラ【スマートフォンゲーム＆位置ゲー】

RedmineのREST APIを使ってみる | 『世界』はあまりにも広い

Redmine REST API の翻訳 | プログラマーズ雑記帳

【1】RESTはマッシュアップというWebサービスの一つ。
REST APIを使えば、Redmineからチケットの情報だけでなく、プロジェクトやユーザ、果てはWikiまでHTTP経由で取得できる。
RedmineのREST APIの内容を見ると、GETメソッドだけでなく、POST・PUT・DELETEもサポートしているようだ。
また、取得結果はXMLだけでなく、JSONにも対応している。
つまり、JavaScriptで操作したいなら、JSONの方が楽だろう。

RestAPIを使うには、Redmine REST API - r-labsのように、システム管理画面でAPIを有効にした後、個人設定画面でAPIキーを取得すればいい。
そのAPIキーをリクエストに含めてHTTP接続すれば、欲しいチケット情報を取得できる。

ブラウザ上でRESTを試すには、Firefox RESTClientやChromeのAdvanced REST clientを使えば良い。
URLを設定するだけで、GETやPOSTを実行できる。
藤原さんがBlogに書かれているように、Java製のRESTClientもあるので、ローカルPC上で試すこともできる。

Rest api - Redmineによれば、下記のURLにAPIキーをセットすれば、以下のURLでデータを取得できる。
Firefox RESTClientからPOSTして、データを登録してもいい。

# 全チケットを一覧表示
http://localhost:3000/issues.xml?key=XXXX

# チケット番号2の情報を表示(カスタムフィールドも含む)
http://localhost:3000/issues/2.xml?key=XXXX

# プロジェクトID＝2の全チケット一覧を表示
http://localhost:3000/issues.xml?project_id=2&key=XXXX

# 全プロジェクトを一覧表示
http://localhost:3000/projects.xml?key=XXXX

# プロジェクトID＝2のメンバーを一覧表示
http://localhost:3000/projects/2/memberships.xml?key=XXXX

#全ユーザ一覧を表示
http://localhost:3000/users.xml?key=XXXX

# 実績工数のすべての履歴を表示
http://localhost:3000/time_entries.xml?key=XXXX

# チケット番号8470の関連チケットを表示
http://localhost:3000/issues/8470/relations.xml?key=XXXX

# fooプロジェクトの全バージョンを表示
http://localhost:3000/projects/foo/versions.xml?key=XXXX

# Wiki名「マニュアル」のWiki内容を表示(日本語名もOK)
http://localhost:3000/projects/foo/wiki/マニュアル.xml?key=XXXX

# カスタムクエリを一覧表示
http://localhost:3000/queries.xml?key=XXXX

# システム管理画面で作成した全ステータスを一覧表示
http://localhost:3000/issue_statuses.xml?key=XXXX

# システム管理画面で作成した全トラッカーを一覧表示
http://localhost:3000/trackers.xml?key=XXXX

# システム管理画面で作成した全ての優先度を一覧表示
http://localhost:3000/enumerations/issue_priorities.xml?key=XXXX

# システム管理画面で作成した全ての作業分類を一覧表示
http://localhost:3000/enumerations/time_entry_activities.xml?key=XXXX

# プロジェクトID＝2のカテゴリを一覧表示
http://localhost:3000/projects/2/issue_categories.xml?key=XXXX

# システム管理画面で作成した全てのロールを一覧表示
http://localhost:3000/roles.xml?key=XXXX

# システム管理画面で作成した全てのユーザグループを一覧表示
http://localhost:3000/groups.xml?key=XXXX

上記のGETメソッドを見れば分かるように、Redmineにある殆どすべての情報をHTTPレスポンスで取得できる。
このレベルまで対応したOSSのツールはあまりないのではないだろうか？

【3】RestAPIの使い道としては、スマートフォンなどの他のデバイスでRedmineを操作したい時や、他システムと連携してRedmineにある開発プロジェクトの進捗や品質に関する情報を取り込む時があげられるだろう。

前者の場合は、RedminePMのように、iPhoneやAndroid上でRedmineチケットを操作できる。
外出先でRedmineをちょっと見たい時に便利だ。
あるいは、Windows上に、メールソフトのようなリッチクライアントを作って、Redmineチケットの一覧を表示したり、チケットを一括更新できるような機能を作ってもいい。

iPhoneアプリRedminePM: プログラマの思索

後者の場合は、例えば、原価管理システムへRedmineチケットの予定・実績工数を取り込むことで、原価計算することも可能だ。
あるいは、Redmineのチケット情報を夜間バッチで取り込んだ後に、多種多様なメトリクスを日次で蓄積して、時系列で分析するやり方も可能だ。
つまり、経営者に日々の売上や月次のPL/BSを報告して経営判断に使うように、Redmineにある開発プロジェクトの情報を取り込んで、日次・月次のタイミングで進捗や品質に関するメトリクスを出力して、プロジェクト管理の強化に役立てることもできるはず。

【4】RestAPIが有効である理由は、Redmineのようにシステムに有用な情報が蓄積されていることが前提条件だ。
システムに蓄積されたデータが少なかったり、そもそも扱いづらいデータ構造ならば、RestAPIで提供してもあまり意味が無い。
逆に言えば、有用な情報を蓄積したシステムは、RestAPIのように外部の利害関係者へAPIを公開すれば、そのAPIでWebサービスをマッシュアップしてもらうことで、ビジネスチャンスが生まれる。

例えば、下記のマッシュアップ情報一覧サービスサイトを見ると、GoogleやTwitterやAmazonだけでなく、食べログやリクナビ、楽天、天気情報、書籍レビュー、ゲームレビューなどのAPIも公開されているらしい。

ワッフル/WAFL｜みんなで作るWeb API&マッシュアップ情報一覧サービスサイト

マッシュアップの対象として、Googleマップだけでなく食べログの情報も組み合わせたWebサービスを作ったら、面白いのではないだろうか？

また、天気予報APIでは、気温や降雨量の情報を取得して、コンビニの商品の売れ筋傾向を見ることもできる。
あるいは、湿度情報・花粉情報・ビール指数・アイスクリーム指数・素肌乾燥指数などを組み合わせて、医療品やビール、アイスクリームなどの商品を売るタイミングを見つけ出すというWebサービスもありうるだろう。

天気予報API｜活用方法

最近はビッグデータ活用と言われるが、これらの情報を組み合わせて、予期しない事象を見出すというクラスタ分析も簡単になった。
アルゴリズムは既にあり、HadoopやMauhtのようなレコメンドエンジンもあるのだから、アイデアとプログラミング能力さえあれば、いくらでも新しいビジネスを創出する可能性がある。

オープンソースのレコメンドエンジンMahout: プログラマの思索

Redmineにもビッグデータを活用できる可能性が秘められていると思う。

ソフトウェア開発は自己目的化しやすい

ソフトウェア開発は何故失敗しやすいのか？
その一つの理由として、ソフトウェア開発は自己目的化しやすいことがあるのではないかと思ったりする。
ラフなメモ書き。

【1】ITシステムの開発方法として、Enterprise Architecture(EA)という手法がある。
以前、経産省が手法をまとめて推進したために、EAブームがあったが、今は殆ど見る目もない。

Enterprise Architectureの悲劇: プログラマの思索

EAの目的は素晴らしい。
ITシステムは、個別のプロセスの効率化ではなく、ゴールを見据えてプロセスを全体最適化すべきだ、と謳うのは上手い。
BPRのように、既存の業務プロセスを抜本的に見直して再構築する考え方とマッチする。

経産省はEAにおける必要な成果物もドキュメント作成手順も統一化し、公開した。
しかもPDCAサイクルで回すというEAのプロセスまで語っている。

しかし、EAの結果は惨憺たる結果だ。
EAと直接関係ないかもしれないが、日本の官公庁のITシステムで成功した事例はほとんど聞かないように思う。
目立つのは、ITシステム開発プロジェクトの失敗事例ばかりだ。

ASCII.jp：情報社会の新たな課題～消えた年金のシステム問題～

特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態 － Publickey

官公庁のITシステム開発は金額が途方もなく大きく、工数も莫大にかかるぐらい、複雑怪奇なシステムだ。
EAを標準にして開発プロセスを定めたとしたら、EAのサイクルであるPDCAサイクルがうまく回るわけではない。
EAには実際の具体的な改善サイクルのノウハウは書かれておらず、現場任せだ。

また、EAの成果物を作るだけでも途方もなく多くのドキュメントが必要だ。
ドキュメントを作るだけで精一杯になりがち。
だから、計画を作って実施して評価の報告を作って終わりになりがち。

更にまずいのは、ドキュメントを作れば仕様が確定するので、予算が取れることだ。
すると、EAとは単なるドキュメント生産活動になってしまい、保守されないドキュメントが山のように作られる。
時代に合わせて、現場に合わせて、システムをどんどん改善しないといけないのに、ドキュメントの整合性を取りながら保守するだけでも大変で、肝心のシステムに反映されない時が多い。

EAはそれ自身が自己目的化してしまい、肝心のITシステムの全体最適化には有効でないように思える。

【2】EAの失敗事例は、CMMIやERPのような失敗事例を想起させる。
CMMIはソフトウェア開発プロセスを標準化し、プロセスをレベル分けすることで、組織の開発能力を評価して改善させようとした。
ERPは、業界のベストプラクティスを集めて標準化したプロセスをパッケージ製品として提供し、既存の業務プロセスを抜本的に改革することを目指した。
しかし、CMMIもERPも、現場の担当者レベルでは、ドキュメント作成活動に自己目的化しがちだ。
現場で活動する人達が実際に作業している内容と、高邁な目的の間にギャップが大きすぎるのだ。

CMMIもERPもプロセスを標準化しようとする。
その最大の欠点は、フィードバックプロセスを重視していないことではないか？
現場の担当者のフィードバックをプロセス改善に活かす活動がうまくいっていないように思える。
フィードバックしても、課題と現場の作業にギャップがありすぎて、課題を解決することがとても難しいように思えてしまい、メンバーにとって、改善している感覚がないのだ。

また、フィードバックを受けても、フィードバックの量が多すぎたら、開発者も開発チームもその内容を咀嚼して制御することもできないだろう。
そんな状況は「相殺フィードバック」と言われるらしい。

相殺フィードバック: プログラマの思索

だから、CMMIもERPも現場担当者のレベルでは、それ自体の作業が自己目的化しやすい。

【3】「ソフトウェア開発は自己目的化しやすい」弱点に対し、アジャイル開発が良い所はいくつかある。
一つは、フィードバック活動に注力していることだ。
XPやScrumにしても、朝会(デイリーミーティング)やふりかえり(レトロスペクティブ)というイベントで、開発者が現状の問題点をチームに公表する機会が必ずある。
そして、その問題点をチームで解決しようとするプロセスがある。
特に、ふりかえりではKPTが有効で、KPTのやり方にはノウハウが結構ある。

フィードバックはたくさんありすぎても意味が無い。
フィードバックを受けた内容を次の開発サイクルに適用して、改善するように回さないといけない。

XPが提唱する小規模リリースでは、2～4週間のイテレーションで、定期的にリリースしていく。
たとえ機能が少なくてもリリースすることで、顧客に価値あるシステムをいち早く届けることができる。
そして、開発者も開発チームも、実際に動くシステムに触ることで、顧客から有意義な改善要望や障害報告を受けて、より良いシステムを作れるように、次のイテレーションへタスクを当てはめていく。

スクラムでは、スプリントの終わりに必ずデモを行い、利害関係者全員に見せるイベントがある。
デモを見せるからには出荷可能な製品をスプリントの最後にはリリースしなければならない。
「Demo or Die」という言葉が象徴的だ。
デモを見せることによって、顧客からのフィードバックをプロダクトバックログへ反映させて、次のスプリントに向けて改善していく。

いずれにしても、フィードバックプロセスを開発チームがコントロールできる範囲内で制御し、出荷可能な製品という現物を顧客に必ず届ける。

また、XPならオンサイト顧客、Scrumならプロダクトオーナーのように、開発チームは顧客を巻き込んで開発に取り組む。
彼らは、ゴールを開発者に思い出させる役割も持っている。
今作っている作業は、顧客にとって本当に価値あるものなのか、という評価をすぐに受ける仕組みが揃っているのだ。

【4】実際のソフトウェア開発は、ソフトウェアを作ってリリースするだけでもすごく大変だ。
ソフトウェアを無事にリリースするだけで精一杯なので、リリースしたソフトウェアがユーザにとって本当に価値があるかどうかまで正直頭が回らない時が多い。
だからこそ、タイムボックスで短い間隔でリリースしてフィードバックを受ける仕掛けが必要になってくるのだろう。

この辺りの議論はもう少しまとめてみる。

第5回品川Redmine勉強会のオープンスペースでは「開発者がRedmineを使いこなすには？」のテーマを議論します #47redmine

来る6/29(土)の第5回品川Redmine勉強会のオープンスペースでは、開発者・マネージャ・運用担当者・Redmineシステム管理者の4つの立場で議論します。
私が担当するテーマは「開発者がRedmineを使いこなすには？」なので、そのお題を事前に公開します。
自分はどんなことを議論したいのか、事前に考えて、当日は同じチームの参加者に意見をぶつけてみてください。

第5回勉強会 - shinagawa.redmine

第5回品川Redmine勉強会～開発者がRedmineを使いこなすには？ from akipii Oga

【お題】
4つの課題のうち、1個以上の課題について、議論して、チームで発表して下さい。

・チケット入力
・チケット集計
・ワークフロー
・SCM連携

【1】チケット入力

・チケットのタイトルはどのように書いていますか？
一目で分かるタイトルですか？
例えば「Exception発生」「お客様の問合せについて」のように、数日経ったら誰もすぐに判別できないタイトルになっていませんか？

・チケットの内容はどのように書いていますか？
他人が分かるように書いてますか？
チケットの内容がアバウトすぎて、作成者にもう一度問い合わせたりしてロスが発生していませんか？
チケットが障害票の場合、障害の再現手順を明確に書いていますか？
顧客の問合せ内容について、的確に記載するように追記していますか？

・カテゴリにはどんな値を設定していますか？
チケットの属性の中で最も重要です。
カテゴリを上手く使えば、Redmineのチケット集計画面で色々使えます。
カテゴリには、システムの機能、サブシステム名、開発チーム名、工程名など、色んなやり方がありますが、あなたの現場では、どんな理由でどのように設定していますか？

Redmine等のチケットの書き方について、特に自分の考えをまとめるという観点から - 蟲！虫！蟲！ - #!/usr/bin/bugrammer

【2】チケット集計
Redmineは、チケットの属性とチケット集計機能の関連性がよく考えられています。
Agile開発はロールでViewを意識的に切り替えます。
例えば、プロダクトオーナーや顧客はバックログ、開発者はタスクボードのように、同じデータを別のビューで参照しています。
しかし、WF型開発は、ガントチャートやフィルタ付きのExcelぐらいしかなく、意外にビューが貧弱です。

・他に使いたいViewはありませんか？
ITSはチケット集計機能が意外に貧弱です。
マネージャの進捗管理は、ガントチャートだけではないです。
アジャイル開発の管理も、バックログだけではないはずです。

・ロールで見え方が変わるViewはありますか？
顧客と開発者では見たいViewは違います。

・現場でどんなカスタムクエリを使っていますか？
新規開発と運用保守、問合せ管理では、見たいViewが異なります。

【3】ワークフロー
ワークフローはペア作業で考えよう。
チケットは2人以上の担当者がキャッチボールして終わる。

ワークフロー(トラッカー)にはアンチパターンがとても多いです。

・足りないステータス
作業者が作業中の状態とステータスが一致していない。
バグ修正とバグ検証を開発者とテスターがやり取りする場合、テスターの作業ステータスは「担当」なのか「解決」なのか？

ステータス名を「～前」「～待ち」のネーミングにするとフィットしやすい。
例えば「検証待ち」「レビュー待ち」「リリース前」などにすると、今誰がチケットを持っていて、ボトルネックになっているか、判断しやすい。

Redmineチケットのステータスのネーミング方法: プログラマの思索

・運用とずれているワークフロー
「バグ」と「顧客問合せ」を同じワークフローで扱う。
ステータス名と実際の運用が一致していないので、ステータス名を別の意味に置き換える必要があり、途中参加のメンバーが分かりづらい。

・複雑すぎるワークフロー
「終了」まで10個以上のステータス遷移がいる。
ワークフローをガチガチに運用しすぎる。
マネージャが管理にはまるとよく起きる。
ワークフロー管理は考えだすととても楽しいが、キリがない。
現場の作業者の気持ちになって、ワークフロー管理を考えよう。

・多すぎるトラッカー
同じワークフローなのにトラッカーの種類が多すぎる
例：仕様変更、仕様追加、バグ修正、新規開発 etc.

トラッカーのライフサイクルで区別したり、OOAの知識操作パターンでトラッカーを統一したりしよう。

チケット駆動開発がもたらした新しい観点part3～トラッカーの考え方: プログラマの思索

【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12: プログラマの思索

【4】SCM連携

・No Ticket, No Commitの運用で工夫していますか？
面倒という理由でやらない人へどのように説明しますか？

・No Ticket, No Forkの運用上の注意点はありますか？
Gitでトピックブランチを作ってmasterへマージする時、どれを選んでいますか？　その理由は？
Cherry-pickしてマージする
Merge -no-ff でマージする
Merget -ff でマージする
Rebaseしてマージする

【5】最後に
Redmineの楽しい使い方を提案して下さい

チケット駆動は意外に面倒です。
チケット無しの作業不可、チケット無しのコミット不可 etc.

楽しくする仕掛けはありませんか？
進捗や品質を見える化
Likeボタン、Good Job画面
Twitter、Blog、ニコニコカレンダー etc…..

Redmineに入れたプラグイン一覧part3: プログラマの思索

Redmineに入れたプラグイン一覧part2: プログラマの思索

Redmineに入れたプラグイン一覧: プログラマの思索

当日の勉強会で熱い議論になることを期待しています。

【追記1】
@kazuhito_mさんが、第5回品川Redmine勉強会のCMを作って公開して頂きました。
ありがとうございます！

Twitter / kazuhito_m: @sakaba37 @naitoh @akipii ところがどっこい！ 昨日もう作っちゃったんすよねーw https://www.dropbox.com/s/vlwh6gu5sg35vn9/sinagawa_redmine.mp3 … やっつけすぎるので、ボツなら作り直します。

【追記2】
@tech_machiiさんが、「マネジャーがRedmineを使いこなすとは？」のお題を公開してくれてます。

第５回品川Redmine勉強会の資料 from Masanori Machii

第5回品川Redmine勉強会にTiDD本著者の基調講演があります #47redmine

第5回品川Redmine勉強会に、TiDD本著者@sakaba37さんの基調講演が追加されました。

第5回勉強会 - shinagawa.redmine

タイトル：「チケットシステムの可能性 - 開発から業務まで -」
講演者：@sakaba37さん
概要：
「エクセルでできるやん！」そんな疑問に答えます。チケットシステム(ITS)はスプレッドシートと比べてどのような可能性があるか、その違いを身近な比喩で説明します。ソフトウェア開発にチケットシステムは当たり前だとわかっていただけるでしょう。
　また、導入中の社内業務の改善事例も説明します。簡単な事例ですが、社内での説明や、業務改善のヒントにしていただけるでしょう。

なお、下記の方のBlogを読むと、過去に何度も足を運んで頂いて、たくさんの刺激を持ち帰っていただけたようです。
スタッフの一人としてとても嬉しいです。
今回の勉強会も、参加者にとって有意義な1日になるように準備したいと思います。

第5回shinagawa.redmine勉強会が6/29（土）に開催 - torutkの日記

第4回shinagawa.redmine勉強会に参加してきた - torutkの日記

第3回品川Redmine勉強会に参加してきた - torutkの日記

FreeMindの応用的な使い方

FreeMindの使い方がオンラインで公開されていたのでメモ。

【元ネタ】
FreeMindの応用的な使い方 | FreeMind使おう会

Main Page - FreeMind

マインドマップでは、1階層目のブランチの書き方が大切。
手書きの場合、ノードを太く書くことを推奨されていた。
FreeMindのデフォルトはイマイチなので、設定を変えておくと良い。

1階層目から華やかに | FreeMind使おう会

【推奨】初期画面をカラフルにするには | FreeMind使おう会

Excelの表の添付もできるのは便利。

Excelの表の利用 | FreeMind使おう会

書籍を読んだら、マインドマップで簡単にまとめておくと便利。
僕は手書きで書いているが、PCで書いておけば、後から流用することもできる。

書籍の情報収集・要点整理の事例 | FreeMind使おう会

第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy

第8回#RxTStudy勉強会の感想をメモ書き。

第8回RxTstudy : ATND

RxTstudy

【1】@hakuraiさん「BacklogチームのGit運用」

BacklogチームのGit運用のお話。
Gitは1年前から使い始めたとのこと。

初めの頃は、masterからフィーチャブランチを作り、cherry-pickでマージしていた。
この運用方法は、Subversionのマージ方法と同じ。
しかし、cherry-pickなので、元のコミットと別物のため、どのリビジョンからマジされたのか後で分からなくなること。

次に、masterからトピックブランチを分岐して修正した後、-no-ffでマージして、ブランチの履歴を残すようにした。
すると、コミットグラフにどのブランチからmasterへ取り込まれたのかが分かる。
A Succeccful Git Branch Modelを参考にしたのと事。
しかし、トピックブランチが乱立して、コミットグラフがわかりにくくなった。

そして、今は、コミットログに必ずチケットNoを残し、rebaseを使ってマージするか、Fast Fowardでマージするようにしたとのこと。
No Ticket, No Commitがあれば、ブランチの履歴はコミットグラフに逐一残す必要がない。
rebaseやFast Fowardマージによって、リビジョングラフが一直線になり、見えやすくなる。

この運用方法は、Redmineコミッタのまるやまさんが質問されていたが、Redmineの開発スタイルと同じ。
RedmineはSubversionで管理しているため、Gitが使えず、rebaseでマージするしか仕方ない理由もあるが、大人数で開発する時はこのやり方がBetterなのだろうと思っている。

【2】@g_maedaさん「Redmineによるメール対応管理の運用」

Redmineによるメール対応管理の運用事例 from g_maeda

Redmineをヘルプデスクに使った運用事例のお話。
顧客からの問い合わせメール対応を行うヘルプデスクの問題点は
・どのメールが未対応なのか分からない
・メールは履歴を追いにくい
・問い合わせメールが埋没しやすい
点がある。

上記の問題点を解決するために、
・Redmineの機能である「メール発行でチケットを自動登録」する方法を使う
・返信メールのような履歴は、チケットの注記(コメント)で記録する
・添付ファイルもチケットで集中管理する
・問い合わせメールから発生したタスクも関連チケットで管理する
ように対応した。

メールでRedmineチケットを自動登録する方法は、メールサーバー上でリアルタイムにチケット発行する手法と、Redmineサーバーからメールサーバーへ定期的にPOP3経由でメールを取得してチケット発行する手法がある。
やり方は下記に書いた。

メールでRedmineチケットを登録する機能のアーキテクチャ: プログラマの思索

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

@g_maedaさんは、メールサーバー上でリアルタイムにチケット発行する手法を採用したらしい。
だから、Redmine設定画面でメール登録用のAPIを発行して、mail_handler.rbをメールサーバー上に配置して実行しているらしい。

メールによるRedmineチケット登録機能には、
・Subjectに「[#123]」のようにブラケットとチケット番号があれば、返信メールも該当チケットのコメントに追記してくれる
・添付ファイルもチケットに自動で添付してくれる
点があるのでとても便利。

また、ステータス管理は
・新規：問合せメール到着
・進行中：問合せメールを対応中。要返信。
・解決：問合せメールを返信済み。回答待ち。
・終了：「ありがとうございます」の返事で対応完了。
に置き換えて運用しているとのこと。

問い合わせメールをRedmineチケットで管理する利点は
・対応漏れをチェックしやすい
　(一定期間更新されていないチケット(例：3日以上)をクエリでフィルタリングして、スタッフに対応させる)
・メール到着状況やメール対応状況をチェックしやすい
　(ステータスをgroup byして、進行中や解決中のチケットを日々追跡してスタッフに対応させる)
点がある。

但し、問合せメールのRedmineチケット管理にはまだいくつかの問題点が残っている。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
　メール対応という一つの目的で2つのツールを使っている。
　だから、一つの対応方法としては、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきか？
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
　古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
　顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
　忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
　メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の運用は、Redmineがコールセンターのヘルプデスクシステムとして使えること、つまり、RedmineがCRMシステムとして運用できる可能性を秘めている事実を示している。

いわゆるCRMソフトでは、顧客からの要望や苦情のメールを一つのメールアドレスで受信する機能(インバウンドメール)、CRMソフト上から特定の顧客へ返信したり、顧客全員にメールを一括送信できる機能(アウトバウンドメール)がある。
「メールによるRedmineチケット登録機能」はまさに「インバウンドメール」機能そのものであり、Redmineに不足している機能である「Redmine画面上で返信メールを送信できる機能」はまさに「アウトバウンドメール」機能だ。
つまり、Redmineにもアウトバウンドメールの機能が追加されれば、CRMソフトとして一通り揃っていることになる。

SugarCRMを参考にしたら面白いと思う。
SugarCRMにも実は問合せ管理のためのチケット管理機能があるからだ。

SugarCRMの運用サイクル: プログラマの思索

Redmineチケットに顧客の問合せメールが転記されることによって、チケットが顧客情報に対応付けられ、チケット集計機能によって、顧客の行動を分析できるインフラが自動的に整う。
CRMではいわゆるバケット分析など、顧客の行動を分析するデータマイニングの手法はかなり揃っているので、Redmineのチケット集計機能へ応用すれば面白いと思う。

【3】＠marutosijpさん「Redmine本体の開発スタイル(仮)」
Redmine本体の開発スタイル

詳細は上記の資料通り。
興味深かった点は、Redmineはテストが厳しいこと。
日々CIでテストを自動化しているし、カバレッジも測定している。

RailsはVer2とVer3では、フォルダ構造もアーキテクチャもガラリと変わったため、VerUp対応はとても大変だった。
Redmineはテストが厳しく、テスト自動化の環境があったからこそ、RailsをVer2からVer3へ無事にアップグレードできた、とのこと。

RedmineがRails3対応を始めた時、コミッタのJPLは、まずテストのカバレッジを100％にすることから始めた。
その点はJPLはすごい、とのこと。

実際、Redmineから派生したChiliProjectやOpenProjectはRails3へのVerUpに成功していない。
コミッタやコントリビュータはいるが、ほとんどコミットされていないことからも分かる、とのこと。
RailsをVer2→3へアップグレードする作業がいかに大変であるかが分かると思う。

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

おそらく、Railsの古いバージョンで作られたWebアプリはいずれも、Railsのバージョンアップに苦しんでいるだろうと思う。
システムがVerUpする速度に追いつけない理由の大半は、テスト自動化の環境がないために、品質が劣化してしまうからだろう。
解決の鍵は、テスト自動化にある点がとても興味深い。

【4】懇親会で@akahaneさんと話していて気づいたことは、RedmineがERPの情報系システムとして使える可能性を秘めていること。
GoogleのPageRankでは、あるWebページが他のWebページから参照される回数が多いほど有用であると判断するアルゴリズムがある。
すると、Redmineのチケットに関係するタスクや障害などを関連チケットや子チケットとしてリンクしておくと、そのチケットは、PageRankアルゴリズムの検索エンジンで上位に表示される可能性が高くなる。
何故なら、他チケットから参照される回数が多いからだ。

つまり、チケットという情報を有用であるデータにするには、単に障害をチケットに起票するだけでなく、過去のチケットと関係していれば関連チケットに紐付けたり、コミットログにチケット番号を書いたりして、そのチケットのWebページが他のページから参照できるように運用した方が良い。
すなわち、URIというWebページ表示のインターフェイスを通じて、チケットを検索する機能を有効にするには、チケットを他チケットやリビジョンから参照するように、チケットを保守する運用が大切なのだ。

同様に、Amazonのレコメンドエンジンでは、ある商品を買う顧客に対して、同じ客層の購買履歴から関連商品をお勧めする機能がある。
すると、Redmineでも、一つのソースを修正した時、他に関連するソースも修正した方がいいよ、とお勧めする機能があってもいいはずだ。
そのイメージは下記に書いた。

Redmineにお勧めソース機能が欲しい: プログラマの思索

つまり、Redmineのチケットに貯められた情報は、PageRankアルゴリズムやレコメンドエンジンを使ってデータマイニングすることで、有用な結果を抽出して分析に使える可能性があると思う。
RedmineをいわゆるBIとして使えるようになる可能性があると思う。

BTSをBusiness Intelligenceとして使う: プログラマの思索

ITSをBusiness Intelligenceとして使う方法こそが本来のソフトウェア工学におけるメトリクスの分析ではないかと思ったりする。

僕はRedmineをアジャイル開発に適用した事例しか持っていないけれども、@g_maedaさん、@akahaneさんのお話を聞くと、Redmineを単なるソフトウェア開発のタスク管理ツールとして使うだけでなく、他の用途にも使える可能性がある事実を示唆しているように思える。
Redmineのメーリングリストでも、Redmineを「製造業での工数実績収集分析ツール」として使いたいと考えている人もいる。

利用の可能性 - Google グループ

そんなことを考えると、Redmineはカメレオンみたいなツールだと思う。
ある時は、障害管理システムであり、タスク管理であり、ヘルプデスクシステムであり、工数実績収集分析ツールでもある。
その背後にあるチケット駆動開発には、どの場面に適用できるのか、という問題意識さえ持てば、たくさんの可能性が秘められているのだと思う。

iPhoneアプリRedminePM

iPhoneアプリRedminePMが使いやすいと言う話を聞いた。
リンクをメモ書き。

【元ネタ】
RedminePM - Redmine Client for iPhone

RedminePM　～この上ない使いやすさに脱帽！Redmineユーザー必携のクライアントアプリ！～ | アプリ | AppLibrary

RedminePM

Twitter / YOhwada: @akipii PCでの使い勝手には当然およびませんが、チケットのチェック位なら便利です

Redmineを運用してくると、PCでアクセスするだけでなく、スマートフォンからもアクセスしたいと思うものだ。
たとえ社内用Redmineだったとしても、マネージャは会議でほとんど自席にいないため、社内からスマートフォンでアクセスできるようになると色々と助かるものだ。

あるいは、Redmineを営業マンのタスク管理ツールとして使っているならば、営業マンが社外からアクセスできるようにすると便利だろう。
思い出せない情報をチケットから探したり、顧客訪問前にWikiやチケットの中身を見ておいたり、客先からチケットへiPhoneカメラ画像を添付するなど、いろいろな用途が考えられる。

RedmineのiPhoneアプリは以前からもいくつかあったけれども、いまいち使いづらい点があった。
RedminePMを今度使ってみようと思う。

なお、RedminePMの開発者の方が第5回勉強会 - shinagawa.redmineに参加されるというFacebookの記事があったので、ちょっと楽しみだ。

MEDIA MAKERSの感想

「MEDIA MAKERS」を読んで面白かったのでメモ。
著者は、リクルート、ライブドアの広報関係を経て、NHN Japanにいるらしい。
自分のBlog、Twitter、Facebookを持っている人は参考になると思う。
ラフなメモ書き。

【参考】
[書評]MEDIA MAKERS―社会が動く「影響力」の正体 | ごりゅご.com

書評『MEDIA MAKERS 社会が動く”影響力”の正体』(田端信太郎)がめっちゃ勉強になる | Last Day. jp

[書評]ブロガーも必読。MEDIA MAKERS―社会が動く「影響力」の正体 - 拡張現実ライフ

Facebookはセルフブランディングの最強ツール: プログラマの思索

ビジネス特化SNS「Linkedin」から見えるもの～人脈はデータマイニングで作られる: プログラマの思索

Twitterは最速のメディア: プログラマの思索

真のIT企業はメディア企業を目指す: プログラマの思索

Google、それは強大な広告代理店: プログラマの思索

【１】メディアリテラシーがマネージャや経営者にも必要になった現代という時代

経営資源といえば、人・モノ・金・情報。
過去はお金がボトルネックになりがちだったが、現代はかなり変わった。
リーンスタートアップのように、小さなビジネスから始めて大きな会社に変わる事もできる。
シリコンバレーのIT企業がその典型例。
FacebookもGoogleもいつの間にかMicrosoftと肩を並べる企業になった。

すると、「War For Tarent」のように、メディアを使って、いかに優秀な人材を集めるか、ということが企業にとって死活的に決定的に重要になってきた。
メディアは、人の注目を集め、優秀な人材（タレント）を引き寄せて、タレントを動機づける機能を持つ。

現代では、マネージャという管理職、組織を動かす経営者は、メディアという機能をもっと知る必要があるし、効果的に使う方法を知る必要もある。
それは丁度、経営者やマネージャのレベルの人は、減価償却やキャッシュフローの意味を知っていて、会計やファイナンスを理解しているのが当然のように。

【２】メディアが存在する意味～予言の自己実現能力

メディア自身が保つ意味は、予言の自己実現能力。
大手新聞や大手テレビが、現実はそうなっていないのに、こうなるだろう、と予言すると、その方向へ現実が変わってしまうこと。
例えば、企業の倒産につながる大事件などのようなスクープは、そのニュース自身が政治的に大きな影響力を持つ。
沢山の人、集団を巻き込んでしまう。

そして怖いのは、その発言（予言）は間違っていたので訂正します、という作業が不可能なこと。
予言が現実になってしまった後に、現実を訂正することはできない。
予言の自己実現能力の的中率が大きいほど、政治的影響力も大きくなるから、それ自体が権力にもなる。

だから、メディアは信頼性や高潔さ、ブランドが重要視される。
誰もそのメディアの情報を信じなくなったら、メディアには存在意義がない。
編集権の独立は、メディアにとって死活的に重要な要因。
広告主や株主の意向で簡単に変わるようなメディアであれば、ユーザはすぐにその意図を感じ取り、メディアの影響力は限定的になる。
メディアの信頼性が他メディアの差別化要因にもなる。

【３】メディアの種類

メディアの種類は、３種類の軸がある。
一つは、ストック型・フロー型。

メディアの情報がストックされるのか、フローとして流れていくのか、の違い。
ストック型は例えば、源氏物語のような古典小説もあれば、WikipediaのようなWebメディアもある。
Wikipediaはgoogle検索と相性が良い。
実際、google検索エンジンの上位にはWikipediaがあり、Wikipediaはたくさんの人の目に触れて、更新されることでその存在価値を増している。

フロー型は例えば、TwitterやLINEなどもあるし、新聞も同じ。
新聞は１日しか賞味期限がない。
(Twitterは現代のメディアの中で最速のメディアだと思う。その分、Twitterの政治的影響力は大きい。大阪維新の会の橋下氏はTwitterを有効に使っていると思う。)

２つ目は権威型・参加型。
例えば、権威型はミシュラン、参加型は食べログのような違い。
権威型メディアは、内容を恣意的に制御することで、メディアの内容の価値や信頼性を高めようとする。
参加型メディアは、Googleの検索結果のように、集合知に特徴がある。
カカクコムにおける製品の感想、Amazonでの商品の感想も同様。

Googleがその検索アルゴリズムに恣意性がないことを保証することが彼らのビジネスで決定的に重要であったと判明した事象が、中国から除外された事件。
GoogleのPageRankアルゴリズムに恣意性が混じっていると判明したら、Googleの存在価値はかなり落ちてしまうだろう。

３つ目はリニア型・ノンリニア型。
メディアに触れる時に時間を縛るかどうかの観点。

例えばリニア型は映画。
映画館で２時間も拘束する。
そして、映画監督はCMディレクターなど似たような職種の中で最も権威が高い。
書籍もリニア型に近い。

ノンリニア型は、Web。
主権はユーザにあり、マイクロコンテンツ化される。
サイトマップを作って、Webにストーリー性を入れても、SEOでリンクから入った画面しか見ない時が多い。

今のメディアは、フロー・参加・ノンリニアへどんどん重心が移動している。
それが良いかどうかは別として、その傾向がある。

【４】メディアのビジネスモデル

稼げるメディアは自由になれる。
貨幣とは鋳造された自由。
編集コストを気にしなくていいし、イベントの広告宣伝もできる。
株主や広告主のような外部の利害関係者からも自由になれる。

Webメディアの利益は、（PV当たり売上－PV当たり費用）* 全体PV　という簡単な公式。
だから、KPIとしては、PVを増やすためにUU（ユニークユーザ）を増やしたり、UU当たり売上を増やすなどの方法がある。

新聞やWebなどのメディアの弱点は、売上回収のビジネスモデルが不安定なこと。
新聞もWebメディアも広告モデルに依存していた。
しかし、広告主自体がメディアを持つのが簡単になり、TwitterやFacebookなどで告知する影響力が大きくなったから、広告を出す必要もない。
（個人メディアとしてはBlogにGoogleやAmazonのアフィリエイトが普及したことにより、個人メディアでも広告モデルが成り立つようになったのは大きい事象だ）

そこで、メディアとしては課金モデルの確立が課題。
最近は、個人メディアとして有料メールマガジンが流行している。
メールマガジンという最も古い媒体で課金モデルが有効であるのは興味深い。

【５】メディアはアーキテクチャに支配される～媒体手段が人間の経験形式を規定する～

メディアの内容は媒体手段というアーキテクチャに大きく支配される。
CDが７４分なのは、カラヤンが第九が入るだけの容量にして欲しいとソニーにお願いしたから。
そこから音楽CDが流通手段として普及し、音楽の聞き方も変えてしまった。
特に９０年台。
サビ頭の曲が増えた。例えばZard。
音楽CDはリモコン片手に好きな曲だけつまみ食いできるから。
以前のように、後半にサビを持ってくるような曲は減った。
iTunesになって、更に曲はバラ売りされるようになった。

WebメディアはPVを稼ぐように最適化されている。
例えば、タイトルや見出しは、SEOで検索されやすい言葉を並べるように変わってしまった。
スマートフォンのようなデバイスが普及して更に変化した。
だから、新聞のような大手メディアも、いつの間にか時代遅れの路地裏の店に変わらないとも言えない。

新聞はプラットフォーマーなのか、プレイヤーなのか？
GoogleのCEOが話したように、ネット上のプラットフォーマーは、Google・Amazon・Apple・Facebookのたった４社だけ。
プラットフォーマーは莫大の個人情報データを持っているのが最大の強み。
しかも、AmazonやAppleはクレジットカード番号の個人情報も持つので、ユーザが興味を持てばすぐに支払ってくれる基盤すらある。
そこからより効果的な広告を表示したり、レコメンドエンジンで商品を誘ったり、色んなビジネエスができる。
プラットフォーマーに新聞がないだけでなく、マイクロソフトやヤフーすらいないのも興味深い。

【６】メディアの怖さ～個人メディアは無限責任、組織メディアは有限責任

商業メディア、組織メディアは株式会社であるからには、有限責任になる。
しかし、「誤報すら自己実現化してしまう」メディアと有限責任は相性が悪い。
組織メディアの最終責任は会社の倒産だが、個人の責任まで及ぶことは稀。

でも、メルマガやBlog、Facebookなどの個人メディアで同様のことがあれば、その個人の社会的地位や評判、名声を否定され、社会的な抹殺までされてしまうだろう。
つまり、個人メディアは無限責任。

個人メディアは、そのメディアを発信する個人が持つ信頼や影響力に大きく依存している。
その信頼や影響力を評価資本と呼ぶこともあるらしい。ある意味では個人ブランド。

個人メディアを持つ人は、ある分野において信頼と影響力を持つ個人型メディアといかに付き合うか？
そこで披露される知見を他メディアとどのように差別化していくか？

【７】「MEDIA MAKERS」を読んでみて、BlogやTwitter、Facebookが、個人メディアになる可能性があり、影響力を持つツールであることを改めて痛感させられた。
最近は、「メディアが予言の自己実現能力を持つ」意味をよく理解していて、うまく使いこなしている人も多いように感じる。

特に、社長のような経営者や政治家は、BlogやFacebook、Twitterを上手く使って、自分の考えを発信することが重要になっていると思う。
ITベンチャー企業のような小さな会社は、アナログの営業よりも、BlogやFacebookで開発者や潜在顧客へリーチする手法を使った方がより効果的だろう。

でも、メディアにはその影響力の行使と表裏一体の怖さもある。
今後、ITリテラシーと同様に、メディアリテラシーも普通の一般人にも必須の能力になってくるのかもしれない。

Rubyのガントチャート生成ツールTaskJuggler

フリーのマインドマップFreeMindをいじくっていたら、エクスポート機能にTaskJugglerという項目があった。
TaskJugglerはRubyのコマンドラインによるガントチャート生成ツールらしい。
以下メモ書き。

【元ネタ】
taskjuggler/TaskJuggler · GitHub

TaskJuggler 3 超入門 - 目次とTaskJugglerのインストール：プロジェクト管理 -- フリーソフトでやってみよう：So-netブログ

TaskJuggler - A Free and Open Source Project Management Software - About TaskJuggler

TaskJuggler 3.4.0 on Windows/on MacOS X：プロジェクト管理 -- フリーソフトでやってみよう：So-netブログ

TaskJuggler|オープンソース・ソフトウェア、ITニュースを毎日紹介するエンジニア、デザイナー向けブログ

Taskjuggler を mac にインストールしてみた - takenoko1977の日記

Bluetooth詳説 - TaskJugglerについて

TaskJuggler を触り始めた

nDiki: ガントチャート - 今日のさえずり: 男性が1人でするならマンションで、複数でするならメンションです (2012-02-07)

nDiki: ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

【インストール方法】
Rubyはインストール済み
↓
gem install taskjuggler
↓
tj3 --version
TaskJuggler v3.4.0 - A Project Management Software

【使い道】
サンプルファイルtutorial.tjpに対し、下記を実行すれば、HTML出力される。

tj3 tutorial.tjp

DSL風に、WBSやら期間、工数、担当者を入力すると、ガントチャートやバーンダウンチャート、リソースグラフなどを出力してくれるらしい。
出力形式はHTMLもあるし、色々あるみたい。
但し、PDF出力はない。

Product Burndownのサンプルは下記の通り。

Scrum Example Project - Product Burndown

コマンドラインしか使えないので、スケジュールに関するデータをテキスト形式に書かないといけない。
また、TaskJugglerのためのマクロを覚えないと、希望通りに出力されない。
でも、逆に言えば、テキストファイルでスケジュール管理できるので、バージョン管理で簡単に履歴管理できる。

元ネタのスケジュールをテキストで履歴管理するだけでなく、Webサーバー上へ定期的にHTML出力して公開するようにするやり方もある。
つまり、スケジュール管理も継続的インテグレーションで定期ビルドしてしまえばいいのだ。

使い道を色々考えてみる。

Enterprise Architectureの悲劇

Enterprise Architectureに関する記事が面白かったのでメモ。
あくまでも感想なので、ラフなメモ書き。
おかしな所があれば後で直す。

EAコラム(1)　みなさん元気にEAやってますか？ | ARIS BPM Community

EAコラム(2)　EAが巻き起こした悲劇 ① | ARIS BPM Community

EAコラム(3)　EAが巻き起こした悲劇 ② | ARIS BPM Community

EAコラム(4)　EAが巻き起こした悲劇 ③ | ARIS BPM Community

EAコラム(5)　EA来襲　その時歴史は動かなかった ① | ARIS BPM Community

EAコラム(6)　EA来襲　その時歴史は動かなかった ② | ARIS BPM Community

Enterprise Architectureと言えば、全体最適化のためのITシステム戦略のイメージだが、バズワードに近いと思う。
上記の記事にも書かれているが、複数の個別システムの全体最適と言いながら、中身は下記のドキュメントをキングファイルでまとめるだけに過ぎないと勘違いしやすい。

　・業務説明書
　・機能構成図（DMM）
　・機能情報関連図（DFD）
　・業務流れ図（WFA）
　・情報体系整理図（UMLクラス図）
　・実体関連ダイアグラム（ERD）
　・データ定義表
　・情報システム関連図
　・情報システム機能構成図
　・ネットワーク構成図
　・ソフトウエア構成図
　・ハードウエア構成図

システムの整合性やデータの整合性、システムと運用のバランスを考える所まで頭が回らず、ひたすらドキュメントを作るだけで終わってしまうのがオチなのだろう。

おそらく、EAはDOAの観点で、各システムに散らばったマスタデータを一元化し、各システムのトランザクションデータを外部接続で連携して、各システムのデータを一つのビューで分析できるような仕組みにスべきだろうと思う。

でも、サイロのようにバラバラに散在している業務システムをシステム間連携するだけでも大変なのに、目的を定めて本来の用途に使えるように開発するのは並大抵の作業ではないだろう。
おそらく、メインフレームという余りにも古いシステム、何十年も運用して蓄積された膨大な固定長データという古いデータ構造だろうから、コード変換処理という無駄な変換プログラムがたくさん作られるのだろう。

アジャイル開発が最近注目を浴びているのは、恐竜のように肥大化して身動きの取れないシステム開発よりも、哺乳類のように小回りがきいてすぐに変化に対応しやすい開発スタイルの方が、システムの価値が得られやすいからだろうと思う。
そんなことを考えると、業務システム開発をDOAの観点でアーキテクチャ設計する場合、本来のゴールは何なのか、というマネジメントの部分がクローズアップされてくるように思える。
単にアジャイル開発すれば全ての問題が解決するわけではなく、顧客やベンダー、開発者などの利害関係者の間で根回しして調整して、システムの本来の価値を考えようとする仕組みが必要になってくる。

多分、それが要求開発のこたつモデルであり、ソフトウェアプロダクトラインにおいてアーキテクトが調停者の役割を持つという意味につながるのだろうと思っている。

ERPの落とし穴part5～コード設計の難しさ

業務システム開発で、マスタテーブルを新規に作る場合、コード設計を事前に深く考慮する必要がある。
考えたこと、経験したことをラフなメモ書き。

【元ネタ】
Hot Heart, Cool Mind.: コード設計の話

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (1/3) - ＠IT

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (2/3) - ＠IT

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (3/3) - ＠IT

うぃっとWorks: 有意コードと無意コード

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (1/3) - ＠IT

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (2/3) - ＠IT

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (3/3) - ＠IT

【1】2013年の日本の政治でマイナンバー制度が決まった。
この法律は、日本人全てに固有の一意の番号を割り当てて、今後増大するであろう年金の管理や税金の徴収に使いたい目的があるのだろう。
その場合、マイナンバーというコード(主キー)はどのように作ればいいのか？
コード設計がまずいと、システムの運用が長引くにつれて、どんどん複雑化し、システムの運用の支障になる。

SEの観点によるマイナンバー制度の解説については、@hatsanhatさんの下記の記事がとても秀逸。

共通番号制度（旧：マイナンバー制）施行に合わせて、IT企業は何をすべきか｜HATのブログ

コード設計が重要な理由は、ERP導入時に、現状の業務システムにバラバラに散在しているマスタを一元化するために使われるからだ。
普通の大企業では、サイロのような業務システムが過去に作られていて運用が続いているために、コード体系がマチマチで業務に支障が出ている場合は少なくない。
例えば、小売業の商品マスタや顧客マスタや取引先マスタ、製造業における製品コードや製番管理などがあげられるだろう。
ビジネスの変化にコード設計がついていけない状況が多くなっているのだ。

だから、ERPを導入する時に、過去システムのデータを移行してコードを振り直したり、過去システムは捨て去って、新たにコードを振り直す。
会計、CRM、SCMなどのデータが業務の流れで一元化して管理しやすくするために、マスタのコードを一元化するのだ。

【2】コードの種類には、幾つかの概念がある。

有意コードは、特定のけたに意味を持つキー。
業務で使われるキーが相当する。
よくある例は、国民年金で有名な社会保障番号、日本人全てに振られるマイナンバーなどがあるだろう。
他にも、病院の診察券に振られた患者番号、スーパーのポイントカードにふられたカード番号、クレジットカード番号、銀行の口座番号も相当するだろう。
あるいは、製品コードを仕様コードと設計コードとプロダクトコードでハイフンでつなげた番号などがあるだろう。
これらはユーザキーであり、自然キーでもある。

無意コードは、特定の桁に意味を持たせないキー。
OracleなどのDBが振るシーケンスが相当する。
人工キーである。

標準コードは、業界標準のコード。
有意コードが多い。
商品のJANコード、書籍のISBN番号があるだろう。
これらの番号は、公的機関ないし公的と認められる団体が一意に番号を振る。

独自コードは、企業などで独自で振るコード。
例えば、会社の社員番号。
普通は業務システム内部で採番しているだろう。

【3】コード設計には、DOAで既によく知られた幾つかのノウハウがある。

【3－1】業務で利用するキー（有意コード）は主キーにしない

コード体系とデータベース設計を独立させるという観点で重要。
有意コードを主キーにすると、有意コードは変更される可能性があるため、主キーは値が変わらないキーという前提が崩れる。
主キーが変わるということは、その主キーを参照するテーブルにも影響があり、データの整合性やプログラムの複雑化を考えると、大変な作業になる。
普通は、主キーは無意コード化した方がDB設計上もプログラミングも都合が良い。

@sugimoto_keiさんの下記の記事がとても分かりやすい。

Hot Heart, Cool Mind.: コード設計の話

主キーはシーケンスのような無意コードとし、ISBN番号やJANコードのような有意コードは2次識別子(代替キー)として設計した方が良いと思う。

昨今のWebシステムでは、Railsのように主キーは全てサロゲートキー(代理キー)にしてしまい、RESTfulにする設計が主流になっているように思う。

【3－2】プログラムで利用する有意コードは分解する

有意コードはプログラム内部で分割して、条件分岐や検索処理のために使われる時が多い。
例えば、最初の8桁のyyyyMMddは切り取って、その後の桁の値を元に検索したりする。

有意コードを分解して利用する共通ロジックが多いならば、有意コードを分解してテーブル内で保持する方がプログラムも書きやすいし、データの重複も減る場合がある。
検索で使うならば、有意コードを分解しておく方が、テーブルにインデックスを貼ることで性能を上げることもできる。

【3－3】外部システム連携で使うキーは保持する

例えば、EOS発注のように、仕入先に発注した商品の伝票データを、仕入先企業の外部システムから自社の業務システムへ取り込む場合、仕入伝票番号を受け取る時がある。
その場合、外部システムから連携される仕入伝票番号というコードは、自社システムで保持しておく。
その理由は、例えば、紙でもらった伝票番号と自社システムに取り込んだ伝票番号を照合するなどのマッチング処理で使いたいからだ。
つまり、外部システムから連携された伝票番号とそのデータ内容がそもそも正しいのか、自社システム内部で照合処理に使うわけだ。

その場合、伝票番号は、外部キーないし2次識別子としてテーブル内で保持する場合が多いだろう。
つまり、T字形ERで解説するならば、eventとeventを1対1ないし1対多でつなぐ場合、先行トランザクションの主キーを時系列の遅い後続トランザクションに外部キーとして保持するパターンになる。

候補キーと2次識別子に関する概念: プログラマの思索

【3－4】コード化する件数を把握する

コード設計するからには、コードの件数や桁数をあらかじめ事前に計画しておかないといけない。
何故なら、後から桁数を拡張したり、データ型を変更するのはかなり難しいからだ。

桁数が小さすぎると、コードを使い切ったら、過去のコードを使いまわす事になり、One Fact One Placeという原則が崩れてしまう。
コードの件数が多すぎる場合、桁数を増やしすぎると、無駄にディスクスペースを消費してしまう。
この辺りの物理設計はデータベースの知識がモノを言う。

【3－5】DA（データ管理者）を決める

コード体系を決める場合、業務をよく知っている人がDAの役割を担って、コード体系が破綻しないように見守る。
各部門で保持するコード体系はどのように振るか、業界標準の標準コードを採用スべきか、過去のコードを再利用すべきか、有意コードや無意コードをどの範囲まで適用するか、色々考えるべき点がある。

【3－6】ユーザの使い勝手を考慮する

例えば、JANコードにはチェックディジットのように、バイトの人が商品番号を入力する時に誤って入力したらエラーになるような仕組みがあったりする。
商品のバーコードやクレジットカード番号にもチェックディジットの仕様が組み込まれている。
あるいは、コードの意味がユーザに分かるように、シーケンスのような数字の羅列ではなく、英数字にしたり、日付や顧客番号を組み合わせた有意コードにしたりする。

【4】コード設計は正直アジャイルにはならない。
一度作ったテーブルの主キーの設計を修正するのは、あまりにもシステムの影響が大きく、業務の支障にもなる。
もちろん、ユーザの使い勝手も変わってしまう。
だから、どうしても事前の計画の準備が重要視されるために、DOAはウォーターフォール型開発とセットになって運用されやすい。

でも、DOAの重要性は業務システム開発では変わらない。
マイナンバー制度のように、コード設計が最初から間違っていると、データ構造の複雑さに耐え切れずにプログラムは複雑になるし、業務システムを長く運用してデータが増えていくにつれて、データの整合性を維持するだけでも大変になる。
一度作ったコード体系を破棄することは余程のことがない限りありえない。
だから、コード変換処理という無駄なプログラムが増えて、業務システムはどんどん複雑化していく。

アーキテクチャ設計の鍵は、アーキテクチャ設計の未熟さをプロセスでカバーするアジャイル開発か、正面から設計を考えるDOAの2つにあるような気がしている。

SECIモデルはパターンランゲージの作成プロセスに似ている～第52回SEA関西プロセス分科会の感想 #seaagile

第52回SEA関西プロセス分科会で、平鍋さんの講演「アジャイル開発とスクラム」を聞いてきた。
感想をラフなメモ書き。

6月7日 第52回 SEA関西プロセス分科会

第52回 SEA関西プロセス分科会-SEA関西

【1】参加者は70人余りでおそらく過去最高の人数ではないだろうか？
講演内容も素晴らしかったし、1時間半の質疑応答は引っ切り無しで、参加者もアジャイルにとても興味を持っていることがよく分かった。
平鍋さんは、関西はアジャイルで独自の活動をされている人が多い、と言った後で、「わかりやすいアジャイル開発の教科書」と一緒に「チケット駆動開発」の本も紹介して頂き、嬉しかった。

平鍋さんの講演では、「アジャイル開発とスクラム」の内容紹介よりも、野中先生の経営理論からアジャイル開発のスクラムが生まれた経緯を中心に話された。

【2】スクラムという概念は、野中・竹内先生の論文「The new new product development game」から生まれた。

Newが2つある理由は、2つ目のNewは「新製品開発」の「新」、一つ目は「新しい」という意味らしい。
従って、論文は「新しい新製品開発」という日本語タイトルになる。
つまり、野中先生は、80年代の日本企業の開発プロセスを研究して、生産ラインに乗らないような新製品開発について分析していたわけだ。

論文では、3種類の開発プロセスが説明されている。
一つ目は、NASAの開発プロセスで、品質ゲートが設けられていて、ある工程で品質をクリアしたら、次の工程へドキュメントと一緒に送られる手法。
ウォーターフォール型開発と呼ばれていないが、まさにそれと同じ。

2つ目は富士ゼロックスの開発プロセスで、品質ゲートがなく、工程の間の切れ目が曖昧になっている。
3つ目はホンダの開発プロセスで、前工程が後工程に重なっている。
つまり、前工程に関わった人はその後の工程でも関わっていることになる。

その手法はアジャイル開発と呼ばれていないが、まさにそれと同じ。
つまり、要件定義や設計で携わった人は開発やテストでも一緒にやり、製品に関わる。
仕様書を下請けに回して、それでおしまいという手法ではないのだ。

野中先生は、そのプロセスの絵を最初は「刺身モデル」と呼ぼうとしたらしい。
前工程のプロセスが後工程に重なる姿が刺身に似ているからだ。
でも、もっと良いネーミングがないか考えて、ラグビーの「スクラム」のように、パスを出す人もパスを受ける人も一体化して前へ走るイメージで「スクラム」という言葉を持ち出したらしい。
だから「スクラムマスター」ではなく「刺身マスター」と呼んだかもしれない、と。

【3】講演で興味を引いたのは、「SECIモデル」と「フロネシス」。
僕は野中先生の本を何度かトライしたが、難しすぎて、理解できなかったが、今日の話を聞いて、何となく引っかかりはつかめた。
SECIモデルは、暗黙知から形式知、形式知から暗黙知へ変わる知識創造のフレームワーク。

知識創造理論：SECIモデル : NED-WLT

暗黙知は例えば、直観や共感。マニュアルにできないもの。
例えとして、自転車の乗り方。
自転車は本で教えても、実際に乗ってみて、転んだり、トライしなければ身につかない。

形式知は言葉にできる知識。
ポータブルな知。
コンテキスト非依存、他人に伝播可能という2つの特徴がある。

SECIモデルは、まず経験(共同化)して、それを言葉にして(表出化)、別の知識と連携して(連結化)、自分の中に取り込む(内面化)というサイクルを繰り返す知識の発展の理論。

この話を聞くと、KPTによるふりかえりと同じモデルであるように思える。
KPTでは、Problemで現状の問題点や課題が出てきて、その問題を解決しようと色々な解決案がTryに出てくる。
そのTryを試してみて、次回のふりかえりで、うまくいったTryはKeepに貯められ、うまくいかなかったTryはProblemで一つの経験として貯められたり、もう一度やり方を変えてTryを試す。
その後、問題解決するたびにKeepにたくさんのノウハウが貯められていき、そのノウハウがチーム全員で当たり前となれば、暗黙知となってKeepから消えていく、という流れ。

つまり、まずは問題解決を試して経験し、経験した結果は実践知としてKeepに貯められ、他の知識と結びついて、当たり前になれば暗黙知として水面下に沈むという流れになる。

【4】知には「暗黙知」「形式知」「実践知(フロネシス)」という3つの種類があると、アリストテレスは言ったらしい。
実践知は、フロネシス - Wikipediaによれば「個別具体的な場面のなかで、全体の善のために、意思決定し行動すべき最善の振る舞い方を見出す能力という意味らしい。
僕の理解では、実践知とは、状況(コンテキスト)に応じて知恵を使うことができる能力と思っている。

野中先生は、フロネシスを伴ったリーダーシップが重要で、そのような人が、SECIモデルを組織内で実践していくと考えているらしい。

実践知（Practical Wisdom）とは？：アリストテレスがポジティブ心理学に出会う | 仕事の心理学

フロネシス・リーダーシップ（野中　郁次郎教授） eqpartners/ウェブリブログ

つまり、フロネシス(実践知、パターンランゲージ)を伴ったリーダーシップを持つ人(スクラムマスター)は、実践知を組織化する能力(開発プロセスを進化させる)を持っている。
平鍋さんは、その構造は再帰化みたいですよね、コンポジットパターンですよ、と言っていた。

そのようなフロネシスを生み出すには場(ba)が大事と言う。
つまり、二人の人が互いに自分の意見をぶつけたり、議論したり、共感しようとしたりして、お互いの力の相互作用が生まれる場が発生し、実践知が生まれていく。

この場というアイデアは、量子力学のfieldという概念に似ている。
電子や粒子が存在すると、その周囲に電場や磁場が勝手に作られ、波として力の相互作用を及ぼす。
場であるからには、引力もあれば斥力もある。
つまり、相互に惹かれ合う場合もあれば、相互に反発し合う場合もあるだろう。

そして、海兵隊のように陸軍・海軍・空軍のスキルを持つ専門的な人達が集まってチームをなして、プロジェクトに取り組む。
それは、スクラムが、ユーザ・マネージャ・開発者を巻き込んだチームとして、プロダクトオーナー・スクラムマスター・チームの役割を持つスクラムチームと呼び直して、ソフトウェア開発に取り組むやり方に似ている、と。

【5】その実践知はコンテキスト依存であるという平鍋さんの話を聞いて、まさにパターン言語そのものではないかと思った。

パターン、Wiki、XPは良書: プログラマの思索

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

パターンランゲージの形式と正当性: プログラマの思索

パターン言語は実践知や経験知を一つの形式でまとめたカタログ。
その経験知は、パターンとして他人にその意味を共有することができる。

コプリエンのパターンの形式は下記のスタイル。
まさに、野中先生の言う実践知(フロネシス)とぴったり合うのではないだろうか？

パターン名称(Pattern Name)：
問題の解決の仕方などが直感的にイメージできるような名前。

別名(Alias)：
上記のパターン名称の別名。すべてのパターンが別名を持っているわけではない。

問題(Problem)：
解決したい問題。あるべき課題。

コンテキスト(Context)：
問題が発生しているまわりの状況や、問題を解決しようとしている人が置かれている状況。
現実と理想のギャップ。

影響する事柄(Forces)：
問題解決に際して影響を与える事柄や考慮しなければならない事柄。

解決策(Solution)：
問題解決策。

結果として生じるコンテキスト(Resulting Context)：
問題を解決したことによって生じる状況。

論理的根拠(Rationale)：
パターンが効果があることの論理的な根拠。

フロネシスの体系化がパターン言語であるとすれば、複数のパターンを組み合わせることで、パターンでは語られなかった新しい性質が生み出されるという、パターン言語の最大の特徴が出てくるが、それはどのように解釈されるのか？
つまり、生成的(generative)というパターン言語の特徴だ。
例えば、XPのテスト駆動や継続的インテグレーションなどのプラクティスは、それ自身では品質や効率について何一つ語っていないのに、それらプラクティスを組み合わせると、従来のWF型開発よりも品質が良く、効率も良くなるという特徴を持つ。
この特徴こそが、XPの面白い部分であり、アジャイル開発を経験して成功したことがなければ分からない部分だと思う。

パターン言語の生成的(generative)という特徴は、SECIモデルやフロネシスではどんな文脈で説明できるか？
平鍋さんに質問してみたものの、僕の理解ではよく分からなかったけれど、パターンの生成的な特徴は、SECIモデルの「連結化」に相当するような気もしている。
複数の実践知、経験知を組み合わせると、今までになかった新しい特徴が出てくるという部分に相当するのではないだろうか？

すると、SECIモデルとパターン言語は、それぞれの概念やプロセスがどのように対応していて、どの部分に差があるのだろうか？

チケット駆動開発をパターン言語として考え直すアイデアは、ちょっと止まっていたけれど、新しい考え方を取り入れることができて刺激になった。

【6】平鍋さんの話を聞いてみて、「スクラム」といい「かんばん」「リーン」などの概念を日本人が生み出し、それを欧米人が理解して、ある意味では自分たちの都合の良いように取り入れて、「アジャイル」という新しい言葉で提唱して、日本に逆輸入されたことに、正直悔しいなあと思っている。

何故、日本人はそのアイデアを生み出したにもかかわらず、日本のソフトウェア産業に適用して、発展させようとしなかったのか？
アジャイルといい、DOA(データモデリング)や品質管理の技法と同じく、日本独自の歴史を持ちながらも、そのアイデアは僕ら開発者に全く生かされていない。
この辺りの知識体系を日本人自身の手でまとめて、世界に提唱できたらいいなと思っている。

「チケット駆動開発」の感想を集めてみたpart7

「チケット駆動開発」の感想を見つけたのでメモ。

『チケット駆動開発』のレビュー (ktakeuchiさん) - ブクログ

(引用開始)
素晴らしい内容。
私の追求したいものは、多岐にわたっている。
・対話的手法（ゲームストーミング、フューチャーセンター等）
・リーンスタートアップ、生産性向上
・アジャイル開発、デザインパターン・テストドリブン開発
・デザイン思考、ソーシャルイノベーション
といったもの。これらはどれも興味があるが、私としては全部が同じものであって、全体として一つのツールだと思っている。

おそらく、同じような考え方の人や、同じ所に行き着いた人も、世の中には結構いてるのではないかと思う。いろいろな業界に。
一言で伝わるもっと適切な概念や定義や言葉がほしいけど、バズワードになるのも嫌なので、できるところから実践をつまないといかんな。

そう考えると、自分の商売の分野であり、自分のスキルとして到達可能なところであり、なにより好きな分野として、やはりコンピュータの世界であろうと思う。
もっと勉強しよう。
(引用終了)

最近思うのは、新しい言葉や概念を定義する作業は重要だと痛感している。
ソフトウェア開発をもっと楽にしたい、ソフトウェア開発をもっと楽しくしたい、という理想があるのに、現状は泥沼プロジェクトというギャップがある。
その問題意識から、こうあるべきだという課題が明確になり、そこから、新しい概念で課題を解決しようとする。

そもそも、目の前の問題がすぐに解決できるなら、わざわざ新しい概念を試行錯誤して編み出す必要もない。
今までの知見を適用して解決すれば言いだけのことだ。

しかし、ソフトウェア開発の問題はどれも根が深い。
開発プロセスを整備したり、ツールを使うだけでは足りない。
その背後にある今までにない言葉や概念が明確にならなければ、本来の課題は解決できないと思う。

チケット駆動開発の利点は、従来から知られていたプロジェクト管理(PMBOK、ITILなど)やソフトウェア工学(テスト管理、アジャイル開発、CMMIなど)の技法がBTSというソフトウェア上で実現すると実際に使い物になる、という事実があることだと思っている。

第5回品川Redmine勉強会はRedmine運用に関する討論会です

6/29(土)に第5回品川Redmine勉強会が開催されます。
内容は、Redmine運用に関する討論会です。

【元ネタ】
第5回勉強会 - shinagawa.redmine

第8回RxTstudy : ATND

【内容】
Redmine を使っている方、使い始めようとしてつまずいている方、運用方法についていろいろ悩むことが多いと思います。

今回は運用上の課題について下記それぞれの役割にたって Redmine の活用・運用方法について互いに議論をおこなうワークショップ形式で進めたいと思います。

・ソフトウェア開発者向け
・マネージャ向け
・(非開発系)運用者向け
・Redmine 管理者向け

日時
2013/06/29(土) 13:00～17：30

場所
東京都千代田区神田神保町1-105 神保町三井ビルディング 17F

最寄駅
東京メトロ 半蔵門線、都営地下鉄 新宿線、三田線「神保町駅」A9出口 徒歩2分
東京メトロ 東西線「竹橋駅」 3b出口 徒歩5分
東京メトロ 千代田線「新御茶ノ水駅」B7出口 徒歩5分
JR 総武線、中央本線「御茶ノ水駅」御茶ノ水橋口 徒歩8分
※会場はIIJ様のご好意でご提供していただいています。

申し込み
第5回shinagawa.redmine勉強会 - PARTAKE

※登壇者の方は登録は不要です。

登壇者の方で顔出しNGの方は事前にスタッフまでお知らせください。
ツイッター、Facebook等でコメントや写真など、お寄せ頂けると幸いです。

Chefのメモ

Chefという技術が出てからAWSに日の出の勢いを感じる。
Chefはまだ知らないので、記事についてラフなメモ。

【元ネタ】
【WEBクリップ】　今もっとも学習コスパの高い技術はChefだと、Chef勉強会に行って確信した ? akiyan.com | Never Be Repeated

Chefで構築するRedmine環境: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

Twitter / akipii: なるほど RT @joker1007: Chefそこまでガンガン使ってないけど、あれの嬉しい所って、サーバの構成を記述した文書とサーバの状態を一致させる事が出来る事だと思っている。Chefで弄ってる限りは状態が設計とズレてない事が明確になる。 #rubykaigi

「今Chefをやるべき9つの理由」として下記の9つの理由が書かれている。

・猛烈に流行り始めている
・インフラ構築は誰もがやる
・個人でも使い道がある
・インフラ構築を「コード化」できる
・インフラエンジニアにChefは必須になる
・インフラの「更新」もできる
・3,4年は廃れなそう
・Chef自体はそんなに難しくない
・Rubyまわりも覚えられる、いい機会

あ、でもJenkinsはJava実装なのでRuby実装ではないけどね。

面倒なサーバー構築はプログラムで自動化すれば、アジャイルにサーバー環境を構築できるようになる。
AWSというクラウドのインフラが個人でも手が届く環境になってから、Chefという技術の重要性が高まっているように思う。
何故なら、AWSでサーバーインスタンスを気軽に作れるために、それらの環境構築をプログラム化していつでも再現できるようにしたい要求が高まっているからだ。
開発環境やユーザ受入テスト環境を自前で一から作る必要もない。
基本は本番環境と全く同じように作ればいいだけのことだ。

AWSならスケーラビリティをWebシステムのアクセス状況に応じて、簡単に増減することができるから、最初からお金をつぎ込んでフルスペックでサーバーを構築する必要もない。
リーンスタートアップにも適用しやすい環境構築と言えるだろう。

僕としては、RedmineをChefで簡単にインストールできるプログラムがないのか、知りたい。
redmineのcookbookはないものか？
Redmineはインストールが難しいという話はよく聞く。
bundlerのおかげでかなり楽になったけれども、初心者はRubyのインストールの所からつまずいてしまうのだ。
Redmineのインストール作業がChefで自動化できれば、もっとお手軽にチケット駆動開発を楽しめるようになるはず。

「redmine cookbook」で検索してみると下記がヒットするが、実際はどうなのだろう？

cookbooks/redmine ・ GitHub

juanje/cookbook-redmine ・ GitHub

Chef Cookbook: redmine - Opscode Community

今の所、Chef謹製ではないけど、ALMiniumがそれに近いものだと思う。

軽量チケット開発ツールALMinium

ntaka blog : 素のRedmineに比べて様々な使い勝手が向上してるAlminiumのご紹介 - livedoor Blog（ブログ）