はじめに

この記事では、ウォーターフォール開発、スクラム開発の両方のプロジェクトの経験から、「結局抑えるべきところは変わらないのか！」と最近気づきを得た内容について書きます。

両方の手法を経験して感じた共通点と違い。抑えるべき根っこは変わらないところ。

スクラム開発かっこいいな

スクラム開発をやってみる前は、難しそうだなと思いつつ、「かっこいいな、やってみたいな」と羨ましく思っていました。

私が所属する部門では2017年くらいから徐々にアジャイル開発、中でもスクラム開発を導入し始めました。プロダクトオーナー（PO）、スクラムマスター（SM）、開発（DEV）の役割を作ったり、コミュニュケーション管理ツールを活用しつつ2週間スプリントを回すことを、まずはアプリ1チームから徐々に拡大させてきました。現在では5つ程度のプロジェクトがスクラム開発を実施しており、最大6チームのスクラムチームが稼働しているような大規模プロジェクトも存在しています。

私はこのころ適用外のプロジェクトを担当しており、横目で色々変わっていく状況を見ながら、参加できるタイミングないかなと状況うかがっていました。

スクラムマスターに手を挙げてみた

いろいろを経て2020年ごろ、私はスクラム開発を実践するアプリ保守開発チームのスクラムマスターになりました。

以前の投稿した9~12年目の頃です。私はインフラ畑育ちで、アプリエンジニアとして開発ができるわけでもなく、一人目の子育て奮闘中で新たにアプリエンジニアとしてスキル習得する勇気もなく、若手メンバーが多かったこともあり、プロジェクト管理的な要素の今までの知見を活かしつつできるポジションといった感じでした。

スクラム開発は書籍などで簡単に理解はしていたものの、スクラムマスターって何するのか、スプリントってどんなイベントがあるのか体感としてわかっていない状態で、後輩のスクラムマスターの動きをみながら、チームをみながら学びつつ、徐々に理解を深めていきました。

結果として、チームワークを重視し、コミュニュケーションをこまめにとりながら進めていく開発スタイルって面白いなと思いました。

実は、最初は全員で会話する時間が多すぎて、時短で働く私にとっては厳しいスタイルだななんて思っていたこともありました。しかし、いくつかのチームでの経験を経て、今では困ったことがあれば仲間に相談しながら、頼りながら、集まったメンバーで最高の成果を目指していくスタイルに心地よさを感じています。

自分のライフスタイルと合致した

スクラム開発がどんどん好きなったのは自分のライフスタイルと合致したからだと思います。

ウォーターフォール開発で納期に合わせて不具合があっても残業でどうにか間に合わせるというシステム開発のあるあるに対して、この働き方はずっとできないなと思っていました。

システムへの興味はあるものの、働き方が続けるのが難しい・・・。今後どうしようかなと思い、転職サイトを眺めたりしていました。
システム開発は多くの人が協力しあって作るものなので、人が動いている限り日々何かが起こります。何か課題や追加機能開発が発生した時に、うまく調整できればいいけど末端のメンバーは大体残業することで帳尻を合わせにいきます。

残業は、家庭時間や自分時間が減ります。たまにはいいし、自分の興味ややりたいのための残業ならいいけれど、計画されたスケジュールの遅延状況をどうにかするため帰ろうにも帰れない（言い出しにくい）状況は、辛いです。

一生懸命仕事しているけど、スケジュール遅延に謝罪し、家族にごめんねといい、心すり減る働き方ってもやもや募りますよね。

自分のライフスタイルは大事にしていきたい、けど人とのモノづくりは楽しい。
（この仕事でこの２つの考えが矛盾してるのかもしれないと思っていた）

そんな中、スクラム開発（アジャイル開発）に触れ合う中で「残業でカバーしても走り続けられない、開発者に無理をし続けさせてて品質がよいものはできない。結果として長期的には残業せずに回すことが大事」「チームで成果を出す」といった考えに出会いました。

えっそれでもいいですか？

正直思いました。残業して、苦しいんだものが、結果を得られる的な考え方が根底にあったのかもしれません。自分で受け持ったタスクは自分がやるべきという考えもありました。これでやれるのだろうかと疑心暗鬼も多少あったものの、今では新しい考えが自分の中で浸透しています。

そんな今ではスクラム開発の目指すところや手法がとても好きなのですが、ウォーターフォール開発であっても結局同じであって、逆にウォータフォール開発での手法の良さもあったりして、違いを見比べつつ、でも抑えるべき根っこは変わらないんだなと感じてます。

ここではどちらの開発手法であっても抑えるべきポイントだと思う３点について、違いも交えながら書きたいと思います。

１.人に注目する

目が見えないものを人が集まって作り上げていくシステム開発は、人に注目することが大事だなととても感じています。
人の心の動きを無視すると、途端に炎上の小さな火種ができていて、炎上プロジェクトは小さな火種の積み重ねであることが多いです。

会話がしづらく、質問しづらくて、タスクを進めてみたものの最終レビューしてもらったところやり直しになってしまった
要件変更の意図が分からないけど、やれって言われたので、ここだけやっとこう
発熱してるけど、スケジュール遅れているし休めない。でも頭回らないな
あいつが悪いから、自分のせいじゃない
なんのためにやっているか分からない
言っても理解してもらえないし、言わないでおこう

辛いという身体状況で休むに休めず、とりあえず勤務するという状況は、仲間にそれを言えない何かがあります。
やるべきことがわからなかったり、意図が理解できなかったり、言うことをやめたり、
コミュニュケーションのすれ違い、気持ちすれ違いの積み重ねによって、火種は起こっています。

スクラム開発（アジャイル開発）では、デイリーでのアイスブレイクや、振り返りなど自分の思ったことや考えを発言する機会が多くあります。また、インセプションデッキを最初に作りますが、プロジェクトの参加者全員が会話をして、なぜやるのか、何を大事にするのか、何をやらないのかを腹落ちさせつつ、主体的に行動するが求められます。インセプションデッキの項目には、「やらないことは何か」「何が怖いか」といった項目もあり、立場や考えを共有します。個人との対話を大事にし、協調していくことを大事にする仕組みがあります。

ただ、これはウォーターフォール開発でも、うまくいっているプロジェクトでは、プロジェクトマネージャーを中心に、スコープ管理やリスク管理し、なぜやるのかを伝え、認識齟齬があれば会話を埋めながら、みんなが心動くコミュニュケーションを実践しています。考えを引き出す問いを投げたり、さまざま工夫してみなさん実践していますが、私の感覚では、プロジェクトマネージャー個人がそれぞれで実践しており、スクラム開発のようにみんなが主体的にやれる仕組みはあまりないように感じています。そして、プロジェクトが忙しいときにはこの人とのコミュニュケーションの優先度を下げがちだなと思います。

人に注目して、人のやる気を引き出しつつ、人を大事にしつつ進めること。　とても大事だなと感じています。

2.トレードオフ

スクラム開発（アジャイル開発）では、トレードオフスライダーを使って、スコープ、予算、納期、品質の優先度を設定します。それぞれの軸に対して、全て優先度高とは設定できず、どれかを選択するには、どれかの優先度を下げざる得ないようにつくられています。

ただ、スクラム開発であっても、優先度はある程度の幅の範囲での優先度というのが現実です。

スコープ：トレードオフではあるけど、ここまでの機能は必須でほしい、そして出来ればこれも欲しい
予算：費用のお財布は大体決まっている。ある程度のリスク費は確保しているものの、これ以上は追加予算の調整は難しい
納期：ターゲットリリース月に対して、遅れてもｘｘヶ月程度で納めてほしい
品質：それなりに稼働する品質は必要。

そう、企業のシステム開発であれば、物事をやるには、予算承認をとり、やることを説明して経営層との合意を取って、各関係者と調整して進めるので、ある程度の範囲でのトレードオフはしていくものの、ある程度の範囲以上は許容難しいです。経営がアジャイルでの経営判断を真に実践していれば別かもしれませんが…。その点現状との歪みがあると感じています。

このように、スクラム開発でもある程度のところ守る必要があると述べましたが、
ウォーターフォール開発についても、トレードオフスライダーの概念もしっかり持つ必要があります。
何かを優先させる場合、何かの優先度を下げたり調整が必要になってきます。

ウォーターフォール開発では、スケジュール修正ってなかなか柔軟にはしづらく、日々の小さな変更や調整が反映されず、たとえば元々想定していたタスク以上の内容を同じ期間で実施せねばということにもなりがちです。

今何が変更されて、何を優先すべきか、やることやらないことを常に判断していくことが大事です。
これ、実際に実践するのは、実はめちゃ難しくはあるのですが・・・笑

この優先度は、状況に応じて常に変わっていくので、今どう状況にあって、どう考えていくのか、よく状況を俯瞰し、絶えず会話していくことが大事だと考えています。

3.可視化する

あれもこれもやることが増えている、チームの進捗状態が悪いが気がする　といったなんとなく感じる違和感や直感あると思います。その違和感や直感、大体間違っておらず何かが起こっていると思うのですが、それが、文章や数字になっていないと、なかなか周りに伝わりません。

何が問題で何をすべきがみんなが共通の認識を持てる情報がそろっていること。そして誰でもその情報にアクセスできることは重要だと思います。一人一人が主体的な行動をするには、情報がオープンに誰でも同じ情報を持っている必要があります。チーム外の人からのアドバイスをもらうには、気軽に情報をのぞいてコメントもらえるネタが必要です。

マネージャーだけが、リーダーだけが情報をもっており、一部のメンバーだけが会話している内容が分からないであったり、メンバーはリーダーの判断を仰がないと決めることができない場合、動きは停滞します。

そのための仕組みとして、最近活用しているJIRA、Cofluenceはかなり有用なコミュニュケーションツールだなと感じています。ぜひこのツールの良さは別途話したいなと思うのですが、エクセルで情報を管理することには限界があるなと思っており、違いを伝えていきたいと思っています。

おわりに

この記事では、ウォーターフォール開発とスクラム開発の両方の手法を通じて学んだ、共通する点とその違いについてお話ししました。どちらの開発手法を選ぶにしても、人を大切にし、状況に応じたトレードオフの判断を行い、情報を可視化することが、プロジェクト成功の鍵となることを改めて実感しています。これからのプロジェクトにおいても、手法にこだわりすぎることなく、チームの強みや状況に合わせた柔軟なアプローチを心掛けていきたいと思います。

そして、こちらのQiitaでの投稿では、システム開発の現場で思うことに対して言語化をしていっているのですが、これらのポイントや仕組みはシステム開発以外の現場でも転用できるものだと思っています。ここらへんうまく伝えられるようになるといいなと思いつつ、言語化の鍛錬中です。。。

最後までお読みいただきありがとうございました。皆さんのプロジェクトにも少しでも役立つ情報があれば幸いです。