【読書】システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意

モニターということで、ソフトバンククリエイティブ様より御本を贈って頂きました。ありがとうございます。

まだ隅々までは目を通しきれてはいないのですが、いま読んでいて思ったことなど書いておきたいと思います。



■はじめに

この本の最後の章には次のような記述があります。

・本書は共通・文書化などを取り上げているため、「ウォーターフォール」型開発に関する書籍だととらえられてしまうのではないかという危惧を抱いています。 

・本書ではあえて設計や文書化の方法に多くの説明を行っています。これは、「設計要素を知っていて文書や記述を削る」のは適切な行為だと思いますが、「設計要素があることを知らずに文書や記述を削る」のは品質やプロジェクトの遂行に対してマイナスの要素をもたらすと考えているからです。 

・アジャイル開発では「設計はしない」「設計書は書かない」ととらえているとしたら、それは誤解です。アジャイル開発においても当然設計は行います。

この本自体は、要求から始めて段階的に設計を詳細化していくというスタイルで記述されており、一見するとウォーターフォールなソフトウェア開発における上流工程のエンジニアリングについて書いてあるように見えます。

しかし、先ほど引用した文章に書いてあるとおり、著者の意図は『この本に書いてある順番どおりに設計プロセスを進めて欲しい』ではなくて、あくまで『各種設計フェーズにおける検討事項や設計する際のポイントについて理解してもらいたい』なのです。

ここを押さえて読むのと押さえないで読むのとでは、だいぶ受ける印象が違うと思います。

※なお、3つ目の引用では、アジャイルと設計・ドキュメンテーションの関係について触れているのですが、この点はとても大事だと思います。大事なことなので繰り返し書きますが、アジャイルなソフトウェア開発でも設計はするし、必要なだけのドキュメントは書きます。



■感想

システム設計についてこれから始める人にとってはいろいろ便利な本なのかなーと思いました。

タイトルにあるとおり、この本はシステム設計についての本なので、システムを構築するにあたっての知見がいろいろと詰めてあります。例えば、要件定義から設計の間にやるべきこととして、次のような作業を上げています。

●全体設計
・システム境界図
・システム俯瞰図
・サブシステム連携概要 

●アーキテクチャ方針
・オンラインアプリケーション方針
・帳票出力方式
・ジョブ管理・実行方針 

●標準設計
・文書テンプレート
・記述粒度・ガイドライン
・設計基準 

●共通設計
・画面共通
・帳票共通
・バッチ共通
・DB共通
・メッセージ共通

割とがっつりと検討してますよね。で、この"がっつり"という点が個人的には重要だと思っています。

例えば、システム設計について経験したことが無い人がその辺りの知識を自主的に学ぼうと思った場合を考えます。個人的にちょっとしたツールなどを作るときに、設計などやってみて知見をためるというのは1つの優れたやり方ではあるのですが…　こと設計については話がやや異なると思っていて、それは"ちょっとしたツール"という規模だと、上述したような質・量で事前の検討はしないと思うからです（してもあまりメリットを実感できないと思います）。つまり、そこから学ぶことができるはあくまで"ちょっとしたツール"の規模の複雑さと、それに応じた設計までにしかならないということです。

あるいは、自主的に学ぶのではなく実際にシステムを作るときに失敗などを経験し、そこから学ぶのもよいのですが、現場で失敗するのはいろいろとおいしくないし、それよりは先人の知恵から学んだ方が良いわけで、そういう意味でこの本は便利だなーと思いました。


で、この本を読む時、成果物として定義してあるドキュメントの書き方からそのまま覚えていくという、ストレートな学び方もありだと思うのですが、ここまでかっちりしたドキュメントが必要となる現場はともかく、そうでない現場にいる人であれば、もう少しエコに読み進めていくのが良いとも思います。

システムの構築を行う際にその設計が求められる理由や、その設計を行うことによってどのようなリスクを事前に考慮できるのかなど、そういった観点に立って読んでいくと良いということです。


また、粒度や方針・整合性といった、一貫性のある設計をするのであれば否応なしに意識せざるをえない観点について、繰り返し記述が入っているのも良いと思いました。そういうのは大事です。

設計における一貫性を検討しない（設計思想がない）まま実装を始めてしまうと、やはり当然というか、コードからは設計レベルにおける意図が見えてこないような成果物ができてしまうだけなので…　やはりそういうソースは保守していくのも面倒だし…



■最後に

この本はオブジェクト指向やドメイン駆動なアーキテクティング・デザインについての本ではないと断ってあるのですが、OODやDDDから始める場合だってオブジェクトを永続化するのに使うのは大体の場合DBなわけで、そうであるならI/Oやトランザクションについて検討するのはやはり重要なわけです（この本に書いてあるような事柄を検討しないまま実装するとだいたい後で酷い目に会います）。

この本は、そういう意味でも"開いた"内容になっているので、この本に書いてあることがズバリ当てはまるような業務系のSEだけではなく、広い意味で設計に関わっていくような人はまず押さえておくとよいのかなーと思いました。

個人的には、手元においてハンドブックみたいに使おうかなーと思っています。

Scrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』ノート（後半）

2012/01/16に開催されたScrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』のノートです。こちらは後半部分です。



（前半の続き）

■野中氏の講演

◆実践知・ジャッジメント・コンテキスト

◇全てを総合するリーダーシップ = フロネティックリーダーシップ
・フロネシスの語源
　→ギリシャ語
・実践知
　→賢慮(Prudence)と実践的な知恵(Practical Wisdom)を併せたもの
　→文脈で使い分けられる
・ハーバードビジネスレビューにこれに関する論文を書いたとき、日本の経営者を中心に調査した
　→こういうのもは日本が得意だと思う
　→→日本の組織には、一丸となって知を生み出していくというDNAがあるのではないかと思っている

◇知の生態系は不確実
・そんな中でのイノベーションには実践知のリーダーシップが必要
・ワイズリーダー
　→さまざまな円環の中で持続的に知を作り続けるリーダーシップ
　→文脈を読みながら絶えずSECIプロセスを回し、触発・支援・蓄積ができるリーダーシップ
・個別を離れた普遍の知はなかなか存在しない
　→観念論としてはあるかもしれないが、実践論としては？
　→「何が本当か？」はその都度のコンテキストの真っ只中で判断できないといけない
　→→身体性を伴うということはそういう意味で重要
・個別具体の文脈で"Just Right"な判断をしていかないといけない
　→単なる改善ではない
　→大きなビジョンやイデアが関わってくる
　→→そういう志を持ちつつ、現実の中でのジャッジをする必要がある
・最初から演繹的な絶対的な真理からブレイクダウンしていくのではない
　→これはウォーターフォール的かもしれない

◇実践知の考え
・どういうものか
　→『イデア（顧客の思い）がある』けど…
　→『それがあると信じる』けど…
　→現実の中で一緒になって、皆の英知を結集してベターに向かってやっていく
・行為の真っ只中で考える
　→動きながら考える
　→そして文脈に即したジャッジをする
・DecisionではなくJudgement
　→マネジメントの領域ではDecisionだと言われてきた
　→→これはコンピュータでもできるもの
　→Judgementは背後にあるコンテキスト（関係性）の読み
　→→全ては読みきれない
・なぜ読みきれないのか
　→その都度の動きの中での関係性が、背後にあるから
　→→お互いのインタラクションを通じて、Assumptionを豊かにしながら明らかにしていく必要がある
・Contextual JudgementとTimely Balancing
　→事象の背後にある関係性は見えない
　→→だから、現実の只中でコンテキストに応じたジャッジメントをすることが重要
　→→それを適時・絶妙なバランスでやらないといけない



◆フロネティック・リーダーシップの6つの能力

◇フロネティック・リーダーシップについて
・何が必要か
　1. 何が"Good"なのかを作る能力
　→→スパイラルをどこでやめるかとか
　→→志の大きさに依存する
　2. 場をタイムリーに作る能力
　3. 現実を直視、直感する能力
　4. 直感の本質を概念・言語化する能力
　5. スパイラルして"やりぬく政治力"
　→→イノベーションはおそらく政治プロセス
　→→現実の只中でしかるべきタイミングでジャッジする能力
　→アリストテレスのいう中庸
　→→グレーなものをコンテキストを読みながら判断する能力
　6. 実践知を組織化する能力
　→→実践知を組織に埋め込む力
　→→全員がリーダーになるまでリーダーシップを高める力

◇（アジャイルを含めた）プロジェクトで重要なこと
・何が重要か
　→人が育つこと
　→リーダーがたくさん育つこと
　→→自立分散型のリーダーシップ(Distributed Leadership)

◇1. 何が"Good"なのかを作る能力
・「何が善いか」についてはいろいろ議論がある
・アリストテレス
　→「本質的に人はいいことをしたい」
　→「世の中の価値には、絶対に手段にならない、それ自体を追求する価値があるものがある」
　→幸福とか自己実現
・確実に唯一最善のものに到達できるという方法はない
・マッキンタイア
　→「絶えずエクセレンスを追求する、そのプロセス自身が"Good"」
　→職人の道
　→→ベターに向かって無限にイデアを追求するという姿勢
・人は理想を追求する
　→達成できないかもしれないけど、達成しようとする
　→→だから人間は限界を超えて知を作る
・スティーブ・ジョブズ
　→「我々の心を高鳴らせるものはリベラルアーツと結びついたテクノロジーであり、人間愛と結びついたテクノロジー」
・本田宗一郎
　→「どの国境、どの人種の上を越えても、いつだれがどこで考えてもそうなくちゃならん、ということが世界的視野」
　→「国境を越えて、人類として、人間である限りは、必ず納得できるような、理論の持ち主になってもらいたい」
・ホンダの本田宗一郎、Panasonicの松下幸之助、シャープの早川徳次
　→創業者はみな技術者

◇2. 場をタイムリーに作る能力
・文脈に応じてバランスをとる・共有する
・いかにバランスを取るかがリーダーの仕事

◇3. 現実を直視、直感する能力
・日々変化する現実を全身で理解する能力
・全ての五感を総合して、相手の視点に合わせる
　→その上で共感する
　→そして、彼の視点から次の仮説を立てる
・全ての五感を総合する
　→そうやって瞬時の想像力や判断力を高める
　→そうすることで研ぎ澄まされた共通感覚を得ることができる

◇4. 直感の本質を概念・言語化する能力
・それを大きな物語にして共有することが重要
　→大局観が必要
　→→Historicalな歴史観が重要になる
・物語はチームを元気付ける
　→会話をしながらコンセプトやストーリーを作っていく

◇5. スパイラルして"やりぬく政治力"
・周囲を説得して価値創造にまい進する
　→説得できる演説力が大切になってくる
　→→「一般通念を打破する新しいビジョンはレトリックに頼らざるを得ない」
・スティーブ・ジョブズの現実歪曲空間

◇6. 実践知を組織化する能力
・個人の全人格に埋め込まれているフロネシスを組織に埋め込む
　→実践の中で自律分散的な体系化・伝承・育成を行う
・そうすれば何が起こっても弾力的に対応できるしなやかな組織ができる
　→そのためには評価システムが適応している必要がある
　→あるいは徒弟制度
・意図的に大きな挑戦を与えて飛躍的成長をしてもらう
　→絶えずフィードバックを得るようにする
　→複数のメンターを付ける
　→→そうやって仕事の型を共有させる
・ホンダの考え方
　→「全員が本田宗一郎になろう」

◇シュンペーターが指摘していた問題から考えてみる
→「組織は個を殺すから崩壊するしかない」
・そうではない組織のあり方があるのでは？
　→個をクリエイティビティする組織
　→組織の知をもっと大きくするような組織
　→→そのためのやり方があるのではないか？
・そのために必要なリーダーシップが1から5
・組織知にするためには6がなければならない



◆組織・フラクタル・ミドルアップダウン

◇最近の組織構造はマトリックス型が多い
・部分最適で終わるのではないか？という話がある
◇そうではない組織構造のケース
・ダイハツのケース
　→新製品開発に辺り全員転籍
　→→帰る場所はどこにもない
　→人事権はPLである部長が持つ
　→→結果として人が育った
　→→→これを受けて組織全体の再編へ
・JALのケース
　→アメーバ経営
　→→時間辺り付加価値を全面的に導入
　→→→組織の末端が社長と同じことを考える
　→予算の執行権を経営企画から経営管理部へ
　→フラクタルな組織経営になっている
・アメリカ海兵隊のケース
　→フラクタルな組織
　→→パイロットは地上部隊のリーダーを1年経験していないといけない
　→→全員でライフルマンをバックアップする
　→仲間（個）のために戦う
　→→お互いの信頼関係が非常に重要
　→→→数人で一個小隊を撃破することもある

◇自立分散型実践知経営
・フラクタルな組織は絶えず環境と共振する
　→組織が1つの個であるかのように振舞う
・クロネコヤマト
　→社長曰く「うちの社長はセールスドライバーだ」
　→→彼らが知の最前線にいて、即座に対応できる
・マージナルマン
　→境界にいて絶えずコネクトしている人が重要

◇フラクタルな組織ではミドルアップダウンが重要になる
・トップダウンやボトムアップではない
　→ミドルが非常に重要な役割を果たすようになる
・Cisco
　→"Lead from the middle."
　→社内SNSで知をアドバタイズしながら、知を絶えずリンクさせている
　→→Distributed Leadership
・明治維新もミドルアップダウンの方式になっている

◇アジャイルやスクラムもこのコンテキストで見るとどうなるか
・組織的なイノベーションやDistributed Leadershipを作ることができる、1つのプロセス

◇コミュニティと知の関係
・コミュニティが内に向かうと知は枯渇する



◆最後に

◇実践知は非常にリスキー
・でもベターを追求するためには必要
　→だからCourageが大事
・ロロ・メイ
　→「Courageはすべての徳の源泉である」
・本田宗一郎
　→「試す人になろう」

◇賢慮と実践知のリーダー : 知的体育会系
・ベターを無限に追求する人
　→現実の中で実践的推論を重ねて真理に近づいていく






野中郁次郎様、平鍋健児様、Scrum Alliance Regional Gathering Tokyo 2013 実行委員会様、翔泳社様、ありがとうございました。

Scrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』ノート（前半）

2012/01/16に開催されたScrum Alliance Reional Gathering Tokyo 2013『野中郁次郎氏 : 特別講演 知識創造企業』のノートです。いつもとは違う刺激や気付きがあって良かったです。こちらは前半部分になります。



■平鍋健児氏によるイントロダクション

◆野中氏の紹介

◇野中氏はスクラムと言う言葉を最初に作った人
・でもソフトウェア業界でスクラムと言う言葉がここまで使われていることは知らなかった
　→一昨年開催されたイノベーションスプリントで知った
・世界で最も影響力のあるビジネス思想家の1人
　→日本からオリジナリティのあるアイデアを発信している
　→本を英語でも書いている

◇ソフトウェアの大切なところ
・技術
　→これはもちろん大事
・人と人とのコミュニケーションのデザイン
　→マネジメントも含めて、これが大事

◇アジャイルが気付いたこと
・「どう"コミュニケート"したら、良いソフトができるのか」
　→アジャイル = ソーシャルなコミュニケーションパターンデザインの方法
　→→そこで使われているコミュニケーションデザインの方法について、始めて言及したのが野中氏



■野中氏の講演

◆はじめに

◇知識創造理論はアジャイルと関係なくやってきた
・イノベーションスプリントの基調講演の依頼を受けて、初めてつながりを知った
　→自分はそもそもコンピュータを使えない
・「アジャイルはソフトウェアの開発の話に留まらない」という話
　→聞いて納得するところがある
・アジャイルは組織変革のプロセスそのものにまで展開されつつある
　→アジャイルとスクラムというのは物凄く大きな話になっていくのではないかと思っている

◇マネジメントにはいろいろな切り口がある
・我々は知識ベースのストラテジックなマネジメント
　→今は戦略によっている
・戦略と組織は分離できない
　→戦略は人間が解釈して作り出すもの
　→戦術を実行するのは組織
　→→人間の解釈や実践・組織作りがないと戦略は成立しない
・戦略と組織を分けるという考えが、欧米では伝統的に強い
　→でも、いくらビューティフルな戦略を考えても実行できなければ仕方がない
　→→戦略と組織をダイナミックに統合するのがストラテジックなマネジメント

◇知識ベースのストラテジックなマネジメント
・これの大まかな枠組み = 絶えずイノベーションを生み出すようなコミュニティ
　→そこには大きな枠組みや大きな志がある
　→→"共通善"があるということ
・大きな枠組みを代表するのが企業ビジョン
　→それを具体的に組織全体に落とし込んだのがビジネスモデル
・いかにユニークな価値を顧客に創造するか？（価値命題）
　→これは非常に難しい

◇SECIプロセス
・「顧客にいかにユニークな価値を提供するかという命題」にどう応えるか
　→そのための知識を作り続けるのがSECIプロセス
・SECIプロセスとそれを支援するプラットホーム（場）の関係
　→顧客や自社の能力があって、知を利益に変化できる
　→→ここにコスト構造など勘案してビジネスの流れを作る
・これら全てをまとめるのがリーダーシップ（フロネシス）



◆経済モデル・完全情報・知識創造理論

◇20世紀は資本主義の時代
・アダムスミスの『神の見えざる手』
　→企業も個人も自分の利益を追求すればよい
　→→そうすると神の見えざる手が市場を媒介してバランスがとってくれる
　→個人利益の追求が社会の幸福につながるという考え
・その後の経済学を科学的にしたいという流れ
　→このなかで科学的・論理的なモデルが出来ていった
　→『神の見えざる手』を理論的に分析した
・完全情報という仮説の登場
　→互いが完全情報を持っていると仮定する
　→→そうすると、個々のプレーヤーの利益追求によって、論理的・数学的に市場がバランスする

◇「でも…　資本主義が社会の幸福につながるのか？」というのが今の時代
・カール・マルクス
　→このことを最初にいった人
　→「資本主義は資本の蓄積、さらなるお金を求めて永久運動するプロセス」
　→「これは格差をもたらすし、資本家と労働者の搾取モデルになる」
　→「だから階級をなくす革命が必要となる」
・ドラッカー
　→「21世紀は知識創造・ナレッジソサエティの時代」
　→知識というわけの分からないものを経済に落とし込むことが必要
・シュンペーター
　→イノベーションについて初めて言及した
　→「新古典派の考えるような均衡はない」
　→→「均衡ではなく、絶えざる均衡破壊がある。それがイノベーション」
　→→→イノベーションで資本主義を延命させるという考え方
　→マルクスとは対極にいる
・ハイエク
　→「マーケットは単なる競争の場ではない」
　→「顧客のニーズというのは定式化されていない」
　→→「完全情報なんていうものはそもそもない」
　→→→「いかにそういうものを発掘して形式的な知識につなげていくか」
　→→→→「マーケットはそういうものを発見する場」

◇完全情報になっていない部分とは何か
・我々の言葉なら暗黙知
　→『氷山のモデル』
　→→形式知は海に浮かぶわずかな部分
　→→水面下には膨大な暗黙知があり、それが知の源泉になっている
　→マーケットは知の創造の場

◇再びシュンペーター
・彼はある種のペシミズムを持っていた
　→「様々な知を組み合わせ均衡破壊をするのはは企業家・個人と銀行」
・これは組織化の時代になるとサイロ化していく
　→→そうやってできる官僚機構は創造的な個を殺していく
・「企業家が持っている、天職としての倫理を持つ資本主義」
　→ウェーバーが言っていたこと
　→これが金儲けに走るうちに失われてしまう
・それから民主主義にあるポピュリズム
　→ここから来る、ある種の平等感が企業家精神を劣化させてしまう
・そして資本主義は自ら崩壊して社会主義にいくという悲観
　→これがシュンペーターのペシミズム

◇知識創造理論の源泉
・我々が知識創造理論を思いついたのは…
　→組織はクリエイティブでありうると考えたから
　→組織は個の力を増幅させることができると考えたから
　→イノベーションが持続する組織がありうると考えたから
　→→そういう組織をどうやって作るか？という話
　→その1つとしてアジャイル・スクラムも大きな話につながっていくと思う

◇知識という、よくわからない財をどう概念化するか
・知の源泉は自分の主観
　→知は最初からあるものではない
　→知は客観的に与えられるものでも、簡単に組み合わせられるものでもない
・知は情報
　→自分の主観を真理に向かって社会的に正当化していくダイナミックなプロセス
　→→イノベーションは知識創造プロセスであるということ
・知は主観
　→知は人間が介在し解釈するからでてくるもの
・そのための知識創造プロセス = SECIモデル

◇知識創造理論の背後にある考え方
・理想主義のプラトン
　→演繹の父
　→→「真・善・美は天上にある」
　→→「イデアこそ真理」
　→→体は五感の塊だからそれを抜いて考え神に近づく
・実践主義のアリストテレス
　→帰納の父
　→→「イデアは地上にある」
　→→「実践が大事」
　→→BODYが大切
・イデアには簡単に到達できない
　→実践の中で考える必要がある
　→→SCRUMに似ている？
・プラトン以来の知の伝統が、西欧にはある
　→身体を否定して純化するというアイデアが強い
・知識想像の考えが影響力が持つのは何故か
　→そうではない考えが前提にあるから
　→→「身体の知がその前にあって、それが源泉なのではないか」



◆暗黙知・型式知・SECIプロセス・場

◇今まで強かった考え方
・主観的にものをいかに客観的に修正するか
　→客観的・科学的で形式的なものが知識
　→マネジメントもサイエンス
　→→それもいいけど…

◇マイケル・ポラニー
・「われわれは語れる以上のことを知りうる」
・「すべての知識は暗黙的、あるいは暗黙知に根ざす」
　→暗黙知の根底にはBelief（信念）がある
・知るということには個人がコミットしないといけない
　→全身全霊でコミットして、そこから生み出されるのが知
　→→だから信念と暗黙知、信念と理性の関係が必要
・アートとサイエンスがたえずダイナミックにバランスを取っていく中から知が生まれる

◇SECIモデルではどうなのか
・暗黙知と型式知がある
　→どちらが先かという話がある
　→→我々は初めに経験ありきではないかと考える
　→言葉は後
・暗黙知と型式知はおたまじゃくしのように円環する
　→相互に円環しながら膨らんでいくと言うイメージ
・トヨタの偉い人
　→「経験・知覚というのは、五感を想像すれば言語よりはるかに豊かなもの」
　→「でも言語も五感を豊かにする」
　→「両方が弁証する相補的な関係にある」
　→→「One wayではない」

◇暗黙知には瞬時に想像する要素がある
・でもそれは言語化できないといけない
　→言語化を積み重ねていくと言葉が豊かになっていく
・ワインの話
　→ソムリエの田崎氏が、暗黙知と形式知のスパイラルと同じようなことを言っている
　→「暗黙知を豊かにするには、いいワインを飲まないと駄目」
　→「そのとき感じたことをきちんと言語化しないと駄目」
　→「顧客とは一期一会なので、あった瞬間に現在・過去・未来を瞬時に想像できないと駄目」
　→→暗黙知があると予見能力が高まる
・でも暗黙知がたくさんあるだけでは駄目
　→それは言葉で語らなくてはいけない
　→→言語化を積み重ねることで、本質的な言語化（メタファーやレトリックを使った感覚的で詩的な言語）に至る
　→言葉にすることでスパイラルアップできる

◇SECIモデルでは
・共感→概念化→モデル化→実践のフェーズを経る
　→チームの知が組織の知へ
　→それが個に返りつき、さらに大きな知へ
・スパイラルにすることでもっと大きな知を想像できる
　→知を組織的に作るモデル

◇イノベーションはSECIスパイラルである
・共同化→表出化→連結化→内面化
・『相手の視点に立ったときの気付き』がないと本質には辿りつかない
　→本質は見えないので対話を通じて徹底的に考えないといけない
・それをコンセプトに凝縮して、関係付けして、量モデル化して、徹底的に分析する
　→そして技術・経験・サービスなどに価値化
　→→知を血肉化（内面化）して暗黙知化するということ
　→これは（結果として）組織や市場の新たな知を提供することになる
　→→これが新たな知を触発する
　→→→この新たな知をまた共同化する
・この反応を絶えず生み出す

◇この反応が生み出される状態をどうやって目指すか
・個人を殺さず、個人を活かし、個人ではできない知を創造する状態
　→こういったものをきちんと量モデル化しないといけない
　→→そのためには場（プラットホーム）が必要
・どういう場である必要があるか
　→コンテキストがあるもの
　→スパイラルアップするようなもの
・場の文脈は常に動いている
　→動いている文脈を共有できるのがダイナミックな場
　→そういう場で、皆の主観(Belief)を出す
・場を『皆の主観の場』にする
　→思いは言葉、言葉は形にしないと共有できない
・全人的に向き合うことで自己を超える我々の主観を生み出す
　→そのためにコンテキストがとても重要だということ

◇言葉の意味は、インタラクションの中でしか分からない
・「けっこうです」
　→"いる"ということ？
　→"いらない"ということ？
・言語学の関連性理論でのコンテキストの定義
　→「お互いの発話の解釈の手助けになる、聞き手の頭の中にあるAssumptionsのこと」
・アジャイルやスクラムもそう
　→顧客とのインタラクションの中でどう解釈するか
　→→ここでAssumptionが出てくる
　→→それを対話の中で共有しながら新しいAssumptionを作り出していく
・場 = 動いているコンテキストを共有するところ
　→そして知を生み出せるところ



◆身体・体験・ビジネスモデル

◇もう1つの重要なこと
・合意形成について
　→皆の主観（相互主観性）を作り上げるプロセス
　→→この中でベースになるのは身体

◇身体のタッチ（メルロ・ポンティ）
・身体感覚は相互に浸透する ： 間身体性
　→右手で左手に触る
　→→しばらくすると左手からも右手を触っていることを感じる
・Embodied Mind（フランシスコ・ヴァレラ）
　→ボディとマインドは分けられない
・ミラーニューロンの発見
　→他人のしていることを自分がしていることのように感じる細胞
　→→模倣すると相手の意図が読める

◇共感の土台が重要だということ
・我々は生まれつき共感を覚えるように出来ている
　→マズローの自己実現理論の上には、コミュニティを作るというニーズがあるということ
・場の根底にあるもの
　→タッチも含めた身体的・精神的な触れ合い
　→→Socializationにおける重要な概念
・マーク・ザッカーバーグの提唱するエコシステム
　→「2人の人間のインタラクションの場（社会の基盤）を作る」
　→「それを繋げてもっと大きな場を作る」
　→「究極的には大きなイノベーションを作る」
　→「最終的に大きなHapinessにしていく」
　→「単なるマーケットを越えてコミュニケーションする関係を作る」
・でも組織が直接インタラクションすることはできない
　→実際にやるのは個人
　→→場を作ることとそれをスピーディにやることが重要

◇なんのために知を想像するのか
・最終的には"Common Good"
・もっと具体的には価値命題とビジネスモデル
　→いかにユニークな価値を創造するか
・ビジネスモデル = 知を価値・利益に変換すること
・　「コトづくりのためのモノづくり」
　→ユニークなコトを提供するためにはユニークなモノが必要
・コトから入っていった方が大きな経験価値を与えるモノを作れる
　→音楽配信という経験価値を与えるためにモノを作る
　→→モノは体験を提供するためのもの
・「iPodというモノはマルチメディアの視聴という体験（コト）を与えるためのものである」
　→ここまでコンセプトをクリアにする
　→→これがわかれば、誰が顧客でどんなユニークな価値を提供するべきかが分かる

◇顧客にユニークな価値を提供するためには
・流通の最先端、顧客の最前線まで行ってきちんと意味を伝えないといけない
　→絶えず価値命題は変化している
　→→最先端で顧客から学び、それをフィードバックサイクルの中に入れる

◇ビジネスモデルについて
・知識ベースでの基本的な考え方
　1. いかなるコトを与えるのか
　2. 顧客は誰か
　3. 能力（能力・知力）はあるか
　→→（どこをクローズドに、どこをオープンにするか）
　4. コスト構造
　5. それで利益を考える
・（ポーターの）伝統的な戦略論での考え方
　→極力競争しない
　→差別化して参入障壁を高める
　→価格決定権を渡さない
　→→サプライヤのパワーを高め、顧客のそれを低める
・伝統的な戦略論の目的
　→既存の市場をいかに守るか
　→競争の少ない市場を作るかというもの
　→→こういうのもが支配的だった
・ドラッカーがそうではないといった
　→「企業のミッションは顧客の創造である」
　→→そういう意味で顧客創造・価値命題がでてくる

◇今はイノベーション系のビジネス思想家の影響力が高まっている
・ナレッジベースはいかにユニークな価値を提供するかのために有効
　→バリューは主観的
・戦略 = いかに1人1人の主観・価値を合意形成して自分の真理に向かって実現していくか
　→だから戦略以上に重要なのは組織であり人・最近、ポーターのコンサルティング会社が倒産した
　→価値命題が非常に重要になってきているということ

◇コトで世界を作る
・名詞ではなく動詞でとらえる
　→絶えずダイナミックな関係性を洞察する
　→動きながら考える
　→→SCRUMのプロセスがやろうとしていること
・ここで全てを総合するリーダーシップが重要になってくる

（後半へ続く）






野中郁次郎様、平鍋健児様、Scrum Alliance Regional Gathering Tokyo 2013 実行委員会様、翔泳社様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 1 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートのパート1です。

パート2はこちら

◆高橋 一貴氏「スクラムマスター思い出語り」

◇アジャイルコーチをやっている

・自分は推進係

　→知らないところで好きにやっていたりする

・昔は壁に張り物がなかった

　→今は場所取りが必要なくらいになっている

◇スクラムマスターって？

"スクラムマスターは、スクラムチームとのやり取りで役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらうようにする。

スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。"

 - (Ken Schwaber and Jeff Sutherland､ Scrum Guide)

　→みんなのやり取りを変えてもらうことでスクラムチームの作る価値を最大化する

◇最初はわからないことだらけ

・スクラムマスターについて

　→どこまで理解しておけば？

　→チームとの関わり方のコツは？

・どこから始めれば？

　→『塹壕より Scrum と XP』を読んだ

　→→今だと若干古いところがあるので注意

◇失敗

・Excelでスプリントバックログとプロダクトバックログを一元管理

　→プロダクトバックログのアイテムの下にインデントでタスクを並べる

・個人別にバーンダウンチャート

　→個人の遅れもばっちり把握

・フロントエンドとバックエンドでチームをわける

　→効率的な分業

・スクラムマスターがタスクをアサインした

　→抜け盛れを防ぐ

・レビュー完了はスクラムマスターが判断

　→確実な品質確保を

・詳細仕様をプロダクトオーナーに承認してもらう

　→外部仕様より先の話

・ミーティングはスクラムマスターがどんどん発言

　→進行も決定も効率的に

　→自分の意見もどんどん言う

◇こういうことをしているといろいろ変になる

・タスクの残量が把握できない

　→並べてあるから見える化

　→→全体量が分からない

　→→メンテナンスが大変

・遅れている人を問いたださないといけない

　→いつも遅れている人に余計なプレッシャー

・堂々巡り

　→「バックエンドが終わってないから画面作れない」

　→「いやいやフロントエンドが終わってないから見せられない」

・追加タスクが申告されない

　→バーンダウンチャートが増えるだけだから隠してしまう

・自分のところでレビューが溜まりすぎる

・POと話がかみ合わない

・チームから活気が消えた

◇どうなったか

・葬式のような振り返り

　→ミーティング全てお葬式に

　→→こんなはずではなかった

◇もう一度定義をよく見直した

・スクラムの理解と成立のために

　→皆のやり取りを変えてもらう

　→→スクラムチームの外側ステークホルダーに理解と行動を促す

　→→→個々の作業に関与しすぎるからうまくいかない？

◇やり方を変えた

・手法や環境へ働きかける形へ

　→作ったものや個人ではなく、全体的な視点で

・スプリントバックログは付箋とペンで

　→『塹壕より Scrum と XP』どおりにやってみた

　→→一覧性がぜんぜん違う。何が起こったかすぐわかる

・チーム全体のバーンダウンチャートのみに

　→チームを解散させたいなら個人別バーンダウンチャートがオススメ

・チームはクロスファンクションで組成し直し

・放置・滞留しているタスクに気付いてもらうように

　→「しばらく貼りっぱなしだけどどうしたの？」

　→→意外と話してくれる

　→→→フィードバックすれば自主的にやってくれる

・レビューはチームで完結

　→実施有無とレビュー観点のみ見る

　→後はチームに任せる

・詳細仕様は求められた場合のみ説明

　→プロダクトオーナーはデータベースとかに興味ない

・ミーティングへの貢献の仕方を変える

　→ゴールとアジェンダを必ず用意

　→→参加者に手伝ってもらうつもりで

　→進行のコントロールに徹する

　→→内容には干渉しない

　→→→"誰が喋るか"を決めては駄目。"誰から喋るか"を決めるのはよい

◇大事だと思うこと

・いっぱい勉強してやってみる

　→今はいろいろなところで話を聞ける

・『自分が信頼している人に見せる態度』でみんなに接する

　→ノーガードで飛び込んでしまう

　→→ガチで殴ってくる人はいない

　→チームの少々の混乱は覚悟しておく

・Be Nice

　→いい人のいいところを容赦なく真似る

◇変えられないものを受け入れる

・変えられるものは変える

　→そこはあきらめない

・判断できる力をつける

高橋 一貴様、スクラム道様、ありがとうございました。

『スクラム道 EXPO 2012 - 午前のセッション』ノート

2012/10/28に開催された『スクラム道 EXPO 2012』午前のセッションのノートです。


◆和田　卓人氏「ペアプログラミング ホントのところ」

◇質問「ペアプロすべきか？」
・答え「状況による」
　→それはずるい
　→→経験者としてそういう結論になるのはわかるが…
・ペアプロは議論を巻き起こす
・見た目も派手

◇ペアプログラミングって何？
・書籍「プログラマが知るべき97のこと」
　→「いかに周りの人とお客と仕事をするか」という中身が詰まっている
　→→プログラマは技術が優れいてるだけでは充分ではない
　→→他人との連携でより大きな成果が上げられるようでなければならない
・2人で1つのマシン、1つのキーボード
　→ドライバとナビゲータ
　→2人でコラボレーション
・いろいろなイベントではモヒカンが切りあう形になっている
　→それも面白いが…
　→チーム（ペア）でプログラミングするもの

◇ペアプロをやっている人の結論
・外国でやっている人も国内でやっている人（自分）同じような結論に至る
・やっている人とそうでない人ではイメージがだいぶ違う

◇ペアプロの利点
・規律の強化
　→1人だとサボったり、コーディング規約が億劫になったりする
　→→1人だと悪魔のささやきに負けやすい
　→→2人でコードを書いているときは天使の方が勝る
　→ペアプロ中ってtwitterやネットサーフィンをしない
　→→仕事モードになっている
　→→→仕事と休みのメリハリが付きやすい
・より良いコード
　→品質は上がっていく
　→→すぐ隣にそのコード使う人がいる
　→→フィードバックが非常に早い
　→→→それが良い効果をもたらす
　→ペアは最小のチーム
　→→シンプルさはチームが決めるもの
　→→→複雑なコードは書かなくなる
　→力技でこなす「動けばよい」みたいなコードも書かなくなる
・快活なフロー状態
　→1人と2人とでは深く集中した状態（フロー）が異なる
　→→ペアならではでのフローがある
　→→→1人のときとは異なるフローの状態に入れる
・チームの士気向上
　→ペアプロをすると部屋が無言ではなくなる
　→会話をしていくことがチームの仲の良さ
　→→情報が伝わりやすくなる
　→→→チームがよりよい方向に行く
・コードの共同所有
　→プロダクトコードに持ち主がいない状態
　→→少なくとも2人は知っている状態
　→「ある個人しか知らない」というのはない
　→→保守性が高まる
・学習効果
　→ペアプロはばらつきを一番早く吸収できる
　→→エディタ・開発環境・ネーミングなどなど
　→教える側は知識の整理などが必要
　→→教える側にも学びがある
・チームの一体化
　→チームが同じ方向に進むという方向付けがやりやすい
・割り込み削減
　→ペアプロ中の人には割り込みにくいという調査結果
・つまり…
　→教わる側は当然学べる
　→教える側は滅多なことは言えなくなる
　→→実は教える側の方が学べる

◇1人でプログラミングするのと、2人でするのとの違い
・最大の違いは"喋るか喋らないか"
　→この差は非常に大きい
　→→1人の場合、考えてコードに落として　…というのをグルグル回す
　→→2人の場合、声に出すので頭の中をもう一段整理しないといけない
　→Rubber Duckingという手法もある

◇機能しないとき
・管理者はハードウェアに投資したくない
・現場がペアプロに最適化されていない
　→机の並び方など
・現場では従来型の雇用方法を採用している
　→覚悟や適正など、ペアプロに向いたプログラマーを雇っていない
・現場では反社会的な行動を大目に見る
　→コーディング規約に従わない
　→ペアプロやらなくても「プログラマはそういうものだから」で看過されてしまう
・ペア作業の生産性が理解されていない
　→「生産性が半分になるじゃないか」という管理者の意見
　→→生産性は2割増しくらいになる
　→→仕様・スキルの伝達・Better Codeなどの生産性がある
　→ペアプロにはペアプロの生産性がある
　→→なかなか理解されない
・現場では的確でない開発者を雇っている
・現場は過労と人員不足に陥っている
　→「この期に及んで二人でコードを書くなんて」
・開発者は一緒に仕事をしている人達全員を好いているわけではない
・開発者はそのような面倒なことをしたいとは思わない
・たいていのソフトウェアの現場では、優秀さのことを本当は気にかけていない

◇ペアプログラミングをエゴの問題
・角谷さんとKent Beckさんとのやりとり
　→ペアプロするとき自分のキー配列とかの好みはどうする？
　→→「おまえの好みとチームの成功とで大事なのはどっち?」
・ワインバーグによるエゴレスプログラミングの十戒

◇ペアプロを入れるかどうか
・結局はIt depends.
　→気に入らない人という人も一度やってみると即座に気に入る（塹壕とScrum本）
　→→（結局）8割は気に入る
　→→それでも2割には通じない

◇ペアプロは楽しい
・楽しいのが一番
　→「楽しい」はものごとを前に進めるためのプリミティブな原動力



◆吉羽 龍太郎氏「Doneの定義 虎の巻（再演）」

◇出荷可能な製品とは？
・Doneの定義
　→実施しなければいけないことの一覧
　→→プロジェクトとして定めた『出荷可能な製品』を作るため

◇（個人的には）次の単位でDoneを定義したりする
・バックログ単位
・スプリント単位
・リリース単位

◇何が出来たら完了なのかを決めるもの
・どこまでやったら終わりかが分からずにやると…
　→悲惨なことになる
　→→だからゴールを決めてからやる

◇手戻り
・本人だけできていないつもりで延々と作りこむ
　→時間の無駄が発生
　→→（ex. 誰が見るのか分からないのに、一生懸命レイアウトを整える）
・本来やっていないといけないことをやり忘れる
　→セキュリティとか考えずにとりあえず作る
　→→後でセキュリティホールが見つかったりする

◇アジャイルな進捗の判断は0 or 1
・ウォーターフォールは80%などあるが、アジャイルにはない
　→アジャイルでは、できたか、できていないか
　→アジャイルは判断が必要ということ
　→→その基準がDoneの定義
・バーンダウンチャートの数字が信用できる理由は？
　→Doneの定義に従って進めているから
　→Doneの定義がないと見せかけの進捗でごまかせてしまう

◇プロダクトバックログの受け入れ基準との違い
・受け入れ基準とは
　→どこまでできたら終わりか？を書くもの
　→→機能要件適合性の判定のためのもの

◇体験談
・悪い受け入れ基準
　→『ソースコードが綺麗なこと』
　→→あやふや
・良い受け入れ基準
　→ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
　→→全員が合意できる
・変な基準を強制される
　→品質はコンテキストに寄る
　→→金融・医療・ウェブでは異なる
　→→→社内品質基準は顧客の期待と関係ない
　→そもそもゴージャスすぎる
・守っているかどうか判断できない
・そもそも定義の中身を知らない

◇Doneの定義を守れない理由
・なぜの分析が足りない
・別の圧力に負けれる（スコープの圧力など）
・チームがオーバーコミット
・そもそもDoneの定義が曖昧

◇どうやって改善するか？
・振り返りで改善
　→プロセスが改善されることでDoneの定義が変わっていく
　→1スプリント目と10スプリント目で同じなのは逆にやばい
　→→それは、従来のウォーターフォールの書き方を変えただけ
　→プロセスは自分達で変えることができないといけない

◇Doneの定義の更新
・自明のDoneは外す
　→チームが成熟するとでてくる
　→→もっと進むと『リリースのDoneの定義』をスプリント内でやれたりする
　→→→でもやりすぎには注意

◇Doneの定義の縮小
・気をつけなければいけないこと
　→明確に守れていないものを外すのはまずい
　→→本当に顧客の期待に応えられているかを考える

◇Doneの定義充足の検証
・Doneの定義を見ればチームの技術力がわかる
　→自動化できるものは自動で
　→→より本質的なものに時間が使えるようになる

◇Doneの定義をいつ決めるか？
・見積もりや契約の前に大枠が決まっているべき
　→そうでないと工数がぜんぜん異なる
・誰が決める
　→プロダクトオーナー + スクラムマスター + チーム
　→→プロダクトオーナーは外部のステークホルダーの声も聞く
・決め方
　→必要な作業を付箋に書き出す
　→実施タイミング(Release, Sprint, etc.)でグループ分け
　→リスト化して印刷して、皆が持つ

◇荒ぶる四天王
・品質は固定パラメータ
　→スコープ達成の圧力に負けない

◇大事だと思うこと
・プロジェクト開始時点で決める
・スプリントで全部やろうとしない（最初は無理）
・チームが成熟したら拡張
・品質は固定パラメータ
・途中で縮小しない
・自動で検証
・定義をみんな知っている


◆市谷 聡啓氏「Your Mind is the Scene of Development」

◇なぜインセプションデッキ？
・プロジェクトに然るべき人が集まっているかを確認
　→いないと後で話が変わる
・プロジェクトがしかるべき方向を向いているかを確認
・「チームメンバーが誰もいないところで合意したことを前提にしているからプロジェクトがダメになる(The Agile Samurai)」

◇インセプションデッキとは
・10個の問いから構成されている

◇いつデッキを作るか？
・プロジェクトキックオフ？　最初のイテレーション？
　→それでは遅すぎる
・契約前、予算取り前
　→検討する段階で作る
　→正しい制約を作るために

◇予算が確定した後にデッキを作るにしても、プロジェクトの前提は後からは動かしにくい
・だからステルスデッキ（受注前のインセプションデッキ）
　→前提を作る
　→目的に適した制約を作り、プロジェクトを開始する

◇プロジェクト開始前・開始後で進め方が違う
・開始前（ステルスデッキ）
　→ステークホルダーにはインセプションデッキとあえて言わない
　→→相手の期待値が上がる
　→あくまで制約をあぶりだすための仕掛け
・開始後（インセプションデッキ）
　→目的を明らかにして作る
　→→プロジェクトの方向を明らかにするために

◇インセプションデッキのCRUD
・Create
　→プロジェクト開始前と後
・Read
　→最初はデッキの内容のチームへの定着を図る
　→→週一回全員で点検するなど
・Update
　→デッキの更新はプロジェクトの方向が変わるということ
　→→その認識を併せる
・Delete
　→デッキが用を成さなくなったとき

◇ゴールデンサークル
・why, how, whatの順で考える
　→インセプションデッキの前半5枚がwhy
　→後半5枚がhow
　→ユーザストーリがwhat
・howが変わる
　→インセプションデッキに影響が及んでくる
・whyが変わる
　→プロジェクトの方向が変わる
　→→ステークホルダーが認識しているかを確認
　→→→プロジェクト全体で判断し合意する

◇インセプションデッキの弱点
・whoが弱い
　→エレベータピッチの「対象顧客向け」しかない
・whyを考えるためにはwhoは必要

◇エレベータピッチ
・whoの分だけエレベータピッチを考え、作る
　→ターゲットが複数
　→→ニーズが複数ということ
・複数ニーズに対してプロダクトは1個でよいのか？
　→そういう疑問をステークホルダーと話し合う

◇やることやらないことリスト
・いきなりやらないことを出すのは難しい
・目的
　→スコープを明らかにする
　→加えて、開発への期待を明らかにするためにも使える
　→→開発の苦い経験を明らかにしてもらう
　→→ここを見誤ると、この後の開発での相手の期待がわからなくなる

◇プロジェクトコミュニティ
・誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい
　→顧客には顧客組織が分かる
　→開発は開発の人しかわからない
　→→コミュニティを明らかにする必要がある
・開発のよくある役割を確認する
　→顧客に過去の開発であった役割を思い出してもらう

◇重要なこと
・練習重要
　→本番は本番の結果を出さないといけない
・質問力重要
　→良質な問いかけがプロジェクトの行く末を左右する
　→→アクションラーニングオススメ





和田 卓人様, 吉羽 龍太郎様, 市谷 聡啓様, スクラム道様、ありがとうございました。

『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』ノート

2012/10/17に開催された『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』のノートです。



◆開催概要

◇登壇者
・Jeff Patton氏
・平鍋健児氏

◇会場提供
・楽天

◇共催
・アギレルゴコンサルティング

◇提供
・永和システムマネジメント

◇本日のアジェンダ
・Jeff Patton Lecture(50min)
・Conversation! Jeff & Kenji(60min)


◆はじめに

◇Jeff Patton氏
・デザインとソフトウェアにはただ1つ正しい道は存在しないと思っていて、活動している。
　→20年以上にわたって活動
・ユーザーストーリーマッピングの考案者
　→2001年から12年以上やっている

◇平鍋健児氏
・20年以上オブジェクト指向ソフトウェア開発の経験
・10年以上アジャイルソフトウェア開発の経験
・チェンジビジョンでastahを開発して提供
・「Jeffとは長い付き合い。今日は楽しみにしている」

◇Jeff Patton氏の経歴と今日の話について
・アジャイル界ではアジャイルユーザエクスペリエンスの人だと認識されている
・80年代、美術学校に通っていたことがあった
　→ソフトウェア開発業界にいったらユーザインタフェースのデザインの仕事を任された
・ストーリーマッピングの実践について話をしている
　→12年前(2001年)から
・ソフトウェアを理解するための有意なやり方 = ストーリー
・ストーリーマップの話をする為には、まずユーザストーリーを理解してもらう必要がある


◆ユーザーストーリーの話

◇導入
・2000年、サンフランシスコでKent Beckとプロジェクト
　→xpを教えてもらった
・xpでは伝統的な要求は使わない
　→ストーリーを使う
・Kentは伝統的なソフトウェア開発の大きな問題に対してストーリーを使おうとした
　→うまく書かれていない仕様はソフトウェア開発を阻害する
　→→ストーリーは効果的にコミュニケーションするためのもの

◇ケーキの話
・cakeWrecksというウェブサイト
　→ケーキに書かれた文字を写真にしたもの
・間違った指示がどれだけ面白いケーキを作るか、というサイト
・ケーキに書いてある文字の例
　→best wishes suzanne / under neat that / we will miss you
　　（underneath = 下線を引いてという指示）
　→Congraturations / Three Times
　　（3回繰り返して）
　→I want Sprinkles
　　（カラフルなトッピングをかけて）
→Nuts Allergy / Happy Birthday Peter
　　（ナッツアレルギーです）
→Leave Blank
　　（何も書かないで）
・ケーキの間違いは面白い

◇面白いではすまないものもある
・Mars Climate Orbiterという火星探査機
　→火星の軌道にのらずに爆発
・ポンドとメートルの単位換算をしなかったという失敗
　→コミュニケーションミスが原因で起こった

◇このような問題についてKent Beckは考えた
・解決策はシンプル
　→「さあ、ドキュメントを書くことはやめて、話すことから始めよう」

◇ストーリーのアイデアはシンプル
・欲しいソフトウェアのことを何かカードに書く
　→何を書いてもよい
・それを見て話しあう(conversation)
　→どんなソフトウェアが必要か正確に決められる
・"We should get together and I want to hear your story"
・ストーリーをカードに書く
　→互いに言い合うため
・書くのではなく語ろう
・アイデアはシンプル
　→だからといって簡単なわけではない

◇ストーリーのフローはシンプル
・カードには何が書いてあってもいい
1. 会話する
2. 何か気がついたら書く
3. それを説明する
4. 聞いた人は相手が欲しいものをイメージする
5. そして質問する
　→会話は質問すること
6. ユーザーとデベロッパーは理解を共有する
・"何を作るか？"を共有するということ
　→開発者が独自に想像してものを作るのとは全く異なる
・共通の理解を通じて、何が欲しいのかの理解に達する
　→ユーザー「何を作るかについて詳細に話すことはできない。でも何が欲しいのかはある」
　→デベロッパー「何が欲しいかは分からない。でも作り方を詳細に話すことはできる」

◇ストーリーのシンプルなアイデア
・動かないものを書いたり描いたりすることはしない
→Conversationする
・アジャイルプロセスでは少ないドキュメントで行う
　→Conversationして少しの絵や単語を書く
　→→そうして「何を作るのか？」という理解を促進する

◇プロセスの始まり
1. カードによるConversation
2. Confirmation
3. そしてカードを書く
　→作るものの詳細について沢山ディスカッションする
・Ron Jeffriesの3C
　→『XPエクストリーム・プログラミング導入編』に書いてある
　→→Card
　→→Conversation
　→→Confirmation

◇開発の流れはこんな感じ
1. ソフトを作り始める
2. 話しあった2人以外も見る
3. それを見てもっと話し合いこと・疑問や答えがでてくる
4. 完全じゃないことや変えたいことが出てくる
5. それをカードに書く

◇アリスター・コーバーンが言っていたこと
・「ストーリーは3枚書け」
　1枚目 : 必要なもの
　2枚目 : 1枚目をFIX（直す）するもの
　3枚目 : もう一回FIXするためのもの
　→3回書かないとストーリーにはならないということ

◇今までのソフトウェア開発とアジャイルなソフトウェア開発の違い
1. ソフトウェアを作る
2. 後から変更の必要がわかる
　→今まで：悪い要求で失敗とされる
　→アジャイル：学びとされる

◇Kent Beckが書いたこと
・「ソフトウェア開発にもっとも大きなダメージを与える最悪の単語は"requirement"である」
　・だから話をして学び、作るべきソフトウェアについて書く、というサイクルを行う
　→問題に対するパーソナル(?)な解決策である

◇ストーリーの壁
・Conversationは2人で話しをするもの
　→「私が必要なもの」
　→「私が作れるもの」
・でも周りにはたくさんのステークホルダーがいる
　→それぞれの観点から話しをする
　→→「リターンはどのくらい？」
　→→「ビジネスの何を改善する？」
　→→「進捗はどうなっている？」
・実際にはたくさんのステークホルダーがいる

◇カードの最初のアイデア
・「カードは会話のきっかけ」
　→詳しく書くのではなく、会話を発生させるもの
　→話して出てきた詳細はカードの裏に書く
　→→でもステークホルダーがたくさんいると裏側ではすまない

◇カードは「何について話すか？」のためのもの
・図書館にある"カード目録"を考える
　→本自体は別のところにある
・カードは会話を引き出すためのもの
・沢山の人との会話の結果はカードに書けない
　→wiki, sharepointでもオンラインのドキュメンテーションに書く
　→→少し複雑。当初のものよりちょっと悪くなってしまった

◇ストーリーの大きさ
・「大きさ」はいつでも大切
・ユーザーは気に入ったものを書く
　→ユーザーに大きさは関係ない
　→開発者は正確な大きさを知りたがる
　→→イテレーションに収まるよう細かくする
・ビジネスリーダーは、ビジネスの効果が分かるものを好む
　→ロードアップにフィットするサイズになる
・ストーリーは1つのサイズで書けるものではない
　→それぞれのステークホルダーにナチュラルなサイズがある
　→それぞれに必要なサイズが違うということ

◇みんなストーリーが嫌い
・開発者なら開発できる、QAならテストなど、それぞれ自分の欲しがる形がある
　→専門家にはそれぞれのやり方があるということ
　→それぞれ必要なサイズが違う
・ストーリーの登場によって皆が同じ話しができるようになった
　→ストーリーは、誰から見ても『自分が欲しいものとはちょっと異なる』ということ
　→→皆に対して不完全になっている

◇ストーリーの大きさと価値
・ストーリーはそれぞれ価値がないといけない
　→でも1つ1つは出荷可能ではないし完全でもない
・集まって1つになって、デリバリ可能となる
・ユーザーストーリーはより小さいストーリーに分割される
　→全体になってはじめて1つの価値があるということ
・より上位の視点からユーザストーリーを見る手法が必要だということ
　
◇ストーリーと開発サイクル
1. 最初は大きな機能の話
2. 沢山の会話をして小さいパーツとしてのストーリに分解する
　→ユーザストーリをパイプライン(sprint)を通れるくらいにシュリンクさせる
3. 優先順位をつける「これは最初のリリース」「これは次」
　→ここでUIや受け入れテストなどの細かい話がでてくる
4. ここから開発者が出てきて「まだ大きい。イテレーションに入らない」
　→もっと細かくする
5. 小さいストーリーが完了する
　→価値のあるパーツ（ユーザに見せて正しさを検証できるくらいのもの）ができる
　→→でも、チェックボックスが付いた、なんてものをユーザは見たくない
6. ユーザの目からみて価値のある大きさにまとめてから、見てもらう
　→それを一つ一つ検証(validate)
7. 最後の大きな1つのソフトウェアになる

◇ストーリー = 岩みたいなもの
・割ると沢山の岩になる
→でも頻繁には砕かない

◇ゲーム : アステロイド
・ルール
0. 宇宙を岩が飛んでいる
1. 岩を打つと砕けてあちこちに飛んでいく
2. 砕けた岩を打つと、それもくだけて飛んでいく
3. 何回か細かくすると石は消滅する
4. そうやって全ての石（岩）を消滅させればおｋ
5. 岩にぶつかるとゲームオーバー
・このゲームでは、大きい石を何回も打つのは悪いやり方
　→小さい石がたくさんでてきてすぐゲームオーバー
　→大きなストーリを早いうちに細かくくだくのも同じ

◇ストーリーは素晴らしい発明
・Conversationで共通の理解をするためのもの
・書類は間違いがち

◇ソフトウェア開発でもっとも難しいもの
・「そもそも何が作りたいのか」ということを理解すること
　→フレデリック・ブルックス（人月の神話の人）が言っていた
・コミュニケーションは難しいがそれ以上
・「何を作るか」と言うことは「人が欲しいもの」「作るものが何なのか」を理解すること
　→それが一番難しいこと


◆ユーザーストーリーマッピングの話

◇ユーザーストーリーマップとは何か

左右：Workflow ワークフロー
上下：Details 詳細やオプションとなるストーリー



・構造上の特徴は2つ
1. 左右はユーザの視点からみた物語
2. 上下はバリエーションやオプション
・一番上が一番大きな岩
　→話の背骨になっている
　→細かいものはその石に紐付けられて下にいる
・上（ユーザのアクティビティ）
　→タスク（背骨）をいくつかまとめたもの
・書いて動かしているうちに会話が生まれる
　→それが重要
・マップができるということは会話ができたということ
　→マップは会話の足跡
・マップにシールでタグ付けすることもできる
　→リスクに対する評価や、やる/やらないなど

◇ユーザーがストーリーマップから見るもの
・「この機能は2日」とかそんなものは見ない
・ユーザーはもっと大きなストーリーの流れを見る
　→使っている様子が分かるように書く
　→→そこから会話が生まれ、Detailsに新たなカードが加わっていく

◇ストーリマップはシンプルさを保っている
・ストーリマップはとてもシンプル
　→そこに何を書いてもいい
・「UMLにして他の情報かけるようにしろ」という人もいる
　→そうはしない。そうしてシンプルさを保っている

◇ストーリーのスライス
・基準となる線を用意し、ストーリーを上下にスライスする
　→スライスにカードを割り当てその中でカードを動かし、各スライスのゴールを決める
1. 機能単位で分割線を引き（スライスの作成）、ストーリーを各スライスに割り当てていく
2. 重要な機能のスライスからこなす
（3. スライスが完了すれば、ユーザに価値のある大きさで提供ができる）

青い線がスライス


◇ユーザーストーリーマッピングとは何か？
・ストーリーはバラバラになるので、以下の難しいことをやる必要が生じる
　→全体を考える
　→小さいものを組み合わせて1つにする
　→→これは難しい
・これも難しい
　→全体としてどういう機能があるか
　→細かいアイテムってどういう価値があるものなの？
　→→バックログアイテムを細かく見ていくときにここで苦労する
・解決策としてストーリマッピングを提唱している

◇世界中から写真を送ってもらっている
・いろいろな世界から「クールだろ」と写真が送られてくる
・本どおりではなく、それぞれにあったやり方でやっている

◇平鍋さんの気付き
・ケントベックが提唱していたストーリーとは
　→話すこと
　→「As a xxx In order to...」というフォーマットのことではない（それが悪いわけではない）
・アジャイルに見せるときに、ビジュアルが持っている強さ　






Jeff Patton様, 平鍋健児様, 永和システムマネジメント様, ・アギレルゴコンサルティング様, 楽天様、ありがとうございました。

『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』ノート

2012/09/25に開催された『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』のノートです。
もっといい話をたくさん聞いていたような気がするのですが、あまり残っていないような　…メモ力をもっと高めていきたいです。


◆ウォーターフォールのコンセンサスを作りましょう

◇歴史的背景と現状
起源は1970年代に発表されたWinston Royceの論文。
ただ、これはバッチ生産のためのパラダイムのものであり、所謂ウォーターフォールではない。

Winston Royce - Managing the Development of Large Software Systems
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

◇ウォーターフォール開発プロセスの歴史
1. Winston Royce 「Managing the Development of Large Software Systems」
　→大規模ソフトウェア開発に関する論文。ウォーターフォールという言葉は使っていない。概念もだいぶ違う。ただ、ウォーターフォールはこの論文を元に開発されている。
2. 米国防総省「DOD-STD2167」
　→手戻りなしの規格がこれ。それまでは標準になるような開発プロセスがなかったので、流行った。
3. 米国防総省「MIL-STD-498」
 →ウォーターフォールがうまくいかなかったので、改めて繰り返し開発の良さを認めた。
4. CMU/SEI「Considerations for Using Agile in DoD Acquisition」
　→アジャイルを使うときの手引き

◇ロイスの論文について
・ウォーターフォールは小規模で自らが使うソフトなら充分かつ合理的
・ウォーターフォールは大規模だとうまくいかない
　→直接的には最終成果物に関わらない追加的工程が必要。
　→なければ失敗する。
　→→オーバーヘッドがあれば妥当に失敗する
　→→なければ失敗が発散する。
・壮大なプロセスを踏まないと発散する
・1回きりではうまくいかない
・反復する
・一つ前の工程に戻ることは想定内
　→それは設計が洗練される行為なので望ましい。
　→反復が局所化されない場合（2つ以上手戻りする場合）はリスクになる
　→→最後のテスト工程で出てくるのは一番まずい。
・テスト工程で明らかになると、手戻りが大きいのでなんとかしないといけない

◇リスクを限定するための5個のステップ
1. Preliminary
　→プログラムデザイン（アーキテクチャ設計）をする
2. 仕様の見える化
　→コミュニケーションの媒体（各種引継ぎのため）。品質の見える化
　→あと、結構な量のドキュメント
　→要求定義書。構想定義書。インタフェース設計書。決定仕様。テスト計画、実施結果、使い方。
3, Do It Twice
　→開発工程を2度
　→プロトタイピング
4. plan, control and monitor testing
　→工数を使うしリリース直前なので、非常にリスクがあり、注力しないといけない
　→テスト計画。進捗把握、品質コントロール
5. 顧客を巻き込む
　→アーキテクチャ設計レビュー
　→実装の設計レビュー
　→受け取り検査

◇ロイスがいいたかったこと
・大規模ソフトウェア開発には特有の課題がある
　→小さいソフトウェアの大きい版ではない
・管理強化・工程の細分化が必要
・管理のためのオーバーヘッドを認識しないといけない
・過小評価するととんでもない失敗をする

◇誤解と偏見
・手戻りあり
・失敗のリスクを限定するためのもの
・リスクに対するコストや時間の追加の必要性
・官僚的なプロセスではない

◇ウォーターフォールはなぜ支持が根強いか
・建設・インフラ開発のアナロジー
・生産工程のアナロジー
・当時は開発プロセスがなかったのでウォーターフォールでもうまくいき、成功体験になった
・水の流れはどこかに落ち着く言うメタファがあり、これが意外と強力


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

◇ウォーターフォールとアジャイルの対比1
・ウォーターフォール
　→作業の分割統治（タスクを積み重ねる）
　→工程表
・アジャイル
　→成果の分割統治
　→達成すること(done)を積み重ねる
　→バックログ

◇ウォーターフォールとアジャイルの対比2
・ウォーターフォール
　→マイルストーン
　→プロジェクトコントロール
　→事前に要求の範囲とレベルを明確にし、成果物を確認
・アジャイル
　→タイムボックス
　→環境・条件の調整
　→つど状況に応じて要求の優先順位を明確にして達成を確認

◇ウォーターフォールの難点
・初期の要求がなかなか確定しない場合
・後の工程になって要求が変更になる場合
・事前よ予見しきれない技術課題
・リスク管理とその運用の難しさ
・コミュニケーションの質の悪化
・官僚的な追加作業

◇アジャイルの難点
・品質保証基準の確立
　→ウォーターフォールは履歴情報を使うことで統計的手法を利用できる
　→→工程と品質基準を結びつけることができる（結びついている）ということ
　→アジャイルはそれができない

◇ウォーターフォール開発を適用する場合
・経験豊富で予見性が高い
・再現性の高い作業の集約になっていて計画できる
・大量の単純作業で労働集約的

◇アジャイル開発を適用する場合
・小規模、少人数
・不確定要素が多く予見性が低い
・リスクが高い
・継続的に保守・拡張する場合
・探索的な試行錯誤が必要な場合


◆まとめ
・「よくわからないけど、とにかくうまくいけばいい」というのは当てものでしかないので学習効果が期待できない
・自分にとっての解決するべき問題やその前提条件を具体的に認知できれば対策は見えてくるはず


◆質疑応答
Q.
「wfのメリットが使える現場ってもうないのでは？」

A.
「あるのは事実。だけど、目指すべきではない。」


◆参加者の意見
・ゲーム業界の場合は、コンカレント型かもしれない
　→コードはアジャイルだけど
　→デザインは違う
　→→いったん決まると、大量のアーティストがキャラクタを作ったりする
・デザイナは音楽聴きながら作業したりする
・プログラム側はほとんどそういうことをしていない
　→それはプログラミングにはコミュニケーションが必要だから


◆補足

・告知・募集ページ
当日のプレゼンテーションのスライド、講演動画のURLが公開されております。
→http://agileucdja.doorkeeper.jp/events/1736

・当日のプレゼンテーションスライド

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い from Yoichi Tamamaki

玉牧 陽一様, アジャイルUCD研究会様、ありがとうございました。

『アジャイルサムライ横浜道場 特別編 パネルディスカッション』ノート

2012/09/06日に開催された『アジャイルサムライ横浜道場　特別編　パネルディスカッション』のノートです。

http://www.zusaar.com/event/355105


誰が何を発言したかというところで曖昧なところがあったので、話者の名前は全て伏せました。



◆インセプションデッキ使ったことはあるか？

◇登壇者A
・契約した段階でやることは決まるので、インセプションデッキをやったことはない
・それよりはチームビルディングをやっている
　→プロジェクトが始まったら、なぜここにいるか？をやる
　→これをやるとだんだんベクトルがあってくると思って活動を続けている

◇登壇者B
・実はアジャイルをやっていない
・アジャイルやる理由には方向づけが必要
・「とりあえず、イテレーションや振り返りをやっているからアジャイル」みたいな所も多い

◇登壇者C
・アジャイルは変化に対応すること
・アジャイルでは振り返りが一番大事だと思う
・振り返りの中から方向付けを行っている
・最初に決めたことは正しいとは思っていない
・何をやっていて何を目指すか、という方向付けは変わっていく

◇登壇者D
・結論として方向付けを失敗した
　→受託した段階で、お客様には何かしらの課題がある
　→参加したプロジェクトでは課題は明確だった
　→お客様に現状維持というところがあった
　→こちらから提案をして遂行していた
　→こちらとしての意向もあったが、そちらにはならなかった
・インセプションデッキでもなんでもよいので、お客様が抱えている問題をきちんと共有する必要がある

◇登壇者E
・チームがあって、チームである程度何を作るかが決まっている。
　→方向付けはそこでできていいる。
・インセプションデッキを作って一番盛り上がったのは、やらないことリスト
　→チームメンバーででやると考えていることがバラバラだった
　→これが方向付けになって盛り上がった

◇登壇者F
・アジャイルでやりたいという話がくる、このときに「やり始めたら上司は基本的に口を出さない」と約束する
・最初はチームはうまく回らない
　→心配になっても口は出さない
　→気になるなら私に相談しろと言う
・チームには段階がある
　→まずは期待や課題・やって欲しいこと（TiDD・タイムボックス的なもの）を伝える
　→やったら次の希望を言う
　→次に一時間面談を行う
　→→「あなたは何をやりたいか、どういう方向性をやりたいか」「こちらとして期待するものは何か」など
・そうやってチームとしてやりたいことの暗黙知をためていって、方向付けをしている


◆方向付けフェーズやお客さんの意向を探るときなど、どうしているか？

◇登壇者C
・今はご年配が使うシステムを作っている
　→そこでの使いやすさは"自分の使いやすさ"とは違う
　→想像して、ヒアリングして、ちゃんと対象の具体的なデータを集めてこないと具体的な方向性は出せない
　→→そこで手を抜くと、内側によった自分達だけが考えたシステムになってしまう
・自分達が生みだす価値が何かを考えたら、使う人をできるだけ想定するしかない
　→使うターゲットが明確なら楽

◇モデレータA
「自分は農協のシステムでタブをつけたら、それは誰も使わないと言われたことがある」

◇登壇者B
・ユーザ会社とシステム会社の偉い人で方向付けが違うことがある
　→そうすると作っても平謝りするハメになる
　→「そもそも何を作ろうか？」「何のために？」「何を効率化しようとしてたの？」というのをやらないといけない
・理解できないものに100%の頭を使うことはできない。

◇登壇者C
・大きいシステムだと全員に周知できないのが問題だと思っている
・方向をごく一部の人が握っているだけだとうまくいかない
・その齟齬を解消しようとするのがアジャイル

◇登壇者D
・お客様のほうで制度を変えようという話があって、お客・コンサル・偉い人の話は合っていた
　→でもそれぞれ方向付けは違っていたのかな？と思う


◆みんなの方向がバラバラだと気付いたときにどうしたか？

◇登壇者B
・バラバラなのは話がまとまってないから
・おなかがすいているというのが一致していても、それぞれの状態が異なる（とにかく食べたい、空腹だけど胃もたれしている…など）

◇登壇者F
・似たような状況があった
　→POはある程度の責任を持っている
　→でも彼がユーザにとって本当にいいアイデアを持っているかというと、そうではない
　→そうなるとPOに対して、いい関係を作ったりモデリングをしても答えが出ない
　→そうするとPOはしょうがないとして、エンドユーザを見つけてそこにアプローチしようとしている。
　→→でもエンドユーザは忙しい
　→→その上の人に働きかけして、デモの時間をもらったりした
　→→そうやって少しずつ関係を作っている
　→→→そうやるとチームが顧客の欲しいものについて考え始める

◇モデレータB
・そもそも人のことを知らなさ過ぎると思う
　→10年後何をしたいかとか、家族のこととか
・何でそれが問題かというと、チームを同じ方向に向けるときに全員に同じやり方ではうまくいかないから
　→「ならば、チームのことをしらないでどう働きかけるんだ？」という話になる
　→「お客はもちろんだが、チームを知るために何をしているか？」という話

◇モデレータB
・向け方はいろいろある

◇登壇者F
・強制しても向かないので、向くようにする必要がある

◇登壇者C
・人はかえられることを嫌がる。変わるようなヒントを提示しないといけない

◇登壇者F
・だから先に聞く
・そこから「そこを僕は期待している」というと喜んでもらえる
　→その人のキャリアも含めてモチベーションを上げていくことを考える

◇登壇者C
・どうしても合わない人もいると思う

◇登壇者A
・みんな人間なので、そこは信頼関係
・相手が困っていることを助け、信頼してもらうことを繰り返し、関係を築く
　→そうすると、こちらがやりたいことができるようになる

◇モデレータA
・チームにコミットしてもらい、チームとしてプロダクトにコミットしてもらわないといけない

◇モデレータC
・作るべきフェーズがとっくに終わってるのに、インセプションデッキが入って無いという話があったが…
→インセプションデッキはいつ作ってもよいもの


◆アジャイルをやると問題が早く見つかって早く対処できるという。本当に？

アジャイルで見つかるものも見つからないものもあると思うが？

◇登壇者C
・アーキテクチャの根幹に関わるようなもので、ちょうど見つからない問題があった
　→アジャイルはコミュニケーションを活発にする手段
　→→チームでは活発的になって、その中で出るような話題は見つかる
　→その隣のステークホルダー、想定しきれなかったユーザの持っている問題は見つけられない
　→→→それで酷い目にあったりする
・コンセンサスが取れていたというところで思い込みがあった
　→それはアジャイルどうこうというより対話のミス
　→そういうものはアジャイルでも取れないよ？

◇モデレータC
「その問題はなんで見つかったの？」

◇登壇者C
「リリース前に想定していたユーザに話をしたときに突っ込まれた」

◇モデレータB
「ポイントポイントでデモしてなかったんですか？
顧客プロキシにはデモしていたけど、顧客にはしていなかったってこと？」

◇登壇者C
「そう」

◇登壇者A
「前向きに捕らえたらリリース前に見つかったという話では」

◇登壇者C
「そうだけど、そのときに作ったひずみで今苦労しているという」

◇モデレータB
「アジャイルで早く見つかるものとそうでないものがある」

◇登壇者A
「今のケースは早くフィードバックを貰えたからいいのでは？」

◇モデレータB
「今のはウォーターフォールでも同じでしょ？」

◇参加者
「逆にアジャイルだからこそ見つからなかったことって？」

◇登壇者B
「アジャイルでは問題がイテレーションごとに解決される。
お客様が暗黙に期待してしまうことがある。
いつか何とかしてくれるでしょ？という」

◇モデレータB
「それはプロダクトバックログの運用ミスのような気がする」


◆参加者
「新しく機能が発生したゆえに、前の問題が出てきたことは？」

◇登壇者A
・ジャストインタイムで機能を提供していたときがあった
　→増改築の繰り返していた
　→何ヶ月かあとにアーキテクチャが破綻した

◇モデレータA
「それはじっくり設計したら回避できたパターン？」

◇登壇者A
「どこかでリファクタリングしていればどうにかなったと思うが、ある程度大きくなるとどうにもならない」

◇モデレータA
「リファクタリングしていればなんとかなった？」

◇登壇者A
「傷は浅かったと思う」

◇登壇者C
「リファクタリングし損ねたのと、アーキテクチャが破綻していたのは別」

◇モデレータA
・リファクタリングっていうのは、ご飯があふれているかきっちり詰まっているかの話でしかない
　→そこに入らないものはそもそも入らない

◇登壇者F
・今のような事例が起きたら、まずチームに問題があったのでは？と考える
　→案件やチームによって、その事態の重要度は違う
　→自己組織化が基本なので、それはチームで答えを出してもらって次に生かしてもらうようにしている
　→→要はチームの力不足
　→→本当は隣の人にも気をつけないといけなかった
　→→それはウォーターフォールでもアジャイルでも変らない
　→→ならどうして最初から考えられなかったのか？というのを促す


◆モデレータA
「チームの力で解決できると言う話であれば　…すごいチームなら何でもできる？」

◇登壇者F
・精鋭が集まればウォーターフォールでもアジャイルでも何でもできる
　→だから、問題にチームでアプローチし、チームなりに答えを出してもらう

◇登壇者D
・早くお客に見せていて気がついたことがある
　→コンサルのいうとおりに作っても、お客に「違うよ」という風に言われる
　→→コンサルの方向とお客の方向は違う
　→→アジャイルならそれを拾っていける

◇モデレータA
「実はコンサルが言っていることが正しくて、ユーザが間違っている場合があると思う。自分の中でユーザ側に倒した理由は？」

◇登壇者D
「お客様の声がすごい強かった」

◇モデレータA
「確実に地獄行きでも？」

◇登壇者D
「そこは取捨選択した」

◇モデレータB
・どのくらいの地獄かによる
→マイルドな地獄なら行かせる
→会社がやばくなるなら絶対とめる

◇モデレータD
「アジャイルかどうかと問題が早く見つかるかはあまり関係ないような気がする」

◇登壇者E
・アジャイルじゃないと「問題が見つからない」と言って隠す
　→アジャイルだと隠しようがない
・今までだと（作成中に）必要だとわかっていても、その時点ではやらなかった
→そのまま作って、使いにくくなってからやっていた
→アジャイルだとその段階で手を入れられる

◇登壇者D
・けっこう頻繁に聞けたときはあまり炎上しなかった
→結局、コミュニケーションがとれてないと駄目


◆ウォーターフォールについて

◇モデレータA
・ウォーターフォールはある時点での幸せな話
　→後で本当かどうかは誰にもわからない
・ウォーターフォールで違ったら、また滝を流せばよいだけ
　→そこでとめてしまうというのがそもそもの原因
　→→スパイラルで回せば解決するのでは？


◆ストーリーは必要になったら詳細化すればよいというが、そもそも詳細にしないと分からないことがあるよね？ということについて

◇参加者
・ユーザストーリのときは詳細に分析するなというが…
　→普通の人の場合、具体的な画面や例外ルールを見せて初めて気付いてくれることがある
　→→詳細な分析をして始めてユーザが受け答えできるという話
・詳細な分析をしてみないと、アーキテクチャに関わるような問題が見つからない場合がある
　→そこは難しい？

◇登壇者A
　→→それはリスクをどうヘッジするかと言う話
　→→→やったことがないというリスクを最優先にするか、価値を最優先にするか

◇参加者
アーキテクチャに関わるところはリスクだから最初にやろうということ

◇登壇者F
・平鍋さんが言っていたこと
　→ショートケーキを小さく作るのと同じで、アーキテクチャも本当に薄く作っていく
　→それでうまくいくのではないかと思ってやっている
　→アーキテクチャもアジャイル的に育てていっている

◇参加者
・ファウラーも「アプリもアーキテクチャも同じ人がやっていないと分厚くなる」言っていた

◇登壇者F
・チームでコミュニケーションできるようにして、横のつながりを作っている
・3週間枚に集まってアーキテクチャやフレームワークを入れていってもらっている


◆モデレータA
「アジャイルを始めるにあたっての最初の問題は？」

◇登壇者E
・ベロシティが0だった
・ストーリが大きすぎた上に、何をしたらいいのか分からない状態だった
・そこがわかってからはよくなった

◇モデレータC
「それは問題？見つかってよかったね？」という話では？


◆モデレータD
「誰も興味を持ってくれないとかは？」

◇モデレータD
・飲み会でうんというまでやるとか
・力を見せるとか
・最初から全ては使えないので一部分だけ使って効果を見せたり
・早く帰ることができるようにしたりとか

◇登壇者D
・名前で言うと拒否られるというのはあるんじゃないかな
　→アジャイルと言う名前を出さないときはよかった
　→アジャイルといった瞬間に「えー？」と言われた

◇登壇者C
・朝会が長いと言うのがある
　→チームにしゃべる人がいると長くなる
　→→個別の状況に入ったりとか
　→→→そういうときはきらないといけない

◇参加者
「それってファシリテーションの能力では？」

◇登壇者C
・そういう人がいるとわかっていても、結局長くなる
・的確な時間に収めるというのはやはり難しい

◇参加者
・朝会の問題は、毎日進捗会議をすることになってしまうということ

◇参加者
・朝会のあるある　…集まらないということが多い

◇モデレータB
・特定の人がいないと集まらないとか

◇モデレータA
・最初に席をたつ人はいつも同じとか


◆モデレータA
「振り返りとかで何かないですか？」

◇モデレータA
・問題を人に落とすというのがある
　→チームではなくて、犯人探しになるとか

◇登壇者F
・KPTがどんどんたまっていった
　→何をどうしたらいいか分からなくなったことがあった
・問題には新鮮さが必要
　→3週間前の問題なんかだんだん忘れてしまう

◇モデレータA
・賞味期限を決めて自動で捨てる人もいる

◇モデレータB
・アクションがないからそうなる
　→Doneの定義がないとなりがち

◇登壇者B
「KPTに何かアクションがとれなくて、ただの愚痴になる状況がある」

◇モデレータA
「制度と会社と仕組みのせい」というのが最初は出がち

◇モデレータB
・そういうのが多いのはもう組織の問題
・チームで拾えないものはマネージャが拾わないといけない
　→こんなこと無理だろうなと思って出てこなくなることの方が怖い

◇登壇者A
・顧客不在
・担当の方が日常業務を持っていて時間をとれないとか
・POが業務知識が薄かったり倒れたりして、来なくなったことがあった


◆そもそもアジャイルをやるスキルがない

◇？
・ペアプロでいいのでは？
・そういうのをやりたがらない文化がある

◇モデレータA
「空気を読んだり、気にしたらダメ」

◇登壇者C
・アジャイルをやるときのチームの意識を一定ラインに保たないとダレる
　→自分の中の人の規律を守らせないといけない
　→守らなかったからって明確なペナルティがあるわけではなくて、緩やかにダレていく
　→→そこでスクラムマスターが欲しいと思う。


◆モデレータB
「個人のバイオリズムもあるのでは？」

◇登壇者C
・気が乗らないとかそういう心理的なものを維持するのは本当に難しい
・でもそれができないとどんどんダレる


◆登壇者A
「だれる原因は？慣れとか？」

◇登壇者C
・自分自身のチームへの責任感をどこまで取れるか
・無理をするというのはアジャイルではない
　→確実にやれる範囲をやるというのはあるが、そこに甘えるとどんどん下がっていく


◆モデレータA
・それは期待マネジメントでは？
　→いつも真面目じゃなくていいのでは？

◇モデレータA
・これらは別
　→アジャイルやるぞ！というテンションの時のオーバーコミット的なもの、それがが落ち着いている
　→単にだれている

◇登壇者D
・ベロシティを計測していたら、見積もりも苦しまずにすむようになった

◇登壇者C
・やれる範囲の見込みがあがった

◇モデレータC
・見積もりの精度も上がった


◆モデレータA
「ベロシティって伸びてる？」

◇登壇者D
ちょっと伸びてるかもしれない

◇モデレータA
伸びてるならいい

◇登壇者D
・残業していないので、けっこう自習する時間がとれていろいろ見えてくるというのがある


◆参加者
「チームのベロシティの上がり具合というのは？」

◇登壇者C
「CI、ユニットテストを明確に意識してくれるようになった」

◇登壇者A
「もうちょっと進むとプラクティスがあるのは当たり前になる」


◆モデレータA
「お客様の変化ってありませんでした？」

◇登壇者B
・アジャイルをやったらフィードバックが早くなった
　→お客様がなんでも言うようになった
・聞き分けもよくなった
　→今まで見たいな無理押しがなくなった

◇登壇者D
・お客様とコミュニケーションを取っている
　→お互いに言いやすくなって信頼関係が築けるようになる

◇登壇者E
・メンバーが明るくなった
　→今まではもくもくとやっているだけだった
　→手が空いたら他の人を手伝ってくれるようになったり、活発になったような

◇明るくなったメンバー
・なんか明るくなったねって言われた
・「進んでこれやったらもっと楽になるのに…」というのをやるのに抵抗がなくなった
・やってもいいんだという気付きがあった

◇モデレータA
・前の会社でカスタマサポート向けの仕事をしていた
　→その仕事を何のためにやっているか、お客様の誰も知らなかった
　→お客様にプロダクトバックログを作ってもらった
　→→そうしたら、お客様が「最終的に会社の業績を良くするためには？」と考えるようになった
　→→→それはすごくよいと思った
　→→→これが最終形だと思う







アジャイルサムライ読書会 横浜道場事務局の皆様, モデレータの皆様, パネリストの皆様、ありがとうございました。

『アジャイルサムライ読書会 新宿道場#10 - トークセッション』ノート

2012/09/01に開催された『アジャイルサムライ読書会 新宿道場#10』のノート。これは前半のトークセッションです。やはり、マスターセンセイの体験から語られる言葉は一味違うというか　…私とは経験値が圧倒的に違うということを痛切に感じました。

何年か後に読み返したときに、今とはまた違った角度から読むことができれるくらいに経験を積んでいきたいと思います。



◆トークセッション

◇マスターセンセイ

・西村直人氏
・角谷信太郎氏


◇質疑応答

※「」がついている発言がマスターセンセイのものとは限りません。ご了承ください


Q. アジャイルやりたい人の転職率の高さは何か？

A. アジャイルはチーム開発。チームでないと始められない

「1人でペアプロしている時期もあった。少しずつ回りを巻き込めたが、本を読んでいるうちにもっと速いペースでやりたくなった」

「「あの人とやりたい！」か「会社を変えたい！」のどちらのパッションがあるかで行動が変わる」

「会社を変えることにパッションがある人もある。会社を変えるのはまた別のパッションということ。自分はそうではないので会社を変えた」



Q. 転職したらハッピーになれるのか？
Q. 転職してすぐにハッピーになれるのか？

A. 自分が転職したときは「アジャイルやってないよ？」といわれた

「客先常駐の仕事ばっかりだった」

「社内の勉強会、プロジェクト間での情報交換などをやっていた」

「アジャイルなプロジェクトはなかったので、アジャイルにできるところは勝手にアジャイルにして始めた。カンバンとか朝会も勝手に始めた」

「現場は少しずつよくなっていった。自分達のやり方が認められることはあったが、それでも変わらないことはあった」

「そのうち、二重にやることの限界が分かってきた。途中から「自分達で仕事を作るぞー」と集まってどうやって契約を取れるかを集まってやった」

「自分で客を取ってまで仕事をするぞ！という人が多かったので、勝算があるとは思っていた」

「売り上げのことは必ず言われる。数字さえ取れば文句は言われない」

「東京は手ぶらできたので色がなかった。自分達で開拓できた。「今までやっていた」ものがなかったのでやりやすかった」



Q. アジャイルって儲かるの？

A. あまり儲からない

「（アジャイルコーチは）いなくてもできるようにするのが仕事なので難しい」



Q. アジャイルの利点は適正なお金で働けること。儲かりすぎたらいけない。と聞いていたので安心した

A. もうちょっと儲かりたいとは思う

「食べられるかというと　…なんとか食べられる」

「もらえる額が決まっている場合、長期間働かされるのでしんどいが、アジャイルはやっただけなのでそこはよい」

「ただ、終わったらそこで終わりなので…」



Q. アジャイルってエンジニアのマインド・スキルが重要だという意識があるが？

A. チームでできるようになっていればかまわない。チームのスキルセットが偏るのはよくない

「スキル重要と呼ばれていく現場は、だいたいレベルが低い（アジャイルをやる以前で、そもそものスキルが低い）」

「お客に価値を届けるという人が多ければ価値をとどけやすい」

「今できない人もプロジェクトの中で学んでいけばいい」

「それは上の人がどれだけ関わるか。成果を出すためにどうすればいいか考えてくれれば結果が出る」

「集めてスクラムやって、だとそこそこの成果しかでない。」

「みんなにアジャイルの価値観がなくてもできる」

「最初は違っても、実際やれば化ける人がいる」」

「縦でスライスして動かすやり方を知り、今までとは違うやり方で成果が出せると気付くと変わる人いる」

「ユーザーからのフィードバックがあると、やっている方も面白く感じる」



Q. キャリアが与えられるものから自分で作るものとなってやる気が出るのか？

A. そうかもしれない

「チーム振り返ってもらうと「仕事の幅・視点が広がった」というフィードバックが多くもらえる」



Q. 与えられるものへの認識が"苦痛"から"もっとやりたいもの"へ変わるというところもあるか？

A. 何がヒットするかは人による

「押しても引いてもだめだという人もいる。絶対変わりたくない人もいるけど、それは100人に1人か2人。だいたいは（度合いはあるけど）順応できる」



Q. 仲間がいないとつらいというのがある。そこへのアドバイスは？

A. やりたい人がいるところに行くのがよいのでは？　一番お勧め！

「プロジェクトの進め方などについては話合うが、そもそも仕事をどうすべきか？ということを会社で普通に話すことはない（飲み会はともかく）。そのような会議体はないし、定例で行ったりもしない」

「言わないだけで考えている人はいる。送別会で「実は…」と切り出す人がいたりして「おいおい！遅いよ！」となることはある」



Q. 失敗談とかありますか？

A. 「なんとかうまく行ったけど、もう一回やれば（もっと）うまくいく！」というのはある。（そういう意味では）失敗ばかりしている

「お客さんの期待をコントロールし、どこまでできるか理解してもうことは重要」

「きちんと踏み込むことも重要」

「リリースにあたっての重要人物や本当の目的などのTough questionも重要」

「"安請負"や"やれると思ってた"で失敗することが多い」

「お客様から言われたことをただやれば価値になると思っていた時もあった」

「「ツールがこうしろと言っている。だからこうする」というのは駄目」

「ツールのせいにしたり、手順を強要したりするのは駄目」

「失敗をアジャイルのせいにするのはよくない。プロジェクトは1回しかないので、何かのせいにするしかないが…　でも、そういうところはアジャイルでなくても失敗する」



Q. ?

「今までの仕事のやり方とは変えていかないといけない」

「昔からある会社は（昔から）違うやり方をしているから、（変化を）やりづらくなっている。大きい組織なら少しずつ変えていくしかない。」

「組織のとしての理解・サポートが重要」

「決める人と作る人の距離を近くしないといけない」



Q. 書類を求めるような、「がちがちに作ってあるから変化に対応する必要がない」と、言っている現場にはアジャイルは向かないと思うが？

A. 「変化しない、タスクがぶれない、要求がぶれない」というのであれば無理してやらなくていい



Q.  テストが実装工程の後にあるプロジェクトの場合、テストファーストで書いていると（バグ発生率などで）困ってしまう。どうすれば？

A. 自分達が書いたテストを後工程でまとめて資料にする

「ついでに既に書いたテストを整理するのもよい」



Q. 大事な要素が後になって判明して大変なことになることがある。どうすれば？

A. わかってから着手すればよい。

「全部決めるのは難しいが一週間なら決められるよね？というのがアジャイル。先のことは難しいという話。フィックスしたものを作ればよい」

「逆はWBSの「先の話は見切ったー！」という話。でも三ヶ月後なんてわからない」

「考えたり、アイデアを出したり、というのも普通にストーリーに入れたりする。あやふやなものを細かくちぎってストーリーにするのが正しい」

「『ふわふわしたものをただ「アジャイルに」とやってもうまくいかない。ただそれはウォーターフォールでもアジャイルでも同じ」

「ユーザはストーリを書けない。それでは価値を計測することもできない。お客様のほうに説明することも大事」

「いったん小さくてもいいから決める。それに対して追加・変更を行う」

「ミニマムでも完成させれば、それは使えるものなので、そこにたいして追加・変更をもらう」

「「できません」とは言わない。「やるけど、できる量は決まっているのでどちらにしますか？」とする。それが変化に対応するということ」



Q. ?

「詳細設計が終わってドキュメントを作っても、結局やり直すことになる。引き継ぐならただ読むだけならだめで、その後ろにあるものも理解する必要があるから。「製造して」とドキュメントを渡されても、製造側は結局全部やることになる。」

「製造フェーズで全部やり直すことがあって、それを詳細要件定義と呼称したことがあった」



Q. ドキュメントをどれだけ作る？

A.  必要なものは作る

「中の人はほとんどドキュメントがいらない」

「お客などに毎日会う環境はいずれなくなる。自分達以外の誰かに引きつぐときにドキュメントを残す必要がある」

「ユーザに合わせて作る」

「全部作るかと言うとそうではなくて、減らせるものは減らせる」

「ドキュメントを書くかわりに、（動作を理解するための）スクリプトは全部作る、というやり方もある。そういう場合、こちらから自信をもって説明することが必要」



Q. 後から入ってくる人向けのドキュメントは？

A. 毎週入ってくるなら作る

「聞いたほうがドキュメントを作るのは良いプラクティス。ドキュメントができあがるので、教える側にもメリットがある」

「何が判らないのか、教える側には分からない。だから聞いた側がドキュメントを作る方がよい」



Q. その日のうちに作ってくれと言う現場があって、そういうところだとエンジニアには無限の負荷がかかる。ユーザ側から見た品質も悪い。そういう現場で人間らしい働き方をするためには？

A. まず見える化

「物凄い量の仕事が来ていることをきちんと見せる。あからさまにおかしいという状況を見せれば、口答えできる」

「退社時間や睡眠時間の見える化も有効」

「見せれば偉い人の誰かが気付く。気づかないなら、それは…」



◇その他

「イテレーションの運営の話について、アジャイルサムライの206ページにしれっと大事なことが書いてある」

「"昨日のテレビの面白いこと"と同列で"アジャイルをやりたい"では誰も信用しない。やはりパッションが必要」

「意外と学習効率って悪くて、学ぶには時間がかかることに気をつける。業務時間外に勉強会などに参加して学んでいる人と、たまたま隣の机に座っている人。使っている時間が全然違う」






西村直人様、角谷信太郎様、tmmkr様、tk0miya様、eji様、ありがとうございました。

Agile Conference Tokyo 2012 『【事例】エンタープライズアジャイル開発における組織と顧客の役割 』ノート

2012/07/19に開催された、Agile Conference Tokyoの講演『【事例】エンタープライズアジャイル開発における組織と顧客の役割 』のノートです。




目次

◆講演について

◇はじめに

◇アジャイルをスケールアップさせるにはどうしたらよいのか？

◇今日もって帰ってもらいたいヒント


◆我々がやっているプロセス : Conversation

◇Conversationの流れ

◇Conversationのポイント

• 仕事についての学び
• 仕事をブレークダウン
• 優先順位付けされたバックログ
• チーム構築
• 価値を届ける

◆導入の事例 : マネージャへ

◇概要

◇ゲストスピーカー

◇作業のブレークダウン

◇優先順位付け

◇フィーチャーチーム

◇その他やったこと


◆導入の事例 : チームへ

◇質問を集める

◇キックオフミーティング

◇キックオフミーティングから学んだこと

• 透明性
• 何ではなく何故
• 引き継ぎ

◇イテレーション1

◇まとめ


◆質疑応答




ノート

◆講演について

◇はじめに

組織がアジャイルになっていくプロセスを考えたとき、アジャイル的なやり方・慣行を行ってアジャイルにしていく場合が多いと思います。

しかし、アジャイル的なやり方・慣行は非常に沢山あります。

「1つの会社をアジャイル化するぞ！」というときにはそれだけの考えが必要であるということです。

「これを大企業でやった場合どうなるか？」という事例を今日は見せます。


◇アジャイルをスケールアップさせるにはどうしたらよいのか？

一度に全てやるのではなく、少しずつやるのがよいでしょう。

"Concept to cash"（すぐに何かを出して認証してもらう）という言葉があります。

"Window of change"（変化で生じる差）という言葉があります。

一度にやるわけではありませんが、変化をきちんと見せていくことが大事です。

変化はスケーラブルでなければいけません。

メンバーはそれに合わせて動けないといけません。


◇今日もって帰ってもらいたいヒント

シングルバックログを作りましょう。会社・ビジネスユニット・チームで使える単一のバックログです。

チームメンバーがころころ変わらないようにしましょう。同じチームで違う仕事に入っていくということです。

安定したチームが存在し、その中にある障壁をマネージャが解決していく、というやり方にしましょう。

また、スケーラブルでなければいけないということを考慮した場合、ミニマルなプラクティス、慣行を決めなければいけなません。

そして、これは忘れてはいけないことですが　…

チームはいつもアジャイルでないといけません。

意思決定はチームがしなければいけません

（ここでいうチームには百人単位のビジネスユニットなども含みます）。



◆我々がやっていること : Conversation

◇Conversationの流れ

1. まず、作業そのものが入ってきます


2. study demand and need

それについて学習・勉強します


3. work breakdown

細かく分けます。作る側・発注側それぞれに分かるようにしながら作業を進めていきます


4. work prioritisation

優先順位を決めます。まずは一番価値があって時間がかからないもの。それから、その次を考えます

・一番優先順位が高いものは？
・その次にしなければいけないことは？


5. work distribution

次は取り決め。どのチームが成果物を持ってくるかを決めます


6. taem construct

取り決めがはっきりしたら、どのようなスキルセットを持つ人材が必要かを考えて人を集めます


7. doing the work

実際にやります


8. poissible vakue delivered

検証し、最初に戻ります


◇Conversationのポイント

・仕事についての学び

どのような作業が入ってくるかを知っておきましょう。

これが分からないと、そのたびに「あれを変えないと！」とばたばたして効率がよくないのです。

例えば、どんなことをしてほしいという要求をボードに貼り付けておきましょう。そうやって誰が見ても一目瞭然になります。


・仕事をブレークダウン

どんなに細かいものに分割しても、それはカスタマーに何らかの価値があるものでなければいけません。

一番最初は情報がないかもしれません。でも作業をしていくうちに明らかになっていきます。

見切り発車でも始めることがポイントです。

何度も何度も確認することができるので、何か全てが集まるまで待つよりリスクは全然少ないのです。


・優先順位付けされたバックログ

バックログ項目が小さくなっていることがポイントです。

優先順位つけのための共通のメソッドを決め、優先順位別に作業をソートします。

このとき、ベースラインが何かということを把握しておきましょう。

そうすれば、ベースラインを超えたか下回ったかを図ることができます。


・チーム構築

我々が作りたいのはフィーチャーチームであって、コンポーネントチームではありません。

フィーチャーチームは様々なものを取り入れて作業できます。

コンポーネントチームには特定のことしかできないという弱点があります。

フィーチャーチームなら会社全体が何かを学んでいることになります。

なお、作業によってはスペシャリストをプラスアルファとして加える必要があるかもしれません。


・価値を届ける

成果物を少しずつ顧客にわたし、どのような価値が実現できているか検証しましょう。

どのようになされたか、どのようなアジャイルの慣行が使われたか。

それから、デプロイやリリースがどのようになされたか（継続的なデプロイやリリース）。

最後に、提供したものがお客の望むものだったかを検証します。



◆導入の事例 : マネージャへ

◇概要

9人で5日間のワークショップを行い、『Conversation』について話し合いました。

まず講義。そのあとにはハンズオン。昼食時間にゲストスピーカー（過去に研修を受けた人）を呼びました。


◇ゲストスピーカー

ゲストスピーカーを呼んだことは重要でした。

参加者にはアジャイルへの温度差・経験の差があったからです。

さらに、実際の作業がどのように行われているかの理解についても個人差がありました。

ゲストスピーカーの時間は、何を達成したいのかを共有するためのよい時間になりました。


◇作業のブレークダウン

お客様によって異なる入ってくる作業を細かく分割しました(Work Break Down)。

この作業を更に細かくするにはどうしたらよいでしょうか？

受け入れ基準（許可）のレベル（Acceptance criteria)が何なのかは、1つの基準になります。

また、「どこからお金が入ってきているのか？」というのは優先順位付けとは切っても切り離せません。

もっとも予算を出してくれた部門はそれだけのバリューを受け取ることができます。

お金を出したのが２０％なら、もらえるリターンも20%ということです。

ただ、"お金に関係ない重要なもの"でやっていくことが重要なので、このモデル自体は将来的には変わるかもしれません。

ポートフォリオをざっくりとみるため、それぞれフィボナッチで見積もりました。最終的な見積もりはチームが行います。


◇優先順位付け

WSJF(Weighted shortest job first = 重要で時間がかからないものから)というのがあり、これを導入しました。

非常に短い会話をして、意見ではなく価値に基づいて優先順位付けをしました。


◇フィーチャーチーム

ここが最も難しい部分だといっても過言ではありません。

どのような人材、スキルセットを持った人物をチームに入れるか　…これはマネージャのスキルも求められてけっこう難しいのです。

予算の関係で人を入れられないこともあります。

また、バリューという観点から見た場合、縦型の組織ではないと対応できないということも分かっています。

できるだけ多くの作業を、それが大きくても受け入れられるようなチームを作ろうと思いました。

最も希少な人材をまず振り分けてから、チーム構成を行いました。

チーム構成の際にはアジャイル的なプラクティスも入れました。



◇その他やったこと

Practice-lead（プラクティショナーみたいなもの？）というのを作り、学んだことを他のチームでも共有できるようにしました。

次のプロジェクトでも活用できるように、情報共有を行ったのです。


また、ワークショップ受講者たちの気持ちも計測しました。

「実現可能に思えるか否か」というのを視覚的なチャートで示せるようにし、毎日の研修開始前に調査しました。

初日は「いまひとつ」というのが多かったのですが、だんだん「できる」と思う人が増えています。


そのあと6週間かけて、やろうと決めたことを詳細化しました。

その後、やろうと決めたことについて、4時間のキックオフセッションをやると決めました。

キックオフセッションでは150人（パートナー・ベンダーなど全ての関係者）全員を集めて、やろうと決めたことを説明するのです。



◆導入の事例 : チームへ

◇質問を集める

キックオフに至るまでの時間、マネージャたちはがありとあらゆるものをカベに貼り付けました。

そして、その内容について質問を集めました。


◇キックオフミーティング

このミーティングの開催理由は2つあります。

・これから何が起きるかを教える
・150人という大きい規模のチームにおける懸念について聞く

なぜチェンジが必要なのか、というところから話が始まりました。

「今の状態で変わらなければ、業務に迅速に対応できない」「間違った成果物を届けている」ということについて合意に達し、「だからチェンジが必要だ」という話になりました。


次に150人にフィーチャーチームの説明をし、チームへの振り分けをしました。

それからチームビルディングのための演習をしました。

その後、各々のチーム10分ずつをマネージャが回りました。各チームはそれぞれ違った事柄についてマネージャと話をしていました。

最後はビールを飲んで、CIOのメッセージフィードを受け取りました。


◇キックオフミーティングから学んだこと

このキックオフから3つのことを学びました。

・透明性

全員が学び、何が起きているかわかることはとても大事です。


・"何"ではなく"何故"

マネージャは、誰が何をするかについては説明していましたが、何故については説明していませんでした。

だから、月曜日にマネージャはそれぞれに配属理由を説明して回らないといけませんでした。


・引き継ぎ

既に何かを手がけていて、誰かに引継ぎをしなければいけない人達は苦労していました。


→最後の2つの問題は、1日で解決しました。それだけチームの結びつきが強かったということです。


◇イテレーション1

次のことを2週間の課題としてやってもらいました。

・最初のフィーチャについてディスカバリーセッション（何が争点になるかの話合い）。

・チームに名前を付けてもらいました。

・仕事の進め方についてプランニングをしてもらいました。

・いっしょに食事に行ってもらうなど、何か楽しいことをしてもらいました。

・チームで許されることなどのグラウンドルールを決めてもらいました（ユニークな社会的契約）。

それから、その中で何を学んだかを振り返りしてもらいました。


最後にはショウケースを行いました。

顧客に『何をやったか』と『これから何をするか』を見てもらったのです。

他のチームに『何をやった』ということを発表する機会も設けました。

（ここでショウケースの写真を見せる）


fuzzyに見えるかも知れませんが　…我々はこれを劇的な透過性(Hyper transparency)と呼んでいます。


◇まとめ

いわゆるアジャイル的なやり方もありますが、これだけ大きなスケールで変えるやり方もある、ということです。



◆質疑応答

Q.
たくさんのマネージャをワークショップに呼ぶよう仕向けるにはどうすればよいか？

A.
シニアマネジメントのコミットメントがあってこそ始めて実現できることではないでしょうか。

意思決定する権限が無い中間管理職(Frozen middle)からやるのは難しいのではないのではないかと考えます。

ただ、アジャイルはFrozen middleも一般の人達もやりたいと思っています。



Q.
アジャイルプロセスに積極的ではないメンバをチームに入れるべきか？

A.
大きい会社なら中にはアジャイルをやりたくない人もいるでしょう。

ただ、最初はためらっていたとしても、アジャイルのやり方で大きな成果を上げることができることがわかれば、彼らの考えはどんどん変わります。



Q.
リリース毎ににワークショップを開催したか？

A.
ワークショップはリリース毎に2時間行いました。

アジャイルでは毎日合ってミーティングを行います。

それからスプリント毎にも振り返りを行います。

そこまでやって、意識がすりあっているため、2時間で終わります。



Q.
どのくらいの期間、そのチームにかかわっていたか？

会社全体に広げるときにはチーム毎にコンサルティングしたか？

それとも途中からは社内でやってもらったのか？

A.
基本的には組織が自律するまでがゴールです。

大きい会社にはマネージャや偉い人達がたくさんいます。

9人で5日間のワークショップは彼らを呼んでたくさん行いました。

組織がアジャイルに慣れて普及していけば、フォローしなくてもうまくいけると思います。

我々は企業がアジャイルになれるインフラを提供しています。

企業毎のアジャイルでやれるようになってくれればいいと思います。











Gary O'Brien様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。

Agile Conference Tokyo 2012 『21世紀型ポートフォリオ管理への変革 〜事例による従来型からビジネスアジリティへの革新方法〜』ノート

2012/07/19に開催された、Agile Conference Tokyoの基調講演 『21世紀型ポートフォリオ管理への変革 〜事例による従来型からビジネスアジリティへの革新方法〜』のノートです。



目次

◆20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント


◇20世紀のポートフォリオマネジメント（伝統的なやり方）

• 伝統的なやり方で重視されているものは何か？
• それはどのような（古い）考えに基づいているのか？
• ソフトウェア開発には伝統的なマネジメントの考え方が残っている
• 伝統的なやり方の一部分だけをアジャイルにして効果があるのか？

◇21世紀のポートフォリオマネジメント（リーン・アジャイルなやり方）

• "計画"から"検証による学び"へ
• "渋滞"から"淀みのない流れ"へ
• "チームの頻繁な解散"から"継続することによる学びの蓄積"へ

◆結論

◇結論

• バックログ
• 検証による学び(validated learning)
• ポートフォリオかんばん(Portfolio Kanban Board)
• かんばんの重要さ

◇最後に

• 本当のビジネスアジリティを得るために

◆質疑応答

◇質問







ノート

◆20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント


◇20世紀のポートフォリオマネジメント（伝統的なやり方）

・伝統的なやり方で重視されているものは何か？

伝統的なPMOはガバナンスとコンプライアンスの2つに注目している。

1. ガバナンス

ビジョン・期待される結果からプロジェクトは始まり、プロジェクトタイトルに基づいて予算・リソースが配分される。そして、予算・スケジュールの中できちんと進んでいるかどうかが監視される。

→監視はしていても、価値について見落としている場合がある。


2. コンプライアンス

　プロセスの方にばかり目がいっていて、パフォーマンスがおきざりにされている。
（きちんとプロセスをフォローし、コンプライアンスに対して監査することも重要）。

　→こういうものを重視しすぎるために、顧客が本当に欲しいものを作る路線に乗っているのかを忘れられてしまう場合がある。



…こういったものはどういうところからきているのか？



・それはどのような（古い）考えに基づいているのか？

レフィングウェルは"古い考えに基づくものだが、いたるところにあった現象だ"と書いている。

そして、レフィングウェルはこの古い考え方について、次の指摘をしている。

1. widget engineering

ソフトは製造業のようなものだ、という意識からソフトウェア開発がなされている。図面を書き、それどうりに作れという考え方。


2. order-taker mentality

オーダーをとってから作るという考え方。作れといわれたものを作るというだけの考え方。プロダクトオーナーの考え方もこれに近い（プロダクトオーナー≠スクラムプロダクトオーナー）。


3. Maximize Utilization

そこにあるものを最大限使う。リソースが全て使われていないのであれば、開発でも全て使えないだろうという考え方。
盛りだくさんにしておけば、フィニッシュも盛りだくさんだよね？という考え方。


4. Control Through Milestones

どんなプロジェクトでもマイルストーンについては答えがもらえるという考え方で、マイルストーンについてチームメンバーが言い淀むことがあれば、そこを調べるというやり方。

（プロジェクトによってはマイルストーン自体が非常にファジィであるにも関わらず）。


5. We can plan a full year of projects

1年分のプラン考えることできるという考え方。きちんと計画すればそれをやり遂げることができるという妄想。

失敗する原因はプランニングそのものの何かが崩れているからなので、プランニングさえうまくやれば今年はうまくいくという考え方。


6. Just Get it done

なんでもいいからやれという考え方。
バリバリと推進するようなヒーローが必要で、その周りの人は残業で疲労困憊してしまう。


…非常に馴染み深いものばかりである。

ウォーターフォールメソッドが頭に焼き付いているとなかなかうまくいかない。チームレベルでガイダンスしても、そこから先が未知なので止まってしまうことがある。これを打破してアジャイルにいかないといけない。

レフィングウェルさんはウォーターフォールマインドセットという言葉を使っている。




・ソフトウェア開発には伝統的なマネジメントの考え方が残っている


テイラーは経営科学という世界で非常に有名な人である。

彼は、二人の作業員が一日にどれだけのタスクをこなすことができるかという実験をした。

これを基準値にしてベストプラクティス・標準時間を計るという考え方である。

これがガントチャートに転出され、それに基づいて労働者が働き、基準より早く作業ができればボーナスを出していた。

1900年代初期のやり方であり、馴染み深いやり方でもある。


彼の本は翻訳され日本でもベストセラーになった。WW2が始まるまでの間、日本の産業はテイラーイズムに基づいて成り立っていた。

1948年、日本でCivil Communication Section（民間通信局）による経営講座が行われ、ドラッカー・デミングなどのマネジメントモデルが入ってきた。

1979年には松下幸之助が、自分達のマネジメントが一歩進んでいるという話をするまでになった。


しかし、このような新しいマネジメントの考え方が登場した後でも、ソフトウェア開発の世界にはテイラーイズムの考え方が残っている。

何故だろうか？

もう少し違う考え方でソフトウェア開発に挑んでもよいのではないだろうか？



・伝統的なやり方の一部分だけをアジャイルにして効果があるのか？

ウォーターフォールでもうまく言っているという人がいるかもしれない。では何故そのような変化が必要なのだろうか？。


それは"Window of Stability"がどんどん小さくなっているからだ。

一昔前なら3年後の計画でよかったが、今なら3ヶ月後のことを考えないといけない。既にウォーターフォールでは追いつけないような時代に突入している。


多くの企業がアジャイルコンピューティングを導入している。

しかし最初と最後はウォーターフォールで、間だけアジャイルというのが多い(Water-Scrum-Fall)。

このやり方にビジネスアジリティがあるのだろうか？　そうではないと思う。




◇21世紀のポートフォリオマネジメント（リーン・アジャイルなやり方）


私はここで21世紀型のポートフォリオマネジメントを提案したい、


・"計画"から"検証による学び"へ


まずは詳細なビジネス計画から離脱する必要がある。これらは教養ある人が『予測しているだけに』すぎないものであり、実際の学習をベースに意思決定していくのとは全く異なる。

デミングが「知識というのはインテリジェンス（知能）とは異なる」といっている。つまりインテリジェンスを使うのはよいが、意思決定をするときは知識を使えといっている。

アジャイルではこれが重要視されていて、起きていることをさくさくと認識するやり方がとられている。何をやっているのか？その付加価値は何か？というのを認識しながら進めている。


計画にはもう1つ問題がある。

ときには計画通りに行くこともある。そうすると「計画通りだからうまくいっているに違いない」と考えてしまう。しかし、最後にエンドユーザーから「これでは使えない」といわれてしまう。


「それをするべきだろうか？」という考え方に変える必要がある。

実際に現場にいって検証することが大事である。

細かく検証することにより、ものすごく痛い間違いを回避することができる。


今まではProcess->Delivery, Process->Delivery, Process…というやり方を繰り返していた。

我々は、問題を解決したか、そこから何を学んだというサイクルに移っている。




・"滞留"から"淀みのない流れ"へ


フローではなくプロジェクトの滞留をマネジメントするというのがここでの考え方だ。

『たくさんインプットすればたくさんのアウトプットが出てくる』という考えではなく、『たくさん終わらせる = もっと沢山終わらせられる』という考え方にする必要がある。



人間はマルチタスクが下手な動物であり、グループの中でそれをやろうとするのは大変だ。


タスクがたくさんあるのもプライオリティが頻繁に移るのもよくない。

トヨタの生産システムを見れば分かる。1つ終われば次。

決してタスクがぱんぱんになっている訳ではない。


21世紀のポートフォリオマネジメントでは、優先順位を付けてことを進める。

このとき、ポリシーがあるから流れはスムーズになる。




・"チームの頻繁な解散"から"継続することによる学びの蓄積"へ


しかし、プロジェクトが大きい場合、1つ終われば次(One in one out)だけでうまくいくとは思えない。

プロジェクトの失敗は"何か広大なことを考えてしまって身動きがとれなくなる"こと。「始めてしまった、もう後戻りできない」となる。

こういう所だと、プロジェクトチームはいつの間にかバラバラにされてしまう。


しかし、我々はチームとして尊重されるべきであり、"用事があれば集まり、用事が無くなれば解散"すべきではないと考える。

学習を蓄積していったチームは、有用なメトリクスを所有する状態になる。


昔のような「わからないことはあの人が知っている」というのはよくない。チームが知っていないといけない。




◆結論


◇結論

・バックログ


バックログを使い、価値と優先順位をベースに入っていくようにする。

そうすることで自由に動けるし、軌道修正もできるようになる。


価値と優先順位について、リーンコミュニティではMVPと言っている。

実際に顧客に手に届くまで、価値があるかどうかはわからない。だから「いいね」といってもらえるかどうか、少しずつ小出しにして実験する。


アジャイルではDoneの定義と継続的インテグレーション。

間違ったものを継続的にデリバリする企業があるが、それは継続的な学習がかけているということである。

私たちがパスしなければいけないテストとは、お客が価値を感じたか、お金を出したかということである。


まずそこに行って何が欲しいかを学ぶ。そうすることによってアイデアが出てくる。

それから実験してテスト。

それを継続的にデリバリする。

そしてお客からフィードバックをもらい、学習し、そしてサイクルを回す（リーンスタートアップのあれ）。




・検証による学び(validated learning)


我々は「これは価値になるはず」と思い込みがちである。

そう思っているなら早く検証する、"検証による学び"というのがポイントだ。



On budget, on planningでは不十分で、お客が満足しなければアウトである。




・ポートフォリオかんばん(Portfolio Kanban Board)




我々は劇的な透過性(Radical visibillity)という考えを用いている。

これは、『見えないことはリスクであり、プロジェクトの全てが見えているのであればリスクは低減できている』ということを意味している。



そして、劇的な透過性を得るためにポートフォリオかんばんを使っている。

ここにはチームレベルの情報が入っていて、入ってくるもの出て行くものをチームが見ることができる。また、価値が検証されてお客様に届くまでの流れも書いてある。

1. study

まずはスタディしてアイデアを出す。


2. ready

ここでは実験。acceptance, validation criteriaが重視される。

全て想定に基づいていた今までのやり方をバリデーションに変え、検証することをかなり絞る。


3. work cell

リリースに向けて動いている段階。

ワークセルの中をいっぱいにするのではなく、リミッタをかけて最小限にしている。
やっているものがほとんど終わったら次を入れる。


ブロックされている場合、一目でわかるのでディスカッションが始まる。

ここで依存関係も見ることができる。


4. release

ここではエンドユーザが試用を行う。

ほとんどのアジャイルチームはここで作業は終わり。

しかし、我々は"contenious validation learning"をしたいので…


5. 1. Pivot

もうちょっと考えが必要かな？というものはPivotにおいておく。


5. 2. Failed

失敗してしまったものはFailedというところにいれておく。

Failedも別に悪いことではない。学べればそれは大変な教材である。


5. 3. Validated


価値が検証されたものが入る。


…そしてこれはサイクルになっている。

Pivotを見ていて浮かんだアイデアは、ワークセルに入っていく。

ポートフォリオかんばんで、コンプライアンスやプロジェクトの健康状態・進捗・学びが一目瞭然に共有されるようになる。



・かんばんの重要さ

かんばんは、ソフトウェア開発から戦略変更まで使うことができる。

かんばんが何故こんなに重要か？

大野耐一も言っている。「イノベーション・改革・継続的な改善を促すためにかんばんは不可欠だ」




◇最後に

・本当のビジネスアジリティを得るために


20世紀のやり方というのは1890年代にさかのぼる。

このような古い考え方に固守せず、離脱しなければいけない。

本当のビジネスアジリティを得るためには、20世紀のやり方を捨てないといけない。


もうずっと続いていてしみこんだ考え方だが、これを捨てれば、顧客からのフィードバックでさくさくと開発していくことができるはず。

それは21世紀型の思考を持っているからだ。


意識を切り替えることは簡単ではないが、まずは自分達の組織からTryするということ。

得られる結果はすばらしいものばかりである。






◆質疑応答

◇質問


Q.
アイデアには優先順位をつけないといけないが、アイデアの評価というものは難しくないか？

どうやれば？


A.
それは顧客からのフィードバックによる。

エンドユーザに聞いてみるのがよい。

携わる人が会議室に篭って評価しても、それは「思う」だけのことに過ぎない。






David Joyce様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。