がるの健忘録 このページをアンテナに追加 RSSフィード

2009-11-18

[][]アジャイル開発の光と影と闇

Manifesto for Agile Software Development(アジャイルマニフェスト)っちゅ〜もんがあるです。

基本非常に素晴らしいので…その辺を「色々と」紐解いていきたいかと。


まずはマニフェストを列挙。

  • プロセスやツールより人と人同士の相互作用を重視する。
  • 包括的なドキュメントより動作するソフトウェアを重視する。
  • 契約上の交渉よりも顧客との協調を重視する。
  • 計画に従うことよりも変化に対応することを重視する。

では。紐解いて見ませう。

光:プロセスやツールより人と人同士の相互作用を重視しましょう。コミュニケーションは大切ですし、プロセスやツールは「それを補助する道具」でしかありませんから。

影:道具に振り回されてプロセス重視にして「そのツールを使う」ために設計をねじ曲げてコケたプロジェクトがどれだけかあることか…

闇:プロセスを大切にしましょう。どうせ結果は「失敗」なのです。そのときにやり玉に挙げられるのは「権力者の独断で決めたプロセスにもっとも従わない憎き人間」がもっとも辛辣に攻撃されるのですから。


光:包括的なドキュメントより動作するソフトウェアを重視しましょう。っつかそも、必要なものはどっちですか?

影:そも「作ってみて初めて気付くミス」もあるわけですし。3手4手5手先までは見る事ができても、投了までを読み切るなんて無理でしょ? そんな無理してるから歪むんですよ?

闇:まずドキュメントを作って、それを承認させましょう。どうせ失敗するんです。「ドキュメントを作った」「ドキュメントにOKを出した」人に責任を取って貰うためにも、微に入り細を穿つドキュメントを作らせて、彼らに責任をとってもらいませんと。


光:契約上の交渉よりも顧客との協調を重視しましょう。お互いがリラックスし、お互いを思いやれればこそ、クオリティも上がるってもんですよね?

影:「契約書に書いてないからやらない」「(どんな無茶でも)契約書に書いてあるんだからやれ」っていう発言が、ギスギスした空気を生むんですよ?

闇:とにかくキッチリと契約書を書きましょう。トラブった時の相手の下品なはしたなさを考えれば考えるほど、文面の文言「だけ」があなたの味方なんですから。


光:計画に従うことよりも変化に対応することを重視しましょう。そもビジネスは水物。それに柔軟に耐えてこそ、ってのは生物の進化とかだって一緒ですよね?

影:だから初手にガッチガチに計画するなとあれほど…。でなければせめて「過ちとわかった時点で過ちを正す」程度の勇気は持ちましょうよ orz

闇:変化? 何をご冗談を。そんなものに対応出来るはずがないじゃないですかお金も払わないくせに。五月雨脊髄反射な修正なんて出来ません。必要なら、予算と仕様をそろえてからまずは打ち合わせ。お話しはそこからです。いずれにしても本来的に「変更は不可」だと思ってください。


えと…我ながら、何が書きたいのやら(苦笑

まぁ。「普段は」光の側の住人ですのでご安心をw


追記:

関連URI's

http://d.hatena.ne.jp/gallu/20080121/p2

http://d.hatena.ne.jp/gallu/20090314/p1

http://d.hatena.ne.jp/gallu/20090316/p1

http://d.hatena.ne.jp/gallu/20090317/p1

2009-03-17

[][]アジャイルは「本質的には」「真っ当な」ビジネスには向いてると思う

んと…

アジャイル批判かぁ。

http://www.milkstand.net/fsgarage/archives/001543.html

予算計画主義とか

http://www.developer0000.jp/2009/03/16/3824/

あたりで取り上げていただいたのでちょっと調子に乗ってみます(笑


とりあえず、若干「現実」から目を半分くらいそらして「理想」に近い部分で考えると。


そも「昨日と同じ今日」など有り得ないわけで、どの程度の粘度かはともかくとして、いずれにせよビジネスは、ある程度流動性を孕む水物だと思うです。っつか流れないビジネスはすでに「死に体」です。

で。

このあたり、別にビジネスに限らず、どこに行ってもそうですが。動かしちゃいけないぶれちゃいけないずれちゃいけない「軸(骨)」と、状況に合わせて柳の枝のように動き増減し変動する「肉」の部分とがあるです。つまりは、ビジネスにも。


軸を決めるのは、多分多くの人が思っている以上に厄介で困難な作業です。ただ、一つだけ言えるのは「軸はかぎりなくシンプルである事」が間違いなく必須。一言で言い表すことが出来ないんなら多分それはまだ練り削りが絞りが足りないです。

で。軸がぶれたサービスほどみっともなくて不可思議なものはないですし、軸がぶれないサービスは、なんだかんだ固定客がつきます。


一方で、肉の部分は「常に変動するべき」ですむしろ。

時間は流れ状況は変動し経験は蓄積され記憶は積み上がり忘却される中。「不変」なんて素っ頓狂なメルヘンを信じるなんてのは正気の沙汰ではありません。

例えば生物を見て取っても。結局、しぶとく生き残るのは「環境適応能力が高い種」です。

環境に適合できなければ、短期的には強いかもしれませんが、中長期をみれば呆れ驚くほどに脆くて弱いです。


故に、アジャイルは、ビジネスに向いています。…もとい。「真っ当なビジネス」に、向いています。

きちんとした「練りこまれ考察された、金剛石のごとき、堅くてぶれない軸」が基準にあるとするのならば。

アジャイルは、どんな変動的で流動的な肉でもそれを実装可能にします。…まぁ「一定の時間単位における限界値」は存在しますが、それでもほかの手法よりはなんぼか。

「昨日とは違う今日」を、今日のロジックで組み直せるのも、アジャイルの優位点です。

ウォーターフォールの、亀のごとき歩みでは到底おいつけない、俊敏なフットワークをビジネスに提供できます。


軸がちゃんと固まってるんならね。


銀の弾丸は存在せず、魔法はあくまでも「別の法則で動く純然たる学問」です。

肉をある程度流動させる手法としてのアジャイルではありますが。

そうは言っても「単位時間あたりの生産性」には限界もありますし。

そうしてなによりも「軸がぶれてたら無意味ってかむしろ危ない」です。軸がぶれぶれにぶれてるんなら、その後の変更がやりにくいウォータフォールのほうがなんぼかマシです。えと…「骨折してるけど外側からギプスで固めてる」感じ?


色々考察を重ねるにつけ…アジャイルで失敗している根幹って、「軸が定まってない」んじゃないかなぁとか考えてしまうのは、うがちすぎでしょうか?

…またいっぱいTBとかくるといいなぁ(笑

2009-03-16

[][]お客様の本音…って…あれ?

元ネタ

アジャイルウォーターフォールだいう前にさぁ

http://shift.cmd-q.jp/weblog/0902/000845.html

プログラム開発手法とプロジェクト管理手法はちがうわな

http://shift.cmd-q.jp/weblog/0902/000846.html


んと…まずは気になる部分をざらりんと列挙しつつ軽く突っ込み。

アジャイルだかウォーターフォールだかどうでもいいよ。

どっちでもいいから、ともかくまずは顧客の要望をきちんとほじくりだして並べてみせてくれよ。

まぁクライアント的に本音ですわな。

顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。

この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初から満足な量の要望なんて出し切れないんだよ?

ここを開き直られると辛いけど…とはいえ、ある程度真実でもあるわけで。

そこを「双方がどう歩み寄るか」なんだろうなぁ、と。

要望を仕様書としてまとめる代わりに、いわゆる「最低限を満たして動くもの」をもってきたとしよう。それに誘引されて顧客側の頭のなかに「どんなものを作るべきなのか」が見えてくるよね。でもそこで「こうじゃなくてこんなのがいい」ってつたえたら「できるけど費用と納期に影響が出ます」って。それはあんまりだよ。もう予算とってプロジェクト走り始めてるんだよ?

限りなくびみょ〜。

そんなのは開発手法以前の問題だよね? 企画意図の共有ができてないなんて開発以前のヒアリング能力の問題だよね?


作らせる側と作る側でどんなものをつくるのか共有できてなくてどうして真っ当なものができあがるんだ?

そもそも作らせる側がどんなものを作ればいいかわかってなくてどうして真っ当なものができあがるんだ?

んと…「お客様がふんぞりかえってる状態」なら、Noと断言する。

システムは(っつか別にほかのものでもそうだけど)、お客様と技術者とのコラボで作られるものだから。

ただ、お客様が最大限努力してなお技術者が歩み寄っていないケースもちらほら見るだけに…必ずしも切り捨てにくい。

顧客側だってちゃぶ台ひっくり返すのはごめんなんだよ。

だからどんなのが出来上がるのか、ちゃぶ台に並べる前に教えてくれよ。

技術者は多分伝えてるんですがね。伝わってないんですよね。

…mock-upとか使うですが、あれでわからないと言われると正直手詰まり感もあります orz

的を射ない要望に対して、ぐだぐだ説明するより動くもん見せちまった方が早いぜ、っていうのは開発者じゃなくても普通にある状況で、事実だと思うんすよね。


けれど、そもそも顧客側(発注側というべきかも)の社内調整ってのは企画立案>承認>>予算提出>承認>>っていうウォーターフォールで進んでる。ぐたぐたいわんと予算よこせってのは当然通用しないし、企画も納期もそうそう手戻りできないんすよ。

なのに、いざ制作段階に入った途端「あじゃいる」とかいわれてもね。開発・実装段階でやるならともかく、設計段階いきなりすっ飛ばしたあげく「手戻り上等ですが予算も納期も手戻りしますよ」じゃそら調子狂うですよ。何か一歩忘れてませんかとか。

さらに、対面のMTGが月イチ×2時間しかないうえ発注受注双方が専任じゃないプロジェクトで、どうやって小刻みなフィードバックフローつくるんすかとか。

そう。結局、ここ。クライアントさんの中でも、彼らは概ね「技術者と上司の間での板挟み」で困るから。


ただ…ここからが…微妙なのですが。

依頼されるものは、大げさに言えば全てが「未知との遭遇」なわけで。

で、割合に多くあるのですが…初期段階で、どんなにかヒアリングしても(営業、接客、販売、占い師の複合スキル持ってるので(全部本職で食ってた経験あり)、相手のニーズの根底まで引っ張り出すのは割と得手分野なんですがね)、正直引き出しきれないんですよ。

理由は簡単で「当人もイメージ全然固まってないから」。

で、いざ納品くらいのタイミングになって、やおら本人イメージ固まっちゃって「いやこうしてくれなきゃ困る」ってそんな限りない後出しされても…ってのは、技術者側の偽らざる本音でもあります。

初期からちゃんとイメージが固まってるんならヒアリングミスで片付くんですがね。…知ってるかぎり、そのケースは稀(0ではない。何度か見てるから)。


まぁ…多分。立案した企画を見せて貰って。可能なら沿うように、不可能なら「どうやって逃げ手を打つか」を提案するのもまた技術者なんですがね。

言い方を悪くすると「間に入ってるWeb担当者さんの言い訳を作ってあげる」感じ。

そこで「相談」されると、多分技術者は味方につくのですが。

Web担当者とかいう人に頭ごなしに怒鳴りつけられたら、責任をそれこそ全部こっちのせいにしようとされたら、多分一言で片付けます。

「御社の発注ミスですが、何か? 契約に明記されている内容ではありませんし、仕様書にも記述がございませんがそれは御社のミスですよね?」

…まぁかくして不毛なバトルに突入するわけです orz


このあたりが。

おいちゃんがいつもいつも「開発ってのは限りなく泥臭くて人間くさい」という理由です。

で。

だからこそ、可能な限り「相談の門戸」はあけておきたいんですよ。希望としては。

でも、ドッチが悪いわけでもない調整ミスやら齟齬やらを「おまえが悪い」って言われてしまうと、相談の門戸を閉ざして、自衛という弓なり槍なり剣なり大砲なり-国連委員会により検閲削除-なりで武装せざるを得なくなるわけで。


そこも含めて。

「密に相談しましょう」ってのが、アジャイルの本質だし、よいところだと思うんですがねぇ。

まぁ。社内政治などがそれを赦さないのであれば。

将棋は一手目に詰めまで全部読み切れるのが御社では当然なんですね?」とか心の中で思いつつ、「アジャイルなんて幻想だ!!」( http://d.hatena.ne.jp/gallu/20080121/p2 )を思い出しつつ、事前に「完璧な準備」を整えましょう。


もちろん「そんな会社から逃げ出す」のもチョイスの一つですが B-p

2009-03-14

[][][]言い当ててるなぁ

結局のところバランスの問題なんでしょうがね。


■[非効率]ウォーターフォール

http://d.hatena.ne.jp/tonotonotono/20090308/1236527471

経由

アジャイルウォーターフォール

http://d.hatena.ne.jp/shivashanti/20090307

こいつは将棋を指す時「詰み」まで読み切ってから始めるのか?


2手3手先とか。熟練者なら4手5手先を読むのは大切。

でも結局「読み切る」なんてのは無理なんだから、ある程度のところで後は「えいやっ」とやらざるを得ない部分が当然ながら出てくる。

…はず、なんですがねぇ。現実を考えると。


おそらくこの辺は「減点主義」が根底にあって。

つまり「全員が横並びで問題を起こさないのが尤も良い」状態で。それこそ「理由の如何に因らず( http://d.hatena.ne.jp/gallu/20080516/p1 )」何か問題を起こしたらその時点でマイナスを付ける。

このやり方って「上司が無能なままで居られる」、おそらく唯一の選択肢な訳ですな。

中身を精査するってぇのはそれなりに技能なり知識なり経験なりがいるのですが。「結果としての問題の露見」は、それこそガキだってわかる。

だから、中身をちゃんと精査するんじゃなくて「最終的なoutputに問題があればNGとする」減点主義のほうが、無能な上司には楽なわけで。


んで。


減点主義であるとするならば、当然ながら「詰みまで読み切ってから初めてもらう必要」が、むしろ不可欠なわけで。

そりゃウォータフォール全盛にもなりますわな。


唯一にして致命的な問題点は「現実に全く即していない」わけです。

まぁ。私も使えるタイミングがあったら使ってみましょうかねぇ。


「詰みまで全部読み切れと、でも?」

2008-01-21

[]「アジャイルなんて幻想だ!!」

アジャイルなんて幻想ですオブジェクト指向なんて偽りです。

変更は容易ではなく軽量な開発なんて存在せず柔軟な設計なんてありえないのです。

アジャイルで簡単プログラミング」とか「オブジェクト指向で変更に耐えられる柔軟なコーディング」とか全部嘘!! 信じちゃいけません!!

すべてはウォーターフォールで流れ、変更は常に重大な問題と莫大なコストを発生させるものなのです!!


…ってことにしとかないとね。

納品の前日に仕様をひっくり返したり納品日になってですら仕様がきまってなかったりして、しかもその上で「出来るでしょ?」とか言われたりするですよ orz


技術者「だけ」の世界観にとって、アジャイルは福音ですオブジェクト指向はレンバスです。

でも、そこに違う人たちが入ってきた瞬間。それは蹂躙対象にしかならんのです。…困ったことに。


うん我ながら「嫌な話だなぁ」とは思うけどさ orz