はじめまして！ピクトリンク事業部でweb開発をしているakanenです🎀
今回は、ウォーターフォール・半アジャイル・アジャイル開発を経験した私の思うベストプラクティスについて開発メンバーとして参加した視点で書いていきます。
前提として私の経歴を簡単にお伝えすると…
プリントシール機ソフト開発 ウォーターフォール開発 約3年
プリントシール機ソフト開発 半アジャイル開発 約2年
ピクトリンクソフト開発 アジャイル開発 約3ヶ月
こんな感じです👩💻
＼ええ！アジャイル歴短っ！／
そう思ったあなた！その通りです。
ガッツリとアジャイル開発に参画するようになってからはまだ3ヶ月👼🍼
なのでぜひラフに、経験談・所感として読んでいただけたら幸いです。
はじめに
各開発手法について触れていきたいと思います🙋♀️
詳細について知りたい方は、ぜひGoogle先生に聞いてみてください🔍
ウォーターフォール開発
システムやソフトウェアの開発において、上流工程から下流工程へと順に開発を進める手法。
上から流れる滝のように見えることからウォーターフォール開発と呼ばれています。
アジャイル開発
システムやソフトウェア開発において、小さな機能単位で実装、テスト、リリースを繰り返しながら開発を進める手法。
私たちはその中でもスクラムというフレームワークを使っています。
半アジャイル開発
これは今回の説明のために私が作った言葉で、正式な言葉ではありません！
上記の2つの開発手法をいいかんじに織り交ぜた開発手法です。
私のいたチームでは、下記のみアジャイルを取り入れていました。
- 毎朝のデイリースクラム
- 週1回のレトロスペクティブ(振り返り)
こちらの記事を読むと、半アジャイルの動き方がわかりやすいかと思います📝
フリューでの導入事例
基本的に、
プリントシール機開発はウォーターフォール
ピクトリンク開発はアジャイル
がフリューのスタイルです。
ただし、チームによって工夫した開発手法をとっている場合があります。
その結果として私の所属していたチームでは半アジャイルが生まれました！
わたしの感じたメリット💡・デメリット🌀
ウォーターフォール開発
💡メリット💡
なんと言っても開発着手からのスピード感！
仕様や期日が明確なので、私たちソフトウェアエンジニアは積まれたタスクをとにかくこなすのみです！！
プリントシール機開発では（もちろん例外はありますが）、
企画→整合→仕様書作成 は企画チーム
実機テスト はテストチーム
と細かい役割分けがされています。
これによってエンジニアはコーディングに集中することができるのです💪
ダダダっと自分のペースで進めていけるのは魅力だとおもいます。
細かく切られたタスクやマイルストーンをこなしていく達成感もあります。
🌀デメリット🌀
仕様変更が入ったとき、スケジュールが一気に崩れる😵💫
プリ開発の特性上、ユーザーの意見によって開発物に大きな変更が入る場合があります。
👧💭 新しいプリ機、6枚じゃなくて7枚撮影したいな〜
この意見を採用するとしましょう。
各々のユーザーに用意してあげられるプレイ時間はあまり増やせません。
私なりに少し考えただけでもこんな変更点が浮かびました。
- らくがき時間を撮影時間の分、20秒減らす
- 可愛く画像処理された画像を想定より１枚多く用意する
- らくがき画面の配置デザイン修正
- シールデザイン選択画面の配置デザイン修正
- らくがき終了→シール排出までの限られた時間でのシール用画像処理1枚追加
整合や設計を再度行う必要のある項目が多いことがお分かりいただけると思います。
楽しみにしてくれている皆さんために、発売日を後ろ倒しにするわけにはいきません！
時には短い期間で各チーム一丸となって奮励する必要が出てきます。
アジャイル開発
💡メリット💡
とにかく納得感が桁違い！
現チームでは１週間と決められたスプリント*1の最初に「何を」「どうして」「どうやって」実装するのかを、エンジニア全員が出席するプランニングというミーティングで決めていきます。
この「どうして」を必ず理解して実装することって、実はレアなのではないでしょうか😳？
👩💻💭AとBとCのタスク、どれもなんか今月中にやれっていわれてるんだよなぁ
👩💻💭AとBは来月のあの試作の事前準備で必要、Cは社内向けの改善案になるらしい！
この2人のエンジニア、どちらの方がモチベーション高く作業を進められるかは一目瞭然ですね。
また、残タスクの負荷やプレッシャーが個人にのしかからないのも嬉しいことだと感じています。
チーム全員が同じ内容を把握し同じ方向を向いてよーいどん！で開発着手するため、チーム全体で課題意識を共有できることに繋がります。
手の空いたメンバーが他のメンバーのタスクへ参加したり、ヘルプをチーム内で完結できたり、臨機応変な対応が可能となります✨
🌀デメリット🌀
どうしてもミーティング時間が多くなりがち…
基本的にはPO*2のおかげで、エンジニアが各企画者と整合する回数は少なく済みます。
ただし、PO→エンジニアのキャッチアップの際、チーム全員分の作業洗い出しをチーム全員で行うのでその時間が積み上がるリスクがあります。
この対策としてスクラムガイド *3では、スクラムチームのメンバー数は、エンジニア3～9人程度と推奨されています。
が、個人的には5、6人が理想的だと感じます！
理由は主に2つで、以下のとおりです。
- ミーティング内での発言者が偏らない
→人数が増えると「意見を伝えよう」という主体性や発言チャンスが薄れる - スクラムガイドで定義されるミーティング時間とのバランスが良い
→チームの成熟度にも左右されますが、例えば1時間で整理や共有できるタスクの数には限度があります
半アジャイル開発
💡メリット💡
マルチな才能を伸ばせる！プロダクトへの愛着が湧く！！！
個人の作業時間を確保しつつ、チーム内の進捗や課題の共有を適宜行うことが可能です。
また、半アジャイルの明確な定義づけがされていないので、企画段階からエンジニアも介入し技術観点でのアドバイスを行うなど、イレギュラーな動きもできます。
…文章にすると小難しいので私の具体例を書きます🎀
ある新規プリントシール機開発で、普段ならソフトチームが介入しない、コンセプト検討の段階からソフトチーム代表として介入させてもらう機会がありました。
過去にないキャッチライト*4をウリ機能にするため、筐体内のストロボ光源を増やす検討がなされていましたが、ソフト観点でみると既存処理の組み合わせでも実現可能と判断し、そのアドバイスを行いました。
結果的に、ストロボ光源を増やさなくてよい分の金銭的コスト削減、既存処理の組み合わせでよい分の実装コスト削減になりました。
検討当初から介入したことで根本改善に繋がり、エンジニアとしても新しい知見を得られた良い例だと思います。
そしてやはり、このプロダクトへの愛着は増しました💗
またこの半アジャイルのメリットは個人の意思を尊重して行動できるところです。
上記の具体例においても、チームの代表者が少なくとも1名参加すれば成り立つことです。
コーディングに重きを置きたいタイプのエンジニアにとっては、そこへフォーカスする時間に当てられます。
🌀デメリット🌀
この手法で開発していることが周りに認知されにくい。
他チーム、他部署から見たときに「レトロスペクティブってなんの時間？」「急ぎの案件あるし割り込んでいいかな？」と思われやすいです。
本来のアジャイル開発ではソフトウェアエンジニアだけでなく企画職やデザイナーなども一つのチームとして成立し、成果物をさらに外の関係者へも共有する時間があります。
これによってアジャイル/スクラム開発への理解度UPが成されますが、半アジャイルにはこれがありません。
一体どれがベストなの？
もちろん、開発するプロダクトのタイプや期日、誰目線の意見なのかにもよると思いますが、
私は半アジャイルが良いと思っています。
個人のやりたいことを尊重できる余白があるのが半アジャイルです！
ガッツリとコーディングをしたいエンジニア、プロダクトの理解や提案をしつつ開発を進めたいエンジニア、などエンジニアの多様化にも配慮しやすいと思います🌈
そしてそれを実現するためには個人の技術力や主体性が必要不可欠になります。
プロダクトを最大限良くするために、チームが個人としての力を最大限に発揮できる環境にしていきたいですね✨
