マネジメントサイクルは「PDCA」ではなく「STPD」で回す

「マネジメントサイクルは「PDCA」ではなく「STPD」で回す」記事をメモ。
以下は理解できたことをラフなメモ書き。

【参考】
ITエンジニアのための押さえておきたいビジネス知識 - 第5回：マネジメントサイクルは「PDCA」ではなく「STPD」で回す：ITpro

リスクマネジメント（安全管理）　楽しいアウトドア活動は安全から STPDサイクルでリスクマネジメント

メルマガ詳細

【近況】Plan-Do-Check-ActionとSee-Think-Plan-Do: クイズの引力実験室

PDJロゴス・ブログ: 今を生きる 「目標を考える（２）」

脅威と正面から向き合えるか　～富士フイルムとコダックの明暗を分けた脅威～：仕事を楽しく未来を明るく：ITmedia オルタナティブ・ブログ

マネジメントでよく出てくるPDCAサイクルの弱点は、Planの意味が大きすぎること。
計画を作るだけでパワーを使い果たしてしまう。
また、計画を一度作ったら、決まったことは最後まで実行しなければならない、と思い込んでしまいがち。

そこで、PDCAサイクルではなく、STPDサイクルという考え方がある。
STPD（See-Think-Plan-Do）サイクルとは、現状直視(See)と分析(Think)を計画策定(Plan)の前に実施する。

(引用開始)
【PDCAサイクル】
１.Plan　（計画する）
２.Do　　（実行する）
３.Check （確認する）
４.Action（改善する）

【STPDサイクル】
１.See　 （じっくり見る）
２.Think （どうするべきか考える）
３.Plan （計画する）
４.Do　　（実行する）
(引用終了)

僕の理解では、See＝AsIsの情報収集、Think＝ToBeの分析と課題発見だ。
つまり、See→Think→Planは、現状収集→課題の発見→AsIsとToBeのギャップ分析→課題の対策作りという流れだと思う。

業務システムの要件定義では、必ずユーザの現状の業務を把握するところから始まる。
そして、あるべき姿を見出し、現状とあるべき姿のギャップから課題を抽出して、あるべき姿へのロードマップを描く。

でも、要件定義のアウトプットや品質が不明確になりやすい。
なぜなら、要件定義で何を作れば完了と見なせるか、その基準を明確にするのが難しいからだ。

要件定義では、設計するのが目的ではない。
むしろ、仕様の元ネタとなる要件を収集して整理する方が大事だ。
アーキテクチャの決定はやるが、アーキテクチャの詳細化も後工程の方式設計で行うのが普通。

また、要件定義はリソースや作業時間が設計工程よりもはるかに限られる。
限られた時間で少人数で、システムのイメージを具体化しなければならない。
したがって、スコープを明確にして、どんなアウトプットとどこまでの品質を出すか、を明示しなければならない。

しかし、要件定義工程はPlanの問題と同じく、分析麻痺症候群に陥りやすい。
分析麻痺症候群は、現状の分析だけで手一杯となり、肝心の成果物が作れない時によく発生する。

STPDサイクルを覚えておけば、今の作業がどの状態で、Planまでにどんなステップを踏めばいいのか、を気づかせてくれる気がする。

現状分析では、まずは現状を知ることに注力し、WhyやWhatを把握するようにする。
いきなりToBeを作っても、AsIsのベースがなければ思い込みに過ぎない。
AsIsとToBeのギャップを把握し、本質的な課題を考えるように注力する。
Planを作る前には、そういう前作業が重要。

実際に使ってみる。

アート・オブ・コミュニティの感想～コミュニティは信用貯金という信用経済から成り立つ

アート・オブ・コミュニティを読んで、コミュニティ運営とは一体何なのか？と考えている。
以下、主張がないメモ書き。

【参考】
アート・オブ・コミュニティ - yuku-t blog

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには | Social Change!

アートオブコミュニティ - Togetterまとめ

ベーコン『アート・オブ・コミュニティ』：是非ともやりたかったんだが。紹介しないのが惜しい本。 - 山形浩生 の「経済のトリセツ」

Sphinx-users.jp Ｘ アート・オブ・コミュニティー (2011/7/23) ? Python製ドキュメンテーションビルダー、Sphinxの日本ユーザ会

アート・オブ・コミュニティ読了, 姫路で毎週水曜日にハックカフェを開きます - Days of Speed(2011-10-18)

アート・オブ・コミュニティを読んだ

【1】僕自身、ITコミュニティの活動に長く携わってきた。
そんな体験を通じて、コミュニティ運営は楽しい時もあるし、逆に負担に思う時もある。

では、コミュニティに関わる根本的な問題とは何だろうか？

コミュニティ運営とはどんな基盤から成り立つのか？
コミュニティとビジネスはどんな関係を作れば、双方ともにWin-Winの関係になるのか？
コミッタとコミュニティはどんな関係であるべきなのか？

【2】コミュニティが発足するきっかけは様々だ。
僕の経験では、有志が集まり、熱烈な動機を持つ少数の有志から始まる。
そして、コミュニティ主催で勉強会が開催され、参加者が集まり、盛り上がるとともに、活動も活発化していく。

でも、コミュニティがいつも長続きするとは限らない。
スタッフは平日は仕事を抱えているし、家族がいたり、他のプライベートな事情もあるから、いつもコミュニティ活動に注力できるわけではない。

一時の熱情が冷めて、スタッフのやる気も落ちると、コミュニティは消滅してしまう。
また、スタッフの年齢が上がり、若手のスタッフに引き継いでいく流れがないと、コミュニティが対象とするマーケットが時代の流れに合わなくなる場合もある。

そういう意味では、コミュニティもゴーイング・コンサーンが最終目的になるのかもしれない。
コミュニティが社会の中で価値があることを示し、継続して活動していくことが目標になるだろう。

【3】コミュニティ活動は、ボランティアベースだが、多少のコストは発生する。
普通は参加費を少しだけ徴収する時が多いが、その理由は、遠方から講演者を呼ぶ費用に使ったり、PostItなどの備品、50名くらい入れる会場を借りる費用に使ったりする。
だから、コミュニティでは、会計担当の働きも重要。

また、コミュニティはビジネスの交流の場でもある。
開発者同士で仕事を知るきっかけにもなるし、企業が優秀な開発者を探しに来たり、逆に企業がコミュニティの場で自社製品を宣伝したりする時もある。

そういう文脈で思うのは、コミュニティを運営するスタッフとしては、コミュニティが参加者に提供できる価値とは何なのか？を自問せざるをえないことだ。

開発ノウハウ、技術ノウハウ、開発事例などを参加者に共有することもあれば、コミュニティに集まるユーザ数の多さや階層が目当てになる時もある。

製品を売りたい企業や、優秀なプログラマを探したい動機を持つ経営者ならば、コミュニティの価値は、そこに集まる人達が高品質であることだろう。

コミュニティに価値があるからこそ、人が集まり、沢山の人達の相互作用で色んな効果が生まれ、好循環に回っていく。

でも、コミュニティを営利目的でやるほどのパワーを注げない時も多い。
むしろ、コミュニティが営利などの目的に変わると、コミュニティの場が変わってしまう。

【4】本来、コミュニティは、熱意のあるスタッフが集まって生まれる。
その動機は様々だ。
アジャイル開発が好きだ、読書会がしたい、こんな最新技術の話を共有したい、など。

そんな人達が多種多様であればあるほど、初対面同士の関係なんか無関係で、想定しないコラボレーションが生まれて、どんどん盛り上がっていく。
すると、コミュニティを運営する上で必要な概念が出てくる。

【5】「アート・オブ・コミュニティ」では、「信用貯金」「一体感」「信用経済」が紹介されている。

信用貯金は、コミュニティの人々の間で行われるプラスの相互作用を集めたもの。
コミュニティの全員が生きる充足性を得る効果が生まれる。
但し、信用貯金は、通貨のように数値化できないし、銀行の預金のように価値を長期間保持できるわけではない。

信用経済は、コミュニティの人々の信頼貯金を通貨で比喩すると、通貨(信用貯金)が激しく取引されることで、コミュニティ内のトランザクションが増えていく経済構造。

コミュニティに信用経済があるからこそ、そこに人が集まり、営利企業も集まってくる。
信用貯金はお金そのものではないが、皆が価値がある、と信じているからこそ意味がある。

一体感は、人々がコミュニティと一体化している感覚。
一体感こそが人々を惹きつける原動力。
コミュニティが存在する証。
信用貯金を元に、コミュニティ内で信用経済が具現化されると、コミュニティ内の人々の心に一体感が生まれる。
一体感は強い信用経済のものさし。

一体感を生み出すプロセス、信用経済の基盤となる信用貯金を作り出すには、コミュニティ内で多種多様な人達の活発なコミュニケーションが必要だ。

活発なコミュニケーションが、各メンバーの信用貯金を生み出し、それを元に信用経済が具体化されると、メンバーにコミュニティとの一体感が生まれる。
コミュニティの価値とは、このような信用経済の構造が発生し、永続的に維持されることにあるのではないか。

【6】「アート・オブ・コミュニティ」で最も重要な概念は「コミュニティマネージャ」だろうと思う。

コミュニティマネージャーとは？職種・役職としての現状｜米国事例 | ダイナ･サーチ

コミュニティ・マネージャとは : まだ東京で消耗してるの？

Wikipediaに見るコミュニティマネージャーの定義 - Community & Social

コミュニティーマネージャーの役割とは？ | SMJブログ（ソーシャルメディアジャパン）

Online community manager - Wikipedia, the free encyclopedia

「アート・オブ・コミュニティ」は「コミュニティマネージャ」を「世の中に変化をもたらそうと協力しあう世界中のボランティアに対して、それを達成することを可能にする」役割の人と定義している。

より具体的には、コミュニティ・マネージャとは : まだ東京で消耗してるの？のように、コミュニティマネージャーはこんな役割の人だ。

(引用開始)
1.製品と企業のエキスパート、エヴァンジェリストになる
2.製品と企業を愛する、しかしユーザーの目線に立つ
3.コミュニケーションスキルを生かす
4.ブログなどを通してソーシャルメディア上でプレゼンスを築く
5.Authenticである
6.力を入れるべきプラットフォームに優先順位を付ける
7.傾聴し、価値を付加し、関係を構築する
8.オンライン／オフラインで関わりあう
9.起業家のように考え、変化に付いていく
10.同僚をエンパワーし、コミュニティビルダーとなる
(引用終了)

コミュニティーマネージャーは、そのコミュニティ内で最も影響力がある以外にも、他の特徴を持つ。

【6-1】僕が一番フィットするのは、コミュニティーマネージャーとは、エバンジェリスト兼ファシリテーターだ。

つまり、何らかの製品や概念、技術に詳しいだけでなく、それらを世の中に分かりやすく説明し、普及する責任を持つ人。
こういう人はエバンジェリストと言われるだろう。
エバンジェリストの具体例は、例えば、長沢さんのような人ではないか。

オピニオン：長沢智治： エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider

エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること: プログラマの思索

エバンジェリストの役割は、単に技術の紹介だけではなく、その技術を必要とするマーケットの創造だ。
新しい市場を開拓し、拡大させることで、新たな経済・売上・利益を周辺に関わる人達にもたらす。

換言すれば、エバンジェリストはコミュニティの信用経済を作り出し、拡大させていく役割を担っている。

【6-2】さらに、コミュニティーマネージャーは、コミュニティ内の人達をファシリテートする能力も持つ人。
実際、コミュニティでは、会社のような権力構造や指揮命令系統は通用しない。
信用貯金を元に人々は動くので、コミュニティ内のゴールや価値観をいかに共有してもらい、自発的に行動してもらうようにするか、の方が重要だ。

ファシリテーターは、メンバー間で信用貯金を生み出すように支援し、コミュニティ内のトランザクションを活発化させる役割を持つ。
トランザクションの例としては、メーリングリストで議論する、イベントを開く、などだけでなく、周囲の人達に働きかけて輪を広げていく活動も含まれるだろう。

ファシリテーターが信頼貯金を増幅させる。
そして、その結果、信用経済を活発化する。

【6-3】コミュニティマネージャーという職業は日本ではあまり聞かない。
でも、ボランティアベースで、コミュニティマネージャーに相当する役割で活動している人は、IT勉強会にいる人なら、なんとなく理解できるはずだ。

個人的には、コミュニティを長期に運営していくには、誰かがコミュニティマネージャーという役割を意識して行動することが必要ではないか、と直感的に思っている。
その直感が正しいかどうかは分からない。

【7】「アート・オブ・コミュニティ」では、コミュニティを経済の概念で比喩しているのがとても面白い。
コミュニティは当初はボランティアベースだし、そんなに価値があるようには思えない。
でも、コミュニティに参加する人が増え、活発になっていくと、そこに何かしら価値があるように見えてくる。

コミュニティの構造は、経済に似ている。
通貨(信用貯金)が発生し、通貨が流通して経済(信用経済)が生まれる。
経済の生産量ないし強度は、コミュニティの信用経済では、一体感の強さで測定できるだろう。

すると、マクロ経済学の基本概念「国民所得＝消費＋投資」「貯蓄＝投資」は、コミュニティの信用経済ではどのように対応付けられるのか？
あるいは、経済学で出てくる概念「利子」「インフレ」は、コミュニティの信用経済でどんな概念に対応するのか？

このアイデアをもう少し考えてみる。

渡辺式データモデリングの復習

渡辺幸三さんのデータモデリングの手法について、復習と理解のために残す。
以下メモ書き。
間違っていたらあとで直す

【1】サロゲートキーの注意点

サロゲートキーは、トランザクションテーブルに多い。
受注番号、注文番号のように、シーケンスとして単に採番される。

しかし、実際のテーブル設計では、サロゲートキーを持つテーブルは、主キーとは異なる一意なキー項目が存在する場合がある。
たとえば、商品マスタのJANコード、従業員マスタの社会保障番号などだ。
あるいは、発注テーブルの受払Noなどもそうだ。

サロゲートキーはWebシステムではとても相性が良い。
しかし、何でもかんでもテーブルをサロゲートキーによる主キーで設計すると、業務要件をカラム間の関数従属性で表現しきれなくなる。
すると、そのような従属性はアプリ層で実装するようになり、システムが肥大化していく弱点がある。
だから、一意制約を持つキー項目でその従属性を表現すると上手くいく場合がある。

サロゲートキーの日常性と心得之条: 設計者の発言

(引用開始)
「サロゲートキー心得之条」
必要なユニーク制約が組み込まれているか注意すべし。また、ユニーク制約に含まれる項目値の更新に対処できているか注意すべし。なお、以って怠りし由（よし）にて死すとも、屍拾う者なし。死して屍拾う者なし
(引用終了)

渡辺幸三さんのデータモデリングでは、一意制約ないし2次識別子を使った技法が多い。
一意制約ないし2次識別子は、ボイスコッド正規化で必要なテクニックであるが、慣れた人でなければ理解しにくいと思う。

【2】動的参照の制約～ビューに対する参照制約(暗黙的なリレーションシップ)

複数テーブルを結合したビューに対し、外部キーによる参照制約がある場合が相当する。
継承属性とか、暗黙的なリレーションシップと呼ばれる。

例えば、渡辺幸三氏の「動的参照関係」について: Hot Heart, Cool Mind.にある例では、地域別配達方法マスタと顧客マスタが動的参照の例になる。

地域別配達方法マスタ----●顧客マスタ●----都道府県マスタ

上記のように、顧客マスタ単独では、地域別配達方法マスタと参照制約をもたせられない。
しかし、顧客マスタと都道府県マスタを結合させると、参照制約が現れる。

他に、生産管理システムの品目マスタと品目構成マスタなどの事例がある。
この動的参照の制約、または暗黙的なリレーションシップを一目で見抜くのはかなりの熟練の業を要すると思う。

「暗黙的なリレーションシップ」をRDBMSで実装することは現在はできず、アプリケーションのロジック層で実現するしか今の所はない。

渡辺幸三氏の「動的参照関係」について: Hot Heart, Cool Mind.

「有効期間」を含むテーブルとの参照関係: 設計者の発言

「動的参照関係」を手なづける: 設計者の発言

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

【3】在庫監視推移方式～派生関係のテーブル間の一意制約

前回のIT勉強宴会で、渡辺幸三さんのライブモデリングを見て、初めて理解できたパターン。
「受払テーブル△--発注テーブル」「受払テーブル△--受注テーブル」という派生関係に対し、受払テーブルの主キーである受払Noを2次識別子として、発注テーブルと受注テーブルに持たせるやり方。

この手法を使うと、発注テーブルで在庫の発注履歴、受注テーブルで在庫引当のデータを受払テーブルで一貫して管理することができる。
つまり、在庫の過去から未来を受払テーブルで監視することができる。

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

このパターンも、2次識別子という一意制約を上手く適用している。

【4】売掛金増減履歴～汎用アクセスキーの例(2次識別子かつ参照制約かつ排他の関係)

テーブル関連の「排他性」をモデル上で表現する: 設計者の発言

例えば、下記のような参照関係があったとする。

売掛金増減履歴●-----受領明細、出荷明細、・・・・・

上記の参照関係にあるテーブル群に対し、取引管理Noが2次識別子としてセットされているとする。
売掛金増減履歴にある2次識別子である取引管理Noは、他の参照先のテーブル群(受領明細、出荷明細・・)で排他の関係、つまりテーブル群の中で一意になるような関係を指すらしい。
このようなデータモデリングの設計ができるのはかなりの熟練の業を要すると思う。

このパターンも、2次識別子という一意制約を適用している事例になる。

【5】逆方向バリデーション～ビューによる検査制約(Check制約)

逆方向バリデーションを自動化する: 設計者の発言

「商品---●受注」という参照関係があった時、商品テーブルと受注テーブルを結合したとする。
そのビューに対し、商品テーブルの販売まるめ数が受注テーブルの受注数の整数倍になる検査制約(Check制約)を持たせる場合を指す。
例えば、販売まるめ数が10ならば、受注数は20、30などしかセットできない。

逆方向バリデーションとは、販売まるめ数を10から20に変更した時、既にセットされている受注テーブルの受注数へのCheck制約を課すかどうかを指す。
例えば、受注数が30のデータが既にセットされていた場合、販売まるめ数を20に変更したら、エラーを検知すべき。
しかし、業務用件によっては、逆方向バリデーションを実施しない時もあるらしい。

上記のように、ビューによるCheck制約は、DBMS上の制約では実現できない。
渡辺幸三さんの考え方では、開発基盤上で妥当性確認を実装すべきであるという思想がある。
例えば、XEAD Driverでは、正方向・逆方向バリデーションに対応しているらしい。

【6】感想
渡辺幸三さんの考え方では、上記のような関数従属性の制約は、DBMS上の参照制約・一意制約・検査制約で表現しきれるものではなく、一つ上のレイヤーである開発基盤で表現して実装すべきものだ、という主張が貫かれている。
確かに、通常のDBMSでは、上記のような制約は実現しきれないだろう。

業務ロジックをデータモデリングで表現しようとするために、開発基盤として強化する考え方はとても興味深い。
他にも理解できた事例があったら、記録しておきたい。

OSSのMSProjectクローンProjectLibre

OSSのMSProjectクローンとして、ProjectLibreを見つけたのでメモ。

【参考】
ProjectLibre の評価・レビュー - フリーソフト100

Home | Projectlibre

ProjectLibreに触ってみる① - 日々の記録

ProjectLibreに触ってみる② - 日々の記録

ProjectLibreに触ってみる③ - 日々の記録

ProjectLibreに触ってみる④ - 日々の記録

ProjectLibreに触ってみる⑤ - 日々の記録

HARD DAY'S NIGHT ブログ ≫ ProjectLibreでプロジェクト管理（操作編）

HARD DAY'S NIGHT ブログ ≫ ProjectLibreでプロジェクト管理

マネージャになるとどうしてもMSProjectを触る時間が多い。
計画はMSProjectで作り、ガントチャートだけでなく、リソース状況、PERT図などで鳥瞰的に見たいのだ。

以前はOpenProjがあったけれど、最近は全く更新されていない。
しかし、ProjectLibreを見つけた。

ProjectLibreを触ってみると、MSProjectのUIとほとんど違和感もない。
日本語化されているので、使い勝手も問題ない。
ガントチャート、リソース状況、PERT図もあるし、クリティカルパスも表示できる。
「Microsoft Project Alternative」とWebページに記載されいてるだけあって、完成度も高そう。

ganttprojectやOpenProjなど進捗管理ツールをずっと見続けてきたが、ProjectLibreでほぼ問題ない気がしている。

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想

第12回RxTStudy「ITS活用最前線～現場からの実践報告」で司会＆モデラーをしてきました。
大手SIのRedmine導入事例が聞けたこと、本音ベースのパネルディスカッションができて、参加者からも満足度が高かったように感じました。
以下ラフな感想。

【参考】
RxTStudy #12 「ITS活用最前線 ?現場からの実践報告?」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

RxTStudy #12 「ITS活用最前線 ～現場からの実践報告?」 - Togetterまとめ

題12回RxTstudy「ITS活用最前線 〜現場からの実践報告〜」 - Togetterまとめ

【1】前田さん

事例から探る、Redmineの機能とよりよい運用 from Go Maeda

【1-1】Redmine本家の話が興味深い。
前田さんは、最近コントリビュータになられたので、Redmine本家にある3千～4千ものチケットを整理したりしている。
実質コミッタ2人で運営されているので、人が足りない気がしている。

Redmine本家のチケットでは、バグ、機能、パッチの3つ。
パッチとバグの使い分けが曖昧な所が惜しい。

チケットのResolutionは、コミッタなど一部の人だけが更新できるようにするために、ワークフローの設定により、権限制御で更新できないようにしている。
この話を聞くと、ワークフロー設定画面でカスタムフィールドの更新制御や、ロールによるステータス遷移の制御の機能がある理由は、Redmine本家の運用に役立てているからだろう、と推測する。

基本的なワークフローは、New→Resolved→Closed。
起票→SVNのTrunkへコミット→チェリーピックしてリリースブランチへマージ→Closeの流れ。
つまり、コミッタの作業状況やブランチのステータスに合わせたフローにしており、すごくシンプル。

カテゴリは、Redmineの機能単位で運用している。
開発者や起票者にとって、すごく使いやすいらしい。

Redmineチケットは約3千～4千個オープンされている。
そのうち、重要なチケットをバージョンに対応付けて、小さなToDoリストにしている。

【1-2】口座振替の請求処理をRedmineで運用している。
MyRedmineのサービスが当初より増えて作業が煩雑になったので、Redmineを導入した。

振替データ確定締切日＝バージョンに設定している。
つまり、事務処理の締め日＝バージョンに対応している。

この話を聞くと、Redmineバージョンは、基本的にはマイルストーンと対応しており、事務処理では締め日で対応づけると、運用が回りやすいという事実を示していると思う。

【1-3】ヘルプデスク処理は、メールによるチケット登録から、顧客が問合せチケットを登録する運用に切り替えた。
利点は、無駄な挨拶文が減ったこと。

工夫した点はいくつかある。
一つは、チケットの項目を減らして、チケットをメールフォームに似せるようにして、顧客の心理的負担を減らしたこと。
もう一つは、他の顧客のチケットを見れないように権限制御を行ったこと。
つまり、情報セキュリティの運用が非常に重要な要件であること。

実際は、不要項目は非表示にしたり、読み取り専用にすることで、チケットをメールフォームに似せた。
さらに、ロールの「表示できるチケット」＝作成者か担当者であるチケット　へ設定して、他のお客様が作ったチケットは見れないようにし、顧客は自分のチケットしか見れないように設定した。

また、プロジェクトのメンバー一覧で、顧客のロール＝「非メンバ」に設定して、チケットの担当者プルダウンに他の顧客が出ないようにした。
Redmineでは、チケットの担当者プルダウンに、非メンバーは出ない仕様だから。

上記の話を聞くと、「非メンバー」「表示できるチケット＝作成者か担当者であるチケット」のように、Redmineのデフォルトの機能を非常にうまく運用していると感じた。

【2】赤羽根さん

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証 from Kuniharu AKAHANE

島津製作所内の業務システム運用、IT全般統制にRedmineを導入した事例のお話。
昨年のSQIPの経験事例に相当する。

前提条件として、Redmineに登録される情報としては、事案関係モデル 3.6万件／年、ソース修正２万コミット／年もある。
つまり、1年で3.6万件のチケットが登録更新され、SVNコミットが2万リビジョンもある事実を意味する。
約5年もRedmineを運用されているらしいので、チケット数はゆうに10万は超えている。

だから、この環境でのRedmineでは、チケットの検索や使い勝手など、性能要件が非常に重要視されるだろうと推測される。
赤羽根さんはRedmineの性能検証で優れた検証結果を公開されているので、最新のRedmine3.0でどれだけ性能要件が良くなったのか、聞いてみたい。

【3】陸野さん

パナソニックの組み込みソフトウェア開発で、Redmineを運用した事例のお話。
昨年のSPESでベストプレゼンテーション賞を受賞された経験事例。

Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用 from Reiko Rikuno

【3-1】陸野さんはSEPGとしてCMMI/PSP/TSP、アジャイルなど数多くのプロセスを導入、運用されてきた。
その過程で、現場にたくさんパッケージ製品のプロジェクト管理ツールを入れてきたが、そのたびに失敗した。

パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれている。
しかし、ツールを使う会社の現場のプロセスにはなかなかフィットしない。
だから、現場の抵抗も強く、ツールのメリットがなかなか出ない。

しかし、Redmineなら、組み込みエンジニアも拒否感がない。スムーズな導入ができた。
実際、Redmineを見て、陸野さんも上司の方も、Redmineなら現場の拒否反応も少ないだろう、いろんな場面に適用できるのでは、という感触を持ったらしい。

【3-2】事例としては、オフショア開発チームと国内のチームがRedmineで障害管理を運用した事例、設計～結合テストまでの大規模組み込みソフトウェア開発の事例、社内の別のBTSとRedmineの連携などの事例が紹介された。

Redmineの利点はいくつかある。
一つは、Redmineはデータや運用の切り替えが簡単なこと。
たとえば、最初は一つのプロジェクトで10人で運用し始めた後、人数が増えてきたら、サブプロジェクトを作って、メンバー数に応じたタスク管理に分割して、切り替えて運用できる。
あるいは、過去のチケットデータをエクスポートして、修正してインポートしやすい。

つまり、柔軟な運用がRedmineでは非常にやりやすい。
他のプロジェクト管理ツールでは、途中で運用ルールを変更するのが難しい状況が多いから。

もう一つは、Redmineを運用すると、ツールを皆で使っている感覚になること。
たとえば、Redmineのガントチャートは担当者が出なかったり、日別の表示がなかったり、ちょっと使いづらい。
だから、チケットをCSV出力して、Excelマクロで簡単なガントチャートを表示するツールを作る人も出てきた。
つまり、Redmineが使いくい状況があったとしても、自分たちで工夫してプロジェクト管理を楽にしようとする雰囲気が出てくる。

他にRedmineを機能拡張した事例として、チケット生成ツール、顧客側BTS連携、ガントチャート生成、メトリクスシート生成、工数登録モニタリングなどがあった。
ほとんどが、RedmineチケットをCSV出力して、Excelマクロでガントチャートやメトリクスを生成したり、逆に、Excelでチケットの元ネタを作ってCSVを吐き出してRedmineにインポートする、とか。
あるいは、RedmineからCSV出力したチケットデータを顧客側BTSのフォーマットへ変換してインポートするツール、とか。
Redmineプラグインも10数個は社内で開発されたらしい。

【3-3】さらに、Redmineを運用して、担当者を必ず入れることで、信頼関係が強化されたこともあった。
オフショア開発チームがQAをチケット登録した時、問い合わせる担当者が誰か分からない、と言われた時があった。
そこで、国内チームで担当者を決定し、QAの回答をスムーズに行えるように調整した。
つまり、必ず、担当者を決めて回答させるようにした。
そういうやり取りが蓄積されて、オフショア開発チームとの信頼関係が良くなった、という効果もあった、と。

【3-4】Redmineにスクラムを組合せて運用した事例も興味深かった。
組み込みソフトウェア開発では、工場やハードウェア部門の権限が大きいから、彼らの信頼を得ることが非常に大切。
だから、ソフトウェア開発者は必ず期日を守るように運用したい。
しかし、実際は難しい。

スクラムを導入した時、計画時にタスクをRedmineチケットで一括登録し、1週間単位の進捗管理を導入したら、計画後の是正対策で早めに動けるようになった。
運用サイクルとしては、毎週金曜に進捗のふりかえりを実施し、1週間の作業内容を精査し、来週の作業計画を修正する運用だったらしい。

また、ユニット(チーム)単位でサブプロジェクトを作り、サブリーダーに進捗管理を担当させたら、各チームで自発的な改善がしやすくなった、と。

この辺りの感覚はとてもよく分かる。
Redmineのロードマップ機能は、アジャイル開発ととても相性が良いからだ。

【4】サンデル教授の白熱教室みたいなパネルディスカッション

Rxtstudy第11回パネルディスカッション「組織に応じたRedmineの運用法 」 from akipii Oga

昨年のredmine.tokyoのパネルディスカッションを真似て、関西でもお題に対し、パネラーや参加者の意見を話してもらいました。
僕はモデラーと言っても、議論を発散させるだけで割と楽な運用でした。

議事録が取れなかったので、思い出したことだけ書いておく。

・現実的には補完チケット方式だが、理想は完全チケット方式という意見が多かった。

・Redmineは最初はオープンソースの開発方式を元に作られているので、アジャイル開発と相性が良い。
しかし、その後の機能拡張をふりかえると、エンタープライズ系の観点の機能追加が多い。
JPL自身も、ユーザのリクエストでも、エンタープライズ系の要件が多いのだろう。

・Redmineのチケットは基本は社内なら、協力会社でも顧客でも公開してアクセスできるようにしている。
但し、新製品の機密情報はRedmineのプライベートチケットで運用し始めている。

今後は議事録を取るようにしたい。

【5】RedmineのチケットをCSV出力した後、CCPMの観点でメトリクス集計した事例を@nmrmsysさんが発表された。
Excelマクロなどのツールでコンバートすればいいから楽だろうと思う。

RedmineとExcelを使ってCCPMっぽい事をしてみる - X-Projects with CCPM

他の感想は別で書く。

【追記】
他のスライド資料はコチラ。

書籍はそろった！コミュニティで情報を共有すればRedmineはキャズムを超える from Makoto SAKAI

これはあなたの人生です

holstee社のポスター「this is your life」の文章が素晴らしいのでリンクしておく。

【参考】
holstee社のポスター「this is your life」を無料でダウンロード！ - ベランダガーデニングの作り方とおしゃれな雑貨VERANDAHER

「HOLSTEE マニフェスト」読んでみてください：An Agile Way：ITmedia オルタナティブ・ブログ

「これはあなたの人生」、とある会社の美しくも力強いマニフェスト | Lifehacking.jp

【引用】
This is your life.
（これはあなたの人生です。）
Do what you love, and do it often.
（自分が好きなことをやりなさい。そして、どんどんやりなさい。）

If you don’t like something, change it.
（何か気に入らないことがあれば、それを変えなさい。）
If you don’t like your job, quit.
（今の仕事が気に入らなければ、辞めなさい。）

If you don’t have enough time, stop watching TV.
（時間が足りないのなら、テレビを見るのをやめなさい。）
If you are looking for the love of your life, stop;
（人生をかけて愛する人を探しているなら、それもやめなさい。）

They will be waiting for you when you start doing things you love.
（その人はあなたが好きなことを始めた時に現れます。）
Stop over analyzing, life is simple.
（分析しすぎることをやめなさい。人生はシンプルです。）

All emotions are beautiful.
（すべての感情は美しい。）
When you eat, appreciate every last bite.
（食事をひと口ひと口味わいなさい。）

Open your mind, arms, and heart to new things and people,
（新しい物事や人々との出会いに、心を腕をそして感情を開きなさい。）
we are united in our differences.
（私たちはそれぞれの違いによって結びついているのです。）

Ask the next person you see what their passion is,
（次に出会う人々に、何に情熱を傾けているか聞きなさい。）
and share your inspiring dream with them.
（そしてその人たちにあなたの夢も語りなさい。）

Travel often: getting lost will help you find yourself.
（たくさん旅をしなさい。道に迷うことで、新しい自分を発見することでしょう。）
Some opportunities only come once, seize them.
（ときにチャンスは一度しか訪れません。しっかりと掴みなさい。）

Life is about the people you meet,
（人生とはあなたが出会う人々であり、）
and the things you create with them
（その人たちとあなたが作るもの。）

So go out and start creating.
（だから待っていないで作り始めなさい。）

Life is short.
（人生は短い。）

Live your dream, and wear your passion.
（情熱を身にまとって、自分の夢を生きなさい。）

【感想】
自分の中で、あるべき姿は持っているし、どの方角へ進めばいいか、何となく分かっているのに、気持ちが乗らなくて一歩を踏み出せない時がある。
そんな時に勇気づけられる。

iDempiereの活用法、アーキテクチャ、開発環境の資料リンク

iDempiereの活用法、アーキテクチャ、開発環境の資料が公開されていたのでメモ。

【1】低コスト経営を実現するためのOSS ERP iDempiereの活用法

低コスト経営を実現するためのOSS ERP iDempiereの活用法 from Hideaki Hagiwara

iDempiereで何ができるのか、どんな利用シーンで使えるのか、が分かりやすい。

【2】EnterpriseArchitectでリバースエンジニアリングした資料

RDRAによる分析で有名な神崎さんが作成されたモデリング資料が公開されている。
神崎さんの話によれば、iDempiereのアーキテクチャはとてもすっきりしていて、ビジネスロジックとユーザ・インタフェースが完全に分離されており、機能追加しやすいアーキテクチャになっているらしい。

Enterprise Architectのリバースエンジニアリングは大量のJavaソースをすぐに読み込めるし、解析できるから便利ですよ、と言われていたのも思い出す。
iDempiereは1000近いテーブル、4000個ものソースがあるから、こういう優れたモデリングツールが無ければ、システムの全体像を理解するのも難しいだろう。

iDempiereの業務分析

iDempiereのアーキテクチャ

要件定義の散歩道 - タイムラインの写真

要件定義の散歩道 - 今まで投稿した記事のもとになったiDempiereのモデルファイル（EAファイル）を差し上げます。...

【3】iDempiereの開発環境の作り方

EclipseとJavaとPostgresSQLを用意すれば、デバッグできる環境が整う。

Java - iDempiere v2.0の開発環境をMacに構築する - Qiita

iDempiereのインストール方法と画面キャプチャ: プログラマの思索

iDempiere（アイデンピエレ）の開発環境構築 - OSS ERP Compiere Distribution Lab

エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること

長沢智治さんの記事がとても素晴らしいのでメモ。
以下は主張のないラフなメモ書き。

【参考】
オピニオン：長沢智治： エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider

(引用開始)
エバンジェリストは、マーケティング活動の一環のため、「市場を作り、成熟させる」ことが求められてしかるべきである。
(中略)
従ってエバンジェリストの活動とは、「自分が携わっている製品や技術の詳細を伝える」ことではなく、「世界観を伝える、つまり市場の変遷であったり、トレンドであったり、その中での製品や技術の立ち位置であったり、コンセプトであったりを伝える」ことが第一だと考える。「世界観」についてのコンセンサスを現場で持てたなら、きっとその現場は、自分たちに合った解を議論と体験の中から導き出せるはずだ。
(引用終了)

akipiiさんはTwitterを使っています: "すごく良い記事。エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること。オピニオン：長沢智治： エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider http://t.co/mn9H0d4ud3"

【1】僕は、RedmineやTestLink、iDempiere、vTigerCRMなどのオープンソースのツールが好きだ。
自分たちで使いこなすうちに、どんな場面で利用すると効果が出るのか、が分かってくる。
使いこなすうちに、自分たちの世界がグレードアップする感覚が好きだ。

そして、じきに新たな課題を感じ取る。
では、その課題とは何なのか？

それは単に、そのツールだけでは解決できない課題という意味だけではない。
そのツールを使いこなすことで、アウフヘーベンされ、本来の問題の本質が見えてくる、という意味の方が強い。

ツールで得られた現場の経験知をモデル化していくうちに、そのモデルがどんな問題にフォーカスしているのか、そのモデルが対象とする問題解決のスコープとその限界が見えてくるのだ。

【2】そんなことを考えながらツールを使っていくと、そのツールの熱烈なファンになる。
こんな機能が欲しい、もっと使いやすくしたい、他のツールに似た機能があるといいな、とか、色んな欲求が出てくる。
あるいは、このツールはこんなにすごいんだよ、と他の人に薦めたくなる。

エバンジェリストの役割は、そのツールを宣伝することだ。
エバンジェリストの影響力が大きいほど、ツールを使うユーザ数も増える。

しかし、その方向性が行き過ぎると、そのツールのライバル製品をけなしてしまう言動をしてしまう時がある。
熱烈なファンがそのツールしか眼中に無く、他のツールの良さまで見えなくなってしまう危険があるのだ。

パッケージ製品のベンダー、オープンソースのツールやパッケージ製品を販売するエバンジェリストは、そのような落とし穴に嵌る時があるのではないか。
僕自身、そんな時があったなと反省するときもあった。

【3】上記の長沢さんの記事では、エバンジェリストは、単にツールを宣伝する人ではなく、ツールが提供されるマーケットを開拓する役割を持つことを主張されている。
その意見は、思わず、そうだよ、と納得した。

ライバル製品との機能比較、製品の持つ新しい技術や仕様などの細部の話が全てではない。
むしろ、エバンジェリストが持つ世界観を世の中に提示すべき。
では、その世界観とは何なのか？

それは、市場の変遷や技術の変遷の中で、そのツールがもたらす新しい価値とは何なのか、を提示すること。
つまり、製品や技術のような枝葉末節の話ではなく、ツールがもたらす価値が現場のどんな問題を解決し、どんなステージを提供するのか、という価値観を提示することだ。

そんな世界観や価値観をエバンジェリストが世の中に提示することで、現場で従来は解決できなかった課題がクリアされる。
あるいは、ツールを導入する前はそもそも、そんな課題すら認識しておらず、問題意識も持っていなかった人もいるに違いない。

そんな人達に、ツールがもたらす価値やメリットを提示して、潜在的なニーズを掘り起こし、問題意識すら持っていなかった新たなユーザ層を獲得し、市場をどんどん広げていく役割がエバンジェリストに求められるわけだ。

市場を開拓し広げていくことで、ユーザから製品へのフィードバックも増えて、製品もどんどん改良されていく好循環も生まれる。

オープンソースの製品もパッケージ製品と同様に、利用ユーザが集まるコミュニティが活発に活動するほど、コミッタと利用ユーザの間で有意義な議論が行われ、製品のあるべき姿が見えてくる。
製品がどんな場面で有効に使えるのか、という利用シーンが明確になるだろう。

更には、製品がもたらす価値のスコープが見えてくることで、製品の新たな課題も見えてくるだろう。
その新たな課題は、製品がどんな方向に進化すべきか、というロードマップに大きく影響するだろう。

個人的な妄想としては、オープンソースの製品群を連携させた一連の「プロジェクト管理サーバー」のような概念を提示し、それがソフトウェア開発プロセスを進化させていることを明示したいなあ、と思っている。

稼働率100％の罠

@hatsanhatさんのツイートから良い記事を見つけたのでメモ。
以下はメモ書きであり、特に主張はない。

【参考】
とれるだけ仕事をとってはいけない : タイム・コンサルタントの日誌から

稼働率100%をねらってはいけない : タイム・コンサルタントの日誌から

佐野　初夫さんはTwitterを使っています: "とれるだけ仕事をとってはいけない http://t.co/JQRIl8fTqP ソフト業界だと危険稼働率をはるかに超えて受注することも普通です 主任の頃に「無理です」と言うと「それを回すのがお前の仕事」と言われました"

受託開発中心のSIでは、PGやSEの稼働率が売上に直結する。
受注したシステム開発案件にメンバーを投入して、人月計算で売上を稼ぐスタイルだから。
すると、PGやSEの稼働率が低いと、空いた時間は売上につながらない作業をしていることになる。
だから、営業も管理職も必死になって受託案件を取ろうとするし、受託案件に社員をアサインしようとする。

SIの部署の売上を見る時、KPIとして稼働率もひとつの指標になる。
稼働率が低い部署は、そもそも案件がなくて暇か、売上に直結しない営業活動をしていることになる。
だから、社員は売り上げにつながる案件に必ずアサインされて、何かしらの付加価値を生み出すことを義務付けられている。

しかし、稼働率が100％になる人は、いつも忙しくしていて、生産性を落としている時が多い。
僕も、何故なのだろう？と思っていたし、自分自身も同じ状況にハマった時に同じように感じた。

その理由は、「ゆとりの法則」にも書かれているように、稼働率が100％になり、ゆとりがなくなると、その人が担当するプロセスがボトルネックになる。
ボトルネックの後工程は暇になるので、暇に見せかけいないように、同じように生産性を落とす。

つまり、システム全体がボトルネックの生産性に合わせるようにスループットを落とす。
遅延だけがシステム全体に伝播するのだ。
それはちょうど、TOCの理論が言う主張に似ている。

また、上記の記事にも理由が書かれている。
待ち行列理論によれば、稼働率が100％に近くなると、急激に待ち時間が長くなる。
この待ち行列の長さはすなわち、その会社における仕掛在庫量を意味する。
仕掛り在庫が増えるほど、月末の在庫計上で赤字になる。

さらに上記の記事で面白いのは「危険稼働率」という概念だ。
危険稼働率とは、ある稼働率を超えると、逆に赤字になる分岐点のことらしい。

普通に考えると、稼働率がゼロに近い場合は売上がゼロだから、稼働率を増やすほど売上も増す。
そのまま稼働率を増やすと、損益分岐点を超えるから、その時点から利益が出る。
さらに、稼働率を増やして100％へ近づけていくと、逆に、利益が出なくなって赤字になるポイントがある。
そのポイントが危険稼働率になるらしい。
つまり、危険稼働率を超えないように受注活動を制限する必要があることを意味している。

その危険稼働率について、いろんな疑問がわく。
危険稼働率は、いくつかのパラメータから計算可能なのだろうか？
危険稼働率は、どんな計算式になるのか？

危険稼働率を、仕事の種類ごとに計算したら、どんな特徴が見えてくるのか？
SIのようなソフトウェア開発の会社ごとに危険稼働率を計算したとしたら、どんな結果が出てくるのか？

色々考えてみたい。

4/11にXP祭りin関西2015 ～Agile S×T～を開催 #xpjugkansai

4/11にXP祭りin関西2015 ～Agile S×T～を開催します。
今年は、「実践 反復型ソフトウェア開発」の著者の津田さん、「実験的アプローチによる現場改善」の考えを広めている細谷さんの講演があります。
アジャイルな開発環境や開発プロセス、新しい技術やアイデアを試す改善アプローチに興味のある方は、是非ご参加下さい。

【告知】
XP祭りin関西2015 ～Agile S×T～ - 日本XPユーザーグループ関西 | Doorkeeper

XP祭りin関西2015 - XPJUG関西wiki

【自分の思い】
【1】「実践 反復型ソフトウェア開発」の著者の津田さんの講演に、とても興味を持っています。
僕は、「実践 反復型ソフトウェア開発」はソフトウェア工学を知りたい人にとってバイブルとなる書籍だと思います。
過去にBlogに感想の記事をたくさん書きました。

実践反復型ソフトウェア開発を読む part1～ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2～マージの戦略: プログラマの思索

実践反復型ソフトウェア開発の読書会ログ: プログラマの思索

実践反復型ソフトウェア開発を読む part3～再現可能なビルド管理: プログラマの思索

「反復型ソフトウェア開発」はソフトウェア工学の良書: プログラマの思索

アジャイルな開発を支える開発環境や開発プロセスには、過去のソフトウェア開発のノウハウの結晶が詰まっており、それらのベストプラクティスには実はきちんとした名前と概念が付いています。

しかし、現状は、それらの概念や知識を整理して、一つの体系としてまとめて、誰もが再利用できるような理論としてまとめられていないと思います。
逆に、技術やプロセスの標準化、枯れた技術にこだわり過ぎて、実は開発の効率を落としている現実もあるでしょう。

概念は強力な武器です。
概念を知ることで、アジャイルな開発を自信を持って実践できるし、他人にも説明しやすくなります。

個人的には、「実践 反復型ソフトウェア開発」にある構成管理の説明が一番好きです。
バージョン管理ツールの使い方を越えて、ソフトウェアの構成管理はいかにあるべきか、という思想が背後にあるように思えるからです。

ソフトウェア開発がハードウェアの製造と異なる点は、バージョン管理の重視であり、広い意味での構成管理の技法の必要性と考えます。
頻繁なバージョンアップを実現できる環境やプロセスを持てれば、自然にアジャイル開発を実践できるでしょう。
つまり、小規模リリースというXPのプラクティスがアジャイル開発の根幹を支える技術だと僕は思うのです。

昨今は、この考え方が広がっていると共に、重要性を増している、と思います。
たとえば、デスクトップアプリやWebシステムのVerUpだけでなく、iPhoneのようなスマフォも定期的にOSやアプリをVerUpすることで、使い勝手と品質も向上し、ユーザに価値を提供できるようになっています。
しかも、IoTのように、ネットワークに繋がるプリンタや家電製品、車載機器などにも、頻繁なVerUpによる機能改善が可能になってきているのです。

つまり、アジャイル開発の概念は、ソフトウェアだけでなく、ハードウェア、そしてビジネスや一般人の生活スタイルにも影響を与えているのです。

チケット駆動開発も構成管理を実現する一つの技術と考えているので、その辺りの議論もしてみたいなーと思います。

【2】細谷さんが提唱される実験的アプローチの考えも非常に興味深いです。

第162回 実験的アプローチによる改善活動（全4回の第1回）｜SQiP：Software Quality Profession

第163回 実験的アプローチによる改善活動（全4回の第2回）｜SQiP：Software Quality Profession

パイロット開発にAgile開発のアイデアを適用した事例～実験的アプローチ　#JaSST_Kansai: プログラマの思索

「実験的アプローチによる改善活動」の記事のメモ: プログラマの思索

僕の理解では、実験的アプローチは、新しい技術を現場に導入するためのメタプロセス、メタアプローチだと思います。
SNSやネット、コミュニティで新しい技術を取り入れて、その技術を適用する場面や課題、利用シーンを考えていくと、今まで認識していなかった課題が現れてきます。
そんな課題に新しい技術を適用すると、課題が解決されるだけでなく、予期しない効果も出ることもあれば、新しい技術の限界も見えてきます。

実験的アプローチは昔のQCサークルと同じ活動でしょう、という意見を聞く時もありますが、僕の理解では、IT業界では実験的アプローチは必須のスキルのようにも思えます。

汎用機、クラサバ、Web、モバイルとどんどん技術が進化しており、そのスピードに技術者も付いて行く必要があります。
このようなメタプロセスを意識して持っておかないと、20代に習得した技術から成長できないのではないか、と思います。
新しい技術を取り入れることは、課題解決に役立つ反面、効果が確実に出る課題をうまく見つけられなければ、効果が出ず、労力だけ費やすこともあります。

その時に、実験的アプローチのような手法を用いて、新しい技術を現場に導入していけば、新しい技術の有効性を速く判断し評価することもできるでしょう。

【3】他にも、色んなコンテンツを準備しています。
近年になく、XP祭り関西は有意義な内容をご提供できると思いますので、是非ご参加下さい。