見出し画像

DX人材育成講座第7回目覚え書き〜正しいってなに？〜

しょうこ

さあ本日もはじまりました。
DX人材育成講座第7回目。

やはりアプリ開発技能のスキルを身につけるには、何度も試行錯誤するのが一番いいのでしょうか？

画面の操作に関してだけ言えば、そう、ですね......！
ただ、DBがあってデータの出し入れ、を分かっていれば、試行錯誤は一定量で済むかと思われます！全部の機能を覚える必要はない。全部使う必要はないので。カンパ先生も何年もGlideを使ってるけど使ってない部分も沢山ある。

Glideで作ったアプリのセキュリティはどの程度設定できるか

ログイン認証がついてるので、最低限のセキュリティは担保されていると思ってもらっていいです！
ただ、「Glideにデータを渡す」はやるので、あとはそこをどう考えるかですね。。
Glideをどれだけ信用するかになってくる。Glideに渡していいデータを考える。
カンパ先生は作業として個人情報に直結しないものを使う。顧客のデータベースをやるということは情報をいれて取り出すということをする。
グライドは作業記録や日報とか。入力して記録する系。

アプリコースを経てfutterflow、そして今回のGlide、それぞれ強みがあるだろうし、どれを使うべきか少し悩みます。恐らく手に馴染んで必要十分な機能を用意できたらどれでも良いのでしょうけど

そういうことです！DBを用意して、データの入れ出しを考える。入力しやすく表示しやすい形を選べば良い。

アプリを農業で作成する場合、気象データ取り込みや生育状況センサー作成設置や環境測定機器の連携などできるのでしょうか？

Glideの場合、月1万の課金をすればZapierとかと連携して可能になりますね！

アプリを作るにあたっては「必要な作業や工程ごとに」都度1つ1つアプリを作成して用意した方がいいのでしょうか？（その場合アプリの数が多くなりそうな気がして。。）

ユーザー体験の設計次第！！
普通はひとつにまとめるのがよいかとは思います。

講座を受けた翌日に年末調の記入の事務処理があったのでチャットgptを使って記入しました。参考資料を見ながら毎年、30分ぐらいかかる資料作成が簡単な受け答えをしながらですと。15分と業務の短縮に繋がりました。こうやって可処分時間を作成していくのですね。

素晴らしい！そういうことです！！

弊社はMS365のbusinessなので、ブラウザ版Copilotは使用できますが、office向けCopilotは契約していません。しかし、講義で紹介のあったようにAzureでも似たようなことが簡単に実装できるのであれば、もう自分達で作るのもありかと考えています。何人かで契約しトライしてみるしかないと思っていますが、subanacoさんでは、誰かが実際一通りのサービスを使って比較されていたりはされていますか？個人の希望で導入していますか？

比較したり触ったりはするけど、割と勝手にやっています。弊社の場合、
責任は経営陣に、権限は現場に。
責任と権限はセットで移譲。ナカムラからは「うんっていうのすらコストだから俺に言わせるな。」と言われています。

看護師が問診する内容をAIに任せる際、後から入ってきた新人さん達はこういうのを聞けば良いんだと分かる反面、自分で勉強する機会が減るからダメっていう上層部がいそうだなって思ってしまいました。

私がした質問だ！

機械にできることは機械に、人は人にしかできないことを。が大前提。
看護師が患者の問診をするのには紋切り型と反応を見ながらする質問の2種類があるはず。機械がするのは紋切り型の質問。
反応を見ながら何を聞くか、考えるということは増えていくはず。勉強する機会もむしろ増える。

小さくアプリ作って試すとのことですが。アプリを作るが先にくるのではなく、ユーザーインタビューをし、業務の棚卸し行い、そこから機械で代用できるかを考え必要ならアプリを作成するという考え方でいいですか？

もちろんそういうことです！

アンケートなどであればGoogle formなどのほうが作りやすいと感じた。自作のアプリでないとできない場合に応用したい

まさに！！

携帯からもWebからも情報を入力できて共通のデータベースをアップデートできるアプリが簡単に作れることに驚きました。今まで現場で手書きでメモして家に帰ってからExcelに情報を打ち直していたのが簡単に現場で入力できるのは素晴らしいです。一方で養蜂や農業の現場では両手に手袋をつけていたり、ドロドロに汚れていたりします。先日のChatGPTを利用した音声入力は現場でのメモ作成にとても相性がいいと思いました。この自作アプリとChatGPTの音声入力がコラボできれば最高なのですが、そのようなことは可能でしょうか？

無料でできるかは微妙ですが、技術的にはぜんぜんできえます。

glideは、現状あるデータをインポートすることはできるのでしょうか？（ユーザー登録など）
また、写真をたくさん登録することになった際、容量に限度はあるのでしょうか？

できます！容量はちょっと調べないとわかりませんが。。。

組織にアプリを入れる場合、アップデートが繰り返されることについていけない人が必ず出てくるので「もうそんな試行錯誤ばかり無理です」勢を、なんとか説得したいなと考えます。

アプリのアップデートがあるということはアプリは関わる人達にとって便利なはずなのに？またアップデートしてくれたんですね、ありがとうございますってなるはず。
それはなにかがおかしいということです。本日詳しく扱います！！

では本題！今日の講義は？

アジャイルなデザイン解決プロセス

今までと違う感じな画像出てきたので思わずスクショ。

小さくつくって進めていく。
どういう考え方？

朝起きられないので、毎回音が変わるような目覚まし時計を作ってくださいByカンパ先生

これは覚える必要なし

↑大抵はこんな風に考える
スタッフがつくってくれた！（優しい）
でも
スピーカーにつなげないといけない
新しい端末が増えても管理できない
スマホに内蔵できないと困る

張り切って使って1度も使われることなくその役目を終えた（え……）
今どこにあるんだろう（え……）

ユーザー体験の設計をする時に考えること
どうすれば良かったの？

普通のモノ作りは大概は全てが完成しないと触ることができない。
全部が出来上がった後にモノがやってくる。ということは？
使えないってなった時、全てがイチからやり直し。
我々（カンパカンパニー）がよくやっているやり方は
【最初に立てた企画が正しいこと】が前提になっている。これがウォーターフォール開発。
爆速で変化し続ける世界に対応することができない。作ってる途中に変わることなんてたくさんある。

機能ごとにサイクルを回せば変化に対応できる→これがアジャイルの考え方

スケートボードの図で言えば

モノはなんでもいいから、カンパ先生の耳元で毎日違う音が鳴ればいい
→それを実装するには？
とりあえず起きる時間にYouTubeでいい感じの音楽をセットして耳元で流せばいい
→それがダメなら基本起きないんだからダメってわかる

耳元で音が鳴ったら使ってもらえているという状況になるので価値提供になる。
機能ごとに作って提供しそれを細かく回していく。
「分からない」ということに合意した状態から正しいものをつくるという状態。
従来のモノ作りは「分かっている」ことが前提になっている（去年に引き続きなど）

誰も作ったことがないものを作るの？
前例に従いながら作るの？
それにもよる。

正しいという言葉は日本の正しさというよりも、的確に適切に精密な、
誰も正解を知らないから小さく作っていかないと効率が悪い。
どうやったら正確にお役に立てるかを模索していく。

正しいものを探すというフェーズと、正しく作るというフェーズに分けられる。正しいものを探すというのは今までのUXやデザインシンキングでやってきた。
検証、リサーチ、インタビューによって観察をして仮説の立案から解決策などを立てその検証して優先順位の高いものをアジャイル開発に向けていく。
検証と仮説立案がいったりきたりしている。
わかりやすい例は

↑これ

開発者ゆーいちさん

開発者のゆーいちさんは、弾ける楽器がなかった。ギターを弾きたくてもコードを覚えるのも押さえるのも大変。結果挫折に繋がる。
じゃあインスタントにコードが押せたらいいじゃないか。
上の写真はボタンを押さえて、弦を弾くとそのコードの音が鳴る（コード覚えなくていいいのすごい）
楽器が苦しい・大変な思いをするだけじゃなくて、簡単に楽しいって思ったってできたっていいじゃないか。
見た目は紙で作って知り合いのミュージシャンに見せて意見を聞いた。
その後木で作った。
紙から少しずつ進化（小さく作って進めていく）
本当に売れるの？特許の出願を出すにもお金がかかる。特許は人前に出されたことがないことが前提。
内容を伏せながら市場調査を進めていった。

楽器を演奏する？
演奏したいと思っているのにしない理由は？など
いくらだったら欲しい？

4万円をこえると一気に数が減った。3万円くらいなら買ってくれそうだ。
3万円で売れるように、製造工程を流通を逆算して作っていった。
自身で箱詰めしたり発送、直売のみを取り入れていった。

ユーザーとの距離を近くしていって情報を集めていった。
（使ってくれる人の意見が直接聞けるって大きいですよね）

約2年半くらいかけて製品化して、発売から1年間の売上が1億円を超えた。
どこまでお客さん（ユーザー）のことを設計できるかって、結局その人の人柄が大きく影響するんじゃないかなってカンパ先生の話を聞きながら思った。

では2時間目
アジャイルの方法にはいろんな手法がある。その中で今回は最も有名な
スクラム
今回の講義ではスクラムというアジャイル方法論を理解してもらうことを目的としてない。
一度聞いたからってできるわけじゃない。従来のウォーターフォール型が染み付いていれば染み付いているほどこの考えかたを取り入れていくのが難しい。
小さく作って確かめながら進んでいくことをわかることを目指そう。
アジャイルの具体的な方法論を始めるにあたり重要な考え方が2つ！！
①変動性を受け入れ、活用する
従来変動性というのはリスクとされてきた
後から変わること、思っても見なかったことはリスクであったがアジャイルではある種嬉しいもの。気づけて良かった。思っていたのと違ったというのを次からのアドバンテージにしていく。取り入れて活用していく。

②価値に主眼を置いたデリバリーに集中する
モノを作る、小さく作るというと

図の上をイメージするかもしれないけれど・・・・。
下側は
1回1回リリースとして製品として成り立っている。1回ごとにプラスの価値として成り立っていることが必要→これがアジャイルの前提

カンパ先生の毎日違う音が鳴る目覚まし時計に例えるなら（毎日違う音が鳴る目覚まし時計）
耳元で音楽が鳴る
LINEで起こす時間を設定したらその時間に起こす（時間セットが可能）
一時的に人力でもOK。
リリースはプラスであり且つ製品として成り立っている。

価値に主眼→毎回毎回受け取って嬉しい
デリバリー→製品が使える状態で手元に届く


従来のウォーターフォール型では形式が決まっているからその分野に詳しい長年従事している人に決定権や承認の権限があった。知識があり、経験があり判断が正しいとみなされる。上司・部下の関係性が必要。

アジャイルは誰も正解が分からない。
1年目の新人でも40年目の大ベテランでもやったことがないということは一緒。承認することはどちらにもできない。
ということは？

チームでの在り方も変わってくる。
役割

プロダクトオーナー：正しいものができるということに責任と権限を請け負う人。権限もセットなので開発者がこうしたいと言ってもプロダクトオーナーの意思決定が優先される。
スクラムマスター：正しく作ることに責任と権限を請け負う人。
チームがチームとして正しく駆動してアジャイルの方法論を適切に実行し進んでいくことのチーム運営に責任と権限を持つ人。
開発チーム：決められた通りにモノを作っていくことに責任と権限を請け負う人。

従来のモノ作りの分かりやすい例としてアデリアレトロというグラスがある。

上司からは古臭いんじゃない？今更？とOKが出なかった。
50代の上司は一度売れていた経験を持っていてもう古いという感覚。提案した社員は20代のその時代を知らない世代。
Instagramでどういうものが売れているか
販売しているショップへインタビュー
インフルエンサーにインタビュー
データを集めて、リアル店舗での販売も確約した。
作ったら売ってくれるという状態を確保した。
Instagramのアカウントを作って投稿していったら好評であった。
2024年で140万個を売っている。
ファクトを元にした提案で企画が通った。

To Doリストと大きく異なるポイントは
例）勤怠登録の機能を実装する：作り手側の視点
↑本来はこんな感じ

従業員は日々の勤怠を登録できる：ここにチェックがついたなら本当に使えるということ。
実装するという表現は、ユーザーにとって価値のあるデリバリーにならない。
開発の優先順位ではなく、関わる人たちにとってどれから作っていくかを考える。作りやすいところからではなく、何の機能から必要かという順番。
プロダクトバックログは、個人単位やチーム単位ではくプロジェクト単位・プロダクト単位。
嬉しい機能の優先順位？
MVP（Minimum Viable Product）
必要最小限の価値を提供できるプロダクトやサービス
実用最小限の製品は何か？
毎回音が変わる目覚まし時計なら
ユーザーは耳元で毎日違う音楽をきくことができる
ユーザーはアラームの鳴る時間を決めることができる
ユーザーはどんな音楽が鳴るかをランダムで登録できる
コアな価値を最初に順番に作る必要がある。最もコアな機能、価値は何か？

関わる人たちの望む価値を書き出していきそれら全ての一本軸の優先順位をつける

作り手側はどうやってこれら全てのいろんな人たちの困りごとを同時に早期に実現可能にするかが頭の使いどころ

プロダクトバックログでの考えかたをしていった時、未知なるものを作るいう前提だったときどのように見積もりをするか？
プログランミングの業界では人月（ニンゲツ）という考え方がある。
1人月なら1人で行うと1ヶ月かかる作業量のこと。
このタスク何時間かかるねという見積もりは土台無理な話という前提に立つ（だってやったことないから）じゃあどうするの？
これは3時間？10時間？随時やるのは骨の折れる作業。
プランニングポーカーという考え方がある（アジャイルのプロセスの1つ）

この作業はどのくらい重たいと思いますか？みんなでせーので番号を出す。
単位はなし。
5時間でも5人月でもない。
5。
それぞれのセクションを相対値を出していく。相対値で出すと、2週間で何ポイント消費したのかという実測値を得られる。
1個前では20ポイント分、では次も20ポイント分消費できるであろう。時間が進めば進ほど不確実性が減少していく。
全員の合意形成がなされてないとみんなの方向性がバラバラになる。
エレベーターピッチ

プロジェクトの全体像を一息で言える。上長にエレベーターの中でスッと言える。
みんなで前提条件を共有していく。
スティーブ・ジョブズとエレベーターで一緒になった時、自分のこと30秒で覚えてもらうなら何を言うかっていうトレーニングに似てるなって思った：エレベーターピッチ

不確実性を孕むものを2週間で作るので、不確実性を全員で共有してメンバーごとのガタ付きをならしたりしていく。

実際使ってみてどう？関係者に集まってもらいこんなものができたという発表会をする。
関わる人達は忙しいから来てくれないという質問がよくくるがおかしな話である。
関わる人たちはそのデモに参加したら業務が楽になって可処分時間が増えるの。なら忙しくてもくるはず。
参加してくれないのなら支障がある。ユーザーの求めているもの（欲しいもの）と作ったモノの乖離がある。

2週間自体がより良いものになるものに。新規プロジェクトは初見のメンバーで構成されることが多い。

KPT
現在の業務を振り返り、ブラッシュアップするためのフレームワーク
Keep(続けること・良いこと)
Problem(改善するべき問題点・不満点)
Try(試すこと・工夫したいこと)
の3つの要素を洗い出し、仕事やプロジェクトの改善につながる具体的な施策・アクションを導き出す。

観察などから一番必要なことを客観的に洗い出す
プロダクトバックログとして関わる人全員にとって優先度の高いモノを並べていく

その中から消費速度を見ながら2週間でどれとどれとどれがやれるかを上から順番に何個かとっていく

2週間でやるべきモノをスプリントバックログ、この計画をスプリントランニングという。
2週間のこと→スプリント
その2週間の中で1日に1回こういうふうなことがあったと報告しあって全体を慣らしていく会を15分程度行う→デイリースクラム
2週間の成果物は出荷判断可能なプロダクトインクリメントすなわち実際に使える状態で価値あるモノでなければならない。

関わる人の前に出して見てもらいどういう反応かみて使ってどうかを確認する機会を持つ：スプリントレビュー

2週間単位で自分達がやっていく作業、プロジェクト運営、チーム運営自体も不確実なものなので振り返りの機会をもつ：スプリントレトロスペクティブ

さあ3時間目
今までは作り手側の方法論
プロダクトはつくって終わりではない
つくったところからスタート
開発×運用で成り立っている。
開発：新しい機能をつけることがゴール
運用：問題なく動き続けることがゴール
ほとんどの場合は利益相反が起きる。
例）ゲームの運営
開発：新しいキャラやイベントを実装する
運用：バグもサポートの手間も増える
開発と運用の利益が相反するのをどうするのか？
そもそも同じ組織で同じものつくっているのに目指すものが相反するの？→見えているものが違うから。

情報と状況をサイロ化させないことで同じ方向を向けよう！：これができたら苦労なんてしないよね。

スマホアプリ作る側：スマホアプリを作るってなったら（ソフトウェア開発の例）
設計、コーディング→ビルド、テスト→リリース→デプロイ→運用監視

スマホアプリを書く側：ビルドからデプロイをCI/CDで自動化
設計とコーディングをノーコードで自動化
とにかくめんどくさい。
次作る時にまとめてやろう、次の時の時でいいやってなっていきやすい
開発の人の頭の中にだけある情報や考えがどんどん増えていく

運用している人たちは実際使われているアプリからの情報
作りたい人の中には〇〇が実装できたらまとめて解決される→伝わらない

これに対して
ソフトウェアではコードを書いてできたっていうボタンをクリックしたら自動的にアプリになってテスト工程も自動化されている。
作ったあとの後工程は自動化されている。
作ったモノをクリックすれば反映される。ウェブ系だと1日に100個や200個更新される。開発の人が頭に思い描いたものは即座に実現される。それは運用の人もユーザーの人も見ているのでオペレーション側からここが使いにくいなどの声は広いあげてすぐに改善できる。一度にまとめて処理する数を少なくしていけば少なくしていくほど部署間の検討違いや見ている場所のすれ違いは減少していく。
バッチサイズの縮小という言い方をする。
どのくらいユーザーに届くスピードが早くなるか、運用は運営の目線に近くなるかが変わってくる。
院長の頭の中にしかないもの
アプリを作る→全員が使ってみる
こういうことがやりたいんだという共通認識が生まれる。
立場が違うことは変えられない事実。

developとoperationの掛け合わせ。
プロダクトにはビジネス（UX、マーケティング）的観点も必要。
ビジネス、開発、運用のサイロ化をなくそう。つくるプロダクトは1つ。

DXの卒業制作は炎上している案件をその場でチームを組んで、2週間後に成果を出さなくちゃいけない案件Byなかまこさん👀　👀　👀

技術がうまれビジネスにつながるまで。
研究開発でできた新しいものは事業化して市場に投入したら売れたのが高度経済成長期。
白黒のテレビがカラーになった。
分厚いテレビから薄いテレビに変化。ここからは雲行きが怪しくなりもうあまり売れていない（3Dテレビ買った人少ない）

小さくつくって回していく。
研究開発が技術的に可能（AIやノーコードの参入）になった。それを実際に事業としてこう出来そうだなというのを考えつつカタチにして使ってみてもらいそれを機能単位で回してもらうということをする。

使ってみるとユーザーから反応がある。
インスタコードを実際プロトタイプとして使ってみてもらう。
ビジネス観点から思うことがある（いろんな立場からの声をピックアップする）

アジャイルなものづくりをしながらいろんな観点をみれて意見を集め小さくつくりループをまわす。
小さくコストをかけて大きな価値をうみだす。

従来ソフトウェア開発は数年に1度ベンダーさんを呼んでなどのいろんなループをしていく。
なかなかイノベーションというか関わる人たちにとっていい状態をつくるのが難しい。イノベーションに貢献するという関わり方をしないので人材が育たない。

できるようになることで、関わる周りの人達を巻き込みこのループにのせるのが役目。
自分の得意分野以外の立場の観点もわかる必要がある。
ループがまわっていくことが道の先にある。

これが出来る会社が勝てる会社

デジタルかどうかに関わらずどの業界でも必要とされること。

DX人材育成講座12期を受けている同期の方達の記事です。

𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄 𓐄𓐄 𓐄 𓐄 𓐄 𓐄 𓐄
新しいことをやろうとするといつもそこには反対は否定の眼差しも意見も集まる。
光が眩しくて羨ましいことの裏返しだろうか。
でもその反対って興味を持っているからこそ。だからそこからどうやってこっち側に巻き込んでいくか。
きっとそのユーザー設計ができたら新しいことへの挑戦も怖く無くなるかもしれない。かな？

あなたの大切な時間を使って読んでいただけて本当に嬉しいです。
ありがとうございます。
もしこの記事が好き！いいな！そう思っていただけたら是非ハートをクリックしていってください。フォローもコメントも大歓迎です。






いいなと思ったら応援しよう！