SUNABACO DX人材育成講座 第7回 アジャイルな問題解決プロセス・BizDevOps
「先の見えないチャレンジだからこそ、開発だけではなく、運用やビジネスも、小さいサイクルで行っていくことが重要。その手法を解説」
もうね、タイトル見た時から、「何言っているのかわかりません！」ですよね。アジャイル、BizDevOps・・・
もう、学ぶしかない！というスタイルで今回も始めていきましょう！
質問解説
ツールが目的ではない。変化のスピードが早すぎるので、機能を学ぶより使うところだけ学ぶのが効率的。学習コストを考えてやることが大事。
ノーコード＜＜＜コードありで自由度が違う。学習コスト、作業コストが増えれば増えるほど自由度が上がると考えて良い。
「情報をしまう、情報を出す」
という機能に注目して操作することで、どのアプリも大体同じ機能になっているので、良いバランスを考えましょう。
Glideに限らず、情報を預ける企業をどこまで信用するかによる。
Google、Microsoftなどにはもうすでに情報は見られていますよね。
個人情報は？→まぁいいとは言えないですよね。特に行政などは具体的な名前を入れられない。これを注意して考えてやりましょう。
SUNABACOでは、
「責任は経営陣に、権限は現場に」
やる人間が・現場の担当者が自らそう考えて「良い」と思ったことは実践しろ。報告すらいらない。
新しいことをチャレンジしない方がリスクである。失敗を気にせずチャレンジできる土壌がある。
これは医療業界では、絶対に醸成できない土壌だなと。
責任と権限の全てが「医師」に集中し、最終的に医者に確認しないと何も動けない。
医師も他職種に「責任の移譲」を行って権限を与えることをもっと考える必要があると、いつも思っている。
でも、「ぼくのかんがえたオリジナルのすごくいいちりょう（データ的には多分誤差範囲）」を他スタッフの運用にも用いるので、再現性が低い・他医師と同一規格化されないため、毎回確認が必要になる。
結果、自分で自分の首を絞めて「24時間ずっとコール待ち」みたいなことが起こっているなぁと。
もっと現場に「権限」
ある程度の責任は「指示をする医師」
再現性のある指示で、「現場の確認を減らす」
これができるだけで、医療業界の無駄な連絡は激減するのかなと思う。長年勤めた医者が待遇が下がってもなかなか他に移動しないのは、この「暗黙知」的なものが他でもう一度再現する苦労を嫌がっているのかもしれない。
おっと、話がそれた。
そもそもAIに任せるために、最低限の知識が必要。
定型化された、知識や経験のない質問はAIが
患者の観察・経験が必要な質問は、看護師がという変わり方になっていくので、最終的には看護師の経験は増える方に行くはず。
音声入力でメモを入れる→メモのアップデートを検知してサーバーにデータを送ることができる。
音声入力をエクセルのセルに送る→背景にGASを入れてAIでエクセル形式に変換し、別のシートに移すことで、自然言語から要素を取り出すことができる。「実現可能な技術である！」
アップデートは新しい機能の実装。
試行錯誤ではなくて、新機能追加の「価値を提供する」ことができればそんなことにはならない。
本日の講義では、そこの問題を解決する手法について学ぶ！
アジャイルなデザイン解決のプロセス
小さく作って、確認しながら進めていく→体系化された考え方がある。
従来の開発では、全てが完成しないと、良いか悪いか判断できない
思ったものと違った結果が出た時、手戻りが大変！
今までなぜそれが押し通ってきたのか
VUCAの時代、前例のないものづくりではうまくいかない。
DXは前例がない、個別化されたことは企画の段階でベストな姿を描くことができません。
それでは、どうしたらいいのか？
「それぞれの機能ごとに開発・検証をする」
クライアントの要件の中で、どの機能が必要かを分解する。
実用最小限の機能を追加して、それで試す（これがうまくいかなかった場合、最低限のリスクでやり直しすることができる）。
その上で新しい機能を追加する→評価する。
「ゴール100点」があり、それを目指すのではない。
なぜなら、使ってもらわないと有効かわからないし、変化が大きく作っている間にゴールが変わるかもしれない。
一番最適なゴールがわからない（作る人、依頼した人ともに）中で、絶対に必要な機能の実装を繰り返して、最終的に出来上がったものが「顧客が本当に欲しかったもの」となる。
実際に使ってもらうものを作るためには、「正しいものを、正しく作る」
最初の時点では、可能性は無限大にある。
ユーザーインタビューを行い、仮説を立てる。実際に検証し、さらに仮説立案する。
非常に良い実例：実際の音楽を作る上でコードは６つしかない。これを電卓のような形で再現することができるのではないか？
ユーザーアンケートで、実際にニーズがあるか調査
価格も調査。3万円台より上は厳しい。
ビジネス上も3万円以下で設計する→結果小売を使うのはやめて、物流も含めてかんがえた。値段から逆算して設計する！
仮説立案（モデル化）→評価→検証→
その中で、最も優先度の高い機能を実装した実用最小限のプロダクトを作る
MVP：Minimum variable product
アジャイル開発（正しく作る）のフェイズに持っていき、小さい機能を追加実装し、実際に使ってもらって改善を繰り返す
正しく作るためのアジャイルの方法論「スクラム」
考え方の根本は、変えていくことを基本とする
試行錯誤のプロダクトでは、途中で変わって困っているようではいけない
アップデートの時には、今一番欲しい状態で渡してあげる！
どんどんより良いプロダクトにする。
関わる人たちにとって、最も欲しいものを作って渡す！
アジャイル開発の全体図
アデリアレトロの例
若手社員が「売れる！」と考えた→経営陣が「そんなの売れない！」→市場調査→試験販売の許可を得た→経営陣がその成果を認める→正式実装
アジャイル開発の良い例（誰も正しいものはわからない、実際にやってみて成果を上げた良い例）
具体的なスクラムのやり方
作るフェーズ
一般的には２週間を一つのスプリントとする。
成果物は「出荷判断可能な状態」であるべき。これを怠ると、アップデートが受けれられなくなるので、めちゃくちゃ重要。
必要な機能を優先順位をつけてリスト化したもの
やるべきことを全て一覧にする。
最も優先順位が高いものから実装していく
一般的なTodoではない！
必要な機能の一覧、「使う側視点のtodo」になっている
「勤怠機能を実装」と「ユーザーが勤怠機能を使える」には大きな壁がある
優先順位はどうやって決める？
条件を削ぎ落としていった結果、「これがないとだめだよね」という機能を優先する。
車で例えるならば、車輪を使って移動するが、一番優先度が高い
優先順位が高いものにはきっちり粒度を上げて機能をバラしておくことで、実装しやすくなる
これは、実際に実装しながら、ユーザーの評価から積極的に優先順位を変えていく「積極的に！」
「これ、見積もりできなくね？」時間的にどれくらいでできるかがわからない。
それぞれの機能を相対評価で見積もることができる！
実際に関わるスタッフで集まって、それぞれの工程に点数をつける。
チームでそれぞれの工程の「重さ」を見積もる
そこを基準として、他の工程の先が見積もることができる。
例えば、
１つ目の工程が見積もり15Pのポイントで２週間かかった。
２つ目の工程はプランニングポーカーで30Pだったとすれば、この工程は４週間かかることが予測できる。
MVP作るのに１５０Pがかかると予測していたのであれば、10スプリント（２週間x10）くらいで作れそうだと予測する。
勘や経験だけではない、ある程度予測可能な理屈で想定する。
実測値が準備できないので、実際やってみた経験からの予測値で工程の先を予測する。
予知や予測がつかない開発なので、何が起こっているかを全員で把握し、最適化する。
確認をするフェーズ
全員が集まって作業結果を検査する
ステークスホルダーが参加してくれないようなら、うまくいっていない！
アジャイルを学ぶなら必須の本
アジャイル開発の考え方は、トヨタ方式からきている
チームで何が起こるかわからない、正解かわからないことが前提で考える。
KTPを確認する
現場のプロダクトで、Keep,Problemを挙げて、今後のTryを決める
変動性を受け入れて、それを確認して進めていく！
スクラムをまとめると・・・
日本語でわかりやすく！
価値探索から、MVPを具体的に作成（スクラム手法＋アジャイル開発）さらにMVPの作成のループについて粒度高く解説された内容だった。
BizDepOps
BizDevOps（ビズデブオプス）とは、企業における開発部門（Dev：Development）と運用部門（Ops：Operations）に加え、ビジネス部門（Biz：Business）の3つの部門が連携してビジネスの生産性を高める概念のことです。また、「企業のビジネス目標をより速く達成するために、3部門が連携する体制や、それを実現する」ための概念だともいえるでしょう。
今まで説明してきた開発（Dev）のアジャイル手法に、運用（Ops）ビジネス（Biz）も合わせてアジャイル手法にしていく話
アジャイル開発することで、開発と運用の距離感が近くなる！
開発、運用が相互に対応し合うことができる。頻繁にデプロイすることで、より運用が求める開発を出しやすくする。
開発と、運用のサイロ化を無くしたら、ビジネスとのサイロ化もなくしていこう！
何がビジネス的価値があるか。それはやってみなければわからない。
アジャイルの形としてビジネスも小さく作り、そのフィードバックを受けて対応する。
将来的にどのようなシステム開発が必要になってくるか？
このままの開発でやっていては、あまりに遅い。数年に一度のベンダー打ち合わせの開発では、全く間に合わない。業務の棚卸しを知っている人間が入らないので、イノベーションが起きづらい
BizDevOpsの考え方を用いることで、素早い開発と運用で、迅速なイノベーションが起こる。小さく作って確認して進めていくことで、運用データからの反応を確認できる→EBPMに基づいた改革ができる。
現場の人間が、新たな技術のキャッチアップができるようになる。
現場の人間が、現場のことを一番わかる！
オペレーションが安定する
統計学的な考え方、得られたデータから、インサイトを得ることができる（運用データから価値提案）
現場の人間が、今の仕事をわかっている。これを自分たちの職場で、自分たちが良い未来を描くことができる。非コア領域を機械にやらせて、省力化できる
最終的にイノベーションを起こす組織の改革はこのループを作ることを目指す。
全てはつながる
勝ち続ける組織は、もう進めている
今まで通りの作り方ではVUCAの時代
リードタイムに圧倒的な差が出てしまう。
BizDepOpsの企業とはスピード感が違う。
最初はマーケティングが比率が高い。しかし、時系列とともに、開発、マーケティング溶け合うようにやっていく。
小さく繰り返すことで、手戻りを極限まで少なくする。
プロフェッショナル仕事の流儀「庵野秀明」
アニメ制作でアジャイル開発
「自分の頭の中で、答えを出してしまうと、限界は自分の中で作ってしまう」
「実際に撮影する、３Dモデルを作ってやってみる。行動して見ることで、新しい発見がある」
みたいなことを言っていた
僕もみましたが、この辺りの話は非常に面白かったので、覚えている。
こちらに詳細が。内容がアニメ映画の話とはおもえないくらいの開発プロジェクトマネージメントに関する濃い内容
今回の感想
アジャイル開発の具体的な進行方法と考え方を学んだ。
小さくやる、実際やる、そのフィードバックを繰り返すことが重要。
今まで開発だけの考え方かと思っていたが、運用さらにはビジネスの形までアジャイルでやっていくことで小回りが効き、時代に・それぞれの仕事にフィットしたDXが可能になっていくことを学んだ。
新しい考え方と、手法が多く、理解が進行形では理解が追いつかなかった。
note復習で今やっと頭が追いついた。
卒業制作では実際に実践していくことになるのだ！（やるのだ！）