00:05
はい、みなさんおはようございます。株式会社ゆめみでチャレンジ取締役をしております。キースことくわはらです。
本日もやっていきます。Web 業界のなんでも雑談室です。
第64回ですね。第64回は
アジャイル開発についての誤解というテーマでお話ししていきたいなと思います。
はい、社内ですね、尊敬する会社の先輩が昨晩ですね、スラックで面白いことを投稿していたので、その内容から
思うところを今日はちょっと喋っていきたいなと思っております。
はい、最近の日本というと、ちょっと主語が大きいんですけども、
ウェロのWeb 業界ですね。私がWeb 業界で仕事をしているからですけども。
はい、でですね、とにかく最近お仕事をするお客さんからですね、
たまにこの今回はアジャイルでとか、アジャイル的に開発を進めていきたいということを言われることが増えてきたんですね。
はい、これは別に悪いことではないですし、そのアジャイルの文化が
日本にも浸透してきたなということで、とても喜ばしいことだと思いますね。はい。
まあ、そもそもですね、そのワードすら聞いたことがないというふうにお客さんも
今まで多かったので、本当に良いことだと思います。
ただですね、1点注意したいというか、
お客さんのそのアジャイルというワードをですね、誤解されていることが多いなというふうにも
ちょっと感じておりますね。はい。
お客さんだけならまだしも、まだいいんですけど、社内の営業の方だったり、PMの方だったり、
社内の方を誤解されていることがもし起きていたら、
その手を動かすデザイナーとか、エンジニアのメンバーにとっては悲劇が起こるなってことを思います。
特にその商談をするメンバーの方が誤解されていると、辛いことがあるなと思っていて、はい。
で、そもそもアジャイルという言葉ですね、そのワードの意味っていうのを辞書で調べていただくと
わかると思うんですけど、素晴らしこいとか、身軽、勉強なとかいうところですね。
あとは頭の回転が早いみたいな意味もあったりしますけど、はい。
こういう意味があるんですね。アジャイル、つまり素早さっていうところが
キーになっているワードなんですけども、はい。
これをですね、2つの意味で誤解されている可能性があるなと私は思っています。
はい、というわけで、いわゆるアジャイル開発を導入したらどうなるかというと、
1つ目に、開発速度も含めたプロジェクト全体のスピードが上がるというふうに
思っていると。2つ目に、変更することが前提としている手法ですので、
何度でも変更ができると思っているという、この2つの誤解があるんじゃないかなと
私は思っております。はい。
この2つの誤解、どちらか1つでも発生してみると、やっぱり悲劇が始まってくるなという
ふうに思いましてですね。本来の意味、アジャイル開発の本来の意味としてはですね、
プロジェクト全体を大きな単位、いわゆるウォート開発だとそれが1つになるんですけど、
大きな単位で開発を区切るのではなくてですね、小単位で区切ってそのイテレーションを
どんどん回していくことで開発を進めていくっていうのが、アジャイル開発の
本来の意味になりますね。
で、アジャイル開発の有名なものとして、スクラム開発というものがあるんですけど、
03:02
これは最近はもうだいぶ日本にも浸透してきたものの1つだと思いますが、
スクラム開発でいくと、このイテレーションのことをスプリントと呼んだりはしますね。
このイテレーションの内容としてはですね、いわゆるPDCAに近いものですね。
計画をして、設計をして、実装をして、それをテストするというところですね。
で、この4つが1つの区切りとなって、その1つの区切りのイテレーションをどんどん回していって、
プロジェクト全体が最後、そのイテレーションが全部終わったらプロジェクト終了というところですね。
で、イテレーションの期間としてはですね、だいたい1週間ないし2週間の期間が一体一般的じゃないかなと思います。
これ以上長くなるとちゃんと区切りができないとか、いろいろ詰め込みすぎていて、
後で破綻することが多いので、単位としては大きいので、一旦それはもう1回切り直しましょうということになると思います。
で、いいんですけど、アジャイル開発でポイントというか、注意したいなというところがあるので、そこも今日お話したいなと思っていて、
アジャイル開発ですよね、フィードバックとかテストを実際にするんですけど、
そのする時点で変更したりとか、ここってやっぱり直さなきゃいけないよねみたいなところが発生するんですよね。
しかもそれを前提とするような手法になっていますので、
いわゆる開発時にですね、詳細まで厳密に設計とか仕様を決めないのがこのアジャイル開発の手法になります。
特徴というか、最初だからその分お客さんとしては不安であったりとか、その分決めないので予算感とかお金を決めるのもなかなか難しいとはもちろん思うんですよね。
そういうメリットデメリットあるとはいえ、最初はそういうスタートの仕方をするのがアジャイル開発ですので、
やはり変更があり得るということを前提とします。
それは別にそういう仕様というかやり方ですのでいいんですけど、
リリース日とか納期というのはやっぱり決まってくるのが実際の現場だと思いますね。
ですので、時間というものが決まっているのであれば、その変更の上限とか限界というか、
あとそのMVPですね、この初段のリリースではここまでしかやりませんみたいなのを決めるのが本当に必要であると思います。
より具体的に言うとですね、先ほども言いましたけど初期リリースではここまでしかやらない、
やらないことを決めるということが本当に重要だなと思っていて、
お客様は何でもあれもやりたい、これもやりたいとかこれも必要だというのをどんどん詰め込んできがちなんですけど、
これは本当にそうですかというのはしっかり議論していきたいですし、
本当に必要であるとしても納期とかお金とか工数って正直言うとこれのどれもが変わらないのであればそもそも変更することはできないので、
どうしてもこれを詰め込みたいとか変更したいのであればこれは除外しましょうとかいうところをしっかり決めなきゃいけない、
もしくはもう納期を伸ばしますとか、あとお金を増やすのでちょっと申し訳ないけど過度を上げてくださいとかというお話が出てくると思いますね。
ですのでここがやっぱり重要ですね、先ほど言った納期お金工数の3つですね、
06:00
このトライアングルのどれもが変わらないのであればもうやらないことをしっかり決めていって、
やらないことを増やした分そこに余裕ができるので、じゃあそこを変更点を詰め込むことができるよねということが話に進むと思います。
という感じですね、もちろん色の調整だったりか文言修正みたいな本当に軽微なものであればもちろん変更は効くのは当たり前ですけども、
それでもやっぱり回数が多くなってくるとチリツモになるので、
工数の調整とかまた出てくるとは言いますね。
というので初段に詰め込むものを減らす必要があるのは当然だなという話です。
もう一つちょっと注意点としてですね、使用の合意形成のスピードっていうのがすごく重要になってくると思いますね。
やはり開発するとしても結局、実写サービスであればあれですけど、お客さんのサービスを自宅で開発するのであれば結局答えっていうのはお客さんが持っているものですので、
お客さんのその使用の合意っていうのがそのスピードに大きく影響をしてきます。
ですのでそれをするためにもですね、プロジェクト開始時にしっかりとコミュニケーションフローであったりとか、
意思決定フローっていうのを確立してからプロジェクトを進めることが大事じゃないかなと思います。
結構これって漏れがちで、使用だったり要件だったり、開発環境とか技術的な話であったり、機能要件どうするかみたいなところを、
要はシステムとかアプリケーションについての話、決定をすることがやはり多いんですけど、
それを進める結局チームとかプロジェクトそのものについての設計っていうのをしっかりやっていかないと、
やっぱりスピード感は出ないのかなと思いますし、後ほどスピードが減速するような要因が出てくる確率は高いなというふうに思いますね。
これは経験則で言っていますけど、確実にこうやったらこうなりますみたいな手法はちょっと僕はわからないですけど。
以上、お客さんが理解していないって可能性はもちろんありますし、プロジェクト開始時にちゃんとアジャイル開発ってことの意味について、
お互いの認識層がないかっていうふうにこちらから出していって確認をしていくことが大事だろうなというふうに思いますね。
もちろん相手はITのプロではないことも多いですし、なんならリテラシーが低いお客さんも絶対多いと思います。
それは当然のことであって、別にそれが悪いことでもないと思います。
なので知らないことはちゃんとこちらから教育するぐらいのスタンスで話していって、
しっかりプロジェクトの悲劇を最初からなくすように動いていくことが大事だろうなというふうに思います。
というところで今日は収録こんな感じで以上となります。
また何か話してほしいこと聞いてみたいことがございましたらお気軽にレーター投げていただければなと思います。
ではまた次回の収録でお会いしましょう。バイバイ。
