Agile Japan 2010に参加しました（その２）
「Agile Japan 2010に参加しました（その１） - Jamzzの日々」に続いて個人的に興味深いと思ったことを書きたいと思います。
大規模アジャイル
一般的には大規模のアジャイルは問題であるという認識ですがこの時のパネラーからはその様な懸念の雰囲気はほとんどありませんでした。
また全体的にどうして大規模案件でアジャイルを採用することになったのかという質問に対して「リスクが高いのでアジャイルで」という趣旨のことが当然の様に言われていました。
私自身もこれらの意見に完全に合意なのですが一般の認識のギャップが少し気味が悪かったというのが正直な感想です。
この中で興味深かった発言を挙げておきます。
- 短納期化、新人、派遣のリスクに対応するためにXPを導入することになった
- 規律を重視する
なんでも規律で縛るのではなく誰でもできる簡単な規律を徹底する。
それにより規律を破ることへの心理的抵抗感ができる。
- 作業分担はクジで決める
- うちの（アジャイル）チームは人が入れ替わっても大丈夫だからということで簡単に人が抜かれる
私も人の流動性を高めることはアジャイルを導入する上で意図するところです。
通常の認識ではアジャイルでは暗黙知が重視されるので人は流動化できないと思われていると思う。
- 草の根アジャイルが展開するきっかけは火消しプロジェクト
今から思えば私自身の最初のアジャイルな体験は火消しプロジェクトへの参加だったと思います。
当時はアジャイルなどの考えなどはなく、その私が所属していた組織では燃え上ると緊急体制がひかれたのですが今考えればそれはまさにアジャイルそのものでした。
従来からの大規模開発の議論はプロジェクトの体制のスケールアップの議論がほとんどだと思いますがスケールアップの戦略は程度の差はあれアジャイルでなくてもいつかは破たんする、あるいは失敗時のペナルティが大きすぎるように思います。
そこで私は大規模化はスケールアップではなくてスケールアウトの戦略が必要だと考えています。
それで大規模アジャイルの構造（体制）は例えばスクラムのスクラム等の多段階の構造であり最適な形、すなわちフラクタルを形成するのではないかと仮説的に思っていました。
そこでIBM玉川さんのこの発言を聞いたのでこの仮説に自信が持てました。
- 大規模と日本特有の大人数は違う
IBM玉川さんの指摘通り大規模ということと大人数であるということは次元の違う話だと思います。
確かに大規模というと大人数が一気にというイメージがあるように思いますがそれは日本独特のものなのでしょうか？
必要以上に大人数であるということが非常に悪い影響を及ぼすことは明らかだと思います。
必要以上に大人数とならない様にマネージメントするにはウォーターフォール等よりアジャイルの方が比較的やりやすいように思います。
このあたりのことも自分の中で「リスクが高いとアジャイル」という感覚につながっている様に思います。
この発言で改めて自覚するができました。
- 施主のメタファ
株式会社情報システム総研では委託元を施主と呼ぶそうです。
確かにユーザというよりは将来のユーザであり、実際の設計施工を行うのが委託先であれば思いを持って取り組む立場は施主といえると思います。
- SOAはナンセンス
株式会社情報システム総研の児玉さんによるとSOAはナンセンスでレベルの低い技術者を集めて開発するためのものということでした。
フレームワークもそうだと思いますが、確かに構造のための構造は必ず冗長性が含まれていると思いますが様は意図や目的と合致して効果的であるかということだと思います。
このコンテキストを合わせないと議論はかみ合わないと思います。
児玉さんはSOAが意図するところやそれを採用する目的についてナンセンスだと言っているのだと思いますが個人的にはSOAを否定はしないが合意できる意見です。
- アジャイルは安い？
児玉さんはなぜアジャイルかというと無駄が減って安くできるからということでした。
一方でリスクを軽減したり人材育成の効果が期待できるがコストはほとんど変わらないという意見もありました。
また別の意見としてアジャイルだとメンバーが作業に没頭できる、手待ちがなくなるので安く（？）なるという意見もありました。
日本ではプロフェッショナルが育たない
ソフトウェアエンジニアで仕事ができる人はプロフェッショナルとしてもっと評価されるべきだという児玉さんの主張は全く同意です。
私が人材育成と活動の場の提供のために起業したのもそためです。
IBM玉川さんも米国ではソフトウェアエンジニアのプロフェッショナルとして日本では考えられない報酬で評価されているが日本ではなかなか難しい、少しずつでも変えていきたいという話をされました。
私も微力ながら努力していきたいと思っています。
大手SIerが提供するのは保険サービス
私が思っていたことを羽生田さんが指摘してくださいました。
請負契約には委託先にリスクを負わせることだと考えますがそこには単なるリスクバッファだけではなく失敗の保険料が含まれます。
つまり、
コスト ＝ 請負契約料 ＝ エフォート料（委任契約料） ＋ そのプロジェクトの見積もりリスク料 ＋ 失敗保険料（失敗時引当金）
この失敗保険料はそのプロジェクトにおける失敗リスクに関する費用ではなくて、委託先企業の中で他の案件等も含めてリスク想定を超える失敗時のコストに充当される費用の保険料になります。
この失敗保険料は委託元にはあくまでもそのプロジェクトにおけるリスク料に見えますが実態は上記のとおりです。
これを委託元が適切にリスクをとることで
コスト ＝ 委任契約料（エフォート料） ＋ そのプロジェクトのリスク負担実費（＜見積もりリスク料）
となって安く早くできる可能性があります。
ただリスクを取りたくない、任せたい、丸投げたいというお客さまもいらっしゃると思います（実際に多い）
その場合には高い保険料を払ってでも安心できるところに任せるということはもちろんあると思います。
ユーザ企業のアジャイルに対する期待
事例セッション「官公庁でも取り組み始めたアジャイル！」の山形県の事例ではユーザ側の山形県庁とベンダ側の双方がそれぞれの立場で別々に発表されました。
通常はこの様な場合には事前に整合されていると思うのですがこの時の発表内容では典型的な認識のズレが見れて個人的にとても興味深かったです。
例えば山形県庁では最初の案件をアジャイルで実施し後、次以降の案件でもベンダーに対してアジャイルによる実施をリクエストしたがベンダ側の提案はアジャイルで無く、その後は一度もアジャイルを実施していないということでした。
他にも山形県庁の考えではオブジェクト指向による設計を進めたいということでそのためにアジャイルでお願いしたいという話でした。
結論を書くとやはりユーザにとっては信頼できて効果的であればその中身はほとんど関係ないということだと思います。
私自身も何度も何度も間違ってしまうのですが、ユーザに中身を一生懸命説明しても仕方がなくて何がどうなるのかという結論を説明しなければならないのだとつくづく思いました。
お役所仕事へのプロジェクトファシリテーションの適用
事例セッション「官公庁でも取り組み始めたアジャイル！」の佐賀県の事例は面白かったです。
この発表の内容と発表者の佐賀県庁の東さんは懇親会でも非常に話題になっていました。
アジャイル的なプラクティスを一般的に堅くて保守的だと思われる地方自治体のお役所の通常の業務に適用して目覚ましい成果を挙げられたということです。
ソフト（やわらかい）の開発現場がお役所より堅く保守的なのがなんとも言えないです。
成長する組織へ導くコミュニケーション変革
ツール・環境編と組織・意識改革片がありました。
- プロセスには始めから監査できる仕組みを組み込んでおく
アジャイルではツール、特にITツールは重視しないということですが個人的にITツールで重要だと思うのはこの点だと考えています。
メトリクスは重要（判断は定性的）だと思うのですが計測のためにチームメンバに負担をかけてはいけないと思っています。
なのでチームメンバがプロセスの中での自然な流れの中で必要なメトリクスが自動的に収集できる仕組みは重要だと思っています。
この点がITツールを活用するべき重要な点だと思っています。
- 事務局が重要
確かに指摘の通りだと思います。
しかし私の立場としてはアジャイルにおけるスタッフの位置づけ、あるいはそもそもスタッフの様な立場は必要かどうか、障害にならないかなど、悩ましいところだと思います。
新たに宿題をもらった気分です。
私も頑張って媒介（徘徊ではない）に努めたいと思います。
- 指示を与えるからサインアップへの転換
例えば誰もが嫌がるタスクをだれが取るのかなど、意識の問題として最も典型的で具体的な現象としてこの問題があると思います。
意見としては西村さんから「リーダが率先してとる」、平鍋さんから「週刊MVPを設けて表彰する」等の意見がありました。
別のセッションでの評価制度の話もありましたが成果主義ではなくてチームへの貢献による評価を取り入れるべきだと思っています。
クロージングキーノート「新時代の開発プロセスに向けて」
豆蔵の羽生田さんによるクロージングキーノートです。
平鍋さんの導入の話で「羽生田さんはいつも自分の前にいて導いてくれた」という趣旨の話をされましたが私自身ももっぱらC言語で開発していてオブジェクト指向にあこがれていた時から自分の興味の先にはいつも羽生田さんがいらっしゃって様々な知識や経験、そして見識をいただいてここまで導いていただきました。
このキーノートの話ではソフトウェア工学を軸にこれまでの歴史と背景を改めて確認することができました。
そしてこれからについて示唆をいただきました。
そして結論は「みんなでわいわい楽しいな。海外の人と交流して。みんなで楽しく進めるのなら、金や役職なんかに興味ないもんね。」でした。
羽生田さんの言葉としてとらえるととても深みのある言葉だと思いました。
発言の中で興味深かった点を挙げておきます。
歴史を振り返って時間軸でみるとプロダクトあるいは技術重視の波とプロセス重視の波が重なりあうところにアジャイルがあるのではないかと話でした。
また暗黙知を肯定し活用するという意味で精神性・身体性を発揮する場の重要性を指摘されました。
- 無知による再発明の無駄
コンピュータサイエンスの教育、実践の問題による無知により再発明の無駄が繰り返される現状をしてきしました。
- 良いアーキテクチャとは何か
良いとは何かを問い直す必要がある。
そしてそれは現場の中にactualなものとして考える必要がある。
- 急がBa（場）回せ
場の上で人が回るのではなく場が回っているという地動説（場動説？）。
アジャイルなBa（場）とは早く良い方向へ向かいながらスパイラルに回ってゆく場である。
- パタンランゲージの可能性
アジャイルな場におけるコラボレーションのためにはパタンランゲージの活用が重要となるであろう。
言葉で尽くせないことを表現しようとしてとても長いレポートになりました。
まだまだ表現しきれてない感がありますがきりがありませんのでとりあえずはこれぐらいにしておきたいと思います。
また思うことがあれば書きたいと思います。
最後になりましたがこのような場を共有できた皆さんに感謝の意を表明したいと思います。
ありがとうございました。
