00:12
ITエンジニアの雑談駆動開発部。 この番組は同い年、若手エンジニア2人が技術のこと、キャリアのことを等身大のまま語り合っていく番組です。
成長中の2人が学んだことをリアルタイムでお届けします。 使用書なし、テストなし、雑談だけで駆動していきます。
ITエンジニアの雑談駆動開発部、始まります!
始まります!
今日の議題なんですけど、ボタンを1個追加してほしいんです。
こう言われたら、どこにボタンを置いて、押したら何が起きるようにするのか考えますよね。
でもその前に聞いておきたいことがあります。
それは、そのボタンで何をできるようにしたいんですか?
はい、始まりましたー!
なんですか? 驚いてるよ。
そのボタンで何をできるようにしたいんですか?
今日は、システム開発で難しいのは、
本当にやりたいことをつかんで仕組みにするという話をしようと思います。
システム開発でプログラムとか言うよりも、それよりもっと前の段階ですね。
本当にやりたいことをつかんで仕組みにするっていう話をしていくんですけど、
例えば、誰かに木に登りたいので大きな梯子を作ってくださいって頼まれたとします。
そしたら、じゃあ何メートル必要なのかとか、どんな材料なら大丈夫なのかとか、
そうやって立派な梯子を作っていきますよね。
で、頑張ってせっせと作ったら、頼まれたものはちゃんとできます。
でも、その前に木に登って何をしたいんですか?って聞いてみたら、
上にあるリンゴが欲しいです。
上にあるリンゴが欲しかったんです。
さらに話してみたら、食べるためのリンゴが手に入ったら、ぶっちゃけそれで目標達成だったんです。
そしたら、それがわかったら、近くの果物屋さんを案内する方法もありますよね。
そしたら、梯子作る時間も木に登る手間もいらなくないですか?
確かに。
最初にもちろん、相手から頼まれたのは梯子だけど、達成したかったのはリンゴを手に入れることだったっていう。
03:04
システム開発でもこういうことめちゃくちゃあると思うんですよ。
なるほど。
この機能が欲しいっていう言葉は、その人が思いついた解決方法かもしれないんですけど、
普段の作業でここが面倒って感じてても、本当は何を変えれば楽になるのか、最初から整理して説明できるとは、
いくらそのシステムを使っているとしても、そうとは限らないと思います。
自分のやりたいことをちゃんと相手に明確に伝えるって、思ったより難しいことじゃないですか。
そこでどうやって擦り合わせていくかっていうと、普段はどうしてるんですかとか、どこが大変なんですかって話を聞いて、
実現したいことを一緒に整理していく。
これがシステムで何を実現するかを決める要件定義の大事な部分だと思ってます。
なるほどね。
上手だね。
いや、なになに。
と思ってるんですよね。
今回はちょっとね、自分の体験談を架空の音楽アプリに置き換えてお話ししていこうかなと思います。
よろしくお願いします。
よろしくお願いします。
で、その人なんですけど、音楽アプリで好きな曲を集めたプレイリストを通勤用と作業用に分けてます。
プレイリストってわかりますか?
はい、わかります。
好きな曲を入れて、自分のアルバムみたいなのを作るやつです。
で、通勤用と作業用に分けている。
で、そしてその人から音楽アプリの改修を依頼されます。
ちょっと機能を改善してほしいってね。
その人が知ってほしいのが、選んだ曲を複数のプレイリストにまとめて追加するボタンが欲しい。
この曲めっちゃいい曲だと思ってプレイリスト追加しようと思ったら、通勤用と作業用どっちにも反映されるみたいなイメージのことをしたいって言われました。
で、そこでどんな時に使いたいんですかってちょっと深掘りしてみたら、
気に入った曲が見つかる度に通勤用にも作業用にも入れてるんですって。
どっちとも聴きたいのでって返ってきたんですね。
で、なるほどと。
同じ曲をそれぞれに登録、一個一個するのめんどくさいですよねって。
で、通勤用と作業用以外にももっとプレイリスト増えたら、それこそ大変ですよねみたいな話をして、
そこで自分がさらに深掘りするんですね。
新しいお気に入りを一度登録したら、どちらでも聴ければいいんですねって確認しますね。
そういうことなら、どのプレイリストからも再生されるお気に入り一覧っていうのを一つ作って、
06:07
通勤用でも作業用でもその曲を含めて再生するようにそのシステムを変える方法も考えられますって提案しました。
なのでお気に入り一覧っていうのを入れると、結局通勤用で再生しても作業用で再生しても
お気に入りの曲が絶対ランダムに流れてくれるみたいなイメージですね。
で、共通して聴きたい曲は一箇所に登録すればいい、で、どちらでも聴きたいという希望を
今回は自分の考えでは共通の曲を一箇所で管理して再生するときに組み合わせるっていう仕組みを採用したんですね。
ここまでなんかわかります?
はいはいはい。
イメージできました?
イメージできました。
最初は一括登録なんで、一括登録ボタン作りゃよかったんですけど、最終的に自分が下した決断は
共通のところに保管して、そっから再生することでどっちにも反映されるみたいなっていう仕組みにしたわけですね。
で、そういった会話で掴んだ目的を画面やデータの持ち方、処理の動きに落としとこんでいく。
で、ここでシステムの設計に繋がっていきますね。
もちろんなんですけど、一括追加ボタンの方が使い方に合う場合もあると思います。
その実装も全然ありだと思います。
目的を確認できたことで、でもですよ。目的を確認できたことでいくつかの方法を比べられるようになったっていう話ですね。
はいはいはい。確かに。
その作ってほしいって依頼したユーザーさんの方も二択の中から選べるじゃないですか。
はい。
だからより自分の欲しかったものに近づけますよね。
満足度が上がって。
そうですそうです。
で、自分が選んだっていうことになりますもんね。
こっちとこっちどっちがいいですかってなる。
こちら勝手に本当はこうしたいんでしょうって決めつけるのはダメですよね。
確かに。
これの方がいいんだって。
さっきの例えに戻るんですけど、リンゴも自分で育てたあの木のリンゴを収穫したいっていう目的だったら、果物屋さん連れてきたらいやそうじゃないんだよってなるじゃないですか。
なので、こうなれば困り事を解決しますかって理解が合ってるか確かめる必要がありますよね。
確かに難しいね。
難しいです。なので、はしごを作るのが絶対ダメってわけじゃないですよ。
話聞いてみて、あの自分で育ったやつを自分の手で回収したいだったら、めっちゃ高いはしごを作るのも正解なんですよ。
なるほど。
その目的がちゃんと擦り合わせられたら。
難しいなこれ。やっぱりエンジニアとは言いつつもって。
そうですそうです。
コード書いてるだけじゃないぞっていう感じがするな。
はい。で、なんか開発、実装ももちろん難しいけど、その前に何を作るか、何をどう作るかっていうのを考えるのってすごい大切だなと思ってこの話をしようと思ってて。
09:15
もう一つこの要件定義で大事だなと思ったのが、今便利になったとしても、それで終わりとは限らないですよね。
システムって作った後も今回の要望みたいに機能を足したり、不具合を直したりしますよね。
はい。
で、そうやって使い続けられるように手を入れるのを保守って言うと思うんですよ。
います。保守。
よく聞きますよね。
そうそう。なので後から変更する時に困らないかも機能を追加したり新規でやる時に考えるのがめちゃくちゃ大事です。
確かに。
ですよね。
今心をつけるのが本当に大事なのかも。
そうそうそう。
毎回毎回ちゃんと確認しないと後からやかましいことになっちゃうんでね。
そう、どんどん後から直す時にはこんなかかるのかよ、これじゃダメなんだよこれみたいになっちゃうから先のことも考えないといけなくて。
例えばなんですけど、音楽アプリで新しい機能を早く作る。時間ない時間ないみたいな感じで、
例えばさっきの一括登録とかの機能で既にある曲を追加する処理っていうのを丸ごとコピーして絶対に変えなきゃいけないところだけ少し書き換えて流用したとする。
はい。
で、とりあえず動くものは早くできるかもしれないですね。それで。
後日なんですけど、曲を追加する時の共通ルールを変えることになったら、元の処理とコピーした処理の両方を直す必要が出てきますよ。
はい。
で、片方だけ直してもう片方忘れたら、使う機能によって動きが違ってしまうとかも起きるんですよ。
右に覚えがあるな。
そうそうそう。そうなっちゃうじゃないですか。流用とか何も考えずに増やしていっちゃったら。
右に覚えがありすぎるかもしれないな。
で、あれですね横展開ってやつですね。
横展開嫌いな言葉。
で、同じような処理を増やすたびに将来の修正箇所も増えていくわけですよ。
間違いないね。
今は時間かかるかもしれないけど、同じルールで動く部分は共通の処理として使えるようにする方法も考える。
うん。
そしたら最初に少し手間かかってもその後の変更が楽になることもあります。
ですよね。
今時間をかけることに重点を当てるか後の時間を生み出すことに重点を当てるかっていうところの違いみたいな話ですよね。
12:01
そうですそうです。
現場の人は本当に今この瞬間早くもう締め切れが近いからやっちゃいたいけど、最終的に本当にトータルで見た時間で考えないといけないってこと?
そう。今苦労して後々ずっと楽するか、今楽して後からずっと不才を残し続けるかみたいなところに繋がってくるわけですね。
なのでちゃんと考えないといけない。
共通化するにしてもちゃんと考えないと痛い目見るんです。
どうやって考えるんですか?
自分が大事だと思ったのが多分機能を回収するときってその機能周りだけ見るじゃないですか。
でもその機能を使う人ってその機能をピンポイントで使ってるわけじゃなくていろんな周りの処理があるじゃないですか。
音楽だったら再生するだけじゃなくてプレイリスト作ったりもできるし、例えば好きな曲を共有する機能もあると思うんですよ。
そういう周りの機能とかがっつり繋がってる機能とかもあるかもしれないですね。
保存する機能とプレイリスト一括登録する機能とかある意味繋がってますね。
再生する機能とかも。
なのでその前後の今自分が回収しなきゃいけない機能だけを見るんじゃなくてその前後に繋がってる機能。
もっと見れるんだったらそのユーザーさんがどういうふうに日々使ってるのかっていうシナリオ。
ちゃんとこういうふうにここからログインしてまずはこういう操作をしてこういうことをして最終的にこういうものを欲してるよねみたいな。
ピンポイントで見る。これもですねピンポイントで見るんじゃなくて全体としてどうやって使ってるのかっていうのがわかったら
なんとなくここって共通化しとかないとこの機能めっちゃ使うとこ出てきそうだなっていうところがわかってくる。
目的をね達成するってことを念頭に置いとくって感じかな。
目的は何なんだってこの機能を実装する目的は何なんだっていうのを頭に置いとけばここで共通化するべきなのか
後々ここは共通化しなくてもいいのかみたいな判断基準にできそうじゃないですか。
あ、そうですね。そこをちゃんとユーザーさんに聞いてないと目的がブレていっちゃうのかなって思いますね。
ありがとうございます。
なのでエンジニアさんに多分こうしたらいいじゃんとか思うと思います。
でもエンジニアさんがちょっとそのやり方避けたいっすねっていう時は作れないっていう意味とは限らなくて
今は作れるけど後から直す時ここ大変になりそうだなっていうのを考えてると思いますね。
で、そういう理由があって別の方法を提案することもあるんじゃないかなって思います。
15:05
もちろんなんですけど将来心配していつまでも完成しないのは困るので
今使える時間と予算とその後の直しやすさを両方考えてこれからの方針を選ぶ必要がありますね。
こう考えてみるとボタン一個追加してっていうお願いにも本当に解決したいことは何か。
ただバカみたいにボタン一個追加しちゃダメなんですね。
ちゃんと話本当にいるのか。
僕はもう素直だからさ。
みんな多分手段で言っちゃう今回でボタン一個追加してとか。
でもボタンを追加するって手段じゃないですか。
じゃあそのボタンを追加することでやりたいことは何ですかって聞いたら結構かみ合ってくるのかもしれない。
いい仕事しますね。いい仕事してますね。
いやいやとんでもないです。でも楽しいですね。
いい仕事の仕方だと思います。
それが要件定義ってやつですね。
使う人は日々の作業や困りごとに詳しい。
作る人はシステムで実現する方法やその後の変更への影響を考える。
その知識を持ち寄って目的に合う形を一緒に決めていけたら
お互い使う側も開発する側もウィンウィンになるんじゃないかなって思いますね。
ウィンですね。
いらないはしごを作らないようにしようねみたいな話でした。
はい。なるほど。面白いな。いい例え話だった。
で、最後にまとめなんですけど
立派なはしごを作る技術もこれから身につけたいんですけど
その前に登った先で何がしたいんですかって聞けるエンジニアになりたいですね。
なりたい。これはなりたいね。
なりたい。これは。
