00:02
こんにちは、kameiです。
yykamei's Podcastやっていきます。
今回はですね、アジャイルの話をしようかなと思っています。
私、ソフトウェア開発者でして、
ソフトウェア開発って結構大変なことがあるんですよね。
建築物とは違って、見えないものを作っているので、結構不足の事態が起きるわけですよ。
そうしてくると期限に間に合わないとか、いろいろ起こってきて大変なんです。
うまくいっているところもあるとは思うんですけど、
そんな中でですね、ソフトウェア開発をやっていく時のどうやってやっていくかというところで、
よくあるのがウォーターフォールと言われているやり方があるんですよね。
ウォーターフォールって何かっていうと、何でしょうねと。
開発を分割してフェーズとか言ったりするんですけど、
その開発フェーズを分けて、それぞれのフェーズが一個一個ちゃんと終わってから次のフェーズに渡すというのをやっていくのがウォーターフォールなんですよね。
あんまり難しい言葉を使いたくないんですけど、最初の方にこれをやるぞっていう要件定義とか言ったりするんですけど、
そういうのをしっかり決めますと。
その後に設計をしますと。
設計をしますと。
その設計に基づいて次に実際のコーディング、開発作業をしていく。
もうちょっと細かいんですけどね。
ここまでが作る過程で、そこからテストの工程に移るわけですよ。
まずは作ったものを細かい単位でテストしていく。
細かい単位でテストするだけだと実は不十分なので、結構大きなソフトウェアになってくると部分部分を結合してテストする。
結合テストっていうのがあるんですよね。
そして最終的に、例えば画面があるようなものであれば画面を使ったテスト。
よく受け入れテストなんて言ったりしますけど、そういうのをやってリリースになると。
これがウォーターフォールの一連の流れですね。
結構昔は、というか今もやってるところもあると思うんですが、ウォーターフォールでやるプロジェクトというのはあって、
03:10
うまくいってたんですよね、昔は。
だけどここ2,30年でどうもうまくいかなくなってくる事例があると。
それこそウォーターフォールのプロジェクトで、よく言う炎上みたいな事象が発生して締め切りに間に合わない。
なので残業のハードワークによってカバーするみたいなことが発生してしまうと大変ですよね。
アジャイルっていうのは、その辺りの反省から出てきたんじゃないかなと思っているんですが、
詳しいことはきっともっと強い方がいらっしゃいますし、Googleでいっぱい出ると思うのであまり歴史についてはしゃべれないんですけど、
そういったところのウォーターフォールの課題感っていうのは、
ウォーターフォールだけじゃないとは思うんですけどね、とにかく開発にまつわる課題感を何とかしようよっていうのがあって、
そういうワードが出てきて、これは2001年らしいですね、アジャイルソフトウェア開発宣言というのが宣言されましたと。
とりあえず宣言の全部読んでみますか。
私たちはソフトウェア開発の実践、あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。
この活動を通して私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、計画に従うよりも変化への対応を価値とする。
すなわち左の事柄に価値があることを認めながらも、右の事柄により価値を置くと言っているんですね。
さっきのウォーターフォールでいうと、ウォーターフォールの最初の方に要件というか、
お客さんこういうの望んでいるからこうあるべきだよね、みたいなフェーズがあって、それを要件定義と呼ぶんですけど、
そこをしっかり固めて設計、開発って移っていくんだけど、
実はその要件って割と変わるよねっていうところがあるんですよね。
それが今4つ言ったんですけど、計画に従うことよりも変化への対応をっていうところになるのかなと。
06:09
アジャイル宣言の背後にある原則って12の原則があるんですけど、
それなんか12個読むとちょっと大変なんで言わないんですけど、
確かこれの中に、どれだったかな。
あ、これだ。
要求の変更は、たとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
って言ってるんですね。
そう、このアジャイルマニフェストの12の原則の中で、
変更要求大歓迎って言ってるんですよね。
これが多分ウォーターフォールと結構違う点かなと思っています。
ウォーターフォールっていうのは、やっぱり最初に立てた計画から外れるわけにはいかないんですよね。
外れちゃうとやっぱりやり直しっていう風になっちゃうし。
なんでウォーターフォールで問題が生じるかというと、
ご存知の通りですね、インターネットっていうのがいっぱい出てきたわけですし、
インターネット以外にも世の中テクノロジーって相当進化してまして、
テクノロジーの進化だけじゃなくて、
人の考え方だとか価値観っていうのがかなり変化というか、
もう画一的ではなくなっているんですよね。
身近な例で言うと、今時って多分このテレビの番組見たって言っても、
あんまり通じる人がいないじゃないですか。
昔だったらこの番組見たよねみたいな話で結構盛り上がったりしそうな感じはするんですけど、
もう価値観が多様化しているので、テレビの話題で多分会話を盛り上げることって、
もう本当にむしろ好きな人同士でしか盛り上がらないんじゃないかなと思っています。
そんなに変化の激しい世界観において、
ウォーターフォールでしっかり計画を立てて開発をしてリリースするってやっていると、
実はそのリリースまでの間に状況が変わっちゃって、前提がもう完全に覆っちゃって、
これリリースしてもしょうがないよねみたいなことが起こってもおかしくないぐらいに
今って変化がたくさん起こっているんですよね。
そんなところで今やっていくと、ウォーターフォールって、
09:01
もちろんきっちり計画立ててやっていけばいいんだろうけど、
結局世の中はそんなにきっちり計画立っているわけでもないし、
じゃあやめちゃおっかみたいなところからきっとアジャイルっていう考えが出てきたんじゃないかなって思っています。
じゃあそもそもアジャイルって何かっていうと、
結局ウォーターフォールの開発のプロセスっていうのはやるわけですよ。
要件定義から設計開発みたいな。
そうするとギュッと圧縮しちゃうわけですよね。
つまり今までウォーターフォールで1年かかっていたものを、
例えば2ヶ月でやると。
それはウォーターフォールでリリースする分を1年を2ヶ月にするは明らかに無理なんですけど、
例えば1年後に提供しないといけないフルフルの機能っていうのを、
実はフルに提供しなくてもこの部分だけとかこの機能だけカバーしていれば、
あとはそこまでしっかり肉付けしなくてもいいんじゃないかみたいにして、
それを2ヶ月ぐらいのスコープにしちゃってリリースしてみるみたいなところの考え方がアジャイルなんですよね。
アジャイルでリリースしていって、2ヶ月でリリースするから2ヶ月でユーザーに使ってもらえるわけですよね。
そうするとユーザーからフィードバックっていうのを受け取ることができまして、
それで方向転換をしたり、このまま進むなりっていう判断ができるんですよね。
私の理解ではアジャイルって結構フィードバックを大切にしているなと思っています。
アジャイルの中にもいろんなさらにフレームワーク、スクラムなどあるとは思うんですけど、
結構振り返りっていうのをよくやっていたりして、振り返りなぜするかというと、
今まで自分たちがやってきた活動っていうのが、それ本当にいいんだっけみたいなところを振り返るっていうんですよね。
これはもうフィードバックなんですよね。
フィードバックがあることによって何がいいかというと、間違った方向にそのまま突き進むみたいなことが防げるんですよね。
例えばさっきの1年でリリースするべきだったウォーターフォールの開発で言うと、
1年後にその機能を出した段階で本当にそれユーザーに響くんだっけっていうのは1年後にならないとわからない。
12:09
でもその1年っていうのは実は6つぐらいに分けてリリースすることができて、
最初の2ヶ月でユーザーに提供して、これは感触がいいなみたいに疲れたら、
それはそれでやっぱり続ければいいし、みたいなところがありますと。
これがアジャイルな考え方なんですよね。
エクストリームプログラミングニューモンだっけ、ちょっと正式な本の名前は忘れたんですけど、
ケントベックのあの例の有名な本ですよね。
あそこに、アジャイルとは言ってないんですけど、結構いい例があって、
ケントベックが車を運転し始めたときに、お母さんについて行ってもらうわけですよね。
練習のときにつき添ってもらうわけですよね。
真っ直ぐの道路を走るぞと言って、ケントベックは真っ直ぐ走ろうとして、
ハンドルをしっかり真っ直ぐ、タイヤが動かないようにしっかりやってたんだけど、
そしたら道の速度に行っちゃったわけですね。
多分アメリカなんで、アメリカっていうか海外の話なんで、
アメリカじゃないかもしれません。
海外の話なんで、道路がそれなりに広くて、
多分それなりに安全な場所だったと思うんですけど、
要するに真っ直ぐ道走れなかったと。
そのときのお母さんのアドバイスが、
車っていうのは常に人間が注意をしながら微調整をして走っていくものなのだと言ってたんですね。
これを例にして、エクストリームプログラミングの考え方みたいなのをやってたんですけど、
まさにこれがアジャイルなんですよね。
本当に車の運転と同じだなと個人的には思っていて、
常に見る、常に見て、常に周りの状況のフィードバックを受け取って、
車はこのまま行くと横ぶつかっちゃうからちょっとハンドルを微調整しないとねみたいな。
それがアジャイルの考え方だと思っています。
もう開発は、多分どの開発現場もアジャイルやろうよみたいなのはあると思っていて、
でもそれでもなかなかできない。
もちろんそこの根底にある考え方をまだみんながみんな完璧に理解しているというわけではないからだと思ってはいるんですが、
15:07
そういうトレンドなんだよということですね。
これはですね、開発者向けというか開発者じゃない方向けにも、
アジャイルってこういうものなんだよって分かってもらうといいかなって個人的には思っていて、
あと、もしウォーターフォールを知っている開発者以外の方がいたら、
実はもうウォーターフォールってそんなに多分トレンドでもないんだよっていうのを知っててほしいなって思っています。
アジャイル、いろいろフィードバックが大事っていうことも言ったんですけど、
あとさっきの12の原則の中でもう一個私が好きなものがあって、これですね。
ビジネス側の人と開発者はプロジェクトを通して日々一緒に働かなければなりませんと言っています。
アジャイルの考え方って別に開発者だけのものじゃないんですよね。
ビジネス側って言っちゃうのもあれなんですけど、便利なんではビジネス側って言っちゃいますけど、
とにかくビジネスの人もフィードバックを受け取ってじゃあこれやろうかっていう考え方自体はとてもいいと思うし、
普段からやってると思うんですよね。
よくPDCAみたいなワードが出てたりすると思うし、
あれなんてまさにちゃんと計画を立ててやってみて、振り返ってみてもう一回やるみたいな、
そういうフィードバックを元にして新しいことをやるっていうことで、
あのPDCAなんて普通にアジャイルな考え方と同じですよね。
ビジネスの人と会話するときによく出てくるのが、いつモリモリで機能を出すみたいなことがあるんですけど、
実はそれってウォーターフォールっぽいんですよね。
ビジネスの人は多分自分たちがPDCAでやることができるのに、
ソフトウェアの開発の要求になると途端に結構でかい計画を出してくる印象が、
私の今の所属組織ではありまして、
あんまりそれってワークしないんだよなっていうのはぼやきとしてあって、
今回このアジャイルについてっていう話をしてみました。
まあ、つらつらとこんなことを喋ってみたわけですけど、
もし興味がある方がいれば気に留めてもらえると嬉しいかなと思います。
18:00
では、以上にしたいと思います。
亀井でした。
