「Agile Japan 2016」に参加しました

2016/5/31(火) 「Agile Japan 2016」に参加してきました。

公式サイト
http://www.agilejapan.org/program.html

今回が初参加です。
会社でアジャイル関係の仕事をやってるので、上司に掛けあって参加費用を捻出してもらいました。
早割15,120円ナリ。

以下、参加したセッションの聴講メモ。

---

初心者向けミニチュートリアル

今村 博明氏

アジャイルとは

• アジャイルに考える、など、形容詞。名詞じゃない。

プラクティス

• 実践とか経験。実践項目。

アジャイル

• 変化に適応しながら、価値を最大化する。
• メンバーが共有すべき考え方と実践するための手法。

アジャイルの実体

• 顧客と開発者が一緒に働く。フィードバック活用、など。
• それらの提唱者たちが２００１年にアジャイルソフトウェア開発宣言を出した。
• あくまで総称。アジャイル開発、というものは存在しない。

Agile Metro Map

• https://github.com/kenjihiranabe/aaguide-jp/blob/master/artifacts/AgilePracticeMetroMap_PrintVersion.pdf
• 今日、印刷物を配っている。
• 現場に持ち帰って、ことあるごとに見て欲しい。

Scrum Guide

• http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf
• 短いので読むことおすすめ。

XP

• 主に３つの特徴がある。

1. 技術的プラクティスが多い
2. 変化を抱擁せよ
3. 人間がソフトウェアを開発するという事実に向き合う

• 　人の弱さを認め、人の強さを活かす

アジャイルの特徴

• 不確実性コーンはWFでもアジャイルでも起きる。
• 最大で４倍ずれる。見積もりは難しい。
• 品質は、WFでは終盤で確認する。アジャイルは頻繁に確認する。
• プラクティスの意味を考える。ただ受け入れるのではない。

ふりかえり

• 場を設定する
  • 趣旨ってなんなの？みなさんに求めることを説明する。
• データを収集する
  • 　壁に貼って議論する。何を感じたかを議論
• 終了の時には感謝。
• こーいう機会にしかメンバーを褒めにくい。

実行委員長挨拶

和田 憲明氏

• Agile Japanは２００９年から始まった。平鍋さんと前田社長から始まった。
• 今回が８回目。総勢５００人。
• 日本のアジャイルを考える場。相互につなぐ場。
• 進化する人たちを見てきた。強いチーム。
• 徹底的に最初、アジャイルにどっぷりはまってみる。アジャイルになってみる。過去の成功を捨てる。これが成功するチームの特徴。
• 「知る」と「わかる」は違う。実行しなければわかったことにならない。

• ３ヶ月どっぷりやれば見えてくるのでは。でも難しい。
• 仲間が必要。
• 午後の事例発表はペア発表。

激励メッセージ

松本 隆明 氏

• カーネギーメロン大学のSEIと連携している。（https://www.ipa.go.jp/sec/mailmag/649.html）
• アジャイル開発の導入は最初、なかなかうまく行かなかった。
• 「政府におけるアジャイル開発－神話、怪物、寓話－」という小冊子を１冊作った。
• その小冊子では７つの神話を上げている。これを使ってアジャイルの誤解を解いてあげる。
  
  • 神話の１つ「アジャイルは流行りものであり、時間が経てば消えていく」は、Adaが流行りものだったのになぞらえている。
  • 神話の１つ「アジャイルはカウボーイ・プログラミングになる」は、どんどんひたすら作っていくとパゲッティプログラムになる、という神話。
  • 政府機関だときっちり仕様固めないとだめ、という誤解がある。これらの１つ１つについて誤解を解いている。
  • これを使っていろんなところに説明に回った。
• 我々ももっと誤解をといていかないといけないのでは。

基調講演1：スクラムがイノベーションを加速する
〜ソフトウェア以外にも適用されはじめたアジャイル〜

Joe Justice 氏

• 日本語：　http://www.agilejapan.org/2016/image/Keynote1_ScrumIncAgileJapan80minJ.pdf
• 英語：　http://www.agilejapan.org/2016/image/Keynote1_ScrumIncAgileJapan80minE.pdf

講演者の紹介

• ジェフ・サザーランドと同じ会社に勤めている。
• ハードを含めてアジャイルをやってる。スクラムを広く捉えて、ソフトウェアじゃない世界でも適用する。
• ワイン制作とか車開発にもアジャイルを適用している。
• TEDトークにも出ている。
• スクラム＝２倍のことを半分の時間でやる。

ハードウェアそれともソフトウェア

• 今の火星と将来の火星の絵がある。
• 火星をバックアップとして１００億人の移住がゴール。それをスクラムチームでやっている。

Amazonのビデオ

• 工場を走り回るロボットを作ってるのはスクラムチーム。

現在の市場

• 日本の企業はもっとスプリントを短くしなければならない。
• プロダクトを出すのに数年単位かかっていて、長すぎ。

スクラムマスター

• スクラムマスターの一番重要な仕事は、チームをハッピーにすること。
• フラストレーションを取り除く。

Scrum法

• 憲法の改定とかもスクラムでやってる。
• ６ヶ月で価値を市民に提供できないものは止めるようにしている。

ボーイング

• ボーイングは航空機を７つのピースに分けて作ってる。
• WFでどのくらいかかるか見積もるが、だいたい間違ってる。
• まだ始まってないものを見積もるのはいつでも難しい。
• ボーイングでアジャイルを使い始めた。
• 1/7の飛行機を作るのに、自分たちで見積もるようにさせた。
• 見積もりの時間がかからなくなった。仕事をする人が自分で見積もるのが一番正確で早い。
• なぜなら、自分で仕事をdecisionできるから。
• 1/7がそれぞれどのくらいできるか、バーンダウンチャートで表すことができる。

抵抗

• 最初は経営者はアジャイルを避ける傾向にある。
• マネージャを納得させるために、スクラムのほうがリスクが少ないことを示さないといけない。
• DoR（準備完了の定義）, DoD（完成の定義）, リリースバーンダウンの３つが無いと判断ができない。
• この３つが無いなら、明日から作ること。

スクラム事例

• ワインをスクラムで作っている
• グリペンの戦闘機もスクラムで作ってる。
• パイロットがスクラムチームに入っている。
• １週間ごとにスプリントやってて６ヶ月ごとにリリースしてる
• ノキアは５年計画をして、誰にも使われなくなった。
• ボッシュは経営者室でスクラムやってる。
• 各パーツにプロダクトオーナーがいる。
• 最初のスプリントでは何もできないことが多いが、障害物リストができる。

基調講演2：アジャイルなIoTプラットフォーム開発

玉川 憲 氏

Agile Japan 2016 | アジャイルなIoTプラットフォーム開発 from SORACOM,INC

アジャイルと私

• IBMにいたころ、アジャイルの元になったUP（Unified Process）をやってた。
• Rational Team Concertという製品はサーバが必要だった。「なんで必要なの？」と思った。
• 留学時代にAWSが出てた。衝撃を受けた。

AWS

• AWSの登場で「とりあえずやってみる」ができるようになった。
• 失敗のコストを下げた。新しいサービスがアイデアベースで出てくるようになって、そこに共感した。

起業

• AWSの上で作れないと思ってるけど作れるものってなんだろうか？とシアトルで飲んで安川さんと話してた。
• ２日酔で暇の中、リリースノートを書いた。
• 世界中やったことないことだったが、いけるんじゃないか。と思った。
• ゼロ・トゥ・ワンという本、ぜひ読んで欲しい。
• why not me.という気持ちがいつもあった。自分でできないのか。
• 玉川、AWSやめるってよ！走り続けた5年と卒業後を聞く

SORACOM

• 「ヒト向け」を「モノ向け」にするモバイル通信サービスに着目した。
• モノの管理がWebでできる。APIでコントロールできる柔軟なインフラ。
• NTTの基地局を借りて、専用線を引いた。世界初のバーチャルキャリア。
• SORACOM Airが放射線マップを作るプロジェクトに使われた。
• 共通基盤として使ってもらうために完全な従量課金にしている。
• エコシステムとして、SIMを入る機器を作ってもらうパートナーとか、認定デバイスパートナーとかを設けた。
• SORACOM Canal ・・・ AWSの閉域網にソラコムのcanelを直接つないでセキュリティを担保する。

資金集め

• 確固たる技術を持っていること
• 狙っている市場が十分に大きいこと

チーム

• 全員がリーダー。マネージャはいない。
• 価値観を１４個決めている。
• 共通基盤をやっているんで、嫌われるとダメ。
• すべてがslackに自動的に投げ込まれる仕組みにしている。

さいごに

• Connecting the dots
• 目の前のことを一生懸命やればよい
• We are our choices.
• gitg（与えられたもの）か、choice（選択するもの）か
• 死ぬときに思い出すのは決断の数々。そこで後悔しないように自分の決断をしていってほしい。

アジャイルは本当に日本のソフトウェア開発を変えることができるか？

Can Agile Really Change Japan's software development from Kenji Hiranabe

アジャイルってなんだろう？

• アジャイルはやはり西海岸から。
• 従来型の問題＝要求の劣化。V字モデルで行って帰ってくる間に世の中は変わる。
• お互い信頼しあわない契約。
  • お客さん＝要求の詰め込み
  • ベンダー＝要求のブロック
• 要求は誰も持ってない、ということもあるので、自分から掴みにいかないといけない。

アジャイル開発とは何か？スクラムとは何か？

• 永和システムマネジメントは金融とか医療とかやってて、アジャイル使えないじゃん、と思われそう。
• 今の仕事で使えないじゃん？それはすごく感じているけど、でもなんかできないか？と思ってる。
• 今の仕事には使えないけど、今よりうまくすることはできる、といった人がいた。
• 「アジャイル」という言葉が引かれていた時代には「プロジェクトファシリテーション」と言っていた。
• キッチンタイマーを使ったポモドーロテクニックというのがある。
• Kanbanは、フローを作り出せばいい、という考え。まず見える化しよう。必ずしもイテレーションしなくてよい。

個人的アジャイル史

• XPの本を読んで感動してXP-jpを作り、２００３年にXP行脚をしてた。
• 以前は「プロジェクトファシリテーション」と言っていたが、最近は「アジャイル」という言葉を使うほうが届くようになった。
• XP本には、「リリースしたらお客さんとシャンパンを開けてください」と書いてあってグッときた。
• XPは、工学以外になんかある、と強く思った。
• それでゲリラ的に渋谷でXPオフミーティングやろうと企画した時のメールが残ってる。(2000年ごろ)
• 倉貫さんがアジャイルのアンチプラクティスを書いた。夜のうちに妖精が全部なおしちゃった・・・とかの事例。

• XPは技術的プラクティスがたくさんあって、一人でできることもあった。

プロジェクトファシリテーション(PF)

• プロジェクトファシリテーション　＝　アジャイルプラクティス　＋　トヨタ生産方式　＋　ファシリテーション
• 参加型意志決定、というのもやってた。

プロジェクトの見える化

• 野球盤が身近な良い例。
• ちゃんと見える化でき、正しい情報が透明化されていることが、現場のモチベーションと行動を促す。

タスクかんばん

• タスクかんばんで、息子二人が中学校の宿題をやった。
• 次男の「ふるさと新聞」という面倒くさい宿題が夏休みの最後までやらずに残っていた。
• そこで長男が次男に、去年自分が書いたのを渡したｗ
• こんな感じで、昔やったのがあるから参考にしろよ、というのが現場でも起こったらいいじゃん。
• タスクボードの前にきて朝会したら、必ずそうなる。助け合う。

バーンダウンチャート

• 朝会の場で、みんなで書く。スルーし難い雰囲気が流れるのが大事。
• みんなで認識することが大事。スルーしないこと。
• 今やってる仕事を見えるようにすることから始めなさい。

Kanban

• トヨタ生産方式をやってる人が「ソフトウェアがわからない」と言ってた。
• ソフトウェアは目に見えない。
• モノが動くというのが大事。かんばんで見える化し、タスクが流れるようにする。
• オレンジの付箋を上手く使っているプロジェクトがあった。
  • 在宅勤務の方は、社内にバディ（相棒）を作って、その名前をオレンジの付箋に書いておいてください、としてた。
  • 在宅勤務の方に何かを確認したいが連絡が取れない場合、オレンジの付箋を見ればバディが分かるので、その人に聞けるようにした。
• こういう工夫は全社統一プロセスなんかやってたら出ない。
• 現場で工夫することが大事。

ふりかえり

• ふりかえりからオレンジの付箋などの工夫が生まれる。
• 「ESMカンファレンス」でググッてほしい。看護師さんの事例を紹介している。

なぜPFが重要か

• エンジニアとして誇りを持って達成感を得る＆プロジェクトを成功させる。このアンドをとりたいと思ってPFをやってた。

問題対私たち

• PFの原則の１つに「問題対私たち」というのがある。問題を壁にはる。壁 vs 私達、という構図を作る。

日本のアジャイル？

• 日本でアジャイルがしにくい決定的な理由は、「エンジニアがベンダ側にいる」ということ。
• ユーザ企業がエンジニア雇用しない。
• それに比べ、ゴールドマン・サックスはエンジニアが２５％もいる。

Agileのスケール方向

• 日本は縦にスケールする。契約を挟む課題がある。

IT人材の流動性

• 日本の１００万人のエンジニアはベンダ側に多い。ユーザ企業側に少ない。

私の会社とアジャイル

• 金融や医療もあって、全体をアジャイル、というわけではいかない。
• アジャイルが持っているマインドとかプラクティスのうち、使えるものを使う、という話を社長になってから社員に話した。
• アジャイルソフトウェア開発宣言の右側は超重要だが、左側も重要。重要じゃない、といったらダメ。
• アジャイル宣言を読むと、自社の社風もアジャイルじゃん、と思った。
• みんなを幸せにしたい。金融も医療もうまくやってほしい。
• アジャイルが持っている何かを伝えたい。

海外での気づき

• ブラジルのCi&T社では、アジャイルの仕事が取れたら、まず最初にお客さんのかんばんを開発ルームに吊るしていた。
• お客さんのかんばんを目に入る位置に吊るすことで、お客さんを意識するように工夫していた。
• お客さんに喜んでもらう仕事をする。
• 英語ができる人ばかりでは無いので、英語の先生を雇って、それ専用の部屋を設けた。
• ６．の写真はシャンパンのボトルの蓋。お客さんと一緒に開けて祝ったシャンパンの蓋を貯め続けている。

変えて行こう

• 自分が変わって未来を変えていく。
• 自ら行動することが大事。

日本型ハイブリッドアジャイルの導入と実践

長瀬 嘉秀 氏　　株式会社テクノロジックアート

日本型アジャイル

• 今日はお固い話をする。日本なりに工夫したやり方。
• ハイブリッドアジャイルという書籍は、関西電力で開発した細かい話を書いてる。
• 日本の旧来型の組織だとうまく行かないので、組織改革まで及んでしまう。
• ベンダーは歴史があって、いきなり変えられない。

生産性

• 生産性はWFとアジャイルで変わらない。人が同じなら、という前提であれば。
• 生産性はツールによって上がる。
• ステップ数で評価、とかじゃなくて、どのくらいの価値を届けたか、が生産性。
• 日本の生産性はちょっと崩れてる。

Open@ReeL

• 日立ソリューションズと共同でOopen@ReeLを作っている。
• ハイブリッドアジャイルから日立色を抜いたのがOpen@ReeL。

契約

• アジャイルの契約形態って、欧米だと請負ってあまりない。
• 客がエンジニアを集めてきて、時給いくらで、という準委任契約が多い。一括受託は合わない。

品質

• アジャイルは日々品質を上げる。最後にテストじゃない。
• 品質部門の人も日々のチェックに入ってくる。

ハイブリッドアジャイル

• ハイブリッド、でどこにアジャイルを適用するか。
  • アジャイルは図の真ん中部分を回す。
• ストーリーを上げてって作っていくが、従来型の人はストーリーをどんどん上げられない。
  • アメリカは貼って議論するのは慣れてるのでやりやすい。日本人はストーリーを練りすぎる。
  • なので、なにもないところでストーリーあげられないので、要求定義部分は従来のWFと似た形でやりましょう、としている。
• 要件定義書や画面レイアウトやモデリングは要件定義として前にやる。
• 図の真ん中の従来型開発の部分をアジャイルにする。
• 日立のOpen@ReeLはツール依存はない。
• スパイクでストーリーを作っておいて、開発イテレーションを回す。
• WFじゃないの？と言う人がいるかもしれないが、開発部分でアジャイルを回すと変更要求を受け入れられる点がWFと違う。
• アジャイルってエンジニアの開発スキルが高くないといけない。
  • 頭の中で設計してプログラムを書くし、DB設計とかも同時にやる。
• WFは順次ブレークダウンするので、設計書が先にあって、コーダーが設計書を元にコードを書くだけ。
  
  • なので頭を使わないでよかった。
• 日本でスキルの高いエンジニアを揃えるのは難しい。数十人集めるの無理。
• ハイブリッドアジャイルだと、開発イテレーションを回す前にDB設計とかモデリングが先に終わっている。
• データモデルとか設計の指標が先にできてると、プログラムを作る人は早く開発できる。
• それがないと手戻りが結構出る。
• 総合テストは日本品質でWFと同じようにやる。

要件定義

• 要求フェーズで要件定義を、作成フェーズで開発をイテレーションを回す。
• 要件定義は全部やりたいが、全部やっちゃうとアジャイルじゃなくなるので、確定的に決まってるところはやるけど、決まってないところは開発と平行で要件定義もやっていく。

イテレーション

• イテレーションの長さは１ヶ月くらい。
• ソートワークスは１週間で早いサイクルでやってる。それができるのは、スキルがないとできない。
• スキルがついてくるとイテレーションが短くなってくる。
• イテレーションでOKをお客さんも出さないといけないので、お客さんも大変。

要求フェーズ

• 要件定義は、一般的なのを想定している。
• 業務プロセスは作っておく。ビジネスフローとか概念モデル。概念モデルはデータモデルかもしれない。
• 日本はデータモデルが強いので、最初にモデルを作る。海外はオブジェクト指向でORMを使ったりするので、もっと早い。
• UMLのユースケースはストーリーと≒に近いものがあるので作る。粒度は２週間くらいでできる大きさにする。
• ユースケースシナリオはテストに生きてくるので作る。
• ビジネスプロセスは、UMLで普通にフローを切っていく。
• 業務フローから機能が起動されてユースケースとか出てくる。
• ほとんどWFでやっている機能分類の大中小分類と等しい。
• 何にもないところからストーリーを貼る、というより、きちんと機能を切り出していく感じ。
• ストーリーはユースケース記述、というのを使ってる。
• 大事なのは、ユーザーストーリーは、テスト駆動開発を使う時のエンジニアのインプットとなるので、具体的な値とかを入れておくこと。
• 最後の受け入れテストも、ユーザーストーリに沿ってやっていく。
• 従来の手法とアジャイルをつなぐということで、こういうやりかたを提唱している。

モデル

• 概念モデルというのは、クラス図の関係を多重度をつけて表現する。
• このくらいまでははじめにやっていきましょうよ、というのがいいのかな。
• WFだとデータモデルを作れる人がいると思うので、そういう人たちと作る。
• プログラムを作る人は、ストーリーからテスト駆動でやっていくんだけど、データモデルを見ながらやっていく。
• あくまでもモデルは参考。モデル駆動でやっていくのではない。

ストーリー

• ユースケースをストーリーのカードにマッピングして貼っていく。
• ストーリーの整理はカンバンでやる。
• 如何にカンバンを最適化していくか。
• カンバンボードはtodo, doing, doneというように、ストーリーごとにレーンを切っている。
• 縦の区切り線も大事だけど、横の区切り線も大事。横の線をストーリーで切ったり、チームで切ったり。工夫する。

バッファ

• ハイブリッドアジャイルだと、バッファという考え方を持ってる。貯めとく。
• 開発できたら、テストの間に、「完了」というバッファをおいている。
• トヨタのシステムのプル型を参考にしている。貯まってきたらなんとかしよう、人増やそう、とか最適化している。
• かんばんひとつでも、バッファとか工夫している。

体制

• 階層型の配置にする。
• 本当は、アジャイルは同列にする。
• 日本型だと、どうしてもPMみたいな人がいないとダメなんで、そういう人を置いてみたりする。

契約

• バッファで大事なのは、契約。
• 大手だと請負契約にせざるをえないので、確定のものと不確定なものがあって、不確定なもににバッファを割り当てる。
• 請負でやる場合は、こういう考え方で請負ができる。でもいつもこういうやりかたでできるわけでない。
• 準委任でやると、責任範囲がこれまでとまったく違う。
• 準委任はユーザの責任になる。ここが大事。
• 今までそうやって今まできてないので、丸投げが多かったはずなので、ここが違うところ。

品質保証部門とアジャイル開発推進部門が一緒に歩んだアジャイル開発導入
～DADベースのアジャイル版開発プロセスの構築、実践と課題～

http://www.agilejapan.org/2016/image/C-3_HiroshiIshii_AgileJapan2016.pdf

なぜアジャイル？

• 協力会社からアジャイル開発を求められた

本発表で考えていきたいこと

• １．アジャイル開発に品を巻き込まないといけないの？
• ２．組織の標準アジャイルプロセスは必要なの？
• ３．アジャイル開発の中で品はどう関わったの？

アジャイルやりたけど・・・不安

• 工場はルールに則って動く思想があって、アジャイルに拒否反応があった。
• １．初めて、変更、久しぶり、にはリスクがある。
  • アジャイルのポイントが失われないように気をつけて進めていった。
• ２．アジャイルと標準って反するイメージないですか？
  • アジャイルはチームの最適を考えるのに、標準？

既存プロセスがそのまま使えるか？

• 節目レビューとかのレビュー対象物が、ウォーターフォールとアジャイルで違う。

アジャイル版標準プロセスを作成

• 標準プロセスとしてDADに注目した。初期計画フェーズの充実が弊社のコンテキストに合っていた。
• DADは方向づけ・構築、移行の３フェーズ

アジャイル版標準プロセスの流れ

• プロセスの選択
  • アジャイルでやる場合、誰からフィードバックをもらうか、なんのフィードバックをもらうか、をはっきりさせる
• 協力会社の監査
  • アジャイルがやりやすい環境があるか、監査する。ない場合はリスク。
• 方向づけフェーズで初期のプロダクトバックログ作成をする。

協力会社のアジャイル成熟度を考慮

• 協力会社さんの成熟度に合わせ、プロセスを選択できるようにした。
• アジャイル経験がある場合、協力会社さんからスクラムマスターを出す。POは設計部門から出す。

３．アジャイル開発で品はどう関わったのか

• 異常系テストの十分性を確認するようにした。デモだけに頼らない。

• 品質状況のモニタリングをやった。不具合密度、テスト密度を算出した。

得られた成果

• 要求定義の時間が３３％減った。

「世界最強トヨタのＤＮＡを自社に移植する！」
～システム保守における現場リーダーの闘いと成長、そして大部屋への挑戦～

http://www.agilejapan.org/2016/image/D-4_AgileJapan2016.pdf

現場のチーム力

• 生き残るものは強いものでも賢いものでもない。変化に敏感なものが生き残る。　By ダーウィン「種の起源」
• 現場の人間がそれぞれ最適な選択をしていくことが大事。経営者が、こっちいくんだ、ではダメ。
• 個人力だけでなくチーム力。

経営層の問題認識

• 特定の人が問題ではなく、組織文化の問題としてとらえたほうがいいのでは。

組織の成功循環モデル　by ダニエル・キムさん

• バッドサイクルとグッドサイクルがある。
• バッドサイクルは、目に見える部分からスタートする。「結果の質」からスタートする。
• グッドサイクルには「関係の質」が大事。ここからスタート。

現場のリーダーの役割

• スクラムマスターにも通じるサーバント・リーダー像
  • チームを活性化する
  • お客様にとっての価値にフォーカスさせる
  • チームによい目標を設定させる

眼に見えない部分の改革

• 現場のリーダー像は、関係の質、と思考の質。
• 目に見えない部分を良くしていくのが、理想とする現場のリーダ像。

しかし・・・

• どうすれば関係の質は変わるのか。
• 関係がよくなると思考の質もよくなる。
  • でも、具体的なリファレンスがないとしんどい。
• 考え方が自分だけ変わっても、周りが変わらないと難しい。

改善塾の枠組み

• 改善塾という仕組みを２０１３年からやってる。
• ６ヶ月、塾に来させる。
• 前半３ヶ月はひたすらチームビルドを実践させる。高木さんに支援いただいている。
• 塾で毎週半日、１５人くらいのリーダーを集める。間接部門の人も集める。
• 宿題を出して、次の塾までに現場のメンバーを巻き込んで、ありたい姿を考え、見える化し、塾生全員でそれを見に行く。

塾で伝える「考え方」

• どういう考え方をしてほしいか。
• 日本のものづくりの知恵、人づくりの知恵を借りてきている。

トヨタマネジメント研究所

• トヨタ生産方式TPSからTMSへ
• やりたいことは会社を１０００年続く企業にしたい。局所的な取り組みでは終わらない。
• トヨタにいる人は、トヨタのマネジメントがなんなのかわからない。ずっとそれがあたりまえになってるので。
• トヨタの強さの原点のマネジメントに特化、進化させたのがTMS。そこを研究している。
• トヨタが最も強いのは、TPSとかではなく、マトリックス組織。
• トヨタは縦でなく横で切っている。開発、営業、運用を横で繋げないといけない。
• 流動的な組織を作ろうとすると、価値観や原理原則が共通なものが必要になってくる。
• 会社はいろんな部署が連携して成り立ってる。そのマネジメントの標準がない。バラバラ。
• トヨタの文化には、古きを訪ね、それらで説明もできる。
• 各社で、共通の価値観がないが７９％
• トヨタは１％の「共通の価値観（原理原則）」に属している。

マネジメントレベルの変化

• 改善塾を６ヶ月やると、チームビルディングできるようになる。
• ３～１０年で、大部屋や組織横断までいくところがでてくる。
• そこができてくると非常に大きい改善効果が出てくる。
• チーム単位でやってても、会社に対し改善効果はでてこない。
• アン・エンタープライズアジャイルという言葉が出てきてるが、それなのかな。

ボーイングの事例

• ボーイング737もTMSをとりいれている
• 737の組み立てにLeanは早くはいってきたが、設計とかにははいってなかたのでTMSをを入れた。
• ボーイングが目につけたのは、現場の小さな改善より、組織をどう変えていくか。そこにトヨタの目を付けた。
• 真ん中にマネジメントのTMSがある。
• 大部屋を作ってクロスファンクショナルな人を集めてやってる。
• 副社長の部屋も、貼り出して見えるようになってる。
• 経営トップ自ら参加するのが大事。
• 経営者を巻き込んでコンサルやっていかないと、できない。
• 生産性をあげるよりも、文化を変えていこう、と動いている。
• まずは見える化から入っていく。
• 欧米系の人は、人間性の話から入ってもダメ。徳とか。
• 早く生産性をだしてくれ、となる。なので、効果を出してから人間系に入っていくと良い。
• 縦軸と横軸のマトリクス組織を作っていこう。

トヨタの方針管理

• topからworkingのレベルまで見える化していきましょう。
• 会社の風土を変えようとして、３～数年やっていくと、変わっていく。
• でも、そこにいる人はそれが感じられない。
• 変われない、と思っていることは変われる。
• TOYOTAのDNAは、トヨタウェイ。
• 現地現物ができているか、常に問いただしている。
• 誰々がこういっていた、というのはトヨタではNG。
• 現地現物ができない障害は、上司の理解。
• 上司も現地にいかないといけないのに、報告を待ってる。そうじゃない。

アジャイル開発に適した要件の作り方 ～何をどこまで決めればよいのか～

小堀 一雄 氏　株式会社 NTTデータ　アジャイルプロフェッショナルセンター


ユーザと作る要件

• アジャイルはcomplex。complicatedではない。
• F1マシンは仕様があって、それを作る。complicated.

• 渋滞情報でどう早くいけるか、を考える問題は、complex
• アジャイルの考え方を使って考えていきましょう。
• 会話が増える＝意識齟齬が減る

Scrumと落とし穴

• 開発の前後をカバーしないと価値がでないのでは。
• Q.プロダクトバックログは誰が作るの？
  • A.ユーザ企業のPOが最初のスプリント計画会議までに。
• Q.バックログどうなっていればいいの？
  • A.deep特性を守ってね。
  • そんなの、できれば苦労しない。
  • アジャイルに適した要件の作り方を考えてコンサルしよう
• depp特性を満たして軽量なフレームワークを活用してつくる。

deepのd：　適切な詳細さ

• スプリント計画に着手できればいい。要件記載ルールを決め、画面イメージを共有する。

deepのe：　見積もり

• 開発する順番を決めたいだけなので、相対的に見積もればいい。

deepのe：　創発的

• 対話をすることで、正しい方向に向けていきたい。
• いろんな人の脳みそを使う。
• ビジネスモデルやユーザ像を共有する。

deepのp：　優先順位

• 手段をいかに軽量に達成するかの問題に落ちる。

軽量な武器を探す

• ユーザーストーリー　・・・　dを達成する
• UI StoryBoard　・・・　画面が見えてくると、裏のビジネスモデルも見えてくる。あー、そういう使い方なのね、と言わせれば勝ち。
• プランニングポーカー　・・・　創発的にも関係ある。３と２０の違いはなんだろう？
• lean canvas　・・・　③の価値さえメンバに伝えておけば、メンバも考えてくれる
• pragmatic persona　・・・　仮説のイメージを作る。
• user story mapping　・・・　線を引くだけでなく、キモなストーリーはどれで、それに本当に価値があるのか、を確認する。
• これらがなぜ軽量か、というと、全部１枚絵で表現できる。

問題１：

• UXが重要でない課題を設定した。バッチとか。

A：

• 短いスパンでユーザと会話しても、創発的な議論は発生しにくい
• UXが重要な課題の優先度をあげて、アジャイル開発の価値を最大化させる
• 要件定義にかけないところをアジャイルでやる

問題２：

• デザインなど頻繁に検証が必要な要件に他の要件と同様に優先度を付ける

A：

• スプリント毎のフィードバックでは遅く、無駄な作業が発生する。
• タイミングを逸する。１週間では遅い。
• →特別扱いでjust in timeでいんじゃないか。毎日だして、お客さんに見せる。

問題３：

• 開発チームが、ユーザ像を無視した開発をしてくる

A：

• プロダクトオーナーは、本質的でない意識齟齬に指摘をし続けないといけなくなる。
• →企画時に作成したビジネスモデルは開発チームに説明し、開発ルームに貼るべし。

おまけ：要件は作ったら試す

• スプリントレビューで試しているんじゃないか。
• でも、通常では関係者のフィードバックしか得られない
• 本来は、市場の反応が判断材料となるはず。
  • フィードバックをもらう仕組みを構築する。
  • まずは反応を見る

各プロフェッショナル団体は、アジャイルをどう考えているのか
～アジャイルに共感できる！できない？～

日本SPIコンソーシアム　小笠原さん

• http://www.agilejapan.org/2016/image/B-5-5_JASPIC-2.pdf
• ソフトウェアプロセス改善活動(SPI)
• SEPG ・・・ ソフトウェア開発プロセスまで整備するグループ。兼務でもいい。
• プロジェクトは進めるけど、俯瞰的に見て、どう高めていこうかに責任を持つ組織。

日本プロジェクトマネジメント協会(PMAJ)

• http://www.agilejapan.org/2016/image/B-5-6_PMAJ.pdf

ソフトウェアテスト技術振興協会(ASTER) 西さん

• アジャイルは工学の進化系
• トヨタ、って言わなくてもいいんじゃないか。
• 日本人は暗黙知でやるけど、海外はスクラムガイドとか形式知でやる。

小笠原さん

• 設計と生産はトヨタでも全然違うのでは。

西さん

• アジャイルってマネジメントの要素が強い。
• トヨタは技術の棚をきちんと定義していて、きちんと分類していくる。

プロセス改善とPMBOKは相性が悪い、という話があった。
→　QCDの時代はそうだったかもしれないが、今は１０個になってて、プロジェクトの成功要件に人材の成長になってたりする。

部課長は「金」、偉い人は「人」、と言う。
人がまずあって、そこにQCDが付いてくる。

TPCは認定とかないが、うまくやったところが賞もらえる。
でも、衰退してきた。それはTPCじゃない、と言い張る人が出てきた。

---

感想

とても充実したセッション構成で、気付きや学びが多かったです。

一番印象に残ったのは玉川さんの講演かなぁ。
あんまりアジャイルは出てこないんですが、エンジニアの生き様そのものを扱っており、とても奮い立つ内容でした。

来年も部の予算を確保して参加したいと思うのでした。