午後はいくつかのセッションがありますが、概ね事例のお話。
Agile とか XP とか Scrum とはいわないけれど、ユーザー企業と開発者の協働体制によってよりよいソフトウェアをリリースできています、というお話でした。最初の総括の部分でも書きましたが、不確実性が高い（要件リスクが高い）開発においては、アジャイル（というより、ユーザーを巻き込んだ開発ですね）重要、という感じです。
そして、成功のポイントとなるのは、やはりユーザー企業の態度、です。要件リスクが高い開発においては、意思決定を遅らせる必要があり、それにより投機リスクよろしく、利得の機会も最大化（最適化）できるというメリットもあるので、そのメリットを享受するために、損失の機会を許容できるか、また意思決定を遅らせた場合に、利得を最大化するための仕組みをいかに用意できるか、というあたりがポイントかと。「仕組み」に関して言うと、単純には開発フェーズでどれだけシステムのエンドユーザーを巻き込み、エンドユーザーにとって優先度の高い機能を実現するか、という点がポイントになるかと。
またその際に、内製化をすすめた良品計画の事例と、内製化せずに対応したリクルートがあるのですが、どちらからも重要なのは内製するかどうかではなく、「100%を求めることではなく、現場を信頼する態度」が重要と感じました。これは一種の「へっちゃらだい！戦略」ですね。その意味で、技術的な正確さを突き詰めるよりも、ユーザーの要求を突き詰めていける態度が、ユーザーと開発者の双方にとって今後重要になる、といえるのではないかと。
ということで、引き続きメモです。
（本間さんのセッションについてはメモできませんでしたが、これも面白いセッションでした。本間さんは、「自分のセッションは時間調整ですから」とおっしゃっていましたが、午後の事例セッションに入る前に本間さんのセッションがあったので、会場の和気藹々度が 50ポイントほど上昇して、後のセッションにつながりました）
スピードがすべてを駆逐する
良品計画のシステム内製化事例
l 良品計画
Ø 15,000アイテム/年
Ø 売り上げ 1454億円
Ø 国内店舗：直営200店、フランチャイズ150店
Ø そのほか、ファミリーマート、キヨスク、海外（100店舗）など。
Ø ネット販売 74億円
Ø 従業員 4300名。
l SPA業態。期間を担うMD(マーチャンダイジング)
l IT戦略
Ø ①「自社の競争力を高める」のか否か
Ø ② すべてに100%を求めない
Ø リスクヘッジではなく、リスクテイク
Ø 本質的な要件定義力を持つ
l システム構造
Ø 「早く柔軟に」開発・変更できる構造
² マスタ類はすべて内製化（管理系システム）
² 実行系システム（POS、物流、勘定システム）などは、仕様が明確になりやすいので外部委託。
² 管理系システムから、マスタデータを実行系システムに配信し、管理系システムは実行系システムから生データを収集する（1時間に1度程度）。
l 内製化の方法
Ø ユニケージ開発手法
² 自社で完結できるシンプルな開発方法
² ミドルウェア、DBシステムは使わない（難・高・灰）
Ø 技術面：コマンド言語だけでシステムを作成
Ø マネジメント面：利用部門は検証力が、開発部門には業務知識が必要
l スピードがすべてを駆逐する
Ø スピード開発の仕組み
² 最初から完璧を狙わず、7割のレベルで早く試作する
² 実際に使って手直しを行い完成度を高める
Ø 「週1回、3回コース」
² 週1回程度、利用部門へモックを提供し、フィードバックを得ながら設計を進めていく
Ø ドキュメントは必要最小限
² ①ユーザー部門のためであること、②ユーザー部門が見て・使えること、③会社組織・業務プロセスは常に変化する前提。
² １部上場企業であるが、監査会社にも上記を伝えており、コンプライアンス的にも問題はない。
l 成果と今後の課題
Ø 「業務改善」への意識
Ø コミュニケーションロスが減った
Ø システム開発部員の育成
Ø システムコストの削減（20億円à12億円。売上高比率 1.8% à 0.9%）
l ちょっとした機能改善を、継続的に
Ø 1日の天気予報 à 1週間に
Ø 今日の誕生花の表示
Ø 店舗から、1週間に500件くらいの改善提案。
l 内製化にしたシステムの稼働状況
Ø ハード60台
Ø 画面数160画面
Ø ステップ数 86600行
Ø システム規模は1/50、パフォーマンスは20倍アップ。
è ここから Universal Shell Programming Lab の當仲さん
l ユニケージ開発手法とは？
Ø パッケージに対して、ユニケージはスクラッチ開発の高効率化手法
Ø Unix Uniq Unify
Ø 「安く、早く、柔らかく」がキーワード
l Shellによるプログラミング
Ø Shell を拡張するためのDSLを内在
Ø 20行程度のCプログラミングで、新しいコマンド(keta, comma)などを用意
Ø Shell で、パイプを使いながら処理をおこなう
Ø 開発環境は vi と cp（コピー）
² 人の書いたコードを使用するときは、written by を自分の名前に書き換える。
² コピー奨励。どうせたいしたコードでないのだから、original の written by は不要。
l ユーザー一体型開発
Ø 業務とシステムは表裏一体
Ø システムは業務にある。
l 非分業のススメ
l ワンプログラム・ワンフロー
Ø 依存関係の排除
Ø 再利用はしない。オブジェクト指向と対極
l 作る側、売る側、使う側
Ø 以前は：（使う側、作る側）、売る側
Ø 最近は：使う側、（売る側、作る側）
Ø 「売る側」、による使う側と作る側の分断。これを解決しないと。
事例：ユーザー企業責任で25歳とをアジャイル開発
リクルート
l 内製化せずに、スケジュールを守って、システムを提供する。
Ø アジャイルでどのように実践したか
l システム部門の組織
Ø 各事業担当と、インフラ担当部門
l Webメディア・サービス
Ø 従来型：新たな情報誌カテゴリを世の中に提案。スタートダッシュ重要。
Ø Webでは：変化が激しく、実際に出してみるまでわからない
l 背景課題
Ø Webでは何が当たるかわからない
Ø そのため、要件を詰め込んでしまう。
Ø そのため、検討時間、開発時間が長期化
Ø そのため、リリースが長期化
Ø 大規模化するために、追加リリースも1年先、といった長期化が引き起こされる
Ø 追加リリースでも要件をどんどん詰め込んでしまう
Ø 負のスパイラル
l 開発方法論やアーキテクチャの変革によりスピードアップ
è サービス開発の「考え方」「やり方」を変える。
l 新しいやり方：SWAT手法(Speedy Willing Alliance Team)
Ø ①スモールスタート (vs 100%の完成度でリリース)
Ø ②ビジネスのコアに絞り込んで検討 （vs もれなく検討）
Ø ③期間と投資上限をあらかじめ設定 (vs やりたいことを積み上げて予算をとる)
Ø ④小規模チームへの権限委譲(vs ステークホルダーとの調整、確認)
Ø ⑤独自のシステム開発手法（vs ウォーターフォール）
l ビジネス・サービスのライフサイクルイメージと使い分け
Ø ①スタートUP：加速 ß SWAT はここで使う
Ø ②成長・拡大
Ø ③成熟
Ø ④衰退
l SWAT方法論自体も漸進進化
l SWATの特徴
Ø 従来型よりもスピードが速い：1500FPで要件定義からリリースまで約3ヶ月
Ø タイムボックス開発
² 仕様の確定はLateBindingな感じ
² Water Fall よりもリスク（投機リスク）が高いが、リスクを許容することで、投資リターンを最適化する。
Ø 1週間単位のスケジューリング、ユーザーを巻き込んだ開発
² ユーザー巻き込みによる後工程（検証、教育）コストを低減
² 仕様の伝達、決定を現場で実施し、オーバーヘッドを減らす。
² ユーザーとの毎週の要件確認会では、実装者が発表をおこなう。ダイレクトコミュニケーション。
² 要件確認会で10分以上議論し、結論が出来ない場合はエスカレーション。
² 事業側、開発側とも、“８０％ルール（仮決め）”、により意思決定をすばやくおこなう。
l 情報を100%もとめず、80%の情報が集まった時点で意思決定
l 80%の完成度で、次の手を判断する。
l ケース
Ø BAD作業中に難易度が高いことが判明 à なんとか実装してよ、の声でなんとか実装 à 次回からは作業見積もりを厳格に出さなければ à 保守的な見積もりと、見積もりの作業の増加
Ø GOOD 作業中に難易度が高いことが判明 à では別の方法でもいいので同じ目的を達成できるように検討しましょう。
l ケース
Ø BAD作業中に機能の絞込みが必要なことが判明 à機能一覧と見積もりを出してください。優先度つけます à 詳細な作業見積もりを作成
Ø GOOD 作業中に機能の絞込みが必要なことが判明 à 大くくりで優先度を指定します。また期日リリースに間に合わせるために落としたほうが良いおすすめの機能提案があれば教えてください。
² SWATでは、要件確認会で、つねに現場メンバーによって作業のスコープ変更に関する判断をおこなうことが求められる。
l SWAT：
Ø 開発をおこないながら、徐々に仕様を決定して行き、「決まったことの量」を増やすことで、先の状況の予測精度を高める。（対極が「決まったことの量」が増えていかないバーンアウトなプロジェクト）
Ø バーンアウトしないために
² ダンドリ重要
² 80%ルール重要
² 人の意識を変えていくこと重要
Ø いずれにせよ「ユーザー企業」の責任、態度が重要。
事例：スピードがすべてを駆逐する Part 2
良品計画、USP
l Q＆A
Ø なぜShell?
² プログラミング言語は難しすぎる。メンバー全員が使用できるのはShell。
² ライブラリ蓄積で、Shell であれば、多くの人が便利に開発できる
Ø 画面は？
² CGIで、Shell で実行した結果をHTMLにしている
Ø 昔は？
² 開発を開始した93年当初はMotif を画面に使っていた
Ø データのやり取りは？
² 基幹DBやPOSデータから、データを取り込み、テキストファイルにしたり、そのままShellでパイプで処理する、という感じ
Ø 良品計画：内製化を進めたのは？
² システム化で時間がかかると、「熱いうちに鉄がうてない」。内製化でタイムリーに。Shellを使うことで、自由度を確保。
² UPSさんとの取引に関しては、担当者が納得して責任を取れるのであればOK、と上司から許可をもらえた。最初は Shellでやる、ということに怖さもあった。
Ø 松田設計って？
² 大阪の松田さん。薬局のボランタリーチェーン(3000点くらいの規模)のオーナー
² 「スピードが速いという価値」と、「情報の価値」は別。商売人は自分の手で、自分が必要とする情報を入手できるようにならなければいけない。
² 上記の思想の元、COBOLとかでなく、バッチで処理をする、データは捨てない（ディスクが増えてもOK）、といった実践。
² 中小企業向けのIT塾を開催。
Ø 内製化と、アウトソーシング
² 重要なのは、何を内製して、何をアウトソースするか、の切り分けをしっかりしておくこと。
² 内製のチームは、業務とシステムの連携、システムの継続的な改善を提供しなければいけない（ルーチンワークで担当していると、業務もシステムもわかっていない人間になってしまう）
Ø ユニケージ手法の展開について
² 拡げるための、教育用の資料などを整備中
² 実績を重ねていく必要。
チームビルディング
永和システム岡島さん
l 「カマスの実験」
Ø カマスは獰猛な魚
Ø えさの前に、ガラスの壁を作っておくと、最初は壁に突っ込む。そのうち学習し、えさを追わなくなる。
Ø ガラスの壁を取り除いても、えさに飛び掛らなくなる。
Ø やる気重要。「ガラスの壁」のメタファ。
l 「開発チーム」と「マネージャ」の緊張関係
Ø 透明の壁をかんじますね、、、、
l アジャイル開発チームに対する誤解
Ø 個人で好き勝手
Ø 組織の成功を軽視している
Ø コードを書くことがすべて
l 開発チームの成功モデル（3つの視点）
Ø 個人的な成功：生活の質の向上、挑戦、やりがい
Ø 技術的な成功：技術的卓越、開発の仕組み
Ø 組織的な成功：無駄の削減、ROI向上
è 個人的なせいこうなくして、組織の成功はない
l マネージャに対する誤解
Ø 組織のルールでがんじがらめ
Ø 人間を軽視している
Ø 売り上げと利益がすべて
l マネージャの成功モデル：２つの価値のバランス
Ø 仕事の論理（生産性）：プロセス、道具
Ø 労働の力学（生き生き）：人間関係、生活基盤、自己実現
l 本質的に開発チームも、マネージャも同じゴールを共有
Ø 仕事の論理 ß 組織的成功、技術的成功
Ø 労働の力学 ß 個人的な成功
l 緊張緩和に向けて
Ø お互いに、成功モデルの本質は同じであることを知り、歩み寄ること重要。
l どうして歩み寄れないのか？ à じつは「透明の壁」は相互に築いているのでは？
Ø 実は、開発者はマネージャに依存している。
Ø 実は、マネージャは開発者に権限を渡したくない。
l 開発チームとマネージャのWinWin
Ø 開発チームの「主体性の発揮」
Ø マネージャーからの「権限・責任」の委譲
l 「グループ」は、各メンバーがそれぞれの役割を果たして共同作業をできるようになって「チーム」になる。
l 「チームは最終状態ではなくプロセスである」
l 「カマスの実験」の続き
Ø 弱ったカマスは、えさを食べない。どうやっても。
Ø そんなときは、新しいカマス、を入れれば、みんなえさを食べるようになる。
Ø チームが停滞したときでも、新しい仲間を巻き込めば、状況を打破できる。
