「エクストリーム・プログラミング」を含む日記

2021-05-29

■スクラムだけが アジャイルじゃない

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

かつて、数々のアジャイルな開発手法が存在して（というか今も存在しており）、この宣言はそれらの開発者が集まって合意したものだ。

ところが、最近ではスクラムだけがもてはやされ、他の手法に全く触れられないことに違和感がある。

また、「うまくいかない原因の根本はそもそも開発チームの問題なんだっけ？」って問題そのものを議論せず、スクラムだけを導入すれば解決すると思い込まれていると思う。

スクラムへの違和感

私がスクラムについて違和感を持っているのは以下のような点だ。

良くも悪くも、スクラムは開発チーム以外の部分を変えなくても導入できてしまうように思う。もし外に問題があるとしても、その変革はあまり主張されていないし、スクラムマスター個人に任されている
自分の周囲では、実際に成功したチームがスクラムに準拠していないことが多い。最初はスクラムだったとしても、プロダクトオーナーが個人でなくなったりして柔軟に変化させている
スクラムはスクラムガイドとその他ドキュメントが整備されている分、教条主義になりやすい。その内容も脱文脈化され「この部分を変えたらどういう悪影響があるのか」ということが分かりづらく、開発チームの変化を促さない
Scrum Allianceがうさんくさく、資格ビジネスの側面も大きいんじゃないかと感じることがある。たしかにスクラムは他の手法（例えばXPやカンバン）に比べて商業的に成功しているが、流行っているプログラミング言語が良い言語とは限らないのと同じだ。またプログラミング言語よりチームごとの工夫や変更が簡単だし、重要だと思う
プロダクトオーナーの役割が偉そう。結局トップダウンで意思決定してるのが気に食わない（※これは自分の性格の問題かもしれないｗ）

※ただし、開発チーム以外を変えなくても導入できるのはメリットでもあり、それでチームの負荷を下げつつ他の問題に対処するのは悪い手ではないと思う

一方で、例えばXPは「開発が成功するためにチーム内外に向けてなんでもやれ」という視点が強く、「ビジネス上と技術上の責任を分ける」などのアドバイスの章も用意されている。

ただその分「ここに注意せよ」くらいしか書かれておらず、結局どうやるかは自分たちで試行錯誤しなければならないことは変わりがないが。

スクラム（というか開発手法全般）を不適切に導入した後の最悪のケースは、本当は他の要因で問題が起きているのに、その分析が全く行われずに、開発チームにだけ際限のない改善が要求されることだ。

例えば「みんなリファクタリングをしなきゃいけないことに気づいており、それが評価されないから新規プロジェクトに力を入れざるを得ない状況だと知っているが、それを誰も口に出さない。その状態で正確な見積もりをしようとしたり、開発スピードだけ効率を上げようとする」という状況は誰もが身に覚えがあると思う。

主張したいこと

つまり、我々の所属するソフトウェア開発チームでは、目の前に存在する問題に対処してアジャイルチームになることが重要で、その方法はスクラムで主張されているような開発手法とは限らないし、むしろそのわかりやすさやきれいなドキュメントがミスリードである場合もある。

そのためには、まず現実の課題が何なのかしっかり把握して、フェアに議論することから始めるのが重要なんじゃないか。

参考文献

Clean Agile 基本に立ち戻れ（isbn:4048930745）:「アジャイルは小規模なソフトウェア開発チームのためのもので、大規模アジャイルやソフトウェア以外への適用に違和感がある」「実践こそが大事でスクラムマスターが数週間の研修でできるようになるわけねえだろ」と批判している
XP エクストリーム・プログラミング入門―ソフトウェア開発の究極の手法（isbn:489471275X）: Clean Agileでは「XPがアジャイルの基本形で、他の手法はその派生だと捉えるのがいい」と解説されている。新版もあるが、Clean Agileの著者のおすすめはこっちらしい。割といいこと書いてる

Permalink | 記事への反応(1) | 09:20

2013-03-23

■いつの 時代のソフトウェア工学の話だよ

http://d.hatena.ne.jp/nowokay/20130322#1363969460

以下の記述のまとめ：

お前の言っているソフトウェア工学は今のソフトウェア工学じゃねえよ．

端的に言うとそんだけ．

で，本題．

まず，書いてる内容が古すぎて救いがたい．iPS細胞の研究がノーベル賞取った現状で，「実験材料に受精卵を使う万能細胞の研究なんて許されませんよ！」と主張されても，その何だ，困る，とかそういうの．

1999年、なにがあったかというと、XP エクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年 12月になっています。
ここからソフトウェア工学がガラガラ崩れた気がしています。

で，何？2000年以降ソフトウェア工学が何も進んでないと主張したいの？

特に学術的にソフトウェア工学に触れたことはない

って最初に書いてあんのに，そこから崩れて何も出てきてないって主張はどっから出てきたの？自分が知らないことが分かってるのにドヤ顔で提言とか大丈夫か？

しかし、結局統一設計手法は完成せず、UMLだけが残りました。実際に使われているのはその一部です。CORBAも普及せず、Web プロトコルにあわせてSOAPが出てきたものの、結局単純なRESTが定着しました。XML はいまは毛嫌いされています。大成功したはずのオブジェクト指向も、Web アプリではうまく適用できませんでした。

だから何だ．提案されても使いにくかったり，状況自体が変化したら無用になるに決まってる．まさか「ソフトウェア工学分野で提案された手法はどれだけ開発環境が変わっても生き延びていなければならない」とかいう寝言じみた主張でもしたいのか？言語に流行廃りがあるように，手法にも流行廃りはあるに決まってるだろ．

あとSOAPとXMLに関しては，その衰退過程自体がよくある話すぎて話にならん．一番最初に厳格な重量級の様式が定められて，それをベースに運用レベルを考慮した軽量級の様式が定義されて駆動するってのはよくある話．言い換えると，学術から出てきた理論的に正しい手法が，産業界で必要なところだけつまみ食いされる形で運用されるとか，サンプルは死ぬほどそこらじゅうに転がってねえか？

ああ，CORBAはまあ，うん，そのなんだ．アレはフォローできない．

実際のところ，UMLが残っただけで十分じゃねえの？最初に提案された時の理念さえブレてなければ，つまみ食いしたモノがはやってても提案者的には本望だろ．

そしてCMMもいま特に話題になることもありません。

今はCMMIだ．CMMは2000年にCMMIに統合されてる．今更XPの本出してくるところといい，真面目に2000年より前で知識止まってんだな．

また、動的型付言語の普及も、ソフトウェア工学離れのひとつであると言う事ができるかもしれません。

はぁ？動的型付言語が普及したらなんでソフトウェア工学と離れんのよ？静的型付言語で使えて，動的型付で使えなくなる研究分野なんぞ，完全にソースコードに寄り添った研究だけじゃねえか．

「この手法はC言語を対象としている」って書いてある研究は他の全ての言語には一切適用できないと主張してんのと一緒だ．はじめてのCあたりからやり直せ．

ここで、やはりCMMの失敗がソフトウェア工学にとっての痛手だったように見えます。
もちろん、プロセスを規定することが難しいということは当時からも言われていました。それであるから、CMMはプロセスそのものを規定するのではなく、プロセスの規定方法を規定するというメタプロセスになっていたのです。
そして、すべての組織で同じプロセスを採用することはできないということから、５段階のレベルを設けました。また、プロセスは変化し続けなければいけないということから、CMM 成熟度レベル５では「最適化している」という成熟度になっていました。
これはなかなかいいかもしれないということで、期待は大きかったと思います。
でも、とにかく運用が大変だとか、CMM 成熟度レベル5でも品質がいいわけじゃないとか、そういう話がきこえてくるようになりました。

まず失敗を定義しろ．で，失敗したってんなら，CMMIで未だに新たな認定がなされてる（http://cmmiinstitute.com/assets/presentations/2012SepCMMI.pdf）理由を説明しろ．

で，運用が大変？当たり前だ．品質確保すんのに運用が楽とかあり得んだろ．従業員に好きにやらせてもアウトプットが高品質ならそもそもCMMIなんぞ必要無い．順序が逆だ．「CMM 成熟度レベル5でも品質がいいわけじゃない」ってのも当然だ．アレは組織の成熟度を評価する指標であって，中で働く人間の能力を評価してるわけじゃない．というか流動すんのに評価なんぞできねえけど．

そもそも，CMMI レベル5ってのはおおむね高品質なものが出てくるだけで，人間が関わっている以上ある程度のばらつきは存在する．つーかさー，CMMI レベル5なら必ず高品質のモノが出てくるとか思ってんの？まさかまだ銀の弾丸の存在を信じてんの？「ISO9001に準拠してればリコールなんて発生しない！」と思い込むくらい残念すぎねえか，その思考回路．

ああ，「CMMI」じゃなくて本気で「CMM」の話をしてるんなら申し訳ない．もう無いんだから，CMMの話を最近全く聞かないのは当然で，勘違いしても仕方ない．悪いもしくは古いのはアンタの頭だ．

そこにXPですよ。アジャイルですよ。
もともとソフトウェア工学に対しては「がっこーで現場しらない人が研究してる手法なんて使えない」のような声があったのですが、XPやアジャイルによって「現場から生まれた手法のほうが使えるよねー」というのが決定的になりました。

前半は正しい．ソフトウェア工学の最初期からずっとその手の意見はあって，未だに言われてる．が，後半は話にならん．

真面目に聞くんだけど，アジャイルソフトウェア開発宣言に名前が入ってる17人のうち，何人知ってる？何人が開発寄りで，何人が研究寄りか分かる？まさか Kent Beck1人を見て「アジャイルは現場から！」とか寝言垂れて無いよな？そもそもKent Beckはコンピュータサイエンスで博士号持ってるし，開発寄りと主張していいのかどうかすら微妙なんだけど．

あとアジャイルも突発的に出てきたわけじゃなくて，プロトタイピングとかあの辺（とそれ以前）からの流れがあると思うんだけどなあ．

ソフトウェア工学が何を失敗しているかというと、その学問自体の認知度が低すぎることです。
ソフトウェア工学がどのような問題を扱う学問かが知られていない。どのような問題を扱う学問か知られていないので、その問題に直面している人がソフトウェア工学の成果を積極的には利用できない。

ああ，まあ，うん，認知の低さは同意します．

問題に直面してる人がソフトウェア工学の成果を積極的に利用できないうんぬんについては，最近の国際会議でもその辺を扱った研究が出てきてたりする．ICSE2012のDistingished paperのうちの1本がそんなん．Eclipseの検索ツール使わずに，テキストエディタにコピペしてCtrl+F使ってる人の話とか出てきてた覚えが．

ただ，ソフトウェア工学の認知度なんぞどうでもいいと思うんだけどなあ，別に．そっから出てきたモノが使われさえしてりゃあ．ソフトウェア工学研究の成果が，それと分からずに使われてるんならそれ以上に望むべきモノは無いだろうに．「これがソフトウェア工学様の研究成果でござーい」と大上段に振りかぶって，「ありがたや」の言葉と共に使われることを望んでる研究者なんぞいねえだろ．

就職活動で「半年でプログラムは覚えれるし専門は必要ない」のようなことを言われるという話があります。たしかにアルゴリズムなど実装技術の研究をしていた人をSIの開発現場で生かすのは難しいと思います。でも、ソフトウェア工学の専門知識は、半年で覚えれるものではないし、SIでの開発現場に必要になるはずです。

うん，そうですね．だがそれを学術側を知ろうともしてない人間が言うな．

ソフトウェア開発がある限り、ソフトウェア工学は必要なので、XP・アジャイルを織り込んで再構築して、認知度を高めていってほしいなーと思います。再構築とかは他力本願になってしまうけど。

ソフトウェア工学を再構築しよう，という動きとしては http://semat.org/ あたりがあるのでそっち参照．

あとさー，そもそも論として，ソフトウェア工学の研究内容を「現場」と「学術」に2分することが不可能だって分かってる？工学ってそういうもんだろ？その2分は「工学」と「理学」というレベルでは可能なのであって，既に工学にカテゴライズされてるソフトウェア工学を分けるのは不可能だ．それくらいは語の定義レベルの話なんで，分かっててくれ，頼む．