【読書】システム設計の謎を解く 強い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個でよいのか？
　→そういう疑問をステークホルダーと話し合う

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

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

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





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

【建設予定地】『Rakuten Technology Conference 2012 - Exploring User Wish Through Mindmapping By Kenji Hiranabe』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、平鍋健児氏の講演『Exploring User Wish Through Mindmapping』のノートです。

※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Design Thinking By Jeff Patton』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Jeff Patton氏の講演『Design Thinking』のノートです。

※開催一ヵ月後を目処に公開致します。

『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様, 平鍋健児様, 永和システムマネジメント様, ・アギレルゴコンサルティング様, 楽天様、ありがとうございました。

『Experience Vision のはじめかた』ノート

2012/09/26に開催された『Experience Vision のはじめかた』のノートです。

DevLoveは今日で93回目とのこと。あと7回で大台です！

◆山崎和彦様 - 自己紹介

　

　◇経歴

　

　　・京都工芸繊維大学で工業デザインを専攻

　

　　・クリナップからIBMへ

　

　　・IBMでは工業デザインからソフトウェアのインタフェースデザインへ。ユーザエクスペリエンスデザインセンターを作った。

　

　　・その後はコンサルティングとして、UCDやUXを伝える活動

　

　　・そして千葉工業大学へ

　

　IBM時代にアメリカ人の同僚が言っていた。「アメリカでは家に帰ってから勉強している。大学も単位辺り2万円でとれて、5年かけてMBAが取れたりする、向こうでは余暇としてそういう生き方ができる」

　そういう生き方に興味を持って、神戸芸術工科大学・東京大学で手法を学び、現場で実践していった。いまも商品戦略ウェブ戦略パッケージングなどもやっている。

　

　

　◇執筆活動

　

　　やり方をまとめることの大事さを思い、本も書いた。

　

　　・使いやすさのためのデザイン

　

　　・情報デザインの教科書

　　　→この分野を学ぶための教科書として作った。

　

　　・プロダクトデザイン

　　　→教えることが先生毎に違って、どうなの？と思って出した。工業デザインって、どこでも聞くけど、教科書がない。僕らが始めて作ったという自信ができた。

　

　本として出版することで手法や考え方を使ってもらう。

　自分が学んで経験したことを使ってもらえることで、社会に役に立ったと言う実感がある。

　今日もその延長にある。

　

　

◆エクスペリエンスビジョンについて - どういったものか

　

　◇エクスペリエンスビジョンについて

　

　　・ビジョン提案手法のフレームワークである

　

　　・新しいビジョン・サービスを構築するために役立つという視点から作った

　

　　・ユーザの本質的体験から見た、ユーザがもっと喜ぶような新たな体験を与えるため、本質的な価値と展望を探ることが目的

　

　　・本質的欲求からはじめ、上位の価値やサービスを考える

　

　　・エクスペリエンスビジョンのプロセスを全部使わなくても、全体像がつかめるようなテンプレートがある

　

　

　◇エクスペリエンスビジョンの歴史

　

　　・エクスペリエンスビジョンは5年かけて作った

　

　　・ワークショップや合宿で実証していったら5年かかった

　

　　・いい手法はどんどん取り入れていきたかったから5年かかった

　

　　・世の中にあるものは使い、無いものは考え出した

　

　

　◇エクスペリエンスビジョン本について

　

　　・エクスペリエンスビジョンで使用するテンプレートはダウンロード可能

　

　　・本を持っていなくても落とせる

　

　　・エビ本には、エクスペリエンスビジョンの適用事例・教育事例・ワークショップ事例も書いてある。

　

　

　◇既存の手法をどんどん取り入れたことについて

　

　　・手法を考えた人は、それを使えば世の中を変えるような書き方をしてしまう。でもそれは嘘

　

　　・手法は一部分でしかない

　

　　・いろんな手法を上手く使いこなす。エクスペリエンス・ビジョンにはそういう役割を持たせている。

　

　

　

◆エクスペリエンスビジョンについて - 関連領域との関わり

　

　◇ビジネスとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンにはビジネスの観点もある

　

　　・ユーザとビジネスの両方を見ている

　

　　・モノを売っている人がどうやってサービスに転換していくか？など

　

　

　◇HCDとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンでは勿論HCDを使っている

　

　　・エクスペリエンスビジョンはユーザの価値に基づいて企画やエンジニアが提案するアプローチを取っている

　

　　・今までのHCDはユーザのニーズを受けるものだった

　

　　・今までのHCDは問題解決に寄っていた

　

　　・欧米のHCDの使い方やデザイン思考のアプローチを見ると、HCDはイノベーションの源泉としても使える

　

　　・HCDには問題解決と提案型の2つの使い方があり、それはプロジェクトに応じて使い分ければよい

　

　

　◇シナリオとエクスペリエンスビジョン

　

　　・構造化シナリオを取り入れていることはエクスペリエンスビジョンの特徴

　

　　・シナリオができればユーザの本質的価値を評価できる

　

　　・シナリオを使えば、きちんとしたウェブサイトなどを作ることなく価値を調査することができる

　

　　・戦略的にやるときはバリューシナリオまでやるけど、日々のプロジェクトはインタラクションシナリオで留めたりとか　…そういう使い方もできる

　

　　・ユーザ視点->プロトタイプ、ビジネス視点->ビジネスモデル、の形でシナリオの視覚化ができる

　

　

　

◆バリュー（本質的な価値）について

　

　◇エクスペリエンスビジョンでは

　

　　・構造化シナリオ手法を使い、段階的に明らかにしていく。

　

　　・フレームワーク上では、上半分をユーザ・下半分をビジネス。それを真ん中のシナリオでつないでいる。

　

　

　◇バリューなどの上位概念について取り組むということ

　

　　・これが曖昧だったりレベルが低かったりすると、いいアイデアが埋もれる

　

　　・そういうことはすごくある

　

　　・戦略作りはすごく大事

　

　　・プロダクトを作って、じゃあ2年~3後はどうするのか？ということが書いてない企画がほとんど。

　

　　・半年後の製品をただ考えるのと、ユーザの慣れも考慮したうえで2年～3年後のことを考えるのでは全然違う

　

　　・企画書は自分のウェブサイトや製品のことしか書いてない。戦略は戦略部門の話で別、となってしまう

　

　　・そういう中では新しいことをやるのは難しい

　

　　・新しいことには投資もリスクもある。それは単体の投資では回収できないことが多い

　　　→だから、上のレベルで目標設定することが重要

　

　

　

◆ユーザについて

　

　◇ユーザの本質的価値を知るためには

　

　　・提供価値分析やKA法という手法がある

　

　　・目の前の事象に対して、ユーザの価値や心の声を見つけ出していく

　

　　・潜在ニーズはフォトエッセイや行動観察で明らかにする

　

　　・顕在ニーズは日記や質問

　

　

　◇ユーザ設定

　

　　・ビジネスを考えるのであればステークホルダーも必要

　

　　・ステークホルダー = ビジネスに影響を与える人

　

　　・優先順位をつけて、具体的な対象ユーザを明確にする

　

　

　

◆シナリオについて

　

　◇シナリオとは？

　

　　・シナリオはモノとヒトの関係を表すことができる

　

　　・仕様書にはモノのことしか書いてない

　

　　・シナリオは日本語が読めれば分かる

　

　　・仕様書は専門家が見ないと分からない

　

　　・シナリオを介せばエンジニアとデザイナーが互いにコミュニケーションできる

　

　

　◇構造化シナリオについて

　

　　・シナリオを階層化していることがポイント。

　

　　・バリューシナリオ（ユーザの価値 / なぜ？）

　　　→バリューシナリオ：新規性・魅力がポイント

　　　→ユーザ・ビジネスにとっての価値

　　　→ユーザにとっての本質的欲求がビジネス提供者の提供方針がベースになる

　

　　・アクティビティシナリオ（ユーザの行動 / 何を？）

　　　→バリューシナリオの1シーン

　　　→ユーザの活動の全体が分かるように描く

　　　→ペルソナはこの段階ではっきりしている必要がある

　　　→有用性・便利さがポイント

　

　　・インタラクションシナリオ（ユーザの操作 / どうやって？）

　　　→効率・全体としての使いやすさがポイント

　　　→アクティビティシナリオの1タスク

　　　→具体的なモノ、その使い方を書いていく。

　

　　アクティビティシナリオとインタラクションシナリオの違いについて。アクティビティは人の行動なのでモノははっきりしていない。逆に、インタラクションはモノがはっきりしている。例えば、朝気持ちよく起きるのはアクティビティで、それを照明器具でやるというのがインタラクション。

　

　

　◇シナリオの評価方法

　

　　・ユーザの側面からの評価方法（代表的なもの）

　　　→魅力性・新規性・有効性・効率性。

　　　→魅力と新規は満足度に関係する

　　　→有効と効率は便利さに関係する

　　　→どれを評価するのかはプロジェクトの段階で変わる。例えばバリューの段階なら効率性より魅力性や新規性を見る。

　

　　・ビジネスの側面からの評価方法

　　　→戦略性・事業性・市場性・実現可能性・社会性

　　　→例えば、最初のバリューの段階で戦略を評価し、アクティビティで市場性を見て、操作で実現可能性を見る

　　　→3年後の話を考える時に操作性の話をするのは違う

　

　

　

◆エクスペリエンスビジョン・情報デザインに関して出てきた話

　

　◇問題解決と提案

　

　　・問題解決のプロジェクトは必要だけど、それだけじゃダメ

　

　　・新しいものやこれまでなかったものを考えるためにはユーザの本質に立ち返って、エンジニアからユーザに提案することが必要

　

　　・ただ提案するだけではなくて、ユーザの立場から提案することが重要

　

　　・ユーザの価値に基づいてビジョンを考えると新しいものが見える

　

　

　◇企画提案書について

　

　　・技術・実現可能性がポイント

　

　　・総合的なビジネス企画を立案する

　

　　・製品やサービスに対するユーザ要求仕様をまとめる

　

　　・ユーザ視点から見た仕様の根拠を書く

　

　　・うれしい体験 - 「HCDから見たポイント」「差別化・新規性・魅力」を書く

　

　

　◇本質的な価値の見つけ方

　

　　・本質的な価値を見つけるのは難しい

　

　　・バリューシナリオを作って共感度を見ていくのがよい方法だと思っている

　

　　・シナリオ作りならお金がかからないので、そこを評価して価値を見つけていけばいい

　

　　・何もないところからブレストしても仕方がない

　

　　・砂金取りと同じで数を打たないと駄目。

　

　　・新しいものはどこにあるかわからないので、広くユーザにアプローチすることが大事

　

　　・そのためにはできるだけ簡単な形で聞く方がよい

　

　　・シナリオは完全なプロトタイプよりも量が作れる

　

　　・シナリオなら「こんなものも？」という、プロトタイプでは（費用と優先順位的の兼ね合いで）試せないようなものについても調査ができる

　

　

　

◆もう少し周辺の話

　

　◇ゲームチェンジについて

　

　　・同じ土俵で戦うと安くて効率のよいところには勝てないというのがある

　

　　・そういうとき、欧米ではゲームチェンジを使う

　

　　・アメリカは自分達でルールをどんどん作っている

　

　　・改良だけで日本がやっていくのは今後難しいのではないか

　

　　・目の前の問題を解決するのではなくて、ユーザに本当に必要なものを長い目で見て戦略を立てることが大切なのではないか

　

　　「新しい目覚まし時計をデザインして？」と言われると、既知の固定された記憶の中でデザインしてしまう。そうではなく「朝、気持ちよく起きることができる体験をデザインして？」とすると、1つ上のレベルで考えることができ、もっと自由な提案ができる。チェンジゲームというのはそういうこと。

　

　

　◇スケッチとプロトタイプの違い

　

　　・散策的にアイデアを作るのがスケッチ

　

　　・検証的なものがプロトタイプ

　

　

　◇新しいサービスの確かめ方

　

　　・イベントを1回だけやる。ユーザにとってうれしいかどうかはそれだけで判断できる

　

　

　◇アクティングアウトの使い方

　

　　・いろいろある。実際に設計者が使ってみるとか。

　

　

　◇クイック＆ダーティ

　

　　・クイック＆ダーティに実験することがすごく大事

　

　

　◇構造化シナリオはウォーターフォールっぽくない

　

　　・アジャイルとシナリオは近い

　

　　・どこまで深くやるか？という違いだけの話。

　

　　・アジャイルはソフトウェアまで作るが、（エクスペリエンスビジョンでは）クイックにシナリオ・プロトタイプを作って済ませる

　

　　・クイックに作るのが大事

　

　

　◇心配していること

　

　　googleが自動運転の車を街で走らせ、実証的に走り方をプロトタイピングしている。日本は法律上そういうことが絶対にできないと言われている。iRobotもろうそくが倒れたら火事になるからできなかった。そういう日本人の潔癖さが、機会を遠ざけていることを心配している。 

　

　

　◇異文化

　

　　アメリカでは、新しい発想をするためには異文化の人がいないという認識をする人が多い。技術者・マーケティングの人・デザイナー　…そういう人が混ざることで新しいものができるという発想が大事だと思う。 

　

　

　

　

　

山崎和彦様, DevLove様, ありがとうございました。

　

　

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.様, 株式会社テクノロジックアート様ありがとうございました。

『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』ノート

2012/06/29に開催された『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』のノートです。
"スクラムを学ぶにあたって直面するであろういくつかのケースの中から、自分が話したいケースについてグループを作り、グループ毎に話し合いを行う"というのを2セット行いました。

自分が参加したテーブルの話だけでも、持ち帰れるものがいろいろありました。なのでつい油断してしまったのですが、各テーブルの話し合いの内容については、全く気に留めていなかったという　…自分のノートを整理しているときも、それぞれグループ毎にどんな話をしていたのだろうか、ということがたびたび気になりました。勉強会が終った後に皆でしばらく雑談する時間があったので、そのときに聞いて周ればよかったと思いました。せめて成果物（模造紙）の写真くらい撮っていれば　…誰かのノートに期待します。



◆勉強会の大まかな流れ

1. 勉強会の趣旨の説明
2. ウォームアップ
3. 話し合いのテーマ
4. 話し合いその1
5. 話し合いその2
6. まとめ
7. 勉強会（紹介）LT




◆今日のテーマ"スクラムを学ぶ方法"について

・"Scrumをやる"話ではない
・スクラムやアジャイルで「お客様が何かを作りたい」というときに何をしたらいいのか？というのを学ぶ。
・Scrumの開発手法を現場に導入するためには何が必要なのだろうか？


◇背後にある考え方

・"導入する"ことは現場に非常に依存する
・声の大きい人、力の強い人、同僚にだいぶ依存する
・それを乗り越えることが導入するために必要な要素のうちのひとつである



◆忘れないでほしいこと

・一人で仕事をしているわけではない
・誰のためにものを作るのか？という視点
・Scrumを導入することを目的としてはいけない



◆次のケースから、話し合いたいテーマを決めます

・1. 社内で一人で始めようとするケース
　・1-a. なにから初めて良いかわからない
　・1-b. 上の人をうまく説得できない
　・1-c. スクラムが全ての問題を解決してくれる

・2. 上から言われて、はじめるケース
　・2-a. 権限委譲してくれない
　・2-b. 上司の解釈と微妙に異なる

・3. 誰かと一緒に始めようとするケース
　・3-a. なにから始めてよいかわからない
　・3-b. 友達と解釈が異なる

・4. すでにAgileって言っている人がいる
　・4-a. スクラムマスターがPM
　・4-b. ツールやプラクティスの話しかしない

・5. お客様にはWFといっている場合

・6. 完璧なAgileの開発をしたい

・7. お客様にScrumでやってほしいといわれた

・8. なぜScrumが良いのか分からない

・9. 巻き込み力が足りない



◆話し合い1回目 / なにから始めてよいかわからない

◇考え方
・アジャイルは『ある』『ない』ではなくて度合い
・マインド重要


◇始める
・チームに問題意識があったときに手法を入れるときはうまくいく
・いいタイミングで仕掛けるとアジャイルよくね？と思う人が増える
・先輩に働きかけてそこから推進してもらう


◇問題について
・（問題があるのにそれを）問題だって思ってないことが問題
・（漠然と認識を共有している事柄について）声に出して話をすることは重要
・問題がないところでやっても意味ない。相手がやらされ感を持ってしまう
・問題じゃないときにアジャイルを入れていくのは怖い


◇未解決の疑問
・アジャイルじゃない人が沢山入ってくるときどうするか？
・問題を表面化させることが必要？


◇プラクティスについて
・（スプリントで）実現するフィーチャを決めても、緊急の対応でぐだぐだになる
・インセプションデッキは作るのに時間がかかるけど重要
・コミュニケーションの問題でプロジェクトが炎上した。振り返った結果、朝会をすることになり、それで上手くいった
・バックログが一杯になったら減らすことを決める
→「いらないからやめよう」だと喜ぶ
・フィ－チャ作るチームと既存の問題に対応するチームに分けると、割り込みを回避できる
→でも人数が少ないとそれはできない
・少数人数のチームで一週間毎の振り返りは期間が短い
・振り返りはすごい重要。振り返るとすごいアジャイルになる



◆話し合い2回目 / 巻き込み力が足りない

◇巻き込む自分
・ある程度身銭を切って見せる。そこまでやらないとのってこない
・興味を持った人を引き込む
・根気良く伝えていくと伝わる
・自分がわからないことを押し付けてはいけない。
・誘いのうまい先輩のスキルを盗み、巻き込み力のある人になる


◇巻き込まれる相手
・かっこいい先輩がいると、学ぼうという気になる
・どういう人に働きかけるかによってアプローチが違う
・巻き込み力がある人を巻き込む
・（周囲が受動的な場合）自分がアジャイルできることが前提。やって見せたり、フォローできることが大事
・（周囲が能動的な場合）一緒に学んでいくやり方でもよい


◇巻き込むこと
・ワークショップの写真を見せると興味を持ってもらえる
・信頼をどれだけ稼ぐかが大事。巻き込むというより引っ張っていく
・本を配っても興味ない人はそもそも読まない
・楽しそうな感じを見せることが大事


◇価値観
・うまくいかなかったらやり方を変えたり対象から外す
・休みの日まで仕事のことと嫌がる人はいる
・楽しくないことは続けられないが、成功体験を与えることで続けてもらえる


◇組織
・なんちゃってアジャイルでメタメタになったところは、アジャイルに拒否反応を示す
・社内のあちこちに仲間がいても、各自ばらばらのプロジェクトだと苦戦する
・上司を説得することが重要
・大事なのは強敵と戦わないこと


◇アジャイルについて
・"アジャイルが良い"とは言わない
・"うまくいったこのやり方、実はアジャイル"と持っていく
・アジャイルがバズワード化している
→興味がある人ならアジャイルといってもいい
・そもそもアジャイルはスタンスなので、名前を出す必要はない
・これをやったらアジャイルというのものはない



◆勉強会紹介

◇スクラム道

◇スクラムプロダクトオーナー勉強会

◇すくすくスクラム






すくすくスクラム様、VOYAGE GROUP アジャイル戦略室様、ありがとうございました。