Agile Japan 2015 大阪サテライト「アジャイル開発への架け橋」に行ってきました

Agile Japan 2015 大阪サテライトに行ってきました。

具体的な目的は、アジャイルやスクラムやXPといった言葉を使わずに、チームでの仕事のやり方として、

• どうするのが良いやり方なのか？
• なぜそう思うのか、その根拠は何なのか？

を説明できるようになりたく、理解する必要があると思ったためです。

各セッション

気になった事をメモしています。

アジャイル・テスティング 〜 チーム全体のためにテストとテスターができることを学ぶ旅

• オフショアによる余分なコミュニケーションコスト。
• 「砂場では仲良く」 = 「気持ち良く仕事が出来る職場環境」
• すべて共有する。他人の物を勝手に使わない。
• 意地悪は自分に帰ってくる。他人の砂の城を壊さない。他人を気遣い仲良く遊ぶ。
• 見誤ったまま伝えてしまった。かつ言葉では全ては伝わらない。

デジタル革命にはアジャイルがよく似合う

• スピードが命。弱冠日本語がおかしくても情報が確定していなくても出すようになる。
• トイレのセンサーで明日風邪を引く事が分かる。でも日本では医者しかそれを言わない。
• 競争優位は続かない、1度開発が終わっても安心できないから企業はイノベーションを起こし続ける。
• Customer Centric(顧客中心主義)相手を深く理解する、フィードバックを受け改善を繰り返す。
• Design Thinking(デザイン思考)理解、探査・探索、検討・検証、プロトタイプ・改善を繰り返す。
• プロトタイプを作るとどんどんアイデアが出てきた。
• マインドセットが変わる。体験をする事で本質に気づき考え方も変わる。だからプロトタイプは必要。
• Collaboration ビジネスとエンジニア、チームとお客様
• 議論するのではなく、思いを対話する。
• あなた考える人、私作る人ではだめ。
• 思いを可視化したプロトタイプをお客様へ見せてフィードバックを受ける。
• Visible 見えれば工夫できる。
• Iterative 改善、改善、改善する。
• お客様に教えてもらう。 Feedback!Feedback!Feedback!
• This is Agile。アジャイルそのもの。ソフトウェアを作る事はビジネスを作る事そのもの。
• ウォーターフォールで戦略練って、ウォーターフォールで開発していては遅い。
• ウォーターフォールかアジャイルかなんて議論に意味はない。アジャイルしか選択肢はない。
• Just do it.
• Agile Lean Constant beta
• Agile is Mind-Set
• 3年先が見通せますか？ 見えない3年計画に意味はない。世界はリアルタイムで変わっていく。アジャイル型の経営行動に変えるべき。
• この先ウォーターフォールやっている人なんかいない。そんな議論に意味はない。それなら徹底的にアジャイルを研究するべき。

ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル？

• アジャイルソフトウェア開発宣言
• System of Record(SoR) 基礎体力作り、他社もやっている事、日本企業が望む傾向
• System of Engagement(SoE) 戦闘力、他社がやっていない事、欧米企業が望む傾向
• SoR,SoE両方が大切、基礎体力があって戦闘力も必要。
• SoE 関係性、即時性が大切
• SoR 形式化しやすく、しなければならない
• SoE 要件定義がしづらい、変化に即時に対応しなければならない
• Lean Startup
• 今の時代の変化しやすいビジネスモデルに対応する
• 定義、計画が立てやすい、WBSが作りやすい、タスクテンプレートが使いやすいものはウォーターフォールでもいい。そういったものは過去にあるもの(パッケージ)を使えばいい。
• 相互依存宣言 Agile Project Management Manifesto pmdoi.org
• 相手を知る技術 本音を探る技術、本音に触れる技術
• 相手に委ねる技術 選択肢を与える技術、本音を引き出す技術
• なぜ人を変えるのは難しいのか、人からの押し付けには本能で拒否される。自らが変わり、環境を変える、人が自ら変わりやすい環境にする。

スクラムやったらこうなった

• 勉強会、セミナーでの自分ルール。登壇者の方と話をする、懇親会に参加する、とにかく話を聴きに行った
• 「やってください」ではじめているとうまくいかなかった。
• 実際に自分がやってやりにくいと感じた事を変えてみた。
• チーム目標のMTG共有、個人目標も全員共有、メンバーそれぞれに期待している事を明確に伝える、他のチームMTGに参加した
• ちゃんと、きっちり、しっかり、禁止
• 魔法の言葉「これ、なんのためにやってるんですか」
• 小さな事でもいいから1つ1つ変えていく。変えようと思うのであれば自分から動いて失敗して学ぶ。

行ってみて思った事

• ビジネスがITに直結し、世界がリアルタイムに変化する、今の選択肢はAgile開発だと思う。
• SoRはパッケージ依存でもいいと思う。バックオフィス向けのシステムであってもサービスに直結して差別化の必要なものはSoEと位置づけて考えれば良い。
• とにかく壁が高かろうがなんだろうが動いて、失敗したら改善して動く、それによりSoEのAgile内製開発体制化を目指す。チャレンジし続ける。
• ビジネスのためにやる事が顧客のためになっていなければ意味がないんじゃないかと思う。アジャイルソフトウェア宣言はビジネス成立のための手法から顧客満足度向上のための手法へのシフトなんじゃないかなと思いました。
• もしかすると0.1/100しかないような雑な発想やそれに基づく依頼も、打合せや資料ではなく動くものを少しづつ、プロトタイプを提供する、目に見えるようにする事で限りなく100に近づけていけるのではないかと思いました。
• 0.1しか出せない事には、時間的な制約や、発想そのものがその時点でそれでしかない場合もあると思います。だから言わない、ではなく言ってもらって、少し具現化してみてすり合わせる、結果を提供してそれに対してのフィードバックをもらう、それにより結果的なスピードも質も向上し、さらに計画変更への対応もなんとでもなる、と思います。
• 0.1しかない情報を手がかりに会議室でどれだけ打ち合わせをしていても、奇跡的に合致する場合を除き、間違えた方向へ向かうための結論探しになってしまうのでは、と思いました。

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「AWS認定資格試験テキスト　AWS認定AIプラクティショナー」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。