Day7_DX人材育成講座 アジャイルな問題解決プロセス・BizDevOps DX人材とは
『Day6_アプリケーションの作成』は全然追いつかなかったので、もう少し手を動かしてから書きます／(^o^)＼
とうとうアジャイルについての話が出てきた。正直に話すとXのポストなどで見聞きしたときは「（ふーん、アジャコングみたいやな）」と思っていた。
頭カラっぽすぎてピロリ除菌薬のボノサップ見たときに「ボブサップみたいじゃん、ふーん」と言っていた整形外科医みたいになっていたのですが、とうとうアジャイルの勉強ができて嬉しいです。
つまりそれくらいアジャイルと言う言葉は一般的には浸透していない。このnoteは自分が職場のスタッフへSUNABACOの教えをアウトプットできるように書いています。
そのためにはDXとは、デザインとは、業務過程のイノベーションとは、患者さんが求める「価値」とは、そしてアジャイルとは……をきちんとわかる言葉でアウトプットできなければならない。
僕は心の中に橋本環奈を一人飼っている。妻が似ているというのもあるが、何かわかりやすく説明する時には、心の中の橋本環奈が理解して喜んでもらえるように言葉遣いを考えている（妻ではダメなのかという質問はダメだ）橋本環奈でダメな人はラクス・クラインとかがいいかもです。絶対に僕をディスらないが、分からない時は「(^ ^)？？」と小首をかしげてくれるのだ。よーしもうちょっと頑張って言語化してみるか！となる。仕事の環境をイマジネーションで補うのは結構オススメです。
１．アジャイルの手順
まずアジャイルとは『小さく作り、確かめながら無駄なく迅速に成果を出す』手法です。イメージとしてはアジャイルというものはフレームワークであり、心構えのようなものです。
かつてのモノづくりとは「計画を固めてから実行する」という手順でしたが、これではすべてが完成しないと、成果物を見ることも触ることも試すこともできませんでした。これは最初に立てた企画（仮説）が正しいことが前提になっています。
２．正解がない中で、betterを積み重ねていく
割と勘違いしてる人多いけど、システム開発において正解というものないんですよ。積み重ねられたbetterしかない。
— しのゆー𝕏酒クズエンジニア (@shinoyu) November 13, 2024
あらゆる手段の中で、そのケースにおいて一番相性がいいものを選んでるに過ぎないわけで。…
偶然にもこんなポストを発見してしまいました。betterとはおそらく、「いままでよりもbetter」「手元にある選択肢の中でbetter」なものを選択するの二つの意味があるのかなと思います。
未知なるモノづくりにおいては、「100点を目指す」「実用していない仮説を100%信用して進む」はマッチしない。外部環境がスピーディに変化する中では、小さくても製品たる機能を搭載したモノを作り、そこにマトリョーシカのように外側に機能をかぶせていき製品として大きくするという考え方が良い。
「みんなが分からないゴール」に対して、求められる機能として正しいものを正しく作っていこうという考え方です。
３．正しいものを正しくつくる
「正しいもの」＝必要性に対して正確に役割を果たす「つくるべきもの」
「正しくつくる」＝無駄なく正確に要素を満たすように設計する
正しいものを探索するフェイズと、正しくつくる（アジャイル開発）のフェイズに別れます。
【正しいもの（価値）を探索する】
・仮説の立案⇔検証を繰り返し「本当に正しいものなのか？」を探っていく
・その中で一定の評価を得ることが出来たら、「求める価値」に優先順位をつけていく
・求める価値の中で、最も優先度の高いものを実用最小限の製品＝MVPとして定義する
４．「正しくつくる」の方法論
アジャイル＝小さく作って、確かめながら進んでいく のイメージを掴むために具体的な方法論が必要です。
①変動性は受け入れ、活用すべきもの
かつて変動性（思っても見なかったこと）はリスクだった。しかし、アジャイルにおいては「思ってたのと違った！」とより取り入れていき、活用すべきものとしてとらえる。
②価値に主眼を置いたデリバリーに集中する
ひとつひとつがプラスに価値を生み出し、製品として成り立っている必要がある。デリバリー＝製品が使える形で手元に届く。関わる人たちにとって、前回よりより良い完成物をその都度届けること。
A.スプリント
アジャイルでは極めて短い時間で機能を作り上げ、リリースするを繰り返すためのその区切りの期間のこと。
とにかく製品としてリリース可能な状態を目指す。「◯◯はできる、でも分かりやすくするには説明書がいるね」ではダメだということ。説明書もちゃんとつける。それを目指すことで、作ったものが使えるものとしてユーザーに受け入れられる。
B.プロダクトバックログ
※ただのTo doとは異なる。
必要な機能の一覧なので、使う側視点の要素となっている。
「ユーザーは日々の勤怠を登録できる」を達成した状態=リリースできる状態。ここに書くべきは「勤怠登録機能を実装する」ではない。あくまで「使える」「業務が成り立つ」ことがマスト。
我々が普段やっている「あぁできたできた。でもこれ使ってもらうにはここ少し手直ししないとな」ではダメで、ここの項目にチェックがつくということはそのまま「はいどうぞ」とお渡しできること。
すべての実現すべきことに優先順位をつけて一個の表に並べる
C.見積もりとベロシティ
プランニングポーカー＝チームがタスクの「見積もり」を行うための手法。具体的には、各メンバーがタスクの難易度や作業量に対する意見を出し合い、合意を目指していく過程で使われる。ポイントを数値化して視覚的に比較しやすくすることで、より現実的な見積もりが得られる。
ストーリーポイント＝アジャイル開発でタスクの「作業量」や「複雑さ」を評価するための単位。これは「時間」ではなく、チームがタスクやストーリーの大きさや難易度、リスクなどを総合的に考慮し、相対的なスケールで見積もることを目的としています。だからこのポイントに単位は無い。
ベロシティ＝チームが1つのスプリント（通常は1～2週間）で完了できる作業量を数値化した指標。具体的には、完了したストーリーポイントの合計値として測定される。あくまでチームの中での作業効率や成果を評価するツールで他チームとの比較には使用しない。
D.デイリースクラム
初めての作業を初めてのメンバーに割り振っているので、それぞれできたことできなかったことなど所感を共有する。
E.スプリントレビュー
ここからは検査をする、確認をするというフェイズ。実際に触って使ってもらい、ここで得たレビューをプロダクトバックログに仕込んでいく。
F.スプリントレトロスペクティブ
スプリントレビューは「正しいものをつくれたか？」というフィードバック。
スプリントレトロスペクティブは「正しいものをつくる」というこのフェイズがちゃんと実行されたか
５．BizDevOpsの視点を持つ＝DX人材育成
開発と運用はほぼ利益相反になるので、どう折り合いをつけるか。新しいことをする人と、現行のシステムの保守・運用をする人は基本的に利益相反する。
情報と状況がサイロ化してしまう
＝組織内で情報が部門やチームごとに分断されてしまい、必要な情報が他の部門やチームに共有されない状態
開発側の頭の中には「（〇〇ができたら全部解決なんですわ！まだ作ってないけど😉💦）」みたいなのがたまっていく。これが情報のサイロ化を生む。
それらをまとめて行わずに、アジャイルにより「こうなったらいいな」を小さくでも作ってゆく、それに対してフィードバックも受ける。情報を共有して、一度に出す情報のサイズを下げていく＋運用側の希望を開発側も取り入れることができる。これにより開発と運用を同じ土俵に上げ、目線を一本化していく。コミュニケーションを活性化させより良いモノづくりへとつなげていく。
＝Development Operations（デブオプス）
ここにビジネス目線の人間（経営陣、マーケティング）が入る必要がある。
作るプロダクトは一つなので、それぞれがプロフェッショナル的な意見を出し合い、それぞれの視点がのっかってモノづくりがされていくことを目指す。
何がビジネス的価値に繋がるのか、会社の競争力に繋がり差別化を生むのかもアジャイル（素早く小さくつくる）に入れ込んでみよう。
つまり、「開発してみた」から→「商品として売れる形にした」と言う風に事業化していく。そうすると市場からフィードバックがやってくる。そしてその「使ってみて〇〇だった」というフィードバックは、開発にも運用にもビジネス的観点に対しても役に立つ。
①ビジネスニーズの把握
②業務の棚卸しと仕分け＋最もパフォーマンスが良い所に集中する
③内製化することで知識、データは積みあがり続ける
DX人材育成
上記の①〜③のサイクルはすばやく回さねばならない。そのためには内製化が必要であり、現場の人間が、自分たちの手で技術の進歩をキャッチアップし、自分たちで「こうなったらいいよね」を積み重ねていく。
それにより業務にイノベーションが生まれ、より人間が行うべき業務にコミットできるようになる。
何がいま価値なのかを未知なる中から見つけ出し、プロダクトをフィットさせていくスピード感を早めていかねば、勝ち続けられない。そのための自社内でのイノベーションであり、そのためのアジャイル。
未知なるものをつくるやり方は今までと変わってきている。
これから先は、マーケティング（リサーチ）が主だが、そのリサーチを詰めるのではなく、IT/システムと連携しだんだん「小さく作ってみようぜ」が入ってくる。「作ってみる→使ってみる」で、マーケティング＆リサーチとしていく。このデータを土台にして、技術的には、、ビジネス的には、、と視点を横断的にすすめていく。世間の中での価値が何なのかを見つけ出す時間がどんどん短くなっていく。
まとめ
BizDevOpsという考えがアジャイルの概念を包括していますね。より社会実装された形になっています。アジャイルを歯車としてビジネスの目線を加えることで、プロダクトは様相を変えて来るということですね。
「BizDevOps」の視点はとても大事だなと思いました。自分は理事長兼院長＝経営陣（Biz）＋マネージャー（Ops）の立場なので、開発（Dev）側のスタッフと上手く組んでプロダクトを生み出せるように、自分の手でDevを巻き込んでアジャイルを回していこうと思いました。
この記事が気に入ったらサポートをしてみませんか？