農×システム開発のテーマ
農のかけ算ラジオ、道照らすの山浦です。このラジオでは、農業と様々なテーマ、
漁業史等を組み合わせて、新しい視点やビジネスアイデアを垂れ流していく番組です。
はい、ということで、今回のテーマは、農×システム開発という、なかなか聞き馴染みのない言葉に挑戦していきます。
今回もゲストをお呼びしております。ゲストに株式会社コーリフトを代表取締役、
木下寛太さんをお呼びしております。よろしくお願いします。よろしくお願いします。
はい、何を書くそうですね。木下さんとの繋がりは、いつも寛太さんと呼んでるんで、寛太さんでいきますね。
寛太さんとの繋がりは、古典ラジオを通した古典クルーですね。
はい、そして僕の場合は前職の時からの繋がりで、その時にカンボジアツアーに誘ったら、まんまと来てくれたという。
まんまと、まんまと行きました。
はい、めちゃくちゃ一緒に行けて楽しかったなと。
まあその時他のね、古典クルーの皆さんも来ていただいてですね、かなり深い話とか色々できたなと思っております。
まあそうは言っても、木下寛太さんのですね、自己紹介をちょっといただきたいなと思いますけども、よろしいですか。
はい、株式会社コリフト代表の木下寛太と言います。寛太と呼んでください。
コリフトという会社は、新しいビジネスとかインターネットサービスの立ち上げに関わるコンサルティングとか、あとシステム開発、
あと新しいビジネスとかサービスを立ち上げるので、その立ち上げたビジネスとかサービスを成長させていくためのマーケティングのご支援みたいなことをやっている会社です。
難しいですね、他には。
これマーケティングとかはあれですか、もうどんなもので持っている感じなんですか。
基本的に我々がご支援させていただいて立ち上げたビジネスとか、インターネットのサービスっていうのが、
例えば楽天とかヤフーとか、フェイスブックとかみたいなものを使っていらっしゃる方多いんじゃないかなと思うんですけども、
そういったものをイメージしていただくと良いかなと思うんですけど、ただそこに置いてあるだけでは誰も使ってくれたいので、
それをどういうふうに宣伝していったりとか、使ってくれている人たちの使われ方みたいなものを見ながら改善をしていくみたいなことをご支援していく。
いわゆるウェブマーケティングみたいな感じですかね。
そうですね。
なるほど。ありがとうございます。なかなか農家、僕もシステム開発とか、なかなか今となってハイテクでも何でもないかもしれないんですけども、
そういったものっていうのは聞きなじみないので、ちょっと勉強がてらお話しさせていただければなと思うんですけども、
今回のテーマはシステム開発ということで、そもそもシステム開発とはみたいなところっていう、別に歴史じゃなくてもいいんですけども、
どういったことをすることが、なぜシステム開発が必要なのかみたいなところをご教示いただけますか。
そうですね。まずシステム開発とはっていうのを一言で言うと、いろんな人がいろんな言い方をしているかなと思うんですけども、
システム開発の定義とは
あくまで自分の定義ということで言うと、コンピューターとかインターネットっていう技術を使って課題解決をするための仕組みを作ることというふうに言えるんじゃないかなというふうに思っています。
ちょっと抽象的すぎるので、またもう少し具体的にっていうところは、システム開発で何やってるのかの流れをお話ししていくと分かりやすいんじゃないかなというふうに思っています。
ありがとうございます。
システム開発って言うと山尾さんの中、どんなイメージあります?
いやー、だからSEが何の略かも正直よく分かってないですけど、システムエンジニアであってるんですかね。
そうですね。
なんで、例えば、なんだろうな、それこそ楽天市場とかAmazonとかの仕組みを作るみたいなところとか、あとアプリ。
単純なところでいくと、私のような素人からしたらホームページで、いわゆる黒い画面に謎の用語、言語を書いていくみたいな。
そういうところがシステム開発する人、SEみたいなイメージだと思います。
ありがとうございます。そうですよね。映画とかでハッカーとか出てきて、黒い画面でカタカタカタカタってやってるみたいなイメージですよね。
もうあんなんがみんな全員できるみたいなイメージですよね。
そういうイメージですよね。多分、僕の主観なんで違う人もしかしたらいるかもしれないんですけど、
こういうプログラムを書いているみたいな、黒い画面でカタカタしてるみたいなのは、システム開発の全体の工程の中で多分1割もないかなぐらいで。
そうなんですか。いわゆるプログラミングとイコールではないってこと?
イコールではなくて、むしろ1割ぐらいじゃないかなと思います。全体の工程の中では。
残り9割何やってんの?っていうところから今日お話をさせていただくと、イメージが湧きやすいんじゃないかなというふうに思っています。
すみません。本当に中学生、高校生の分かるレベルでよろしくお願いします。
はい。ちょっと難しくなってきたらどんどん止めてください。
はい。
まず大体大きく4つのステップに分けて今日お話ししようかなと思ってるんですけども、
この最初のステップがそもそも何を作るのかを決めるっていうことなんですけど、これを要件定義っていうふうに言います。何が欲しいか決めましょう。
そうですね。目的が必要ですもんね。
はい。例えば農業で例えてみると、おいしい野菜作りたいみたいな人が来て、山浦さん教えてくださいって言われても困っちゃうじゃないですか。
そうですね。えーと、えーとってなりますよね。
えーとってなりますよね。おいしい野菜を。でもシステムに詳しくない人がシステム開発をしたいときって割とそのぐらいの状態で、
システムを作りたいですみたいな形でご依頼いただくことっていうのが多いかなと思っていて、
僕から農業っていうのを見ても全くやっぱりわからないので、おいしい野菜作りたいですぐらいしか言えないみたいな状況っていうのはすごくよくあります。
じゃあそれってどういうことなんですかっていうのを紐解いていくみたいな作業っていうのがやっぱり一番最初にきて。
具体的にはそのシステムを使って、誰のどんな課題を解決したいんでしたっけっていうことをまず理解をして、
その課題を解決するためにはどんな体験を作る必要があるのか、例えばどんな画面が必要なのかとか、どんな処理をしないといけないのかとか、
そういう課題を解決するためにどんなシステムが必要なのかっていうことを結構細かく定義していくっていうのが最初のステップになります。
そのステップっていうのはインタビューとかそういうところから始まるっていうかね。
そうですね。まず依頼をしてきた人だったりとか、あとシステム開発の中でも作りたいよって言っている企業があって、
その企業の人たちのために作るっていうタイプと、あとは例えば楽天市場とかイメージしていただくといいかなと思うんですけども、
実際に使ってもらう人で、実際のエンドユーザーで何万人何十万人っていうみたいな想定だと、
実際に使う人にどんなの欲しいですかって聞くことはできないんですよね。
そういったタイプのもので、大きくその要件の決め方みたいなものは結構アプローチは違うんですけども、
どちらにせよ誰のどんな課題を対決したって、それはどういうシステムによって対決できるのかっていうことを最初に定義していくっていうことが必要になっています。
なるほど、はい。
で、これが大体全体の4分の1ぐらい占めてるかなっていうぐらい。
まあでもそうですね。骨格がないと、骨格というか目的と、そうですね、それが決まらないと細部まで何も、
要件定義と設計の重要性
そうですね。
グランディングも何もできないですよね。
はい。
だからおいしい野菜作りたいっすって来た人と話をして、つまり甘いトマトが作りたいんだねぐらいまでは、
はいはい。
まずは決めましょうっていうぐらいのイメージが。
誰に届けたいとか、品目ぐらい決めてきてくれよぐらいの。
そうですね。
はいはい。
なんで作りたいんだっけみたいなこととか。
はいはい。
なるほど。
はいはいはい。
はい。
なるほど。
まあでもおっしゃる通り、そうですよね。
農家も漠然と農業してるっていう、一般的なイメージはどうかわかんないんですけども、やっぱり親元から引き継いで、
漠然とやってる方も少なからずおられる雰囲気はあってるですね。
そういった中で、しっかり自分の地に足をつけて、
僕はこういう人たちのためにこういう野菜を作るんだとか、金が欲しいからお金が儲かるために、
じゃあこの品目を作ってこういう売り方をするんだとか、
社会貢献したいから環境に優しい農業をするんだとか、
いろんなやり方があるけども、なかなかそこにたどり着けてない人も、
そこまで考えが至ってない人もなかなか多いんじゃないかなっていう中で、
考え方としてはめちゃくちゃ参考になるかもしれない。
ありがとうございます。
どんな課題っていうところで、もちろん社会貢献でもいいですし、儲けたいでもいいと思うんですけど、
例えば自分で運営してるレストランに卸すためだでもいいと思うんですけど、
結局何のために作るのかによって何を作るべきかって全然違いますよねっていうところの
スタート地点がすごく重要かなというふうには考えています。
そうですね。なるほど。これが4分の1。
4分の1ぐらいですね。
次が設計って言われるフェーズなんですけども、
具体的にそれどうやって作りますかっていうのを決めていきます。
例えば甘いトマト作りたいって言っても、具体的にどんな品種なんでしたっけとか、
土どうするんでしたっけとか、
施設なのかとか。
そもそもどこで作るんでしたっけとか。
めちゃくちゃ農業に合わせて話してくれるじゃないですか。ありがとうございます。
そういうのをちゃんと決めないと作れないですよね。
とりあえず甘いトマト作るって決めたんで、あと種参るときはいいですみたいな話すことにならないじゃないですか。
とりあえずそこらのホームセンターで適当なトマトを何でもいいから植えとこうじゃないですかね。
家庭作業ならそれでいいと思うんですけど、お仕事としてやるにはそれじゃいけないですよね。
っていうのがやっぱシステムも一緒で、システムで言うと分かりやすいところで言うと、
どんな画面、ユーザーインターフェースって言ったりするんですけど、どんな画面にするのか。
ユーザーがこのボタンを押したときに何が起きるのかっていうのをちゃんと決めましょうか。
裏側の方に行っていくと、そのときに入力されたデータっていうのはどういうふうに保存するのかとか。
システムの種類とOSの違い
あとそういう処理をするためのコンピューターが、サーバーって言われるコンピューターが裏側にあるんですけど、
それどんな種類のものを使うのかとか。
そこにも種類があるんですね。
はい、いろんな種類が実はあって、どんな種類を使うのかとか。
あとOSって言われる、例えばスマホでもiOSとAndroidみたいなOSの違いみたいなのがあるじゃないですか。
あれのサーバー版みたいなのが結構あるんです。
そういう種類だったりとか、いろいろと決めることがたくさんあるので、
それを目的に合わせて決めていくことが大事。
ここでやっぱり誰のどんな課題よっていうところが重要なのが、
作り方っていくらでもあって、でも完璧に作るみたいな、
完璧というのもあんまりなくって、結局甘いトマトって一口に言っても何に使うのかによって意味合い違ってくるじゃないですか。
おっしゃる通りです。
システムも一つの、例えば顧客管理システムが作りたいですみたいなことを言っても、
何の目的でどういうふうに使いたいのかによってあるべき姿が全然伝わってくるので、
そうすると設計も全然変わってくるっていうところがポイントになるかなというふうに思います。
これってあれですか、やっぱり頼む人によって、それがSEなのか会社なのか単位は分からないんですけども、
やっぱり同じインタビュー同じ人が頼んでもやっぱりゴールは絶対というかほぼずれてくるのは間違いないですか。
結構違いますね。誰に頼むかでどんな設計になるかが結構違っていて、
本当はシステムを使いたい人がどんな課題を抱えていて、
それをどういうふうに対決していけるのかっていうふうに考えると、
そんなにバラつかなかったりするかなと個人的には思うんですけど、
やっぱり作り手の得意なものとか、作り手から見たときに儲かるやり方とか。
なるほど、コースを増やしたりとか極端な話ですけど。
逆に作り手が慣れているものの方が早く安く作れるとか。
なるほど。
設計の重要性と作り手の影響
必ずしも使い手のための目的に最適化されたものっていうだけではなくて、
作り手側の事情が入ってきたりするので、
誰に頼むかで何ができるか触るっていう面もある。
そこのレベル、SEとしてもしくはインタビューから始まる、
引き出す能力みたいなのもあるじゃないですか、絶対。
はい。
そこも全体を踏まえて含めて、やっぱりレイヤーがあるというかレベルが様々ある。
様々ありますね。
でもそれがイコール値段に反映されているかどうかっていうのは、
素人には多分全く分からない。
全く分からないと思います。
そうですね。
これが正しいんだって言われたら多分そうですよね。
そうですね、そっかってなりますよ。
でもこういうことを言ってくれるファンタさんにお願いすると、
多分僕はそれがほぼ正解なんだろうなと思って、
信頼はしちゃいそうですよね。
結局信頼関係でもありますよね。
そうですね。
あと、私の問題を解決してくれようとしているか、
みたいな観点に聞くのがいいんじゃないかなとは思います。
なるほど。
作り手の事情はそうかもしれないんだけど、
それで私の今解決したい課題は解決できるんですかっていうことに
ちゃんと答えられるかどうかっていうのは、
作り手側のプロフェッショナリズムというか。
そうですね。
正直に言えるかどうかもありますよね、そこをね。
いや、できますよ、大丈夫ですってさらっと言うのか、
いやー、僕ができるのはここの辺までですよみたいなことを
ちゃんと正直に言ってくれる人だったらいいですけどね。
そうですね。
なるほど。
見極めるポイントかなと思いますね。
そこもあるんですね。
ありがとうございます。
すいません、チャチャ入れて。
いい、いい。
プログラミングの工程とエラーハンドリング
今までのところがまた設計のところで大体4分の1ぐらいかなっていうところで、
要件定義と設計で大体システム開発の工程の半分ぐらい。
半分ぐらいってことですね。
そこまで締めていて、そこからいよいよ開発、
プログラムを書き始めるという工程になっていきます。
なるほど、はい。
で、このプログラムを書くっていう工程に入ると
黒い画面でカタカタしてるのかって言うと実はそうでもなくて。
まだなんですか?
工程としては確かに黒い画面でカタカタするフェーズなんですけど、
実際は多分考えてる時間が半分ぐらいで。
あー、そうか。
書いてる時間が残りの半分って感じかなと。
あえてまた農業な感じでいくとやっぱ段取りとか。
そうですね。
リンクみたいな人でとかをいろいろちょっと考えて、
こうすればこうなるみたいなのを、
まあ設計は設計になるかもしれないですけど、
考える時間なんですね。
はい。
ちょっと一個今日、プログラミング思考の体験みたいなので、
例を用意してみたんですけど。
大丈夫ですか?それラジオでいけますか?
多分いけると思うので、いけてなかったらカットしてください。
はい、わかりました。
例えば、何か数字を僕が言うんで、
この数字が3の倍数か3がつく数字だったら、
アホになってくださいっていうプログラムを作ろうとする。
どっかで聞いたことあるよね。
作ろうという風に考えてみたときに、
じゃあ何か数字が与えられて、
アホになるかどうかっていうのを判定するプログラム、
ちょっと考えてみましょう。
はい。
で、一番無直なやり方は、
じゃあ3の倍数と3がつく数字を全部裏列して、
その数字に当てはまったらアホになりますっていうのが
一番無直なやり方だと思うんですけど、
そうすると、3、6、9、12、13、15、18、
どこまでやるのでやりますよね。
そうですね。無限ですからね。
無限にあるのでどこまでやるのってなるので、
もう少し賢い方法ありそうだなという風に考えます。
はい。
じゃあまず3の倍数っていうのと3がつく数字っていうのを
別々に考えてみようという風に考えてみます。
はい。
3の倍数かどうかを判定するためにはどうしたらいいかって
山本さんアイデアあります?
え?僕数字弱いんですよ。
3の何乗みたいな。え?何乗じゃないな。
どうしたらいいんだろう。ごめんなさい。
本当僕数字弱いんですよ。
例えば3の倍数っていうことは3で割り切れるはずです。
3で割ったら割り切れるはずです。
そうすると3で割った余りが0。
はい。
考えるとその数字は3の倍数って必ず言えます。
なるほど。なんか英語みたい。
結構そうですね。ロジカルシンキーみたいな感じですね。
そっち側で考えればいいんだみたいな。
3がつくかどうかっていうのは
これはさっきみたいに何か割り算とかじゃできなそうだなと
はい。そうですね。
例えば123っていう数字が与えられたら
123っていう数字の塊じゃなくて
1、2、3っていう文字が羅列してるんだなっていう風に
はい。
その中に3が含まれるかどうかっていうのを
判定したらよさそうだなと。
はい。そうですね。
そうすると3の倍数か3のつく数字っていうのは
さっきの3で割って余りが0。
もしくはその数字を文字として頭から見ていったときに
3があるかないかっていうので判断したらよさそうだなと。
そうですね。2つを組み合わせて。
っていう考える時間っていうのが
実際にプログラムを書く時間と同じぐらいの時間を考えてるっていうイメージです。
なるほど。それがいくつもいくつもあるってことですね。
はい。
これだけだと結構シンプルなんですけども
プログラミングで、特にシステム開発のためのプログラミングで考えないといけないのは
この正常系の処理っていったりするんですけど
うまくいった場合の処理のことだけ考えるっていうのは実は不十分で
例えば今数字を与えられたらっていう前提条件があったと思うんですけど
システムを使う人って結構それ無視してきて
例えばABCみたいなのが入力で与えられちゃいますみたいなことを
想定をしておく必要があったりするんですね。
なるほど。
そういう時にどういう風なエラーを出力しますかみたいなことまで
実はそのプログラミングをしっかりしないと
拒否せぬ異常収容の仕方をして
システム全体にダメージを与えるみたいなことが起きたりするので
なるほど。はい。
それの異常系っていったりするんですけど
正常と異常ですね。
はい。
異常系の処理みたいなものが
実際は全体のプログラムでやりたいことの
3分とか4分の3ぐらい
異常系のエラーハンドリングって言われるようなものが出たりするので
ある意味リスク管理じゃないけど
そうですね。
はい。
そんなに比率多いんですね。
比率というか
半分以上はエラーハンドリングしてると思います。プログラミングの。
はい。
という感じでたくさん考えることが
実はちゃんと設計をしていても
プログラム各段階で考えることがたくさんあるので
はい。
そういうのを考えて書いて
実際に動かしてみると
だいたい何か間違っててエラーで動かないので
はい。
それ間違ってるっていうのは
そのプログラミングが間違ってるのか
その前の段階の考え方が間違ってるのか
どちらのパターンも
どちらのパターンもあります。
へー。はい。
で、それでシステム、そのプログラム動かしたら
怒られるので
エラーが出て怒られるので
ごめんなさいって言いながら修正して
っていうのを
そのエラーのことをバグって
虫ですね、バグって言ったりするんですけど
バグを取る、虫取りのことをデバッグって言うんですけど
はい。
デバッグをしてみたいなことを
やっているのがこのプログラミングの工程で
はい。はい。
なのでこのプログラミングの工程自体も
全体の4分の1ぐらいだと思うんですけど
うん。
その中でも本当にプログラム書いてる時間半分もないから
はい。はい。はい。
10分の1とか言ってましたもんね。
はい。
で、書いたプログラムっていうのを
今度は最後テストするっていう工程が
またその4分の1ぐらいあって
ああ、まあそうか。テストが大変そうですね。
テストが大変で
今のさっきの3の倍数と3の付く数字ぐらいだと
はい。
結構シンプルなんでそんなに大変そうじゃないと思うんですけども
はい。
そういうこう、まあ部品
うん。
こういう断片的なプログラム、部品みたいなものは
何百とか何千とか本当大きいシステムとか
満単位でこう集まって
はい。
一つのシステムできるので
うん。
それのいろんなパターンを決めるじゃないですか
そうですね。はい。
はい。そのいろんなパターンをできるだけ網羅するような
まあテストシナリオというかテストケースというのを作って
はい。
それぞれもう実際に動かしてみて
はい。
ちゃんと動くか
うん。
ちゃんと意図したようなエラーが出ているかみたいなことも
はいはい。
全部確認して
で、だいたい何か問題があるので
この問題が起きたらそれを対処してまた再テストして
みたいなことを
はい。
やるっていう工程がまた全体のやっぱり4分の1ぐらい
締めていって
はい。
で、車でいうと衝突試験みたいなものとか耐久試験みたいなもの
まあシステム
ああ、そういうのもあるんですね。
やっぱりやって
例えば脆弱性試験って言って
うん。
ハッカーが攻めてこようとしても大丈夫になっているかとか
はいはいはい。
あとたくさんアクセスが来ても大丈夫かみたいな負荷試験っていうのが
はい。
はい。
こんな感じで
なんかちゃんと意図した通りに動くかどうかじゃなくて
いろんなイレギュラーケースでも大丈夫みたいなことを確認することを
はい。
やっているのがテストっていうフェーズになる。
うん。
テストそのテストが終わればOKみたいな感じですかね。
OKで実際に公開して
はい。
運用って言って
じゃあ実際に使われるっていうフェーズに入ってくるみたいな感じですね。
うんうん。
これまあ今までこう流れを全体的に最初からまあ聞き取りからテストまで
はい。
これっていうのは
会社、まあコリフトさん会社なんで神田さんのところは何ですか。
何人かでもう役割分担なんですか。
それを基本的にやっぱり一人で全部はできないのでチームでやっていきますと。
はい。
ただチームの中で今の工程ごとに人が変わるみたいな
そうですね。
役割分担の仕方をする時もあれば
あるのはあるんですか。
はい。
チーム、一つのチームで全部をやってあまりそこの工程で役割分担を受けずに
一つのシステムを一つのチームが全部の工程担当しますみたいなパターンもあったりします。
なんか今の前者の感じだとやっぱりこう細かいところがたくさんある中で
こう伝言ゲームになるとなんかバグが起きそうな
おっしゃる通りです。
イメージが。
はい。
なんですよね。
なるほど。
でも前者もあるってことですね。
前者もあります。
そこはでもプロ同士だから成り立つのかな。
成り立つといいんですけどね。
成り立たない場合も多々あるけど。
成り立たない場合も多々ありますね。
内容がややこしいんで全部一人というか一人のプロデューサーみたいな人がいて
全体を全部見ていくみたいなリーダー的な人は
チームの中でもその中心的な人っていうのは絶対必要だなと思って。
そうですね。
次にちょっとお話したいなって思っているのが
ウォーターホールとアジャイルっていうシステム開発の流れの中でも
大きく二つの流派みたいなのがあったりするんですけど
それの話と今言っていた役割分担の話は結構密接に関わってはいるんで
そうなんですね。よかった言って。
全く聞いたことないですけどね。ウォーターホール、アジャイル。
滝ですかみたいな。
滝ですね。まさに滝ですね。
なるほど。
なのでちょっとこの流れでそのお話もしていけたらなと思うんですけど
お願いします。
システム開発に詳しい人に聞かれるとちょっと怒られるかもしれないぐらい
ちょっと雑に説明するんですけども。
雑にいきましょう。
ざっくり今の要件定義、設計、実際開発、そしてテストする
この流れは大体みんな一緒なんですけども
中でも大きくウォーターホールとアジャイルっていう2つの流派があるっていう風に
整理をしてみます。
ウォーターホールの流れ
ウォーターホールっていうのは何かっていうと
水が上から下に落ちる、そのままウォーターホールするっていう
そのままの意味なんですけど
これはこの要件定義、設計、開発、テストっていうのを
水が上から下に落ちるように順繰りにやって
一番下まで行ったらおしまいですよっていうような考え方。
水は上から下に落ちるので逆はありません。
要件定義して設計して要件定義に戻るみたいなことはなくて
水が下に落ちるように前だけ進みますよっていう考え方が
ウォーターホールっていう考え方になります。
それに対してアジャイルっていうのは
基本やることは一緒で要件を決めて設計して開発して
テストをするんですけども
これを何回も反復して繰り返すっていうのが
アジャイルの特徴になります。
なるほど、はい。
ウォーターホールの場合は大体
短くても半年、大体多分1年ぐらいかけて
要件定義からテスト、終了まで時間をかけるパターンが多い
システム開発やっぱそれぐらいかかるんですね。
そうですね。
アジャイルの場合は大体その要件定義からテストまでを
2週間サイクルとかでやります。
はい、だいぶ。
だいぶですよね。
1年と2週間みたいな差があります。
じゃあアジャイルじゃないですか。
ただもちろんアジャイルで2週間で作れる量っていうのは
すごく少なくなるので
小さく作ってどんどん繰り返してそれを
だんだん大きくしていくみたいなのがアジャイルのやり方。
ああ、そうか。はい、わかりました。
ウォーターホールの場合は全部、全体を最初にきっちり定義して
設計して作っていくっていう形であるので
大きなものを一度に作るみたいなのがウォーターホールの考えなので
小さく作って徐々に増築、改築していくみたいなのが
アジャイルの考え方、イメージ。
なるほど。なんかアジャイルは細かく作って
いっぱい組み合わせていくみたいなイメージ?
そういうよりは最初に動くものを作って
それをだんだんだんだん改善していくみたいなイメージ。
ああ、なるほど。なるほど、なるほど。
例えばこれどういうふうに使い分けるかっていうと
どっちが正しいというか使い分けの問題なんですけど
例えばウォーターホールの場合は大きなシステム
大企業の会計システムを作りますとか
あと顧客管理の大きな会社の顧客管理システムを作ります
みたいなときには最初に正解を決めます。
この課題はこういうふうに解決
こういう課題はこういうシステムで解決しますよね
っていうことを最初にがっつり決めて
一気に作り込みますっていうのが
このウォーターホールで向いていることなんですけど
例えば新しいSNSを作りたいみたいなことがあったときに
XでもFacebookでもInstagramでもTikTokでもない
何か新しいものを作りたいんだって思っても
それがどんな姿をしていて
本当にたくさんの人に使ってもらえるのかなんて
誰にもわからないですよ
ただこんなものがあるといいんじゃないか
みたいな仮説は大体ありますよ
そうですね。作る上では
作るからには特徴みたいなのが
それに基づいて1年とかかけてシステムを作って
3億円もかけて作っても
全然使われないっていう可能性はそこそこ高いです
そういうときにはやっぱり短い期間で
少ない機能で
今の人から見るとしょぼいなって思われるんだけど
それでもこういうものがあればいいっていうところの
特徴にすごく尖らしたものを一回作って
世に出してみて
実際に使われてる使われ方とか
ユーザーのフィードバックを見ながら
少しずつ改善していったり
機能を足していったりっていう風にした方が
うまくいきやすそうだよねみたいな考え方をするのが
アジャイルの考え方になるんです
これ今ちょっと聞いてて思ったのが
ベータ版とかあるじゃないですか
あれはまた別の概念ですか
ベータ版とアジャイル
基本的には似た概念かなと思うんですけど
ベータ版っていうものを作って
一回全部
これを壊して作り直すっていうよりは
まずベータ版として世に出して
ちょっとずつ改良をしていきながら
よしこれでも
ある種の完成形というか
正式版って言ってもいいよねってなったら
ラベルを張り替えるみたいな感覚で
ベータ版っていうものを作ってる場合には
アジャイルってアプローチで作ってるケースが
多いんじゃないかなって思います
こういうことでベータ版ってたまに書かれてるけど
ベータ版の意味がこちらは使う
ユーザー側は何もわからんまま
まだ完成じゃないっていうのは
なんとなく伝わってくるみたいな
そうですね
付ける意味はもう完成じゃないけど
許してねっていうぐらいの意味しかないと思います
なんか特殊な意味があるわけではないんですよね
はい
なるほど
そうか
まだまだ分かってるけど
許してねっていう気持ちですね
その気持ちで使ってねっていう
逆に
怒らないでっていう感じですね
なるほど
Waterfallとアジャイルと
流派というか
2つの流れがある
今話したように
システム開発と農業の類似性
Waterfallとアジャイルって
どっちが正しいとかじゃなくて
使い分けの話なんですけど
これ結構
使い分けるっていうのが
難しいなっていうのを
2つの開発をやっていると感じていて
それの話を何で今日しようと思ったのかっていうと
前に
延山にお邪魔したときに
どうやったと話していたか忘れたんですけど
何を育ててるかっていう作物の種類によって
農家さんのキャラクター全然違うみたいな話を
聞いたのがすごく印象的
ありましたね
葉物農家さんせっかちがちみたいな
農家さんとか
米農家さんすごく
お尻されてる方が多いみたいな話を
これはあれですね
僕が前いた会社アグレスの代表
土屋が言ってた部分でもあるんですけど
やっぱり彼がそうっていうのがあるので
一概にどうこうということはないのかもしれないけど
やっぱり葉物農家として生まれ育った人たちっていうのは
ガッと作ってガッと取ってガッと出すみたいな
例えば火災類、トマトとかイチゴとかっていうのは
本当に手を加えて甘さを引き出したりとか
本当に細かい作業がたくさん必要みたいな
ってなってくると単純にキャラクターとして
品目によって合う合わないは明確にあって
職人肌の人は絶対とは言わないにしても
火災類みたいな細かい作業がたくさん必要な人
とにかく大雑把な人は葉物の方が
いいんじゃないかなっていうのは
勝手な私の定義ですけど
システム開発も一緒だなって思っていて
さっきのウォーターホールみたいなアプローチっていうのは
ちゃんとしっかり計画して
いろんなイレギュラーケースちゃんと考えて
じっくりと1年かけてシステム作るっていうのに
向いてる人って例えば真面目で
両面で忍耐強くないと
僕とかもせっかちなので
いいから早く作ろうよって気持ちになっちゃいますよね
まず作ってみようよみたいな
そこが忍耐強くしっかりちゃんと検討できる人
みたいな人が向いてるなって思うんですけど
逆にアジャイルに向いてる人って
せっかちな人が多いなと思って
いいからとにかく作って
実際に使われてみないと何がいいかなんて分からないんだから
まず作ってみようよって
それで批判も受けるかもしれないけど
それはそれでありがたいフィードバックなわけだから
それをもとにいろいろと改善していけばいいんじゃない
っていうような考え方の人がアジャイル向きの人で
多いなという印象があって
それって割とパーソナリティっていうか
キャラクターの問題だったりするので
画面によって使い分けようっていうのは
教科書的にはそうなんですけど
こんな自分の性格使い分けれないじゃないですか
僕は完全にアジャイルですからね
でも
今の話でいくと
ウォーターホールとアジャイルでいくと
内容でウォーターホールだよねとか
こっちはやっぱり先言ったように
新しいSNSとかはアジャイルで作っていかないとダメだよねっていうのは
内容でももちろんありますよね
もちろん内容が先で
作る作物によってアプローチ違いますよねっていう話なんですけど
ただだからといって
自分の性格そんなに変えれないので
なので割と
トマト作るときと
ほうれん草作るときで自分の性格を
切り替えれますかみたいな
そういう意味でリュウハみたいな
システム会社なのかSEなのか
わかんないですけど
私はウォーターホール側の
システム開発の人ですみたいなことを
歌ったりするんですか
上手くいきやすいなって思う
実際はそうでもないって感じですか
実際はやっぱりあるべき姿は
作るシステムとかお客さんの状況によって
アプローチっていうのを使い分けるべきだよね
アプローチの使い分け
作物によって作り方は
違いますよねみたいなのが
正論なんですけど
ただそんなに正論通りいかないなっていうのを
観察してると思って
どちらかというと向いてる人が向いてるアプローチで
作る作物を分けた方がいいなっていう
イメージがあります
絶対そうなんですよね
どうしてもビジネスっていう観点というか
役を取るとかそういうことでいくと
できますってまず言うとか
苦手な方をやるとだいたい上手くいかないみたいな
のが至る所で起きてるなとは
個人的には観察していて
農家でもそういう部分があるんだから
いろんな職業でもやっぱりありますよね
