yamamanx

growing hard days

*

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

      2015/07/05


Agile-Japan-top0409

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しかない情報を手がかりに会議室でどれだけ打ち合わせをしていても、奇跡的に合致する場合を除き、間違えた方向へ向かうための結論探しになってしまうのでは、と思いました。
@yamamanx
開発ベンダー5年、ユーザ企業システム部門通算8年目のSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

 - event, study , ,

ad

ad

Message

メールアドレスが公開されることはありません。

  関連記事

DevLOVE関西「プログラミングを楽しく続けるための健康Hack」に行ってきました

DevLOVE関西「プログラミングを楽しく続けるための健康Hack」に行ってきま …

Innovation EGG 第8回 『可視化・課題と支える技術』に行ってきました

Innovation EGG 第8回 『可視化・課題と支える技術』に行ってきまし …

Java SE 7 Silver対策勉強をしながらメモ 2015/2/5

本日は例外。 いつものごとくマークダウンで記載したのでそのままJetpack M …

「関ジャバ Java開発のためのDocker & てらださんせきらら in MS関西」に行ってきました

「関ジャバ Java開発のためのDocker & てらださんせきらら i …

「Talend ハンズオンセミナー」に行ってきました

Talendとは データの整備・統合 ビッグデータ対応 ストリーミングデータ ア …

EC-CUBE3.0 コードリーディング勉強会第1回目に行ってきました

EC-CUBE3.0 コードリーディング勉強会第1回目に行ってきました。 ECサ …

DevLOVE関西 現場甲子園2015 「西日本大会」に行ってきました

DevLOVE関西 現場甲子園2015 「西日本大会」に行ってきました。 全部で …

「XP祭り in 関西 2016 〜アジャイル15周年ふりかえり〜」に行ってきました

「XP祭り in 関西 2016 〜アジャイル15周年ふりかえり〜」に行ってきま …

TwilioJP-UG大阪 第二回 勉強会「Report SIGNAL2016」に行ってきました

TwilioJP-UG大阪 第二回 勉強会「Report SIGNAL2016」 …

AWS Summit 2016 Tokyoに参加してきました (Day3)

飛天3日目です。 JAWS-UGブースのすぐ前にあったこのお水がめちゃめちゃおい …