104287_normal_1582037128_スクリーンショット_2020-02-18_23.42.38

2020-03-04 チーム・ジャーニー・シリーズ「プロダクト作りにおける段階的発展とは何か?」 #DevLOVE

2020/03/04 に開催された チーム・ジャーニー・シリーズ「プロダクト作りにおける段階的発展とは何か?」 のイベントレポートです。

●イベント概要
プロダクト作りにおける段階的発展とは何か?
「チーム・ジャーニー」の中核となる概念 「段階」 をテーマとした対談を行います。増田さんはソフトウェア設計の方向性から 「発展」 という概念を見出し、両者で段階との共通性を感じています。

ソフトウェア開発の設計とプロセスが置き去りにしてしまった「段階的発展」について、ダイクストラの「Stepwise refinement」論までさかのぼりながら、現代の現場の最前線にあるプロダクト作りそのものについての方向性について探求します。


■市谷 聡啓さん

●自己紹介
・最近やっていること
  DX支援
    今までできていなかったことを新しく始めたい
    を中の人と一緒に進めている
  仮説検証型アジャイル開発
・書籍
  カイゼン・ジャーニー
  正しいものを正しくつくる
  チーム・ジャーニー
●「段階」とはどういう意味で使っているのか
・プロダクト開発での不確実性
  何をつくるべきなのか
  それをどうやってつくるべきなのか
  あらかじめ正解を手にすることはできない
・意思決定、合意形成が難しい
  方向性や期待が様々
  理解不足、練度不足
・チームもプロダクトも最初から完成型は見えない
  つくりと振る舞い方を同時に進めていく

●agile: 少しずつ繰り返しながら形づくる
・アジャイル開発は20年取り組まれている
  ウォーターフォールとアジャイルの2項対立
  全体性が欠如している
・どこへ向かいたいのかが見えにくい
  1週間のタイムボックス と 単一のリストだけでは
  意思をかたちにするのは難しい
・希望/妄想があるからこそ、歩みを楽しむことができる

●段階の設計が大切
・目的地を見立て、たどり着くために必要な状態を構想
  プロダクトとチームの両面で
・青写真のままになろうと進むのは危ない
  分かっていないことが多い
・青写真自体も変化させる
  目的地は通過点
・目的地を定めて踏み出してみることで見えてくる

●ジャーニー
・プロダクト ジャーニー
  プロトタイプでPSfit
  MVPでPSfit
  体験を伴う検証でPSfit
・チーム ジャーニー
  活動の見える化
  スクラム
  仮説検証
・出発点の位置次第で、目的地への傾きが決まる
・ジャーニーは連動していく
  チームのジャーニー
  プロダクトのジャーニー
  組織の変革ジャーニー
・ジャーニー = 段階的発展 = 進化
  当事者として意志のある進化
  やっていく中で変化が起きる
  想定していたこと、していないことが含まれる

繰り返し = イテレーティブ
少しずつ = インクリメンタル
段階的に = ジャーニー
形作る

スクリーンショット 2020-03-04 19.48.38


■増田 亨さん

●ソフトウェアづくりの考え方の変化
・ここ5年くらいでソフトウェアづくりが大きく変わった

●考えている品質特性
・発展性
・合目的性
・構造の健全性

●発展性
・過去
  保守性、変更容易性で話されてきた
  リリース後は保守モードになっていく
  正解があって、その状態に維持し続けていく
  守りなイメージ
・現在
  改良し続けていく

●合目的性
・過去
  目的が事前定義できた
・現在
  目的が変化し続ける
  変わらざるを得ないことが認識されている

●構造の健全性
・過去
  一度つくったものを使い続ける
  がちっと固定されていることが価値だった
・現在
  モジュールの構造を改良し続ける
  柔らかくしておけば良いわけではない
  なんでも変えられるようにしておいても
  合目的性は実現できない

●ソフトウェアの複雑さに立ち向かう
・Stepwise Refinement
・1970年代でも複雑さ、変化に立ち向かう話題は出ていた
  ダイクストラ、ホーア、ダール
・アジャイルと同じことを言っている
  内容は、現代ならライブラリで済むサイズ

●継続的・並行性・段階的な改良
・CCSR
  Continuous Concurrent Stepwise Refinement
  3つの活動をシームレスで双方向に段階的に広げ掘り下げる
  これを言語化していきたい
・要件定義
  RDRA 2.0
  議論の可視化と合意形成
・仕様化
  ここを新しい取り組みで
  プログラミング言語で仕様を記述
    全体像は見えにくくなる
  可視化、一覧化はツールで自動生成
    ドキュメント->ソースではなく
    ソース->ドキュメント
・現実化
  データ抽象でモジュール構造を導く
  手続き的なモジュール構造では実現できない


■対談

●市谷さん
・この5年といえばギルドワークスと同年代

●増田さん
・5年前だと、この問題に気づいている、いないで世界が別れていた
  SIer / Startup 両方が変わってきた
    SIer: 変わらなければ
    Startup: これで良かったのか
・2011年頃の会話
  設計というものが行われてないじゃないか!
・総論として「今までのままで良い」はありえない

●市谷さん
・DXという言葉に現れている
  バズワードで終わらせるのはもったいない
  迫られている

●増田さん
・バズワードとしてのDXは終わって良い
  トランスフォームすることは必要に迫られている

●市谷さん
・経営〜現場まで伝わるキーワード
  旗振りしやすい

●増田さん
・情シスが遅れている気がする
・困っているけど、どこに進むのかが見えていない
  意志のある変化の意思が持てない
  危機感と意思の間の距離
・ベンダー丸投げではだめは気づいている
  ではなくどうするのか、がわからない
  困っているということなのだろうけど

●市谷さん
・誰が駆動していく力になるのだろう?

●増田さん
・ビジネスがドライバーだと思う
  startupでも歴史のある企業でも
  ソフトウェアではなくプロダクトは良い言葉
  ビジネス活動の基本要素
・DXの象徴だったのはスマホだと思う

●市谷さん
・DXの最前線に行くと
  ツールを見直すではなく
  業務そのものを見直すを選べる

●増田さん
・昔なら日次バッチ処理で済んでいたものが
  スマホでいつでもアクセスできる状況

●市谷さん
・SoRのブラックボックスなデータを、営業がスマホで参照とか
  時代の違う話をつなぐのは大変

●増田さん
・10年前から積み重なってきたものが、変化の足かせになっている

●市谷さん
・SoRの中がブラックボックスでよいわけがない
・ソースコードからの仕様化に行き着くと思う

●増田さん
・仕様記述言語は昔からあるが、重くて失敗してきた
・Excelでガリガリ書いて、プログラムを書くのはコストパフォーマンスが悪い
・2015年くらいから、型でかっちりつくっていく方に倒れてきた
  railsは広まったが、正しくつくったはずが時間が経ったあとで足かせに

●市谷さん
・ドメイン駆動設計との関わりは?

●増田さん
・ビジネスの語彙を型にする
  知識そのもの
  ブラックボックスを避ける意味にも

●市谷さん
・どうやったら開発チームの外に知識を共有していけるのか

●増田さん
・ビジネスの人も、論理的な文章を書けるようになってほしい
  情報や考えを構造化するスキルが必要
・RDRAの始めのRはRelationship
  構造は、関係性
  仮説キャンバスでも始めはラフなものしかかけない
  stepwise, refinementで進めていく
・保険の約款は120ページくらい
  これだ揃っていれば、設計は楽
・表側にカスタマーサポートとマーケがいる
  こっちの内規は怪しい
  場当たり的なスクリプトが組まれていたり
  責任者が変わるとルールが変わる
・昔は、ごちゃごちゃやり取りして決めた後のデータを保存するSoRを作ればよかった
  今は、ごちゃごちゃやり取りして決める部分をシステム化する
・健全なシステム構造を考えられて
  ビジネスにも興味を持っていくエンジニアが必要
  これもstepwise

●市谷さん
・SoE方面で仮説検証、アジャイル開発から入っても
  SoR、組織に向き合う
  この話が必要になる
・誰が担っていくのか

●増田さん
・stepwise refinementは請負契約ではできない
  分析設計は準委任が多い
  分析設計を続けていく体で契約するとか
  小ぶりな構造に分解するとか


■QA

●段階という言葉に「全体が分かっている」という
 ニュアンスを感じる人はいるかも
 不確実性を探索するマインドを育てていくには?
・市谷さん
  全体性の欠如の話につながる
  でも、何もわからないになってしまいがち
・増田さん
  問題意識は伝わってきている
・市谷さん
  傾きの設計は大切
  メンターがいれば調整できる
・増田さん
  一定の傾きで成長し続けることはない
  平らになって伸びると言われるが、落ちることもある
  極端に言えば「楽しもうよ」

●DXという言葉がここ1,2年で盛り上がったのはなぜ?
・市谷さん
  SoRは時間軸を延ばしても、誰も手を付けない
  やらなくてはの危機感が重なってきたのでは?

●段階の設計を取り入れるときに、当事者意識を持たせるには?
・市谷さん
  「持たせる」な状態は問題かも
・増田さん
  どんなとき当事者意識を持つだろう
・市谷さん
  危機感かな?
・増田さん
  サラリーマンしかやったことのない人と
  独立した事業をやったことがある人は違うかも
  視界が違うのかな?
  関心を持つ場所が違う
  関心を持つ機会がなかったのか?
・市谷さん
  関心を持てる機会は、書籍、イベントなど増えている
・増田さん
  「俺の持っている思い入れ」と同じかどうかとは別
  当事者の多様性
・市谷さん
  バラバラの合意形成が必要
  色の濃さの重なり
  完全に一致させようとすると、なにか違う

●現代の複雑性って、昔より大きいんでしょうか?
 現代人が不勉強で退化している?
・増田さん
  リッチなGUIで、インターネットでつながっているという複雑さはある
  退化はしてるね
・市谷さん
  ニッチになった
  できることが増えたが、いろんな状況に合わせてつくることになった
  退化で思うのは、ナレッジマネジメント
・増田さん
  最近はコミュニケーションツールで言語化されたデータが流通するようになった
・市谷さん
  野ざらしに
  活用はできていない
  人間の手で集める段階が今

●ソースから生成したドキュメントはビジネスの人に見せる?
・増田さん
  ソフトウェアを成り立たせる詳細な整合性は、ビジネスで興味はない
  20%くらいを見せる、動くシステムを見せる
  RDRAくらいがちょうどよい

・増田さん
  こういう活動は面白いからやっている
  つらいときには、自分が決めたからやるという意思
・市谷さん
  面白そう から踏み出すのも意思


■感想

たくさん「そうですよねー」をもらいながら、自分の中のぼんやりした知的好奇心の源泉を見つめ直す機会になりました!

事業活動は、想像できる最小〜最大までの多段階のタイムボックスで
組織の内外で関わるリソースを、変わりやすい/にくい で当たりをつけ
組織が制御できるリソースの配置を調整、その時々の役割を遂行し続ける
ことなのかな、と捉えています。

目的地がなければ、何をどう捉えるかも定まらず、迷走か、繰り返し。
目的地を考えようとする時点で、必ず現在地は存在して、そこからの差分でしか認識はできない。

認識したり、役割を遂行するためには、何らかの型にはめる必要があり
的を得た型にはめることができれば、それはフラクタル構造になり
静的な構成でも、時系列の振る舞いでも、どこまでズームイン・アウトしたとしても同じ構造になる。

そんな型を探求することが、自分の中の知的好奇心の源泉なのかな、と改めて感じました!

増田さん、市谷さん、新井さん、ありがとうございました!!


この記事が参加している募集

イベントレポ

いつも応援していただいている皆さん支えられています。