Agile

2016/12/06

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (2)

2016/12/05

AgileTourOsaka2016の感想

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

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

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

| | コメント (0)

2016/11/28

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

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

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

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

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

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

2.Intelligent empowerment

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

3.The holistic effect of team structure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2016/11/03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2016/10/17

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい~技術は人やチームに残る

SPIJapan2016の資料「現場から始めるアジャイルの技術プラクティス」資料が素晴らしいのでメモ。
個人的なラフな感想。

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

akipiiさんのツイート: "良い資料。「技術は超大事」「技術は人/チームに宿る」たぶん僕は技術指向、ボトムアップ指向の方が好きなんだな。組織変革、トップダウンは好きじゃない。現場から始めるアジャイルの技術プラクティス https://t.co/dzCclCA0CA"

akipiiさんのツイート: "聞きたかった!RT @Taka_bow: 今年のアジャイル関連の発表は基調講演の影響が大きくて「先ほど平鍋さんが言っていましたが…」「昨日平鍋さんも仰っていましたが…」という接頭辞が付きまくり。みんな、気にするな!笑 #spijapan2016"

akipiiさんのツイート: "ソフトウェア工学は未熟なプラクティスによって重大な阻害を受けてる、か。RT @hiranabe: 本日の講演資料こちらです。 #spijapan2016 https://t.co/PvOFlDC2cV"

アジャイル開発を日本の現場に導入する時、どこから手を付ければいいのか?
上記の資料では、「テスト駆動から始めよう」。
テスト自動化に反対する上司はいない。

テスト駆動の技術プラクティスは、他の技術プラクティス(CI、より良い設計)や品質改善、コスト改善にも良い影響がある。
なるほど、確かにそうだ。
他の技術プラクティスやマネジメントに目が向いてしまいがちだが、改めて初心に戻るような主張だった。

「アジャイルとかWFとか関係ない」
「技術プラクティスはプロセスに依らない」
「WFでもやれば良い (やるべき) 」
「技術は人/チームに宿る」
「チームを作り上げるには手間と時間が必要」
という主張はすごく同感。

プロセス改善、プロセス標準にどうしても目が向いてしまいがちだが、IT技術者である限り、技術にこだわって進んでもいいのではないか。
技術やプロセス改善のノウハウは、大きな組織やドキュメントに残るのではない。
人やチームに残るのだ。

だから、人やチームを大切にすること、人やチームを成長させる意識を持つことが大事。

個人的には、こういうボトムアップ的な改善方法が好きだ。
トップダウンの指導、標準化は、僕の経験上、上手く言った試しがない。
「選択と集中」という標語は良いが、日本人には向いていないのではないか。

たぶん、日本人は製造業のQC活動のように、ボトムアップのプロセス改善の方が当てはまりが良い気がする。
上から言われるのではない、自分たちの手元にある道具を使って改善できないか、という、ちょっとした動機から、最終的な良い製品を作り出す。
たぶん、そんな方法の方が上手くいく気がする。

| | コメント (0)

2016/10/10

組込みソフトウェア開発のプロセス改善の違和感

先日、組込みソフトウェア開発現場のプロセス改善の講演を聞いてきて、何となく違和感を感じた。
以下は感想とラフなメモ書き。
箇条書きなのでラフなメモ。

【1】こんな講演ストーリー。

【1-1】組込みソフトウェア開発組織での課題。
経営層がソフトウェア開発を分かっていない。
工場のモノづくりと同じような感覚でマネジメントしようとして、思い通りにならないことに苛立っている。

なぜ、そんなにコストがかかるのか? コストやロスを見える化できないのか?
これだけの開発規模で、もっと安く作れないのか? 開発効率を向上できないのか?
人材を計画的に育成して、もっと良い人材を揃えたい。IOTやビッグデータ、AIなどが分かる技術者を揃えたい。

(感想)
メーカーの経営者から見れば、ソフトウェア開発はブラックボックスなのだろう。
モノづくりのように、なぜもっと作業を標準化して、資本(資金)と労働者を大量導入して、大量生産できないのか?と思っているのだろう。
ソフトウェア開発は労働集約的な産業であり、規模の生産性が効かないのを知らないだけ。

【1-2】では、開発者にとってのプロセス改善はどうか?

プロジェクトリーダーにとって、憂鬱な仕事。
現場は、プロジェクトを回すのに手一杯で、これ以上、管理作業を増やしたくない。
SQA審査は無駄、時間の浪費としか思えない。

ソフトウェア開発を失敗しないやり方、うまいやり方はないのか?
しかし、銀の弾丸はないのだから、最終的には、自分達にあったやり方を見出すしか無い。

【1-3】開発標準の目的は、ソフトウェア開発を手順化して、管理できるようにして、効率的なやり方を定着させたい。
製造業の生産工程の標準化、3Sと同じ発想。

SQA審査では、開発標準に定めたルール、それに沿ったチェックリスト、テンプレート資料で、ドキュメントを精査する。
しかし、この開発標準は実質的に機能していない。形骸化している。

現場にとって負担が大きいだけで、効果が薄い。
CMMIのようなプロセスモデルの要求事項を満たすだけのために導入された資料作り、という感触が強い。
では、手間がかかるデータの収集にツールを導入して解決できないか?

(感想)
本当にその通り。
CMMIやISO9001のようなプロセス改善のための資料作りは、審査を通すだけのための作業と化しており、本来の品質維持にあまり役立っていない。
実際、リリース後に、設計書を整備したり、テスト結果を整理する作業をまとめて行う場合が多い。

【1-4】開発の計測として、工数、開発規模、欠陥抽出数というメトリクスがある。
たとえば、下記がある。

欠陥検出密度=欠陥検出数(件)/開発量(kStep)
開発効率=開発量(kStep)/工数(人時)

【1-5】「欠陥検出密度=欠陥検出数(件)/開発量(kStep)」は、どの工程で測定するか、で意味合いが異なる。
たとえば、「設計レビュー」「結合テストのテストNG数」「総合テストの障害数」なら、バグ率。
バグ率を使って、品質を良くするためのプロセスを取り入れることで、開発期間中のプロセス制御に使える。

しかし、レビュー指摘数が多いほど欠陥検出密度は大きくなり、品質が悪く見えるので、レビュー指摘を躊躇する人が出てしまい、悪循環になる場合がある。

一方、製品出荷後なら「流出不具合率」になる。
ハードの製品なら、出荷後の不具合は、PL法(製造物責任法)の制約でメーカーの無過失責任になる可能性があるから、一方的にコスト負担になりがち。
だから、流出不具合率はできるだけ低く、ゼロにしたい。

しかし、流出不具合率は、開発完了後、一定期間を経過しなければ測定できないデメリットがある。
また、開発期間内に欠陥があると分かっていて、その欠陥は品質に問題なしという評価で、出荷する場合もあるが、それは流出不具合率に含めるのか?

(感想)
欠陥検出密度は、テスト前に、他の類似案件を元に計画値を定めて、実績はそれとほぼ同じか、少し低いぐらいの数値になるように収める、みたいなやり方が多い。
でも、欠陥検出密度の測定方法はいくらでも改ざんできるので、あまり意味が無いと思う。
「これは障害ではなく、顧客要望の仕様変更です」と言って省くこともできるから。

【1-6】「開発効率=開発量(kStep)/工数(人時)」は、開発する対象や領域によって傾向が大きく異る。
プロジェクトや製品ごとに違うために、比較しにくい。

また、流用開発や派生開発では、新規開発よりも開発効率の値が低くなりがち。
たとえば、流用率が高いほど、新規作成のソース行数は少ないが、工数は新規開発とそんなに変わらない。

話を聞くと、普通は、5step/時間、800step/人月くらいらしい。
1時間で5ステップ、または5行とは、かなり少なすぎるが、デバッグやテスト、障害修正を考えると、そうなるのだろう。

だから、経営者から見れば、ソフトウェア開発は効率が悪すぎる、と見てしまいがち。
つまり、開発効率は数字がひとり歩きしがちだが、比較は意味が無い。

(感想)
開発効率を使いたい場面は、子会社のオフショア開発者の生産性評価に使いたい場面が多い。
もちろん、開発効率が良い開発者が評価が高い。

しかし、実際は技術の習熟度、プロジェクトの習熟度に依存するので、ほんとうに正しいかどうか分からない。
メーカーのモノづくりならば、生産工程における単純な組立作業、ライン上の作業の開発効率として評価しやすいし、あまりブレない。
むしろ、生産工程の「標準時間」として抽出し、「生産標準」として「この生産工程ではこれくらいの作業時間が標準だ」と定めて、未熟練労働者を指導することもできる。
しかし、ソフトウェア開発でそんなやり方が通用するのか?

【1-7】そんな状況で、プロセス改善活動をやっているが、現場で蓄積するノウハウを展開していきたい。
組織のルールが自分達のプロジェクトに合わなくても、柔軟に解釈して運用する方が良い。
無理に合わせるため必要以上に時間を使わない。

(感想)
現実的にはそうなるだろう。
しかし、そうであれば、プロセス改善活動を進める立場の人の意義は、結局何だろうか?
プロセス改善部署がなくても、現場は回るのではないか?

【2】組込みソフトウェア開発のプロセス改善の話に違和感を感じたのは、製造業の品質管理の技法をそのまま当てはめようとしても、実際はうまくいかない、と思うからだ。
その違和感については、過去に書いた。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

ソフトウェア開発でバグ管理はなぜ必要なのか: プログラマの思索

上記の講演では出て来なかったが、僕が一番違和感を持つ言葉は「標準時間」「開発原単位」だ。
製造業では、開発効率の単位となる「標準時間」、開発コストの単位となる「開発原単位」をメトリクスとして抽出するのが一番重要であり、そこから計画を立てて、正確な見積を行おうとする。

なぜなら、数億~数千億円のような製造装置、製造ライン、工場を建てる場合、正確な見積がなければ、設備投資できないからだ。
しかも設備投資の意思決定は、実際のプロジェクト開始の1年前に決まっている。
だから、早めに開発効率やコストの原単位を計算する必要性がある。

しかし、ソフトウェア開発では、「標準時間」「開発原単位」は計算できるのか?
ソフトウェア技術者の能力によって、生産性や10倍以上違うのだから、標準時間も10倍以上違ってしまう。
開発原単位も、技術者の人月単価は30万円から200万円まで幅がありすぎるし、標準時間も10倍以上も差があれば、見積りのブレは大きくなりすぎ。
つまり、ソフトウェア開発では、「標準時間」「開発原単位」を計算しても、その正当性を説明しづらいのだ。

そもそも、アジャイル開発では、そんなものは計算しないし、計算しようとする動機も持っていない。

一方、日本の製造業では、実際の生産は外注に出している場合が多いので、外注によるアウトソーシングでどれだけコストメリットが出るか、品質が良いか、という評価が必要になる。
その時に、「標準時間」「開発原単位」という指標が外注ベンダー単位に必要なのだ。
そうすれば、今後の発注にも、見積りとして使えるし、納入された製品の品質評価にも使える。

そのやり方をソフトウェア開発にそのまま取り入れてもうまくいくとは到底思えない。

| | コメント (0)

2016/06/11

7/30土の第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいこと #redmine

7/30土に開催される第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいことをメモ。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

(引用開始)
7/30に第65回 SEA関西プロセス分科会&第15回 RxTstudy 「チケット管理システムによるプロセス支援と今後の課題」を開催します。
今回の勉強会のメインセッションは、JAXA様の担当者の方にRedmine運用の事例報告を講演して頂きます。

JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

JAXA様のRedmine運用事例報告を読むと、発注業務以外にISO9001も見据えた運用フローの標準化、ならびに、大規模な組織や多様な業務に対応できるようにRedmineの機能を十分に評価検証したことがよく分かります。
JAXA様の事例講演を次回も聞くチャンスはそうありませんので、ご興味のある方は是非ご参加下さい。
(引用終了)

【1】最近、Redmineの運用をいろんな場所で展開している時に思う問題意識は、二つある。
一つは、大規模な組織形態や多様な業務に対して、一つのRedmineインスタンスでカバーするには、Redmineにはどんな機能が必要で、どんな運用ルールが必要なのか。

もう一つは、組織構造とRedmineの相互関係を整理したいこと。
つまり、複雑な組織構造がRedmineやその運用プロセスにどんな影響を与えてしまうのか、ならびに、Redmineの導入と運用によって従来の硬直した組織の雰囲気を打破できる可能性はあるのか、を事例とその背後にある経験則を編み出したいこと。

【2】第10回東京Redmine勉強会のディスカッションで偶然聞いたグループでは、「闇Redmine」という言葉が出ていた。
つまり、一つのRedmineインスタンスでは他種類の部署の運用、多様な業務に耐え切れないので、自分たちのチームだけにこっそりとRedmineインスタンスを作り、自分たちのチームのソフトウェア開発プロセスの管理に使っている。

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

ツール主導ではなく、自分たちのプロジェクトで成果を出すためにツールを使うのだから、このやり方はおかしくはない。
しかし、自分たちのチームで上手くいったRedmineを隣のチーム、自分の部署のすべてのチーム、他の部署へ展開していくと、Redmineはどんどん複雑化していく。
特に、ワークフローやカスタムフィールドは、野放しに複雑に設定してしまいがちだ。

また、自分たちのチームのプロセスが、保守案件や問合せ管理、事務処理ワークフロー、サーバー資産管理、購入機器の管理などの多様な業務をカバーできるとは限らない。
むしろ、一つのRedmineですべての業務をカバーする方が無理があるのかもしれない。

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

【2-1】JAXA様のRedmine運用事例では、こういう運用の複雑さに対する解決策として、「ロールのOR設定ルール」「カスタムフィールドのAND設定ルール」を提唱されている。
このやり方は、ERPのパラメータ設定のノウハウに似ている気がする。
少ないパラメータ設定で、多様な業務、多様な要件に対応するために必要な運用ルールなのだ。

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【2-2】以前のRedmineでは、ロール単位のアクセス権限の機能が弱いと言われていたが、随分改善されてきた。
Ver3.3では、トラッカーごとにチケット編集・参照の権限を付与する機能が追加される。

akipiiさんのツイート: "これは便利!RT @g_maeda: Redmine 3.3.0に入るのが確定。 ? Feature #285: Tracker role-based permissioning https://t.co/vImWQN2OZy https://t.co/CwSfqamCc2"

Feature #285: Tracker role-based permissioning - Redmine

アクセス権限管理の強化は、Redmineがエンタープライズ分野で利用されるに従って、重要なテーマになるだろうと思う。

【2-4】個人的には、@akahane92さんの思いと同じく、Redmineの機能をベースに、多様な業務に適応するための「ITSガイドライン」のようなものが作れるといいなと思う。
つまり、Redmineというプロジェクト管理用ERPのパラメータ設定の汎用的なノウハウをまとめてみたい。

「ロール設定のORルール」と「フィールド設定のANDルール」はもちろんその中に入るし、他にもたくさんあるはずだ。

akipiiさんのツイート: "面白そう。RT @akahane92: redmine 等のITSのトラッカー設計について、みんなどうしてるのかな。「ITSトラッカー設計ガイドライン」があればいいな。RxTstudyの参加者がトラッカーを持ち寄って、少人数グループで議論して持ち寄ると作れるかな。広く役立ちそう。"

Kuniharu AKAHANEさんのツイート: "@akipii 直感的で有効なステータス名、トラッカーとの組み合わせ、興味深いです。/背景と要求(例: 利用・運営者の組織文化、ITSによる問題解決の対象領域, 等)によるふれ幅がどの程度あるのか。/ケーススタディーの対象にしたとき、参考となるどのようなケースを引き出せるのか。"

neta@とんこつしかたべないさんのツイート: "@akahane92 @akipii いいですね!ウチはほとんど『依頼』、『課題』ですが、『課題』からそのまま解決のための『依頼』になってるチケットも多く、分ける必要なかったと思ってます。"

一つのRedmineインスタンスで、大規模組織でも多様な業務にも耐えれるような運用ルールを策定できれば、Redmineの利用範囲はもっと広がるだろうと思う。

【3】「組織構造とRedmineの相互関係」については、最近色々感じるものがある。

【3-1】従来から経験していることは、トラッカーやステータスは、そのチームの文化、その組織の文化が色濃く反映されることだ。

例えば、オフショア開発チームとRedmineでやり取りしていた時、「課題」トラッカーは使いにくく「QA」トラッカーの方が使いやすい、と言われた時があった。
ワークフローは同じなのに、トラッカー名が変わるだけで、メンバーのモチベーションもかなり上がった。

逆に、障害トラッカーで「リリース済」「対応済」ステータスを使っていたら、そのステータスにアサインされた担当者は何をすれば良いのか、直感的に分からないので、チケットが放置される場合もあった。
「~済」というステータスは、タスク完了なので、自分はやらなくていいんだよね、と思ってしまうらしい。

また、メーカーのように、営業部隊・設計部隊・製造部隊が組織として分かれていると、チケットが組織をまたぐ場合に別のステータスが必要になるという場合もあった。
チケットをやり取りするボールは誰が握っているのか、をステータスで明確にしたいのだ。
すると、メーカーのような機能別組織の場合、一つの製品、一つのソフトウェアを出荷するには複数の部門が関連するために、ステータスがかなり多くなってしまい、チケットが放置される危険が高くなりやすい。

一方、SIならば、普通は一つのチームが要件定義からリリースまで担当するので、一つのトラッカーに含まれるステータスの個数はそれほど多くはないし、多くする必要性もない。
チケット駆動で回したいならば、トラッカーに含まれるステータスの個数は少ない方が回しやすいからだ。

そんな経験を振り返ると、Redmineは機能が豊富な特徴、機能が柔軟である特徴があるがために、逆に、縦割り組織の文化をそのまま持ち込んで、複雑なパラメータ設定になりがちだ。

特に最近、ISO9001やITILの運用プロセスをRedmineに乗せて運用できないか、という質問を受ける時がある。
彼らとしては、Redmineの柔軟なワークフロー機能やREST APIによるチケット情報の取得の容易さ、Redmineの展開のしやすさを生かして、ISO9001のような硬いプロセスを実現したいみたいだ。

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 トラッカーやステータス・進捗率のからみは、組織やプロジェクトの癖がもろにでますね。何もなければ、このルールでやろうねと教育はしているののの、、、プロジェクトごとの癖をみて、ちょこちょこメンテナンスしたりしてます"

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 ちなみに、トラッカー「WBS」「障害」「課題」「要望」「質問」「レビュー記録」、ステータス「新規」「受付」「作業中」「停滞」「確認中」「差戻し」「完了」「却下」です。きっと組織によってぜんぜん違うんでしょうね"

【3-2】一方、Redmineでチケット管理し始めると、チームの雰囲気や組織文化が少しずつ変わっていくという経験もある。

たとえば、Redmineには最初のバージョンの頃から、複数プロジェクト機能があった。
この機能を使うと、ソフトウェアプロダクトラインのような複数製品の並行開発、一つのパッケージ製品を顧客ごとにカスタマイズする派生開発に適用しやすいことは、従来から知られていた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

この機能を使い始めると、メンバーは縦割り組織に属している感覚よりも、複数のプロジェクトで作業している感覚になる。
つまり、組織の建前としてはピラミッド型の組織構造かもしれないが、現場のメンバーにとっては、プロジェクト型組織に属しているような雰囲気になる。
すると、自分の役割や権限が広くなるので、能力のある若手はたくさんのシステムに触れる経験を得やすく、どんどん成長していく事例をよく見かける。

また、プロジェクト型組織になると、プロジェクト内でコミュニケーションが活発化する。
一つのプロジェクト内で、一つのチケットをやり取りして完了させるまでに、色んな部署の人達と連携しなくてはいけない。
だから、自分は○○組織の一員だから、という意識よりも、○○プロジェクトの一員という意識になり、縦割り組織の雰囲気をぶち壊し、風通しの良い組織文化を形成してくれる。

【3-2】また、チケットの構造がチーム内の組織形態を規定する事例も見かける。

若手のプロジェクトリーダーからよく聞く質問は、WBSやチケットは、機能単位で作った方がいいのか、作業ベースで作った方がいいのか、という内容だ。
設計・プログラミング・テストのような単位で作業をグループ化すべきなのか、それとも、画面単位や帳票単位で作業をグループ化すべきなのか、迷うらしい。

会社の研修で教わるやり方は、設計・開発・テストのような工程単位の作業管理だ。
このやり方は、元々、製造業で規模の経済を生かすための作業管理手法であるから、ソフトウェア開発に馴染まない、と僕は常々思っている。
メーカーの組織が営業・設計・製造・品質保証の部門に縦割りになっていて、機能別組織になっているのは、設備投資を有効活用し、製品を低コストで大量生産するために、規模の経済を生かすためにそのような組織構造になっているのだ。

しかし、ソフトウェア開発の場合、人月の経験則のように、作業メンバーを増やすほどプロジェクトはどんどん遅延していくことが既に知られている。
つまり、ソフトウェア開発は規模の経済が通用しない。
むしろ、機能単位に作業を分割した方が管理しやすい。
機能単位ならば、機能の粒度を小さくすることで、小さなチーム構成にすることが可能だからだ。

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索にあるように、工程単位のWBSと機能単位のWBSでは、PERT図の構造が全く違うし、WBSを管理しやすくするための組織構造がWBSに規定されてしまうのだ。

すなわち、チケットの構造は、プロジェクト型組織の役割分担を規定する。
チケットを階層化するほど、WF型開発っぽくなるし、チケットをバージョン単位でグループ化して小規模リリースを優先するなら、アジャイル開発っぽくなる。
開発プロセスは、逆に、組織形態を規定しまうのだが、それに気づかない人も多い。

【3-3】「ソフトウェアアーキテクチャは組織構造の影響をもろに受けてしまう」という経験則は、Conwayの経験則として既に知られている。
この考え方は、組織構造がソフトウェアアーキテクチャ、開発プロセスを規定することから、アーキテクチャやプロセスの複雑さの遠因には、ソフトウェア組織にあるということだ。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

一方、平鍋さんの記事で「逆コンウェイ戦略」という概念を知って、気づいたことがある。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

「逆コンウェイ戦略」の発想は、より良いアーキテクチャに合わせて、チーム構成を作るべきというもの。
その発想を受け継ぐならば、より良いプロセスに合わせて、組織構造やチーム構成を決めてもいいのではないか。

実際、Redmineの導入によって、チームの文化や組織の文化は変わる。
その変化は良い方向性の場合が多い。
だから、積極的に、Redmineというツールの背後に隠れたプロセスを使って、縦割り組織を打破することも可能ではないだろうか。

【4】第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」のパネルディスカッションでは、上記のような経験や事例を元に、組織とプロセスの関係と、相互に与える影響について、パネラーや参加者の知見をまとめてみたいと思っている。


| | コメント (0)

2016/02/27

XP祭り関西2016~アジャイル15周年ふりかえりの感想 #xpjugkansai

「XP祭り関西2016~アジャイル15周年ふりかえり」が無事に終わりました。
約60人もの参加者、木下さんの基調講演、山根さんと土屋さんのアジャイルラジオコンビ、スクラム道関西の4人、藤井さんのDtoD、パネルディスカッションと盛り上がりました。
参加者、講演者、スタッフの方、お疲れ様でした。

以下は、僕個人のラフな感想。

【参考】
XP祭りin関西2016 - XPJUG関西wiki

XP祭り in 関西 2016 ?アジャイル15周年ふりかえり? - 日本XPユーザーグループ関西 | Doorkeeper

XP祭り関西2016~アジャイル15周年ふりかえり(2016/2/27) #xpjugkansai - Togetterまとめ

fkino diary(2016-02-27) "XP祭りin関西2016 に参加しました"

【1】今日の基調講演は、木下さんの「5分で分かるアジャイルムーブメントの歴史 拡大版」。
日本のアジャイル15年の歴史を凝縮した内容で、とても素晴らしいと思います。
僕は、XPJUG関西に10年以上関わってきたので、とても感慨深くて、色んな思いがありすぎて。

日本のアジャイル本の歴史を辿ると、3回のうねりがある。
1回目はXPブーム、2回目はScrumブーム、そして今3回目。

2000年代前半のXPブームでは、開発者がXPに熱くなっていた。
東京のXP祭りに参加して、あの雰囲気を関西でもやりたいと思って、XPJUG関西で企画したのがXP祭り関西2006。
それから10年も続いている。

2008年頃からのScrumブームでは、プロジェクトリーダーがScrumをチーム運営へ導入して熱くなっていた。
田口さんが、僕はScrumを導入して今まで失敗したことがない、と発言されていたのも思い出す。
未知の領域、新しい技術を取り入れた開発でScrumは大きな威力を発揮する、という趣旨を言いたかったのだろうと推測する。

そんな中、永和システムマネジメントとチェンジビジョンしかXPをやっていないのではないか、という疑惑から、平鍋さんが「アジャイル止める宣言」。
そこからAgileJapanが発足し、マネージャ層、経営層向けにターゲットを絞り込む。
また、IPAも「非ウォーターフォール型開発」という名前でアジャイルの研究会と資料を公開し、最初はIPAでもアジャイルと言えなかったのが、アジャイルという言葉が解禁になった。

そして今、ITがビジネスの中心になっているWebサービスやベンチャー企業では、アジャイル開発が当たり前の環境。
アジャイルでない従来型のSIもあるけれど、ネット上にもプラクティスやアンチパターン、事例が溢れていて、少なくとも知識の上ではもう差別もない。
そんな気がしている。

【2】山根さん&土屋さんのアジャイルラジオコンビのお話。
山根さんがJavaの開発で使ったツールやフレームワークの変遷の話は、僕もすごく同感して、感情移入してしまって。

僕も山根さんと同じく、ファウラーの「リファクタリング」本から入った。
僕は2002年頃、「リファクタリング」本を夢中で読んでいた。その頃はJavaプログラムを書ける初心者レベルだったから、こんな風に使うんだ、という知的刺激が楽しくて。
Eclipse上で、リファクタリングやデバッグ、しかもリモートデバッグまでできるのも楽しくて。

Antも随分使っていた。
WindowsでもUnixでも、同じビルドスクリプトが動くので、単体テストでもテスト環境でも本番環境でも同じようにビルドスクリプトを流用できる。
Strutsに初めて触れた時も、これだ!と思っていた。
今はもう、レガシーなフレームワークだけれど。

JUnit、DBUnitなどのテスティングフレームワークも書いていて楽しかった。
Javaでリフレクションはこういうふうに使うのか、モックはこういうものなのか、という気付きが楽しかった。

でも、あの山根さんも最近の技術のトレンドに少しずつ遅れてきていると感じている。
だから、コミュニティに顔を出して、新しいトレンドを取り入れようとしている、と。

【3】田口さんのKPTのプラクティスの事例も興味深かった。
普段はプラクティスの話はしないんだけど、と話しながら。

KPTは良くできたフレームワーク。
長所だけでなく、問題も洗い出して、対策まで考えさせる。

でもKPTを毎回やると飽きる時がある。
だから、他の色々なファシリテーションのツールを使う。
良かったこと・悪かったことをアイコンの周囲に付箋で書き出す。
モスバーガーの店前の掲示板を真似て、朝会の前に、いじりキャラの若手に小さなホワイトボードにその日の気分を書かせて、朝会の雰囲気をほぐしたり。

【4】パネルディスカッションのテーマは「アジャイルの達人に聞く~ソフトウェア開発の質問コーナー」。
僕がモデレータと言いながら、自分が一番聞きたい内容を質問形式にして、パネラーと議論できればと思っていた。
質問は、典型的なWF型開発しか知らない、というSIの立場であえて書いてみた。
5つの質問を用意していたが、最初の質問1個だけで1時間以上も費やしてしまった笑。

【5-1】「要件定義で注意しているポイント」を質問として投げかけた所、藤井さんから、その問題はアジャイルでは既に解決している。
アジャイルでは要件のように機能詳細は定義せずに、ユーザストーリーでまとめる。
1~3ヶ月おきにリリースすることで、ユーザーストーリーを検証・評価して、顧客に価値あるシステムを提供していく。

でも、要件定義が必要なのは、見積りの元ネタになるから。
見積りが契約内容と見なされてしまう。

【5-2】土屋さんいわく。
見積りは2種類は出すようにしている。オプションは2種類作り、双方にメリット・デメリットがあるように説明すれば、お客さんも納得してくれる。
松竹梅、という3種類の見積りあるよね、と。

【5-3】木下さんいわく。
うちは、インセプションデッキが作れるまで開発を始めない。
ユーザとは準委任契約を結んでいるので、要件定義で固定スコープの一括委託契約はしない、と。
顧客はうちの開発力を信用しくれているし、うちも顧客の信頼を崩さないようにと思って、信頼関係を大事にしている、と。
この点は、委任契約にある善管注意義務の発想と全く同じ。

他に、価値創造契約のように、準委任契約ではなく、システムの開発と運用を一体化した契約スタイルもある。

また、ユーザ側の担当者がアジャイルを受け入れてくれる人か否か、を判断している。
ユーザ企業の担当者が上司にお伺いを立てるような人ではダメで、俺がすべての要件を決める、と言う、プロダクトオーナーの役割を自覚する担当者でないと上手くいかない。

【5-4】田口さんいわく。
うちはゲーム会社なので、受託開発案件はそうない。
ゲームでは、ユーザが楽しいと思うものを作る、というふわっとした要件が多いので、要件定義という発想がゲーム業界自体にあまりない。
やってみないと分からないから。
そういう未知のソフトウェア開発では、Scrumがすごくマッチする。
Scrumを導入して今まで失敗したことがない。

でも、たとえば、ゲームのキャラクターを作るという作業の場合、キャラクターの図面を作る、キャラクターのエフェクトを付ける、などの作業を複数人のデザイナーが担当して作業する場合がある。
その場合は、Scrumではなく、タスクかんばんでワークフローとして作業を流す。
その方が回りやすい、と。

【5-5】参加者からの質問も多くて、その内容もすごく共感できて。

準委任契約と言っても、実際は要件定義は実施済みで、どんなモノを作るのか、という仕様が決まっているから、一括請負契約と変わらない場合がある。
そんな場合でもアジャイル開発はできるのか?と。

パネラーからは、顧客と信頼関係を築いていれば、準委任契約でも、スコープを固定せずとも開発は可能。
ある一定期間で、これだけの予算の範囲で作る、という条件があるので、その範囲内でベストなソフトウェアを作る。
その条件の範囲内で、顧客の要望に基づき、フィーチャを取捨選択して、オプションのように取り扱う、と。

でも、質問者の方は何となく納得できていないような雰囲気を感じた。
そして僕自身も、質問者と同じく違和感を感じていて、質問者とパネラーの間で、準委任契約の意味やその背後にある現実にズレがあるように感じた。

僕が知っている準委任契約は、実費請求の準委任契約であり、作業報告書がなければ開発費用を請求できない。
顧客の依頼に基づいて作業した、という契約。
その契約内容は、事実上、一括請負契約とあまり変わらない。

一方、パネラーの場合、顧客との信頼関係があり、顧客はチームの開発力を信用しているし、チームも顧客の要望がスコープに入るかどうか十分に吟味して回答し、その範囲内できちんと結果を出す。
その差は、要件定義がアバウトであっても、顧客がチームを信頼していて、チームも必ずアウトプットを出す、という信頼関係があるか否か。
その差は大きい。

や16ぁさんはTwitterを使っています: "挙げている例が当てはまりすぎててそのままワイに突き刺さる #xpjugkansai"

kawanotronさんはTwitterを使っています: "でも@akipiiさんの悩みよくわかる。 #xpjugkansai"

【5-7】他に、アジャイル開発ではドキュメントを作らないのか?という参加者からの質問もあった。

木下さんいわく。
ドキュメントはうちもほとんど作っていない。
でも、ユーザ側の担当者が変わると、そんな話は俺は聞いていない、と言い出す人がいて、大変になったこともある、と。

【6】アジャイル開発が当たり前の知識になったとしても、実際の現場でアジャイル開発が使えていなかったり、契約や要件定義でアジャイル開発を生かすノウハウがなかったりする。
今日のような場で、その辺りの本音の議論が少しでもできて、参加者の心に残ってくれたらいいなと思う。

| | コメント (0)

2016/01/08

XP祭り関西2016が2/27土に開催されます〜アジャイル15周年ふりかえり〜 #xpjugwest

2/27土にXP祭り関西2016が「アジャイル15周年ふりかえり」というテーマで開催されます。
もうすぐ正式申込が開始されますので、是非お越しください。

【参考】
XP祭りin関西2016 - XPJUG関西wiki

XP祭り in 関西 2016 ?アジャイル15周年ふりかえり? - 日本XPユーザーグループ関西 | Doorkeeper

(引用開始)
今年のテーマは、『アジャイル15周年ふりかえり』
アジャイル開発手法が世に発表されてから既に15年が経過しました。
XPJUG関西では、ここで一度、アジャイル開発手法について振り返ってみたいと考え、「XP祭りin関西」でその場を提供できないか議論を重ねて来ました。

今回、現場で長年アジャイル開発手法に携わっていらっしゃる方々をお招きし、この15年がどうであったか、また、現在、そして未来のアジャイル開発手法がどうなるのか、或いは、どうあるべきなのか、ソフトウェア開発の現場の目線で様々な角度から振り返ってみたいと考えています。
(引用終了)

XP祭り関西も2006年、そして2009年から継続して開催されてきました。
今年は、アジャイル界隈で大物の方(?)をお呼びしてます。

まず、基調講演は東京から関西出身の木下さん。
永和システムマネジメントでは、アジャイル事業部を立ち上げられ、事業部長として、ビジネスでもアジャイルを実践されているのだろうと思います。
どんな内容が講演されるのか、楽しみです。

そして、関西からは、アジャイルラジオで活躍された土屋さんと山根さん、そして、スクラム道関西の方々にアジャイルに関して語って頂きます。

土屋さんと山根さんはXPJUG関西で創立当初から活躍されていて、約5年前からアジャイルラジオというPodCastを流されてました。
アジャイルコミュニティのごく一部では、すごくマニアが多かったように思います。
どんな裏話が出てくるのか、楽しみです。

また、スクラム道関西は、ここ数年とても活発に活動されている関西のアジャイルコミュニティです。
講演者が4人も登壇されるので、どんなサプライズがあるのか、気になりますね。

さらに、企業セッションには、オージス総研の藤井拓さんが講演されます。
藤井拓さんと言えば、オージス総研でアジャイル開発に関する研究所を作られ、その所長をされていると聞いています。
また、オブジェクト指向やRUPからアジャイル開発まで、幅広くソフトウェア設計・開発・工学に関する研究や講演、出版もされています。
講演内容はまだ未定ですが、昨今日本で流行しているドメイン駆動設計などにも触れられるのでしょうか?

最後に、パネルディスカッションでは、私がモデラーの立場で、講演者の方をパネラーにお呼びして、「関西から日本のアジャイルの未来を語る」というテーマで議論する予定です。
久しぶりに、大物のパネラーが多いので緊張しますが、パネラーの体験談を元に、日本のアジャイルの未来とあるべき姿をパネラーに思う存分語ってもらう予定です。

ワクワクした方は、是非お申込み下さい。

| | コメント (0)

2015/10/02

「価値ある製品を生み出すためのアジャイル実践ポイント」の資料が公開されました

8/22に行われたSEA関西イベントの資料「価値ある製品を生み出すためのアジャイル実践ポイント」が公開されたのでメモ。

【参考】
第63回 SEA関西プロセス分科会-SEA関西 価値ある製品を生み出すためのアジャイル実践ポイント

これからアジャイル開発を実践したいという初心者向けに、アジャイル開発のマインドや実践ポイントを解説した資料。
特に、ターゲットは、製造業向けのソフトウェア開発者をイメージしているみたい。
135ページと長いが、「わかりやすいアジャイル開発の教科書」をベースにしているので、内容はとても分かりやすい。

当日の勉強会では、初めて、レゴスプリントをワークショップで経験した。
レゴスプリントでは、ブロックを使って、Scrum風のプロセスで製品をチームで作っていく。
結構面白かった。

なお、レゴスプリントとレゴスクラムは全く違うモノらしい。
それも一つ勉強した。

| | コメント (0)

より以前の記事一覧