皆さん、こんにちは。

Story's代表の佐藤です。

本日は、ウォーターフォール型とアジャイル型の開発PJにおいて、

アジャイル開発のPJに入っていくために、大切なところを説明できればなと思います。

では早速参りましょう。

今回も私の10数年来のIT業界での知見をもとにお話させていただければと思います。

▼よろしければYouTubeもご覧ください！

ウォーターフォール型とアジャイル型の特徴

ウォーターフォール型は各システム開発における要件定義、基本設計、詳細設計、開発、テスト、リリース、運用保守の各工程を終えた後に、きちんと検収をして検収が完了したら、次の工程に進むようになっております。

こちらの特徴としては各工程を、きちんと行っていきます。ただ時間がかかるというのがあります。アジャイル型はまず要件定義をします。その後、Sprintごとで区切っていきます。こちらのSprintごとに設計、開発、テストを行い、その後に事業会社、クライアントの受入試験があり、そちらを元にFBをもらいます。

そのFBを後ほどのSprintで反映していきます。小さい開発サイクルをこまめに回していくのが特徴です。こちらによって素早く開発できます。

ただ、一方で雑になりやすいところもあります。ウォーターフォール型、アジャイル型もそれぞれメリット、デメリットがあります。向いているシステム開発PJも、やはり案件によって変わると思いますので、案件等の中で見定めていければいいのではないかと思います。

アジャイル開発について

今回のテーマ、最近の主流はやはりアジャイル開発が多いです。私もITフリーランスの人材を紹介させていただく時に、要求事項として、「アジャイル開発したことありますか？」や「スクラムマスターの経験ありますか？」などの質問が多いです。「アジャイル開発」や「スクラムマスター」などのワードは、アジャイル開発におけるキーワードだと思っております。その中でも、実際に入って活躍していくというところで、ポイントになる部分は何かというところをまとめてみました。

＜①PJによって定義が異なる＞

ポイント1つ目はPJによって、アジャイル開発は全然定義が違うということです。

小さくスケジュールを切って、スパンを切って、Sprintを切って、色々開発を回していくという中で色々な体制が組めます。そのためPJによって、スクラムマスターというものの位置付けや、スクラムという言葉の定義も、やはり変わったりすることがあります。例えば、案件の面接を受けるときに、「アジャイル開発の経験ありますか？」と聞かれた場合、簡単に「前のPJはアジャイル開発って言ってた。できます！」と言うと、教科書通りのアジャイル開発をしているのと、アジャイル開発とウォーターフォール開発の間ぐらいでやっているという二つの意味で捉えられます。そうなってきた時に1番辛いのは間をやっていたのに、教科書通りのアジャイル開発を経験したと捉えられてしまった場合、言葉が全く違うので、案件に入ってからいきなりわからなくなるという困るケースです。

そのため面接を受ける時のポイントは必ず、「PJによって定義が異なると思うのですが、私がやってきたアジャイル開発はこういうことです」というのをきちんと言った方がいいです。そうすると実際に面接をしているシステムベンダーや事業会社の方が、「うちのPJってこういうことです」とおそらく説明してくれます。

よって、両者の認識のズレを解消しやすくなると思うので、面談の時からもかなり重要だと思います。

＜②事業会社との認識のズレ＞

次に事業会社との認識のズレというのがあります。

どういうことかというと、アジャイル開発は最近の主流ではありますが、例えばシステム開発はクライアント1会社に対して、そんなにずっとやっているかというとそこまで多くないケースもあると思います。「今回、スマホアプリやWebアプリを初めてやります」というクライアント企業の場合、「こちらをアジャイル開発でやっていきましょう。」「流行っているからやってほしい。」「取り入れたいんだよね。」と言われても、おそらく事業会社側にも、やはりそういう人材が慣れてなかったり、いなかったりするケースが多いです。そこでシステムベンダーが「アジャイル開発はこうしたいです」と言ったとしても、やはり、なかなか浸透しないケースが多いです。

私のやってきたPJでも、やはりそのケースはすごく多いです。システムベンダーとしては、自分たちの中で定義したアジャイル開発をずっとやってきているので、事業会社にも「アジャイル開発をしたことがあります」や「アジャイル開発をしていきたいんです」と言うのであれば、「わかるよな？」というのが実際に少しあります。

そうなると、やはり事業会社とシステムベンダーの認識のズレが発生して、PJが全然進まなくなるというケースが結構多いです。

そのため、システムベンダー側にいるメンバーが特に気を付けるべきことは、アジャイル開発の定義というところは、ちゃんとまとめておいた方がいいということです。私は基本的にSprintなどきちんとスケジュールを日単位や週単位、月単位で切って、カレンダー形式で「Sprint1は、こういう風なスケジュールでやります」など全体像を絶対に最初に整理して、事業会社にはきちんと提示するようにはしています。

こちらはきちんとやっておかないと、どうやって進むのかがわからないのが1番困ると思います。

そのため是非きちんとSprint0、むしろ要件定義の前ぐらいにはきちんと伝えておいた方がいいのではないかと思います。

＜③雑にやっていいわけではない＞

最後に雑にやっていいわけではないということです。

アジャイル開発では、特にシステムベンダー側の担当者によって引き起こされます。どういうことが起こるかというと、例えばアジャイル開発の時は要件定義、Sprintの設計など、クライアント、事業会社とやり取りが多いですが、その時に例えば、「ミーティングをしました、議事録を作ります」というのがアジャイル開発が当たり前になっている企業だと、議事録を取らないケースが結構あります。信じられないと思うかもしれないですが、ウォーターフォールだと、逆に議事録も必ずチェック、レビューの対象なので、絶対やります。

しかしアジャイル開発の場合、いい意味で早くやる、レビューや研修などがそんなにないので、「じゃあ、ミーティングとかも大丈夫か」で、タスクなどもきちんと整理しないで、

「あ、こういう話だから大丈夫だよね」という風になるケースが結構あります。

やはりアジャイル開発をメインで育ったSEというのは、その傾向が強いなと思います。

いいことでもありますが、ただそんなことをしていると、絶対に言った言わないの認識齟齬もあります。

そういう風に仕事を進めている人たちのPJに入ると大体炎上しています。

また、アジャイル型のPJで育ったSEは仕方ないと思うんですけど、元々ウォーターフォールでやっていた人たちがアジャイルに来ると、「え、こんな緩くやっていいの？」みたいなところのギャップがあります。

やはり、きっちりやっていたところから緩くなると、アジャイル開発の方が居心地がいいみたいになって、やらなくなってしまいます。おそらく40代、50代のSEがウォーターフォールからアジャイル型に転職してる方がかなり多いです。こちらでその人たちが最初に要件定義とかやってしまうとかなり地獄を見るケースが多いです。

まとめ

今回は私が結構苦労したとお話ししていますが、絶対にアジャイルだからといって雑にやっていいわけではないというのは、少し覚えておいてほしいなと思います。

今回ポイントを3つまとめさせていただきましたが、あげるときりがないくらいたくさんあります。ただやはりアジャイル開発は最近の主流であることは間違いないです。素早くやれるメリット。やはり素晴らしいと思います。

ですので、アジャイル開発でも、きちんと活躍できるようにというところは、まず最初にこちらのポイント3つは押さえてほしいなと思います。

こういった形でシステム開発におけるポイントというところは、どんどん発信していこうと思います。

では、また次のブログでお会いしましょう。