勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

2012-05-15

いいアジャイルは死んだアジャイルだけだ

大手ベンダーがアジャイル検定を始めるようで、これについてはいろいろな意見が出ているようだ。「これはアジャイルじゃない」というような意見もあるようだけれども、「いいアジャイル」も「悪いアジャイル」も無いと思う。むしろ「いいアジャイルは死んだアジャイルだけだ」と考えている。釣り気味のタイトルだけれども。

もし、ファストフードのような開発をアジャイル開発と呼ぶのであれば、私の中で「アジャイル」は死んだも同然です。言葉の定義なんて変わるものだし、正しい定義を振りかざしても仕方がないのはわかっていますが、バズワード化するというのは、こういうことですね。
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない - Social Change!

アジャイル開発は、官僚主義的な計画駆動型のソフトウェア開発へのカウンターカルチャー的な側面があると思っている。これが一般化(バズワード化といったら悪く取り過ぎだ)して、日の当たるところに出て来ると「いいアジャイル」とか「悪いアジャイル」と批評するのはIT業界的にはどうかと思う。

私は「アジャイル」という用語に懸念を感じるようになった。今や過剰に使われ過ぎている。いい開発者はこの言葉とその含むところをすっかり避けるようにした方がいいと思う。「アジャイルプログラミング」の2つの形態について話したが、(まったくちゃんとした)第三のものがあり、それはテクノロジーを使って生産性の向上(つまり「アジャイル性」)を達成しようとするものだ。「Ruby on Railsによるアジャイル開発」とか、「アジャイルAJAX」とか、あるいは「アジャイルC++」というのまである。これらは私の持っている本の中でもごくしっかりしたものなのだが、「アジャイル」という言葉の乱用に拍車をかけている。

そして巷にあふれるアジャイルの多くは、率直にいって悪いアジャイルだ。
いいアジャイルと悪いアジャイル

先行者利益は無くなっていく

大手ベンダーがファーストフード的な「アジャイルなんとか」を推進したとして、私は個人的に面白いと思う。

  • 保守開発もたくさん実施していて、そこにアジャイル的な知識が核融合してそれなりに成果や利益が出てしまうかもしれない
  • 会社の規模が多いので、やっぱり優秀な人もそれなりにいて、その人たちがもの凄い勢いで案件を成功させてしまうとか
  • ビジネス上の問題で(ソフトウェア開発とは無関係に)失敗するようなニュービジネスではなく、更改案件などで十分な素振りができるかも
  • そもそも案件数が多数あるので、アジャイル適用度を図りながら実施案件を選べる。うまくいかなかったら、既存プロセスに切り替えるだけでいい
  • 批判されがちなSI業界だけれども、硬直しているのはベンダ側だけでなく、ユーザ側もそうだ。そんな所に新風を吹き込ませるとか

まぁ、いずれも楽観的な予測だとは思うけれども、どちらにせよ裾野が広がっていくのは良いことではないのだろうか。

少なくとも下克上的、逆転の発想でもあった「アジャイル開発」が主流化していくことで先行者利益は無くなっていくのではないかと思う。

2012-04-26

朝会を進捗会っぽくしない

朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。

朝会のミニ進捗会化

InfoQ: デイリースタンドアップ/スクラムはスクラムマスタのためのものではない

そもそも朝会のようなコミニュケーションの場は特殊で、(日本人にとって)普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有(先生や上司の話を聞く)かボトムアップの報告(上司やリーダーに報告連絡)だから、放っておくと朝会もそうなりやすい。

うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わった気になってしまっている(ノートPCやスマートフォンに注意がいってしまう)。これだと朝会はコミニュケーションの場として成立してすらない。

情報を引き出して共有するファシリテーターをする

たとえば私は朝会がミニ進捗会っぽくならないように、よく以下のような発言をする

  • メンバーの発言のあいだに
    • いまの●●ですけどみんなわかった?
    • いまの●●についてもうすこし解説してもらえない?
    • ●●ってけっこう影響があるんじゃない?影響あるひと!(挙手を促す)
    • いまの●●について誰か付け加えることない?
    • 他の方法ってないのかなあ。どう?
    • その作業って無くせないの?
    • 早く終わらせるためのアイデアってなにかない?
    • いまの報告にコメントない?
    • 反論ない?

要は呼び水になるようなコメントをして、ちょっとした議論や情報交換を促すのである。なお、正解を知っていても出来る限りは発言を我慢して議論にまかせるのがいい。

それでも雰囲気が改善されないときは、サクラで喋る人を仕込んで、誰かの発言の後にサクラと一緒にちょっとした会話のキャッチボールをしてみてもいい。

日本人的なメンタリティだと、常に「正解を言わなくちゃいけない」「誤りをいうと減点」といった空気が出がちなので、これを、どうやってうち崩していくのかがポイント。

以前に書いた朝会に関する記事

2012-04-24

ソフトウェア見積もりとステップ数のこと

そういえば、「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」に「ソフトウェア見積り―人月の暗黙知を解き明かす」が入っていなかったのが気になっていた(「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」はちゃんと入っているのに)。

ステップ数見積を見積工程の成果物にすると、計画を立てずに物事を進めるということにつながりやすいので、いけませんよということです。
生産性とかアジャイルとかフレームワークとか言語とかも大事だけど、見積をちゃんとやるのはすごく成功に寄与するよ。
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - 山本大@クロノスの日記

以下個人的な見解。

  • ステップ数見積もりは思考停止ワードの一種なので、まずこの単語が出て来たらかなり注意する
  • ステップ数見積もりを行うこと自体は悪いことじゃない。ただ、ソフトウェア規模を図る方法の一つであって、工数とかコストを見積もるためにステップ数見積もりを行うのはかなり乱暴
  • 同一の言語、アーキテクチャ、ドメインといった条件が揃えばステップ数見積もりはそれなりに正確にできるかもしれないけど、条件がちょっとでも変ればあまり意味は無い
    • ソフトウェア保守のような局面では、ステップ数見積もりはかなり高い精度で出来るかもしれないけど、やっぱり工数とかコストの見積もりには繋がらない。テストなどの兼ね合いで、ステップ数と工数は単純に相関してないから
  • じゃあ何の為にステップ数を見積もるのかというと、他の手法で行った見積もりを検証したり、他のプロジェクトと比較をするため。要は検算目的
    • 何かの見積もりロジックや計算式がバグっていないかを確認するために時々使えることがある
    • メンバーのひと月あたりの作業量などに割り戻して、「ありえねー」作業量になっていないか確認するとか

コード行という指標は、ソフトウェアの規模を測るにはまったく適さない方法である。ただし、規模を測る他の方法よりはましである。それにもかかわらず、多くの組織では、過去のプロジェクトの規模を測定したり、また新しいプロジェクトの初期の見積りを作成するために、コード行という指標を相変わらず馬車馬のように使っている。コード行はソフトウェア見積りの指標のリンガフランカ(共通語)である。この指標の限界さえ覚えておけば、手始めとしては適しているだろう。
ソフトウェア見積り―人月の暗黙知を解き明かす

最初の一歩であってもいいけど、最後の決め手につかうのはだめだ。

2012-04-22

アジャイル開発に求められる人材像に関する雑感

前回のエントリの反応を眺めながら、そういえば「プロジェクト・マネジャーが知るべき97のこと」でこんな事が書かれていたのを思い出した。

アジャイル開発チームのための技術者を雇うとき、どんな素質が必要だと思いますか? それは幼稚園でうまくやっていくスキルと同じです。

  • ほかの人とうまくやっていけるか?
  • みんなと仲良く遊べるか?
  • 遊ぶのをやめるとき、きちんと後片付けができるか?
  • 新しいことにワクワクするか?
  • 学ぶことが好きか?

プロジェクト・マネジャーが知るべき97のこと 

(あとこちらも参考に。プロジェクト現場の幼稚園化:An Agile Way:ITmedia オルタナティブ・ブログ

または、「アジャイルサムライ−達人開発者への道−」ではこんな記述もある。

いつの日にか、誰もがこんな働き方をするようになるだろうか? まさか。みんながみんな、食べ過ぎをやめて運動してるわけじゃないのと同じだ。警告しておくと「お客さんに価値ある成果を毎週届ける」というのは、気弱な人にはおすすめできない。たとえるなら、アジャイルに開発するというのは、これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚だ。もはや隠れる場所はない。価値を生み出すか、生み出さないか。二つに一つだ。
アジャイルサムライ−達人開発者への道−

これまでの就職や就社では「賢い」ということが重視されてきたのだと考えているのだけど、これからは「賢いプラスアルファ」が必要ということなのだろうか。じゃあ、アルファの部分に入るのは何なのだろうか。

  • コミュニティ適応性?
    • 「協調性」というキーワードだとしっくりこない。
  • チャレンジ精神?
  • 情熱?

社会人基礎力

上記を考えながらネットを眺めていて知ったのだけれども、経済産業省では2006年から「社会人基礎力」というのを提唱しているようだ。

「社会人基礎力」とは、「前に踏み出す力」、「考え抜く力」、「チームで働く力」の3つの能力(12の能力要素)から構成されており、「職場や地域社会で多様な人々と仕事をしていくために必要な基礎的な力」として、経済産業省が2006年から提唱しています。企業や若者を取り巻く環境変化により、「基礎学力」「専門知識」に加え、それらをうまく活用していくための「社会人基礎力」を意識的に育成していくことが今まで以上に重要となってきています。
社会人基礎力(METI/経済産業省)

これはソフトウェア開発に限った話題ではないのだけれども、やはり世の中的にも人材に求められる事が変ってきたということなのだろうと思う。それどころか、従来の「賢さ」に加えてさらに様々なものが追加で求められるようになった、ハードルが上がったとも言えるのではないだろうか。

しかし「コミュニティ適応性」でも「情熱」でも「社会人基礎力」でも、何かのトレーニングで簡単に獲得できるようなものではないのが気になるところ。このところ大手サプライヤーでも人材転換の話題が出ているが、これで自社人材に簡単にプラスアルファの力がつくとは思えない。ハードルを上げてふるい落とすといった方向となってしまうのではないだろうか。

追記(2012/4/23)

ブログでコメントいただきました。

2012-04-19

ウォーターフォールのほうが楽だという話

わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い(プロジェクトマネージャーの立場で、スクラムマスター的に推進)。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。

アジャイルの前のほうが楽だった?

「第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。

他にも似たような情報があるかと思って調べてみると、興味深い記事も。

確かに、アジャイル開発は全ての人に向いている方法では無い。

短い期間で結果をだし続けなければいけないのは想像以上に大きなプレッシャーだと思う。
ウォーターフォールだと期間も長いから少しずつリカバリしていくことが出来た。理論上は。
実際には問題はどんどん積み上っていくばかりだったけど。

アジャイルはその問題を先に見せて、場合によっては毎週のように怒られるのだろう。
それはやだなぁ。
パブリックなメモ : 『アジャイルサムライ』を読んだ

それはいやだ。

日本でよく言われるのが、「期日までに使わない(と思われる)機能も全部作れ、契約だから」とか。限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまう。このような状況が続けば焼畑農業のようにチームには何も残らなくなる。
[Agile][翻訳]ゴールを決め過ぎてしまうことによって陥る罠 | Ryuzee.com

開発プロセスの変化で何が変わったのか

アジャイル開発が、従来型(?)のウォーターフォール型・計画駆動型の開発プロセスと変わった点はなんだろうか。思いつく限り列挙してみる。

  • リリースサイクルが短くなり、常に本番のプレッシャーにさらされる。
  • 常に顧客の近くにいることになる。
    • 実際には週に1回会議でしか会わないとか、間にちゃんとPMが入って緩衝材となる場合も多いようだが。
    • オンサイト(いわゆる常駐型)なのかにもよるか。
  • 数日といった短いサイクルで設計、プログラミング、テストの作業を行う。短い期間でさまざまなアクティビティを行う。
    • これがキツイかもしれない。マインドセットの切替も必要だし、「今日は調子が悪いので機械的に作業するか」というわけにはいかない。
    • 毎日がテスト、と考えると気持ちは重たい。
  • コミュニケーション重視。
    • あとでゆっくり確認するとか、時間をかけて考えるタイプの人にはストレスかもしれない。
  • 自分の作業が終わったらすぐにオープンにする。
    • 手元において、数日の間を置いておくといった行動はしにくい。
  • 毎日成果が求められる。
    • 別に非アジャイル開発でも成果は必要なんだけど、「今日の成果」を毎日求められるようになるのは強いプレッシャーかもしれない。
  • 業務時間内の学習がしにくい。
    • 実際にはそんなことはないと思うけれども、毎日の作業プレッシャー下でどうどうと学習や研究をするのは憚られるような気がする。
  • マイクロマネジメント風。
    • これも実際は違うのかもしれないけど、毎日「自分の作業について語ったり」「人の作業にコメントする」のは一種のコマンドコントロール型マネジメントと似ている側面もある気がする。言う人がマネージャーから同僚に変っているけど。
    • 放っといてくれタイプの人はむかない?

前述の通り不確実性の高い状況下において「達成」に関する約束をすることは難しいが、一方で個人による努力ではなくチーム全員が同じゴールに向かって最大限努力することは約束できるだろう。誤解して欲しくない点として、これは長時間労働や休日出勤をするという意味ではないということだ。アジャイルな開発の特徴は、リソースと時間を先に固定し、その範囲内で最大のビジネス価値を実現するものである。固定された時間の中で成果を出さねばならない。そしてその努力の中には、自分達がより良い成果を早く出せるようになるために、チームで継続的に改善を行うことも含まれるのである。
[Agile]コミットメントとは何か? | Ryuzee.com

常に最大限努力はつらい。

2012-04-09

要求開発のホームグラウンドについての考察

要求開発はソフトウェア開発の企画・要件定義向けの方法論ということになっている。しかしわたしはこれが適用できる領域は限られていると考えている(詳細はこちらのエントリを参照)。では、要求開発が適用できる分野はどこか。

要求開発のおさらい

本論に入る前に、いくつか要求開発のエッセンスをさらっておく。詳しくは以下の書籍やサイトも参考に。

要求開発のことを一言で言うと「企業の経営者・業務担当者・システム部の3者で、後のソフトウェア開発の結果が予想出来るくらいまでイメージをすり合わせて合意する(工程)」になる。逆にいえばイメージが合意できていないとソフトウェア開発はうまくいかないということだ。要求開発のコンセプト資料は公開されているのでそこから抜粋すると、要求開発が念頭に置いている失敗パターンがわかる。

たとえばトップダウンで強力に推進して失敗するパターン。大きめの流行りのパッケージソフトウェアやバズワード的なものが目に浮かぶイメージ。f:id:kent4989:20120409155017j:plain

逆に現場に擦り寄ったシステム開発をして現状最適に過ぎて、目的を達成できないパターン。経営レビューあたりでちゃぶ台をひっくり返されそう。f:id:kent4989:20120409155036j:plain

このような失敗を避けようというのが要求開発の狙いの一つで、経営・現場・開発の三位一体で取り組むことを「要求を開発する」といっているのである。f:id:kent4989:20120409155047j:plain

もう一つあわせて紹介したいのが次のスライド。
f:id:kent4989:20120409155114j:plain
なぜわざわざ「要求を開発する」必要があるのかというと、ベンダーに相対するシステム部の担当者も、すべてが見通せているわけではない。ステークホルダー各人の頭の中にあるシステム像は違っていることがしばしなのである。だからこそ、三位一体でシステム像を改めて可視化することが重要なのである。

ここまで読んで「なるほどそうだ」と思えるのか、「そこまではやらなくても」と感じるか。人それぞれだと思う。それは、要求開発が念頭に置いている前提と読者の環境がどこまで近いかによって変わってくるのではないか。

要求開発のホームグラウンド

要求開発が念頭に置いているものは以下の点だと思っている。

  • 複雑度が高いエンタープライズ系のシステム
  • (人系を含む)ビジネスシステムのリプレース
  • 対象企業の規模は大きめ

複雑度が高いエンタープライズ系のシステム

対象システムの複雑度はまず高いものを念頭に置いているのは良いだろうと思う。そもそも要求開発という工程を追加して構築するソフトウェアを可視化することが必要な複雑度が無いと、要求開発する必然性があらわれない。多部門や多システムと連携しつつ利害関係を調整や合意形成をするといった局面が必要でないなら、あまり要求開発の用は無いような気がする。

要求開発の構想の背景のひとつに、大規模システムの要件定義〜設計フェーズを人海戦術・御用聞き型で突入していく(当時の)大手SIerのイメージがある。大量にドキュメントを作成したあとにコンセプトレベルの見落としや誤りによる手戻りが発生することを、前工程でコンパクトに対策するというのが要求開発の内なる狙いなのではないだろうか。

(人系を含む)ビジネスシステムのリプレース

基本的に想定されているのは既存システムまたは業務のシステム化(ここで言うシステムはITシステムに限定した話ではなく、ヒト・システム混合の業務システム)である。なぜなら企業内にまったくノウハウの無い新規ビジネスであれば、関係者でそもそも『要求を開発』できない。
f:id:kent4989:20120409155132j:plain
例えばマス顧客向けのWebサービスを開発するのであれば、組織内の利害関係者間で『要求を開発』することよりも、素早くシステムをリリースして少しずつ改善するといったアプローチのほうが適しているだろう。スタート時点のゴールイメージを共有するために要求開発的な手法を一部適用するなどの工夫は可能かもしれないが、『要求を開発』するといったイメージとは少し異なるのではないか。

対象企業の規模は大きめ

要求開発は、ソフトウェア開発のための要件定義工程を手厚くする(もしくは要件定義の前工程を行う)ということになる。当初の発想では『ビジネスコンサルとベンダーの間の領域を埋める』もあり、やはり(最近はあまり聞かないような気もするが)ビジネスコンサルを活用するような対象希望にフィットするイメージがある。
f:id:kent4989:20120409155144j:plain
また複雑度のところで述べたことと重複するが、多部門や多システムと連携しつつ利害関係を調整や合意形成をするような状況が無いのであれば、要求開発の用は無いのだと思う。

要求開発の出自などを踏まえて、改めて要求開発のホームグラウンドについて考えてみたが、やはり適用範囲については限定的であると考えている(こんな事を書くと諸氏から厳しいご意見もいただきそうだが)。もちろん、要求開発に含まれる各種のプラクティスや原則にもそれぞれ特徴やメリットも大きく、それを個別にプロジェクトに活用するといった話は充分にあると思う。しかし、トータルパッケージの「要求開発」を導入するかについては、手法ありきではなくプロジェクトのホームグラウンドがどこにあるのかという点について充分に考察する必要があると思う。

参考

要求開発~価値ある要求を導き出すプロセスとモデリング

要求開発~価値ある要求を導き出すプロセスとモデリング

  • 作者: 山岸耕二,安井昌男,萩本順三,河野正幸,野田伊佐夫,平鍋健児,細川努,依田智夫,[要求開発アライアンス]
  • 出版社/メーカー: 日経BP
  • 発売日: 2006/03/02
  • メディア: 単行本
  • クリック: 13回
  • この商品を含むブログ (18件) を見る

2012-04-05

上流工程の失敗カタログ

他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。

「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む

「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。

  • 本来あるはずのレアケース、例外に関する要求が出てこない
  • 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない
  • 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手段がない
  • ステークホルダーによって要求が異なったり、ステークホルダー間で要求が矛盾したりする
  • 複数の要求提供部門が存在し、一方の要求を満足しようとすれば他方が成り立たない
  • 業務用語知識の欠如
  • IT動向や他社事例を参考に、自社システムの実態とは乖離した要求をされる
  • システム化の目的よりも手段が重視され、顧客の真の要求が引き出せない
  • 画面の細部に顧客の注意がいってしまい、本質的な要求でないことに発散
  • 顧客予算に限りがあり、設計書を作成し仕様を確定してから実装をしては間に合わない
  • 計画段階での要求発散や確定漏れ
  • 経験者によるレビューを受けずに要件定義書を作成し、統合テストの段階で仕様にはない日機能要件を要求されて大きな手戻り
  • 要求を獲得した段階で開発規模を示す必要があるが困難である。顧客側にとってもその良否を判断するための手段がない
  • ユーザのビジネス要求の優先順位と要求に対するシステム化の優先順位が異なる
  • 利害関係者からシステム化に伴う費用対効果を求められる
  • 課題に対する原因を検討する方法がわからない
  • 要求の分析が不十分であるにも関わらず、予算や納期が先行している
  • 顧客のシステム導入経験があまりない

さて、上記の状況でどうするかを考える事はできるだろうか。以前に失敗から学ぶというエントリも書いたのだけど、こういったトラブル事例などを見て「考える」というのが重要だ思っている。これらの事例を一般化して方法論が作られたりするのだけれども、一般化した時点で学びにくさや使いにくさというのが生まれてしまう。

上記例については「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF)に対策例が出ているので答え合わせをしてみても良いと思う。

リスクを予測して最小限度の手を打つ

あるべき姿は自分のプロジェクト固有のリスクを特定して、コンパクトに対策を講じること。不勉強だったりトラブルを恐れて「ベストプラクティス全部入り」を目指すと、やらなければならないことが多くなりすぎて個々の検討や分析が浅くなりすぎ、結局トラブルとなる。体系化・一般化された方法論は「ベストプラクティス全部入り」になっていることが多いので本当に注意が必要だ。

残念ながら、それほど自信も専門知識もない開発者や顧客やマネージャは、計画や仕様や標準を一式すべて作成しておいた方が安全だと考えがちである。ここに至ってある種のグレシャムの法則(「悪貨は良貨を駆逐する」)が働き、最も専門知識に乏しい参加者が先頭に立って、必要な部分だけに絞り込むこともなく、文書一式すべてを作成する方向にプロジェクトを押しやることになる。
アジャイルと規律 ~ソフトウエア開発を成功させる2つの鍵のバランス~