hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

事業会社でのソフトウェア開発と現場コーチについて

事業会社の現場の実例

2017年8月29日に実施された下記のイベントに参加してきました。

guildworks.doorkeeper.jp

エウレカ」 の正しいものを正しくつくる事例

Pairsというデーティングアプリを含む複数プロダクトの開発・運営
累計500万ユーザくらい
自社内のビジネス・経営層とやり取りしながら強いチームを作り、自社プロダクトを開発することについて話されていました。

エウレカとしてCTO室長の梶原成親さん、Guildworks側として中村洋さんが話されていました。

www.slideshare.net

こちらがおそらく梶原さんの講演資料です。

「ポレット」 の正しいものを正しくつくる事例

オズビジョンから派生した金融系のスタートアップ。
ポイントをまとめるサービス
カード会社や金融会社などと、excelやメールベースでのやり取りしかできないなどの超固いコミュニケーションしなければいけなかった困難さがあった。
そういう固いやりとりやスケジューリングを外部と握る必要がある状態で正しい開発をやることについて話されていました。

PolletとしてCEOの鈴木良さん、Guildworksとして市谷聡啓さんが話されていました。

www.slideshare.net

こちらは市谷さんの講演資料です。

エムティーアイ」 の正しいものを正しくつくる事例

SNSなどでの共有を控えてほしいとのことだったので書けないですが、エムティーアイでのリーンスタートアップのお話などをされていました。

エムティーアイとして高橋知朗さん、Guildworksとして川瀬浩也さんがお話しされていました。

以下の話は主にエウレカさん、及びポレットさんの話に基づいています。
しかし、発表された内容をそのままでは書いていませんし、全然講演で話されていないキーワードも書いています。
アジャイルの導入やアジャイルリーンスタートアップの現場コーチなどに興味がある人向け、(導入に向けて)上司や周りの人に話をするためにどういうキーワードを出せば筋がいいのか、といったことを考えながら書いています。

事業会社の開発の中でどのように「アジャイル もしくは DRR」が機能するか

  • プロダクトの課題(エウレカの場合は=経営課題)を解決する
  • 「ソフトウェアの価値をユーザーに正しく早く届けたい」
  • そのための自己組織化されたチームとアジャイルな開発

(※DRR = 正しいものを正しく作るというGuildworks社のキャッチコピー)

自己組織化されたチーム

エウレカさんのお話です。

自己組織化されたチームとは何か

  • 会社の「自立、自律」という行動規範を満たす
  • チーム自身にスキルがある、どうすればそのスキルを得られるか知っている状態にある
  • 自分たちで意思決定できる
  • 「週1回の会議でステークホルダーに意思決定してもらう」といった承認待ち・判断待ち・仕様決定待ちではなく、自分たちで最も良いやり方をチームで合意

自己組織化するメリット

  • 現場で判断し、問題、課題を解決することによって早いサイクルで改善できる
  • デリゲーションが適切にできている
  • 仲良しチームでなく、厳しい指摘をフィードバックしあって改善し、視座が上がる
  • デリゲーションはゼロか1かではなく、エスカレーションすべきものは適切にエスカレーションする。

アジャイルな開発

アジリティ、透明性の担保とは何か、スクラムとの関連性

  • アジリティとは敏捷性のこと
  • ソフトウェアは計画をひたすら厳密にやるよりも、動くソフトウェアを常に見ながら改善するほうが届けるスピードが上がる
  • 価値を届けるスピード(アジリティ)を追求する = アジャイル開発
  • アジリティを追求するにはどうしたらよいか? スピードを測れる状態が必要条件となる。つまり進捗状態や障害の有無などの「透明性」
  • ソフトウェア開発の透明性を常に担保し、可能な限りPDCA的なサイクルを早くクルクル回すためのフレームワークスクラム
  • 透明性に重点を置いて、チームが自己改善を進める = 自己組織化されたチーム
  • スクラムも出自はトヨタ生産方式

線表を引いて、マイルストーン(約束)を守りましょう 

  • スクラムアジャイルも計画を立てないということでは決してない
  • 着地までのリリース計画を全員で見立てる
  • いつ、終わるのかという現実感を全員でもつ
  • どうなれば完成と言えるのかの認識を揃えることで、プロジェクトに背骨が通る
  • チームを守る外堀としての線表が存在することになる (not チームを締め付けるもの)

割り込みとバッファのマネジメントについて 

  • チームの開発を守る内堀としてのバッファマネジメント
  • 割り込みや仕様の変更などの遅れは発生するとわかっている -> マイルストーンを使って空のスプリントで受け止める
  • CCPM的に全体の長さを見て、割合でバッファを入れられるのがベターかもしれない
  • 内堀、外堀で守っているものが仮説検証やアジャイルを中心とした「正しいものを正しく作る開発」。

アジャイルコーチについて

「正しいものを正しく作る」に対してアジャイルコーチが果たす役割

  • 「自分たちで考えて行動する」 ことの習慣づけ
  • アジャイル開発やウォーターフォール開発の開発プロセスの知見全般、見える化や課題解決のためのアイデア = 生き字引、あるいは道具箱
  • 様々な場でのファシリテータ 中立性 言いづらいコミュニケーションの橋渡し
  • 変化を推進するチェンジエージェントの最初の仲間

アジャイルコーチのメリットなどについて

  • CTOやスクラムに詳しい人がスクラムの伝道や運用にフルコミットした場合、他の仕事ができなくなるリスク
  • 書籍などで自習した場合、うまくいかなかったときに立ち直るコストが高い
  • トータルのパフォーマンスやチームの成長スピードを考えるとお得

結局のところ、どういう効果を目指しているのか?

  • チームが自己組織化される
  • プロダクトの価値を追求することに集中する
  • (自己組織化とかぶるが)エンジニア組織として当事者意識を持つ、学習する組織になる、ビジネスや目的に対する意識を持つ
  • ITプロジェクトの実行が変な方向に行かない

現場コーチなどのサービスの効果はこのような感じだろうと思っており、そんなもの自給自足できるよという組織もあれば、難しいという組織もあるだろうと思います。 本当にそんな効果あるのかみたいなのは現場の実例を詳しく聞いてみるしかないと思います。