Agile

2017/05/14

第12回東京Redmine勉強会の感想 #redmineT

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

【参考】
第12回勉強会 - redmine.tokyo

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

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)

より以前の記事一覧