夏サミ 2014 『創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について』聴講メモ #natsumi

『創業122年の企業』と銘打たれた東京商工リサーチ社の開発案件について、開発側とユーザー企業側両者からのプレゼンテーションがあったのが特徴的だったのがこちらのセッションです。ちなみに Atlassian 社提供枠の講演だったということ。

創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について鈴木雄介〔グロースエクスパートナーズ〕/和智右桂〔グロースエクスパートナーズ〕/青木光宏〔東京商工リサーチ〕

顧客との関係性、契約関係があるため win-win になりにくいエンタープライズ開発で顧客価値にコミットするには良い関係作り、顧客と開発チームがきちんと意思疎通する必要性
適切なプロダクトオーナーを見つけること
- 組織内のステークホルダーや顧客・ユーザーのニーズや優先順位について深く理解する
- 開発チームに何をどの順番で構築するかを伝え、受け入れ条件を明確にしてその条件を満たすテストが実行されるようにする
  - 和智さんが共同翻訳者のエッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)にも書いてある
世界最高のプロダクトオーナーといえば Steve Jobs なのでプロジェクトでジョブズがどこにいるか探してみる
事例紹介
- 顧客 : 東京商工リサーチ、『倒産』という言葉を広めた老舗商工社
- プロジェクト
  - tsr-van2 : 企業の信用情報や財務情報をオンラインで検索し、閲覧できるオンラインサービス
  - 性能や使い勝手の向上、事業のオンライン化のため刷新
  - 2014/1 にリリース、300人月
    - 最初からアジャイルではなく WF で８割完成させてから継続的改善プロセスに突入
- 多種多様な要件に応えられるスーパーマン（Jobs）はいない、が組織内に個別にできるひとはいる
  - 最もニーズを理解しているのは営業、表示項目の精査は業務部門、伝えるのはシステム本部、受け入れ条件を決めるのは業務部…
- 組織の意思決定プロセスが適切に機能すれば、それがプロダクトオーナーとしての役割を果たすことになる
  - 意思決定はそんなに速くないしフィードバックも速くない、が定期的に行うことはできる
- 組織をプロダクトオーナーにするために定期的な３つのフェーズとサイクルに分ける
  - 新機能 : 年に１、２回 : 企画・設計・開発などそれぞれの段階で役員承認 (WF 的)
  - 定期改善 : 年に４回（日付固定）: 工数枠は事前承認、実施内容はバックログから優先順位で洗濯後に承認(アジャイル的・３ヶ月定期)
  - 保守 : 随時 : 毎月定期保守。実施内容はシステム本部内で決定。問い合わせや障害、ちょっとした改善対応など(いわゆる保守・２週間定期・緊急対応あり)
ソフトウェア開発企業の視点
- スクラム 'を' やろうとしてもうまくいかない : 大切なのはスクラムを取り巻く環境が適切準備されていること
- PM/PL として顧客価値にコミットする
  - 顧客の感覚を理解すること : 同じ物を見て、同じ物を感じる
    - ビジネス
      - ドメイン駆動設計 : 言葉や関係性は常に重要
      - システム全体構成レベルで業務との整合性をとることを目指す
      - お客様の仕事に興味を持つこと（モデルを作るということだけではなく、素朴な興味を含む）
    - ビジョン
      - 顧客がどこに向かおうとしているのか（成長先着、マーケット、投資計画 etc）
    - 伝統と文化（ビジネスとビジョンにより、顧客の見ている景色を教諭できる）
      - そこから何を感じ取れるか
        
        価値観、肌感覚
        
        企業として守らなければならないこと、エンドユーザーから求められているものには敬意を払う
  - 顧客が納得のいくように実行していくこと : 形を決めるのではなくエネルギーの流れを整える
    - プロセスビルディング
      - いわゆるアジャイルのプラクティス
      - スピード感をそろえていく作業 : 息切れしてしまうラストスパート状態から持続可能なペースへ
    - チームビルディング
      - 作る物ではなく出来上がるもの
      - 情報の流れの中でメンバーの力量や適正に応じたロールの配置
      - 穴を埋める人、流れを整えてくれる人
      - リズムに応じたチーム分け
      - リリースに名前をつけてみる、食べ物の名前など（夏みかんゼリーとか）でもよい
      - 夕会での今日の残タスク報告（遅くまで残りすぎないように）
  - 顧客にフィードバックすること : 言われたことではなく納得した上で正しいことをやる
    - システムから読み取れること : 単なる数値の報告に終始しない、ログや統計情報からシステムの改善点を導く
      - プロの開発者としてあるべき姿に対してポリシーを持つ
      - 顧客の感覚理解は大前提、伝えるべきことは伝える
      - 納得いくまで話し合う
顧客からの視点
- 10年前にアウトソーシングを始めた結果、プログラムを書ける人がいなくなり、新規開発案件がない一方で業務部門が独自にシステムを導入するようになった
- 何かが違う
  - ベンダーからのアウトプットにずれ、周りからの要求に応えられていない、今のシステム本部が本当に必要かわからないなどの違和感
  - ベンダー主導からユーザー主導へ、ユーザー側は関係部署を巻き込む形へ
- 若手でコアメンバーを構成
  - あるべき姿を議論
  - 要件定義から設計フェーズにも主体的に参加、受け入れ条件を決めてユーザー企業側で業務テストも実施
    - システム的にわからないこともあり本音ではなんでここまで関わる必要があるのか？と思われていたかもしれない
- 現場とのコミュニケーション
  - 透明性のある情報共有
    - 電話やメール等の個々のやり取りは原則禁止
    - どんな内容でも必ず回答
    - 要望はバックログへ取り込んで優先順位付け
- 役員とのコミュニケーション
  - 役員会での定期的な状況報告
  - オーナー部門性 : 各部門から稟議申請
  - 定期的な改善活動の予算化
- 開発チームとのコミュニケーション
  - 非常駐でリモートワークだったが意外と活発だった (JIRA を活用)
  - 電話・Skype で空気感を共有
- 個人としてはスクラムを知らなかったが、結果的に組織としてプロダクトオーナーという機能を実現できたのではないか
  - ６つの活動を組織してコミュニケーションを通じて意思決定を行うことができた
  - 『想い』を維持・成長させることができる
『想い』 : 何かしら物作りをするときにそこに想いがある
『リズム』 : ユーザー企業毎にそれぞれのリズムがある
想いやリズムを理解し、共にゴールに向かって走る
新しい挑戦 : １つめの新機能開発を実施中
- （システム本部を介さず）経営企画室とソフトウェア開発企業が直接やり取りできるのか？
- 企画と仕様の溝は埋められるのか？
- ユーザーからのフィードバックをどう受け取るか？

受託側の心構えとしての３点、感覚の理解、納得感のある実行、そしてフィードバックというのは当たり前のようだけど整理できていなかったことで今後の参考にできそうです。また今回のように発注側もがっぷり四つで開発現場にコミットする体制があると組織としてのプロダクトオーナーに近づけるのでしょうか。通常一人が役割を担うことで一貫性のある優先度管理・ビジョンの共有などを実現するプロダクトオーナーを複数人で実装する場合、具体的にスクラムイベントなどどのように変化するのか・またそのプラクティスなどが気になりました。

ちょっと調べた感じでもやや古いですが一人のプロダクトオーナーという問題に対する解決策なんていう記事もあったりしたので、毎回立てようとして難易度の高さを感じるプロダクトオーナーの実装方法についてもう少し違う解がないか調べてみようと思います。

値引きにも釣られて帰りがけにエッセンシャルスクラム買ったのでまずはそれ読むところからですが。それにしても同僚から教えてもらったんですが和智さんの翻訳されてきた本のラインナップが凄すぎる。