無料ブログはココログ

« 2013年6月 | トップページ | 2013年8月 »

[#Agile] アジャイル開発の課題と対策 その2

前回の続きです。対策を考えるとどのようになるか考えます。

以下の図ではDBとUIとしていますが、基盤部とUIでも構いませんし、全く異なる切り分けでも構いません。順序に関する制約があるなら、同じようなことを検討すると思います。

前回の復習

アジャイル開発の普及が遅れている理由として、以下の3点をあげました。

  • 日本では データが変わると大変なことになる」と考えている DOAが普及している
  • ビジネスを重視するRADが普及しなかった
  • ルールの明確で複雑な基幹業務が多い

これらによって、逐次開発する事に対する危機感はある反面、必然性がなかった事になります。

そこで、解決策として、ベーム氏の「アジャイルと規律」から

  • リーンやFDDなどのリスクベースのアジャイル手法と計画駆動を組み合わせる
  • アーキテクチャ設計を予め行う
  • 開発内容にあわせて計画駆動のチームとアジャイル開発のチームに分ける

の3つを取り上げ、さらに

  • ビジネスの視点でアーキテクチャを考える

という提案をしました。

開発イメージ

今回は、アーキテクチャ設計後の開発をどのように行うかを考えてみます。
まずは基本イメージを見てみましょう。

Base_2

WF(ウォーターフォール)は予めDB設計を行った上で、UIなど他の部分を開発するでしょう。アジャイル開発はDBとUIの開発を並行して行います。単純に考えるとこのようなイメージですが、実際はもう少し工夫しているでしょう。

Real

現実のWFでは、DB設計が終わるまでにプロトタイプを開発しています。開発者を早めに投入する事でコミュニケーションを容易にし、DB設計が終わった後にすぐにUIの開発ができるようにします。

プロトタイプは性能などの評価、操作性の検討、 HTML作成(MayaaやWicketのようにHTMLがそのまま使えるフレームワークもありますね)、 横展開のひな形、部分的な本格実装、などが考えられます。WFなのでこの期間には各種設計書も書かれるでしょう。

現実のアジャイル開発では、ストーリ単位で開発されますので、DB設計とUI設計が交互に行われるでしょう。ある程度仕様が固まるまでDBは構築せず、モックで開発を進めるかもしれません。

アジャイル開発では単純に優先度の高い順に開発すると思われるかもしれませんが、手戻りのリスクも考える必要があります。早く実装するとリスクの下がるものと上がるものがありますので、リスクを考慮して開発順序を決めます。

Compo

チームに分ける場合は、WFとアジャイル開発を組み合せます。粗な関係で分離できるなら、インタフェースだけを決めておいて単純な組合せで独立して開発できるかもしれません。

もし、開発法で分けられないなら、DBチームとUIチームに分ける方法もあります。UIは共通処理の開発やモックによる開発などをすすめ、DBは早めに決めるべき所から設計します。チームは厳密に分けてしまうと、作業の融通が利かなくなりますので注意してください(多能工ではなくなりますので、アジャイル開発のアンチパターンですね)。

まとめ

この他にも色々な組合せがあると思います。単純にこの方法が良いというものではなく、ベーム氏の5つの重要要因にあるように、開発対象の業務や規模、メンバーのスキルなども考慮すべきだと思います。

物事を2元論的に捉えると、違いが明確になってわかりやすいという効果があります。しかし、ソフトウェア開発は複雑な作業の組合せであるほか、業務と直結していますので、「試してみる」ということはなかなかできません。

プロジェクトを成功させるには「xxと言われているから」ではなく、具体的なイメージができる程度には理解が必要です。なぜそのようになるかを理解し、チームの能力を最大限に生かすべく、様々な工夫を凝らす事が、大切だと思います。(続く

このエントリーをはてなブックマークに追加


[#Agile] アジャイル開発の課題と対策 その1

アジャイル開発が日本で知られるようになって10年以上経ちました。去年、あるいは一昨年からアジャイル開発2次ブームになって、大手ベンダーが取り組みを始めるようになりました。たぶん、今回は一定の広がりを見せると思います。

しかし気になるのは「なぜ、普及が遅れたか?」です。アジャイル開発の特長は数多くありますが、コード優先の繰り返し、テスト自動化、 現場能力発揮、顧客優先、いずれも大きな障害と考えにくく、 そのいずれを考えても遅れた説明がつきにくいと思っています。

関連する文献

そこで思い出したのは、児玉さんの「UMLモデリングの本質」に書かれた一文でした。

1990年代に入って、世界では構造化分析/設計手法がオブジェクト指向分析/設計手法に取り込まれました<中略>。一方、日本では、情報システムをWebアプリケーションで作成する事が主流になる2000年までは、DOA型の構造化分析/設計手法が依然として優勢であり、オブジェクト指向への取り組みが進みませんでした。

一方、平鍋さん・野中さんの「アジャイル開発とスクラム」には、こうあります。

コンウェイの法則によれば「ソフトウェアの構造はそれを作り出した組織構造に従う」となるだろう<中略>。ならば、オブジェクト指向的な組織構造を作ったらどうだろうと考えたというわけだ。

この二つを単純につなげると、日本ではオブジェクト指向の普及が遅れていたので、アジャイル開発の普及が遅れたとなりそうです。しかし、そこに(日本ではまだあまり説明されていないと思われる)アジャイル開発の課題があるのではないか。というのが、この記事の主旨です。

アジャイル開発の特長は理由にならない

(1) コード優先と繰り返し

オブジェクト指向を実践しているかどうかに関わらず、新しいフレームワークを利用する際や、Rubyのように動的な要素を含む環境では、机上の設計だけを先行しておいて、一気に開発するような事は危険です。プロトタイピングはもちろんですし、基盤部分とサンプルなどから順次構築していくことも珍しくありません。次にあげる自動化と共にあたりまえに行われていると思います(自動化による信頼性向上 - オブジェクト指向とアジャイル開発 -

(2) 自動化

Eclipseのような統合環境による支援、テスト自動化や継続的統合、は、アジャイル開発をきっかけに広がった感があります。統合環境はアジャイル開発と関係なく使われていますし、JaSST(ソフトウェアテストシンポジウム)などでも、早くからテストファーストは有効だという意見がありました。継続的統合がそれほど普及していないとしても、自動化が大変だからアジャイル開発をしない、などという話は聞いた事がありません。チケット駆動開発が注目されているように、自動化によるプロセス改善への抵抗は(手段が目的化した場合の批判はありますが)あまりないと思います。

(3) 現場能力発揮

欧米との価値観の壁は確かにあると思います。しかし、プロセス改善を実践されている方とお話をしていると、現場への押しつけになってモチベーションを下げないように、勉強会の開催や各種フィードバックを心がけられている方も多いです。そのような方が一定量おられるなら、アジャイル開発が一定の普及をしてもおかしくないはずです。

(4) 顧客優先と契約

請負一括開発でディフェンシブになるのことについては、ないとは言いません。しかし、共存共栄できなければ仕事はなくなりますし、そもそもお金を握っている発注側が、日本では一般に強いでしょう。

[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かうに書いたように、従来の開発法で進めるよりはアジャイル開発の方が有利な面が多く存在すると思います。また、契約面で考えると、顧客が望みさえすれば[#TiDD] アジャイル風開発ラフシミュレーションに示した、五月雨ウォーターフォールが実現できますし、実際されています。この事から言えるのは、未だにウォーターフォールに近い開発をされているユーザや開発部門は「その気になっていない」のだと思います。

DOA

このように見てくると、その良さが伝わるのに時間がかかるとしても、10年はかかり過ぎだと思います。そこには、アジャイル開発に移行できない「危機感」があるのだと思います。

【初級】ゼロから学ぶDOA 第1回にあるように機能よりもデータが安定しているので、データに注目するという認識を持つ方が多いでしょう。私もワーニエ法やジャクソン法、構造化設計/分析などを学ぶ際に、機能よりもデータが安定しているので、データに注目した方が良いと言われている、と教わりました。

しかし、DOA(海外ではDDA)を実践されている方にうかがうと「データが変わると大変なことになるから」というのが本当の理由だそうです。以前話題になった渡辺さんの「データモデルなきアジャイル」の危うさ: 設計者の発言はそのように読めます。また、それを受けたkent4989さんのアジャイルとデータモデル、DB進化設計のこともそれを肯定されているように読めます。

これに対して平鍋さんはデータモデリングなきアジャイル開発は危ういか?の中で、リーンソフトウェア開発の「決定をできるだけ遅らせる」というプラクティス(セットベース設計)、ベーム氏の記事からプロジェクトごとに異なる計画とアジャイルのバランスのほか、「高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い」とも言われています。

また、tgkさんは[モデリング]データモデル自体はアジャイルなのだが...の中で「データモデル変更の影響範囲を極力狭めるようアプリケーションをレイヤリングする」こと、つまりデータモデルを参照する範囲を限定せよと言われています。

これらは正しい事を言われていると思いますが、DOAを実践する際のモチベーションである危機感をなくして「先にデータモデルを作らなくて良い」と考えさせるには力不足ですし、解決策に至っていないと思います。

つまり、アジャイル開発の良い所も認めるし、うまくいく場合もあるでしょう、でも、私たちの仕事はうまくいかないんだよ。という方達の意見を覆す事ができていないと思います。

日本の特徴

解決策を考える前に、DOAがなぜ日本では根強いかを考える必要があると思います。

a) 既存業務の存在しない新規開発が少ない

最近は起業する人も増えて、リーンスタートアップなどが注目されています。しかし、日本のソフトウェア産業は大手ベンダーが中心で、新規の業務をこれから作るという事が少ないと思います。

既存システムのリプレスの場合、サービス開始当初から多くの機能が実現されている事が要件になります。 業務を止めないように細かなところまで必要とされます(場合によっては不具合までも仕様になります)ので、スモールスタートできる可能性は、あまりありません。

b) 基幹業務システムの割合が大きい

会社の屋台骨である基幹業務は、ルールの明確な複雑な処理です。法律の変更によって仕様が変わる事があっても、外界の変化によってスコープが変更される事はあまりありません。

結果的にスケジュールを守る目的で、運用で回避する事はあっても、作り上げながら仕様のバランスを取るような要素は、ユーザインタフェースを除くとあまりないでしょう。

c) 全体最適主義

個々の事情よりも全体の管理が優先されます。上に述べたように現場のモチベーションも重視されますが、部分最適よりも全体最適の方が効果が大きいからでしょう。

予算獲得もなぜそれが必要かの説明や、どこまで実現するかのコミットメントが求められ、全体を考慮した上での決定がなされます。

d) ミッシングリンク

そんなことを言っていたら「ビジネスに乗り遅れる」と最近のアジャイル技術を知っている方なら思われるでしょう。「許可を求めるな謝罪せよ」( CSMA/CDを思い出すのは私だけ?)とまで言われるように、スピードがビジネスには欠かせないはずなのに、なぜ日本だけ違うのでしょうか?

古くから欧米は起業精神が高いと言われますが、現在の日本の大企業も明治時代や戦後に起業しています。安定になれてしまったとか、インターネットバブルが日本では失われていたとか、色々な説明ができると思いますが、ここではDOAから考えてみます。

上で引用したITproのDOA解説の年表にも出てくるジェームス・マーチン氏はInforeation Engineeringの後にRapid application development(RAD)を、インターネットブーム直前の1990年に発表されています。これは、繰り返し型の開発や顧客と共に開発するなど、アジャイル開発の要素を含んだ開発法です。なぜか、日本ではあまり盛り上がらず、RADといえばVisualBasicのような開発環境しかWikipediaには載っていません。

海外ではビジネスチャンスに開発を最適化し、新規ビジネスを起こそうとしていたころ、日本では景気回復まで耐えるべく、全体最適とクライアントサーバーで乗り切ろうとしていたのでしょう。もちろん、日本でもインターネット関連は大きな伸びを示しましたが、海外と比べるとM&Aが多かったように思います。

この記事のはじめに、日本は10年遅れたと書きましたが、RADから考えると20年おくれていることになります。

解決策

では、これから景気が回復して、新規ビジネスが増えて、アジャイル開発が増えればそれで良いかというと、大いに問題があります。

新規ビジネスはリーンスタートアップでスモールスタートできますが、日本を支える既存産業が時代遅れになってしまうからです。欧米が20年かかって学んだ事に追いつき、追い越さないといけません。

まず10年取り返すには「アジャイルと規律」が参考になります。この本はXPが出てきた後に、5つの重要要因に注目してアジャイル開発と計画駆動の開発をどのようにバランスするかが書かれています。

この本のポイントは、以下の3点です。

  • リーンやFDDなどのリスクベースのアジャイル手法と計画駆動を組み合わせる
  • アーキテクチャ設計を予め行う
  • 開発内容にあわせて計画駆動のチームとアジャイル開発のチームに分ける

これで10年ほど、取り返せます。

さらに10年を取り戻すには、上記のアーキテクチャ設計をビジネスの視点で考える事だと思います。日本でも実装の基盤として多くのアーキテクチャ設計が行われてきました。しかし、ビジネスの視点でアーキテクチャを考えれば、計画駆動のチームとアジャイル開発のチームをうまく分ける事ができるでしょう。

また、時間軸の考慮も有効だと思います。「決定を遅らせる」べきものを拙速に決定するのではなく、リスクが少なくなるように効果的なタイミングで実施することで、より競争力が増すでしょう。

どこかで良いといわれたプロセスを盲目的に当てはめるのではなく、プロジェクトにふさわしいアーキテクチャとプロセスを構築すれば競争力が増し、20年間の遅れは問題にならないと考えています。

まとめ

日本でアジャイル開発の普及が遅れたのは、徹底したDOAが基幹業務の開発に向いていたからで、新規ビジネスの少なかった日本の競争力を支えてきました。基幹業務のノウハウを活かしつつ新しいビジネスを生み出すには、アジャイル開発だけでも、DOAだけでもうまくいかず、バランスを考慮したプロセスが必要でしょう。

この記事ではベーム氏の「アジャイルと規律」をヒントに、ビジネスとプロセスを考慮したアーキテクチャ設計を提案しました。他にないサービスを実現する事でビジネスが成り立つように、ビジネスにあわせたプロジェクトのプロセスを構築する事で他社との差別化が可能になると思います。

ソフトウェア開発だけに注目するとプロジェクトの共通性に目が向きがちですが、ビジネスに注目するとプロジェクトの個別性が目立つようになります。プロセス標準と共に個々のプロジェクトを支援する事も必要です。

ふさわしい組織作りをする際に、コミュニケーション、構成管理、ワークフローなど様々な検討と支援が必要になります。そのような場面で、チケット駆動開発はセメントのように、様々な問題を解決して、組織を形作ってくれるでしょう。

[#Agile] アジャイル開発の課題と対策 その2に続く

このエントリーをはてなブックマークに追加


[#TiDD] チケット駆動開発はプロセス改善の隙間を埋める - SPI Japanへの思い -

チケット駆動開発はプロセス改善、正確にはプロジェクト改善だと書いていますが、組織レベルのプロセス改善との関係をまとめておきます。

プロセス改善の枠組み

プロセスモデリングの目的は以下の4つといわれています。

  1. プロセスに関するコミュニケーション向上
  2. プロセスの再使用の促進
  3. プロセスの進化の支援
  4. プロセスの管理の促進

* W. S. Humphrey, M. I. Kellner, Software Process Modeling: Principles ofEntity, Proc. of 11th ICSE 1989. (PDF)

プロセス改善の枠組みでは、標準のプロセスモデルを用いて、1、2、4を直接支援して。3の標準プロセスの作成・変更はSEPGなどの専門チームが実施します。しかし、このやり方だけをしていると、与えられたものに従順になり、現場が考えて工夫することがなくなると思います。

先日も紹介した坂本さんの論文にはこうあります。

改善というと小集団活動のQCサークルと同じで、現場の誰でもが取掛かれると思って いる人が多い。確かにソフトウェアにおいても開発現場だけで解決できる小さな問題はた くさんあるが、しかし組織全体の成熟度を上げていく改善は実に奥が深く、専門性の高い 知識、技術を必要とする。

この文章は当時の様子を良く表しています。多くの企業は管理的目的で、規模や障害数など、一定の開発標準作りが既にされていました。その中で、QCサークルなどを通じて、現場が色々と工夫をしていました。

しかし、それは基本的な管理や工夫の延長でした。組織的に情報共有は行われていても、ソフトウェア工学の成果の利用や、組織的にプロセス改善を進める視点が抜けていました。

そこで、CMMなどの(組織)プロセスの視点での改善が注目されました。ソフトウェア工学の成果を標準プロセスに組み入れて、組織的な改善を進められたのです。

組織プロセスだけに注目しすぎた

組織プロセスを中心とした改善は大きな成果をあげました。しかし、「悪くはないけど、昔の方がよかった」という人もいました。当時はよくわからなかったのですが、坂本さんの論文の引用部分を見ていると、「開発現場だけで解決できる小さな問題」が置き去りになったのではないかと思っています。

CMMは組織プロセス中心ですが、チームプロセスを扱うTSPと個人プロセスのPSPというものがあります。CMMの段階モデルの提唱者であるハンフリーさんの「TSP ガイドブック:リーダー編」では紹介文(PDF)に書いたように「開発者の能力を最大限に引き出す」と、サーバントリーダシップやプロジェクトファシリテーションと同じ事が書かれています。

しかし、日本では多重請け負い構造の弊害か、組織プロセスだけが注目され、チームや個人のプロセスはまだまだこれからのように思います。前述のように、CMMブーム当時は現場での改善が行われていましたが、レベル達成が組織のゴールになると、チームや個人はその大きな目標の達成で精一杯になってしまったのでしょう。

急速な社会状況の変化

現場での工夫が少なくなっても、安定してソフトウェアが開発できているなら問題ありません。しかし、[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発に書いたように、ビジネス環境、開発環境、実装方法など、社会の変化によって、ソフトウェア開発は多くのリスクを抱えるようになりました。

1レベルに3−5年かかるともいわれた段階モデルはもちろんのこと、自由な成長が認められた連続モデルであっても、変化への対応は困難です。組織的に試行・評価した後でないと標準プロセスは変更できないからです。

チケット駆動開発はプロセス改善の隙間を埋める

チケット駆動開発は、抽象度の低いプロセスモデリングです。開発の計画、備忘録、履歴、ノウハウが記録されるほか、プロダクトや他の作業への関連も示す事ができます。最低限の標準化は必要ですがが、このモデルは基本的にプロジェクトの管理下にあるものです。

チケット駆動開発は、プロジェクトの個々の問題に対して様々な工夫が可能です。現場力を向上させ、挑戦の道具になるものです。プロセス改善の枠組みで抜け落ちた工夫の助けになるでしょう。

プロセス改善の枠組みでもテーラリングが許されています。開発標準のうち必須でないものは、変更が可能です。テーラリングのガイドを整備されている所もあるでしょう。ぜひ、そこにチケット駆動開発を取り入れて欲しいと思っています。

チケット駆動開発を導入すれば、もっと積極的にプロジェクト固有の問題に対応できるようになるでしょう。そして、 現場のモチベーションがもっと向上し、より効果的なソフトウェア開発が行われるようになると思っています。


[#TiDD] AsIsとToBeの視点によるチケット駆動開発の事例の考察 - 坂本記念WorkShop -

SEA SPIN(SEA関西ではなく本体の方)の「坂本記念WorkShop」に参加してきました。

坂本さんについて

この「坂本」といのは、オムロンの故坂本さんです。坂本さんは、社内のプロセス改善を進められる中で、CMMに興味を持たれ、活用されました。

坂本さんは単に社内でCMMを活用されるだけでなく、SEA(ソフトウェア技術者協会)やJASPIC(日本SPIコンソーシアム。SPI:プロセス改善)の活動、著作を通じて業界内での普及にも貢献されました。

CMMのころは全面的に応援され、CMMIになってブームが来た頃にはレベル達成を目的としたプロセス改善活動が増えてきた事に警鐘を鳴らされていました。

坂本さんの言葉

ワークショップでは、多くの方が坂本さんの思い出、あるいは、テーマの定量化に関する発表がありました。

ピープルウェアや「日本のソフトウエア産業、衰退の真因 」で有名な松原さんは坂本さんの思い出として、「士農工商メカエレキソフト」という言葉を取り上げられました。そして、縦社会の中で情報は上から下へ流れ、その中でソフトウエア技術者は、システム全体を把握できる最も有利な立場にいる。また、ソフトウェアは他の専門分野の知見を利用できる。とされ、坂本さんは外からの助言を改善に活かそうとされた。と話されました。

愛弟子の高木さんは、坂本さんの博士論文(PDF)から改善を難しくするものを話されました。その中では特に「改善成果が出るまでには時間がかかる」とされているが、結果をすぐに求めて、単価を値切るなど「悪魔のささやき」に負けてしまう。というお話が印象的でした。

濱崎さんは坂本さんの言葉をいくつか取り上げられました。その中でも

「基本手順なんてもんは、そのままやったら60点取れへん人達を、なんとか60点取れるようにするためのもんや。100点取りたかったら自分で工夫せんとあかん。」

という言葉が印象的でした。思い起こせば、坂本さんは社内の開発標準を厚くしないで「考えろ」と言っている。と話されていました。

AsIsとToBeの視点によるチケット駆動開発の事例の考察

初めに書いた坂本さんのCMMの活用方法は、以下の手順でした。

  1. 社内の状況をAS-ISマップでモデル化する
  2. 問題点を見極める
  3. CMMのプラクティスから対応策を探す
  4. 改善活動をする

業務モデリングにAS-ISからはじめるかTO-BEからはじめるかの議論があるように、プロセス改善もあるべき姿(TO-BE)とのギャップ分析から始める流派と、現状(AS-IS)から始める流派があると思います。

坂本さんは、TO-BEというべき段階モデルしかなかったCMMのプラクティスを用いながらも、AS-ISから始めるという現実的な改善活動をされている方でした。

そこで、今回はこの2つの視点でチケット駆動開発の事例を考察して、発表させていただきました。

資料に出てくる3種類の事例については、SPI Japan 2013で発表させていただことになりました。ご興味があれば、ぜひご参加ください。


[#Agile] 自己組織化あるいは自律的組織 #UAS3

最近、チームはどうあるべきかを考えています。

アジャイル放談

考え始めたきっかけは、8月11日に頒布開始されるUAS3(Ultimate Agile Stories iteration 3)掲載に向けたアジャイル放談でした。今回も内容豊富な議論でした。編集を意識したり、ただ酔っぱらっていたり、と楽しいひとときをすごさせていただきました。

議論し尽くせなかった内容は、自転車の教え方 - トレーニングのあり方の考察 -[#agileradio] アジャイルラジオはメディアミックスの力を持つ! に書きました。そして、最後に残ったのが自己組織化あるいは自律的組織の議論です。

組織パターン

自己組織化に関しては、今夏に和智さんが訳されたJim Coplienらの「組織パターン」という本が出ます。しかし、よりUAS3を楽しんでいただくことと、読んだ際の気付きも明らかできる、と思いますので、この本を読み始める前、現時点での考え方をまとめておきます。

とはいうものの実は「XPやアジャイル開発の「価値」 -「価値観」でお願いします - #devsumi」で書いた様に和智さんの講演は聞かせていただいたので、講演資料の防火壁の事はすでに頭にあります。

自己組織化に境界は必要か?

アジャイル放談で議論になったのは、境界が必要かどうかです。「アジャイル開発とスクラム」にある様に、スクラムはオブジェクト指向化したプロセスですのでカプセル化は当然ですし、組織パターンのCoplienが関わっているので防火壁も意識されているでしょう。

実際、スクラムの価値である「集中」を実現するには外乱からチームを守る必要があり、サーバントリーダーシップを発揮して実現すべき事の一つでしょう。しかし、それは単純な境界で良いのか?というのが私の疑問です。

他の組織や関係者との情報共有

アジャイルのスクラムは良くできているものの、知識共有がチーム内で閉じている点がオリジナルのスクラムに劣っている点である事は、野中さんが「アジャイル開発とスクラム」で書かれているとおりです。

これに対して、現場ではタスクボードを見える場所に置いて、関連するチームや関係者で情報共有をされています。多くのチケット駆動開発プロジェクトが、社内に公開されているいたり、関係者をメンバーにしておくのと同じですね。

マルチロールな関わり方

アジャイル開発のワークショップでは「マルチロールは良くない」と言われます。しかし、実際問題として、プロジェクトは一つでも、事務作業や勉強会のような社内作業のほか、個人的な趣味や過程な事情など、人間が社会的な動物である限り、複数のロールを持つ事は当然です(関連「複数の組織に所属するユーザを支援するマルチロールコミュニケータと権限の委譲機構@SS2001」)。

欧米はどちらかというと個人主義・契約主義ですので、40時間など契約の時間内の作業をこなせば後は自由であるとか、複数のロール間で何らかの取り決めをしておくのかもしれません。しかし日本の場合、あたり前の様にプロジェクト以外の色々な仕事が割り当てられてしまうとか、出産後の時短勤務であっても遠慮しながら帰るなど、なかなか難しいかもしれません。

マルチロールの場合も情報の共有が有効だと思います。どのような作業にコミットし、どのような計画で作業を実施する予定であるかを関係者に示す事が効果的です。しかし、チケット駆動開発であっても個人の状況は意識的に見ないとわかりません。朝会などの全体のコミュニケーションの場で、本人や事情を知る人が、チーム以外のロールを説明して、情報共有して個人の防火壁を築く必要があるでしょう。

自己組織化は同じ方向を向く事から始まる

このようにチームの運営を考えると単純な境界ではうまくいきません。バザール方式(リンク先はwikipedia)のオープンソースソフトウェア開発やコミュニティの活動でも自己組織化されているように、必要なのは方向性の共有だと思います。

チームに境界を定めるとその中だけで自己組織化されますが、多くのソフトウェアはリーマン先生の言われるE-Typeですので、単独で存在せずに外界のシステムに組み込まれて実行されます。そこでは、ユーザを含む全てのステークホルダーを巻き込んだ組織化必要です。

作って終わりではなく常に進化し続けるには、境界を作ってその中で自己組織化するだけではなく、関係者が重層的なロールを持ちつつ関わる状況が必要です。その様な状況も含めて、自己組織化を実現していくべきだと思います。

現場には多くの事情が存在する

スクラムは一つの有効な解を示している事は間違いないと思いますが、現実には色々と考慮しないといけない事情があります。それは受け入れて解決しないといけない問題です。

スクラムのアイデアの元になったオブジェクト指向は優れたモデリング技術の一つですが、言語によってはやりにくい事があります。そこで、アスペクト指向、多重継承やMixinのような改良が行われています。

これらは多くの問題を解決する反面、シンプルさを損なって新しい問題を生む場合もあるでしょう。しかし、単純にはいかない場合があるという現実を知っておく事は重要です。現実の問題点を踏まえた上でシンプルな実現を目指せば、より良いものにできるからです。

おわりに

以上、実際のチーム作りがどうあるべきかの考えをまとめました。境界を定める事は有効だとは思いますが、必須ではないし、それ意外の視点も大切ではないかと思っています。

自己組織化に必要と思われている境界が、書籍「組織パターン」でどのように語られているか、楽しみにしています。

#この記事は、UAS3のアジャイル放談とあわせて読まれると、より楽しめると思いますw


[#Redmine] Redmineによるメール対応管理(その2) - 検証編 -

RxTstudyの記事にまとめた様にでRedmineのメール処理を教えてもらったついでに、少し試してみました。

メールの取得法

いつもお世話になっているRedmine.jpの「メールによるチケットの登録」によると、rdm-mailhandler.rbによる方法と、rakeによる方法があって、それぞれ以下のような特長があります。

(1)rdm-mailhandler.rbによる方法

メール受信のためのAPIを有効にした後、メール処理専用のAPIキーを用いてRedmineに登録します。これは個人のAPIキーではなく、Redmine全体で共通のものになります。

通常、メールサーバ上の/etc/aliasesに登録するもので、メール受信時に標準入力を即時処理します。APIでアクセスしますので、rdm-mailhandler.rbを登録したメールサーバとRedmineサーバは異なって良い様です。

/etc/aliasesを修正するには管理者権限が必要ですが、UNIX系の環境なら、ホームディレクトリの.fowardでも同じ様に、パイプ処理をしつつ残したり、別のアドレスに転送する事も可能です(UNIXの部屋 コマンド検索: ~/.forward)。

(2)rakeよる方法

Redmineサーバ上で動作します。入力はIMAPによるメールの読み込みと標準入力による方法があります。IMAPなのでメールサーバの管理者権限は不要で、メーラーと同じ様に一定時間ごとにメールを取り込み、フォルダの振り分けることもできます。もちろんメールサーバはRedmineサーバと異なって構いません。

標準入力の場合は、メールの内容をリダイレクトできれば、そのデータがどのように作られていても構いませんので、メーラーからコピーして登録する事も可能です(これはrdm-mailhandler.rbも同じです)。

RubyならIMAPを使ってGMailにアクセスするにあるように、rubyで簡単にメールサーバにアクセスできますので(サンプルの半分は認証用のコードです)、前処理をする目的で、標準入力を使っても良いかもしれません。

メールの前処理

@akipiiさんのまとめられた「メールからRedmineのチケットを自動登録する時の注意点」には、スFrom、To、CCなどヘッダー情報の保存、テータスの変更、という2つがありました。

From、To、CCなどヘッダー情報の保存

これは、上記の標準入力の前処理として、メールの初めから改行のみの行まで(つまりメールヘッダー)のうち、必要なデータを残しておいて本文にコピーすると良いでしょう。

ステータスの変更

もともと、メールでステータスを変更できますので、「フィールド名: 値」の行を本文に追加します。許されているフィールドの設定行は成功しても失敗しても消えますので注意してください。

しかし、実際にやってみると、ステータスを「新規」に変更仕様としてもうまくいきませんでした。どうも値が日本語の場合はうまくいかないか、私のスクリプトが悪かったようで、新たにreopenというステータスを作り、ワークフローを追加すると、「status: reopen」と言う行を追加する事で、ステータスが変更できました。

スクリプト

/etc/aliasesに追加する場合、前処理を|(パイプ)でつなげて書く事ができませんでした。そこで、ラッパーにして、前処理と本来書くべきrdm-mailhandler.rbの処理をパイプでつないだシェルスクリプトを登録してみました。ざっくりしたものですが、20行程度でした。

日本語のステータスの問題は残っていますが、課題はひとまずこなせました(タイムラグができますが、@akipiiさんが書かれている様にrakeのオプションで設定すると良いかもしれません)。

rakeの検証結果(2013年7月12日追記)

rakeの標準入力で確認したところ、オプションでステータスを変更する事はできませんでした。本文中に「status: 新規」と記入する方法で、ステータスを変更できました。

試しに/etc/aliasesにrakeを設定してみたところ、project意外の多くのオプションでエラーになりました。ただし、allow_overrideが指定できないものの、ステータスの変更はできました。rakeのトラブル報告もありますので、何らかの不具合があるのかもしれません(追記終了

まとめ

もともとCRMのツールではないですが、多機能が特長のRedmineだけあって、ちょっと工夫するだけで色々使えそうです。真剣に作り込むなら色々と考えないといけない事が出てくると思いますが、目先のちょっとした利用なら、かなり使い出のあるツールだと思います。


[#Redmine] 立っているものはJenkinsでも使え! - ALMiniumで外道Jenkins -

「立っているものは親でも使え」と言いますが、RedmineのオールインワンパッケージでsるALMiniumを入れると、 (インストールをyとすれば) Jenkinsサーバーが立っています。これを使わない手はありません。

このJenkinsはCI(継続的統合)ツールと言われるもので、ソースのコミット時や夜間などの定時処理、あるいは必要な時に、ジョブと呼ばれるビルド処理を実行できるツールです。

このビルド処理は、MavenやAntのようなビルドツールだけでなく、シェルスクリプトでも実行可能で、Haziさんの「邪道Jenkins」やnetmark.jpの検証記事の様に様々な応用が可能です。

外道Jenkins

さて、この記事ではそんなJenkinsを、webから実行可能なシェルスクリプトとして利用したいかにも外道なjenkinsの利用例です。具体的にはALMiniumでRedmineを遊ぶ色々拡張する際に必要な、Redmineの再起動ジョブを作りました。

単に再起動するだけでは面白くないので、(ビルドツールではなく)スクリプト中でチケットの登録をAPI(を使うスクリプト)でしました。

準備(ALminiumをインストール)

MacBookAirのParalells 7 に、ubuntu Desktop 12.04 LTSとALminiumをインストールしました。こんな感じで、ざっと2時間です(すごい!)。

まず、Parallelsのメニューからubuntuを入れますが、これはALMiniumが64ビット版が対象であること(日本語チームのものは32ビット版)、仮想環境とホストOSでマウス共有やコピー&ペーストするには、仮想環境のツールを仮想環境にインストール必要があり、自力のubuntuインストールでは難しかったからです。

上記では英語版が入りますので、日本語化して各種設定します。上記の手順に抜けていますが、タイムゾーンの設定のほか、ポートフォワードの設定をしてホスト側からアクセスできる様にすると良いでしょう。

細かなところでは、ubuntuインストール後にALMiniumをインストールすると、curlのエラーとrewriteのエラーが出ましたので、上記のような順序でやり直しています。随時スナップショットを取っておくと、やり直しが簡単なので良いでしょう(もしかすると、すでに改善されているかも)。

ジョブスクリプト

ジョブのスクリプトは以下の2行です。

touch /opt/alminium/tmp/restart.txt

ruby /home/parallels/rb/redmine_issue_post.rb 1 3 "$JOB_NAME No.$BUILD_NUMBER" $BUILD_ID

再起動処理

1行目で、Redmine(というかRuby on Rails)の再起動する際は、アプリケーションのtmpに restart.txtを作成または更新します。これが面倒なので、JenkinsさんでGUI化した理由です。

ファイルの更新ができる様に、ユーザjenkinsをグループwww-dataに追加して、上記ディレクトリのグループのライトパーミッションを立てています(755->775)。

Redmineのチケット発行

2行目はRedmineのRest APIでチケットを作成しています。これにはredcuineや多機能なgodmineなどがありますが、後から独自拡張しやすい様にtakashibaguraさんのrubyスクリプトを使わせていただきました(バージョンが違うのでrequire の'json/pure'を 'json'にしました。良い修正法があればお教えください)。

引数の1と3はプロジェクトIDとトラッカーIDです。設定順の通りでしたが、念のためMySQLで確認しました。

エラー処理

スクリプトの1行目が「#!/bin/sh」のように「#」で始まっていないので(実はrubyでもperlでも書ける)、デフォルトで「-ex」付きのシェルが動きます。

このオプションが付いていると実行履歴を出力しながら、エラーが出ると底で止まります。つまり、1行目でエラーが出るとチケットは発行されません。

実行結果

上記設定の後、キャッシュの影響かうまく動かないので、OSの再起動を一度しましたが、jenkinsのjob実行でRedmineが再起動する様になりました。

JOB_NAMEが「Restrat Redmine」なので、このようなチケットになります。

Photo

まとめ

以上、そこまでしなくてもalias切るだけで良いとか、色々ご意見はあると思いますが、やってみたかったというのが正直な所です。たった2行のジョブですが、Redmineの運用や業務処理など、様々な応用の可能性を感じています。

最後に、ALMinium、Redmine、jenkins、の作者の皆様とtakashibaguraさんに感謝いたします。ありがとうございました。


[#Redmine] Redmineによるメール対応管理(その1) - 第8回 #RxTstudy -

RxTstudy(Redmineやタスク管理を考える勉強会@大阪)第8回 RxTstudyでは、Gitはrebeseで使うべし、Redmineの開発裏話、パネルディスカッションなど興味深い内容が盛りだくさんでした(つぶやきまとめ)。その中でも興味深かったのが、前田剛さんの「 Redmineによるメール対応管理の運用事例」でした。

Redmineのメールの仕組み

このお話で、興味深かったのはRedmineのメールの仕組みです。

  • Redmineのメールにリプライするとコメントとして追加される。
  • Redmine(のメールハンドラー)はメールのタイトルにある[#番号]でチケット番号を認識する
  • デフォルトでは送信者のメールアドレスが登録されている必要があるが、--unknown-user=acceptとすると匿名ユーザとしてコメントできる

この講演に関連して@akipiiさんが記事を書かれています。

私なりに考えた事がありますので、まとめておきたいと思います。

オープンソース的なカスタマ管理

そもそもオープンソース系のBTS/ITSのはじまりはメールをインタフェースとしたものであることは、共著Redmineによるタスクマネジメント実践技法に書いた通りです。また、チケットと言う表現は英語のwikipediaにあるように、電話応対のメモが語源の様です。このように元々は、様々なメールや電話のカスタマ対応を効率化したものです。

特にオープンソース系の対応では元々メンバーと言う概念が希薄で、メンバーの概念の無いBTS/ITSもあり、誰にたいしてもでも対応するというのが基本なのでしょう。そう言う意味では、--unknown-user=accept ではなく、--unknown-user=create つまり、問い合わせがあればメンバーにすべきです。

こうすると、@akipiiさんの課題であるカスタマの管理のほか、会社との紐漬けも解決します。メールを受けた際に、ユースケースによってユーザあるいはチケットの属性として、会社を手作業で確認して登録すれば良いのです。会社の属性はリストとして、無い物はドンドン追加していくようにすると分析も容易になるでしょう。

チケットの番号間違いとステータス

さて、前田さんの発表で課題とされていたものに、チケット番号が間違っているものや、クローズしたものの場合がありましたが、これは、関連チケットのステータスをnewか適当なものにすれば良いと思います。

ステータスを変える方法には色々あると思いますが、メールハンドラーを修正しなくてもメールの最後に「Status: New」という行を追加するフィルタのスクリプトを、メールハンドラの前にかませれば良いと思います(詳しくは続編を見てください)。

こうすると、クローズされていないメールを管理するだけで、番号違いなども拾う事ができるでしょう。

まとめ

以上の様に、CRMにどこまで求めるかによると思いますが、結構良い線までいくと思います。問題は、--unknown-user=create とすると、アカウントが増えすぎて管理が面倒になることですが、それはやりたい事なので仕方がないと思っています。(続編へ


理にかなったアジャイル王子の華麗なるペラペラ英会話メソッド - 第24回 関西IT勉強宴会 -

英語が大の苦手で、英語の入門書は山の様に買いました。何度挑戦してもやる気が続くのは初めだけで、もう買うまいと決めていました。しかし、第24回 関西IT勉強宴会 「ITエンジニアの ゼロから始める英語勉強法」で、アジャイル王子こと著者の牛尾さんの説明を聞いて、この本はぜひ買いたいと思いました。

王子の説明をまとめると(私の理解した)ポイントは以下の3点です。

  • 能力にあわせて勉強法を選ぶ
  • 発音から始める
  • 英語脳になるには英語漬け

シンプルな方法ですが、これが理にかなっています。

能力にあわせて勉強法を選ぶ

多くの学習法はそれなりに納得できる説明があり、良さそうに思うのですが続きません。これは私も経験したことです。王子いわく、学習法にはそれぞれ前提があるが、説明されていない。前提となる能力がなければ身に付かないし、どの学習法もある程度続けると伸びなくなってくるので、別の勉強法に変えなければいけない。とのこと。

確かに「好きこそものの上手なれ」と言いますし、モンテッソーリ教育でも学習が進む期間を「敏感期」と呼んで、子供に一つの事に集中させます。面白いのは、楽しくなくなったり、能力の伸びを感じなければ、積極的に切り替えるところです。このような学習法はあまりないと思うのですが、興味の湧くものを選べばうまくいくのかもしれませんね(類似のものとしては「つまみ食い勉強法」というものもあるそうです)。

発音から始める

発音練習の本は語彙数も少なくて良いと聞きますが、王子の方法はもっと基礎的な所からです。子音から、音に区切って発音する事から始めます。スマートホンで自分の発音を録音して、正しい発音かどうか確認します。発音ができれば、そのレベルで聞き分けられる様になるとのこと(人に聞いてもらうともっと良いそうです)。

もともと、日本語は音が少なく音域が狭く、広い音域を使う英語の勉強は不利です。そこで、マジックリスニングが良いとか、モーツアルトが良いとかいわれていました。でも、聞こえる音域が広がっても、音を正しく認識できなければ英語になりません。そこで、基本的な発音の練習によって発音と共に音の分解の練習をするのでしょう。

英語脳になるには英語漬け

王子の著書に「オブジェクト脳のつくり方」という本がありますが、今回は英語脳の作り方です。王子いわく、英語学校の様に週に一度、時々英会話をするだけではダメで、どっぷりと浸からないといけないようです。また、王子いわく、 日本の英文法は海外の情報を和訳するために必要な知識を提供しますが、現地ではシチュエーションに合わせた話し方を学ぶそうです。知識中心ではなく話す事が大事な様です。日本語に直さず、とにかく話す事が大切との事。

これは、人間の脳細胞を模したというニューラルネットも同じですね。一度の経験ではなく、同じ事を繰り返す事で脳細胞は最適化されるのでしょう。

私の経験からもそう思います。一度、1週間近く海外に行った時は、知り合いに頼れない状況も間々あって、繰り返すうちにいい加減な英語なら考えずに出る様になりました(その時だけですが)。また、英語ネーティブな人と週に何回か食事に行く経験もしましたが、考えて話していても一向にペラペラにはなりませんでした。

以前、スタートレックシリーズなら単語のレベルがそろっていて良いと聞き、試しましたが、英語字幕に頼っていまい、英語力は向上しませんでした。王子の言われる様に、聞き流すのではなく集中する必要があったのでしょう。

まとめ

以上が私の大まかな理解です。必要に応じて学習法を変更する、録音してフィードバックを得る、というのはアジャイル的ですし、計測できなければ制御できないとも考えられますね(さすがエンジニア)。

勝手にタイトルを付けましたが、これはこのメソッドの本質だと思います。ムダな努力をせずに、華麗に、楽しく、勉強法を勉強して、ペラペラになるのがこのメソッドです。王子いわく、「このメソッドでペラペラにはなりますが、英語力は上がらない」との事。必要に応じてほかの勉強法も併用した方が良いでしょう。

注:本を読まないで書きましたので、間違いがあるかもしれません。不明な点があれば本でご確認ください。


« 2013年6月 | トップページ | 2013年8月 »