こんにちは。システムズエンジニアリングセンター(SEC)の五十嵐です。
昨今「DX を推進するため開発手法はすべてアジャイル開発をするべきだ！」
と言わんばかりの勢いでアジャイル開発は会社でも世間でも推されています。
そんなアジャイル開発を、研修が終わったばかりの新人や若手が入っても
上手く馴染んでやっていけるのか、それとも初めはアジャイル開発は避けた方がいいのか、
何か工夫をしないといけないのか、、、
若手からの視点で、アジャイル開発を若手にも勧めることができるのか、
ということについて記事にしようと思います。
まず、クレスコでは若手の期間に、様々な部署にアサインされる SEC という部署に所属します。
その部署に所属する期間が 3 年間なので、私の指す若手は 3 年目までとします。
私は研修が終わってから今まで 3 業界経験しました。
その中のどのプロジェクトでもそれぞれの作業に開始日や期間などの
詳細なスケジュールが引いてある、いわゆるウォーターフォール開発のプロジェクトばかりでした。
そんな中、ローテーション制度によって、アサイン先の部署が変更となりました。
新しいアサイン先での新しいプロジェクトでは、機能単位で設計から開発・テストまでを行い、
それを何度も繰り返していく、いわゆるアジャイル開発というものでした。
アジャイル開発について詳しくなかった私は、オンライン学習サービスでアジャイル開発について以下のようなことを学びました。
- アジャイル開発の中には更にいくつかの手法があるということ
- アジャイル開発にも向いていないことがあるということ
- スプリントという特定の開発の期間を指す言葉があるということ
ウォーターフォール開発では基本的にそれぞれの工程の作業に集中しています。
また、次の工程に進んだら基本的に前の工程に戻ることはありませんでした。
そして、次の工程に進むのはその工程での全ての機能の作業を完了させてからでした。
アジャイル開発では各々のメンバーが、機能ごとに設計からテストまでの工程を行っています。
なので、メンバーごとに作業している工程にばらつきがありました。
1 機能ごとに全ての工程を行うので、テスト工程まで進んでも次の機能の開発に着手し始めたら、
また設計から始まりました。
プロジェクトではアジャイル開発のスクラムといった手法を用いた開発でした。
スクラムではスプリントという固定の短い期間に区切り、
それを繰り返していくことで開発を行います。
スプリントを始める前に、そのスプリント中に何をどれだけ作成するのかといった、
スプリントプランニングと呼ばれる計画を毎回立てます。
新しいプロジェクトにアサインしたことにより、
私はアジャイル開発とウォーターフォール開発の両方を体験することができました。
新しいプロジェクトはアジャイル開発ということもあり、
上手くゴールが把握できないのと知らない言語であったため、
作業の進め方に慣れるのに苦労し、中々仕様やコードの理解が進まなかった印象です。
私は、若手はウォーターフォール開発からが良いと思います。
なぜそのように思ったのか、その背景は以下の3つです。
- ウォーターフォール開発だとそれぞれの工程に集中できる
- チームメンバーも同じ工程のため人材育成がしやすい
- アジャイル開発を行う上でのメンバー体制
以下で 3 項目について説明したいと思います。
まず、ウォーターフォール開発では各工程での期間が長いので、仕様、作業内容等の開発の
基礎の定着がしやすいです。
例えば、若手(特に新人)は各工程での作業など開発の基礎がよく分かっていないでしょう。
そこで、若手が新しく参画してきた際には以下のような対応をすると思います。
- 仕様や作業内容を説明。
- 作業を通しての開発でのイロハなど。
- 説明できなかった箇所は、その場合その場合で確認、対応。
1 工程内での作業が続くので、その工程内でそれぞれの作業を十分なほど繰り返すことができます。
仕様や作業内容に関して定着しやすく理解も深まりやすいでしょう。
そのため、開発の基礎を十分に身につけることができると思われます。
しかし、アジャイル開発では設計から開発、テスト、リリースまで短いスパンで進めていきます。
そうするとそれぞれの工程について、何をするのか、どの様にするのか等の説明されるも
不十分な理解のままになってしまうことも、、、
いきなりそんなに大量の情報が入ってきてしまえば混乱してしまいます。
アジャイル開発を行った場合を想定してみます。
- 若手に開発の仕様やその他 etc..を説明をする
- 作業する(理解できていない部分あり)
- 次の開発工程でまた説明を受ける
：
- 1.の開発工程に戻ってくる
1 の工程に戻ってきた際に、あの作業はどうなっているんだっけ？
あれってあの工程のことだったような？この場合だと状況違う⁈
といった理解できていない部分に加え、他の工程を通して抜けてしまいます。
作業内容の定着がしづらく、基礎が固まる前に次の工程の作業となってしまいます。
そのため、スムーズに進められない期間が長くなってしまいます。
ウォーターフォール開発の方がアジャイル開発よりも、
新しく入ってきた若手へ指導がしやすく、 若手も先輩への質問がしやすいです。
例えば、アジャイル開発では各々でタスクごとにサイクルを回しています。
なので、A さんは今 UT、B さんはコーディング中、C さんは、、と人によって状況は様々です。
質問する側もされる側どちらの状況も工程も違います。
その中では質問する側は説明力がより一層求められ、
質問をされる側は汲み取る力がより一層求められると思います。
それに比べてウォーターフォール開発では A さんも B さんも C さんも同じ工程です。
質問しやすく、された側も答えやすい。
同じ工程のため同様な作業を通して見本を見せるなど若手への指導もしやすく、
アドバイスや問題点の共有もしやすくなります。
アジャイル開発では同じくらいの技術力の人たちで、チームが構成されていると良いとされます。
それは、開発を効率よく進めるようにするためです。技術領域で作業分担をせずに、それぞれが柔軟に様々な作業を行えるようにします。
しかし、若手が入ってくるということは、チームの技術力に偏りが発生します。
まず、若手に他メンバーと同じように作業を回すことができないでしょう。
なので、特定の誰かとは言わないにしても、作業に偏りができます。
そして、メンバーと若手の技術力の差からプランニングでは想定していなかった作業時間の差が発生してしまうことでしょう。
3 つをまとめた話として Minecraft の開発者であるヘンリック・ニバーグ（Henrik Kniberg）氏が描いた、アジャイル開発とウォーターフォール開発を比較する有名な例えの画像を引き合いに出したいと思います。
アジャイル開発を使用したビジネスの進め方を分かりやすく表現していると思います。
アジャイル開発では顧客のフィードバックを得るために、
初めの小さなリリースでも「走る・止まる・曲がる」の機能を提供する必要があります。
メンバーはそれに向け各々が機能を実装し、テストまで一貫して行います。
その点、ウォーターフォール開発では最後のリリースで車を提供します。
それまでに設計書を元に皆で車体を作っていき、
完成したら実際に運転して適切に動くか確かめているが近いと思います。
なので、最初の内は車は動いてなくても大丈夫ですし、
メンバー全員が車の免許を持っていなくても大丈夫です。
アジャイル開発では初めから動くものである必要があり、メンバーは運転もできないといけない。
こう考えると最初からアジャイル開発は大変そうだなと思いますよね。
でも、メンバー全員が初めからすべてできるなら、
アジャイル開発の方がより求めているものを作れそうですね。
以上より私は、若手はウォーターフォール開発からが良いと思います。
特に研修が終わったばかりの 1 年目には、ウォーターフォール開発を通して各工程の作業の理解を深めて、開発の基礎を先に学んだ方が良いと思います。
私は若手がアジャイル開発を取り組んでいくなら、以下の 3 つの様なことができる人だと思います。
- 顧客からの要求や仕様を把握して、タスク内容を具体的に想定できる
- コーディングする言語に知見があり、CD/UT が独力でできる
- 自らの作業の見積もりを立てることができ、その計画通りにタスクを行える
上記に関して十分でなくても若手にアジャイル開発を取り組ませるなら、
チームとして以下を協力し改善して進めていけば、アジャイル開発に移っても問題ないと思います。
アジャイル開発では個人ごとに役割があり、タスクをこなしていきます。
なので、仕様やタスク内容をウォーターフォール開発より把握している必要があります。
アジャイル開発は仕様変更に柔軟に対応できるとあるように、
ウォーターフォール開発の様に開始時点で全ての要件定義をしたりしません。
顧客からあのようにしたい、このようにしたいと要望があり、それを元にタスクを作成します。
また、設計書がない場合もアジャイル開発では多々あるでしょう。
若手ではそのタスクのゴールがどこであるのか、それまでのプロセスはどういったものなのか分かりづらいでしょう。
なので、そのタスクのゴールを明確にし、共有することでチームでの認識齟齬が無いようにします。
そして、どのようなプロセスを通してそのタスクを進めていくのか明確に伝えましょう。
アジャイル開発ではウォーターフォール開発に比べて、コーディングする言語に知見があり、CD/UT が独力でできる必要があります。
1 つ前でも書いた通りアジャイル開発では設計書がない場合が多々あるでしょう。
設計書を元に似たような動作をしている所からコードを引っ張ってくることもできません。
それなら、コードに書いてあるコメントを頼りにすればいいのではないか、
と思う人もいるかもしれません。コメントも期待できるほど書いていないと思われます。
なので、ウォーターフォール開発に比べると知見がない場合にとてもハードルが高いのです。
そこで、ペアプログラミング行い画面を見せ合いながら作業を行います。若手は有識者から処理の流れや仕様、言語について開発を進めていきながら学びます。
また、知識やアドバイスをもらうことで、若手では思いつかないようなロジックの実装などを学ぶこともできるでしょう。
結果として、知識や仕様の理解に加えて、若手のコーディング能力の向上も見込めます。
アジャイル開発ではスプリントプランニングを行い、
そのスプリント内でどれだけのタスクを消化していくか計画を立てます。
なので、自らの作業の見積もりを立て、その計画通りにタスクを行える必要があります。
まず、前提としてスプリントは 1 週間を想定します。
作業の見積もりを立てる際にこの作業は何日くらいと薄っすら思い浮かべていませんか？
実際に自分の MTG などの作業のできない時間を抜いて計算してみます。
そうすると、1 日あたり、1 週間あたりの時間は思っているよりもきっと少ないでしょう。
その時間の差が進捗と見積もりの差になる一因と思われます。
私がいたチームでも 1 日を7.5 時間としてでこれくらいならできそうだと、薄っすら決めていました。
しかし、スプリントの終わりに近づいて来ると毎回できずに漏れてしまうタスクがありました。
そんな中、MTG の時間や作業のできない時間を考慮していないから漏れてしまうのではないかと、
ふりかえりで意見が出てきました。
また、どのタスクを誰に振るか決めておき、その担当者に合わせたプランニングをおこないます。
ふりかえりの意見を取り入れ、以下の様に考慮したプランニングをするようにしてみました。
- MTG などの作業のできない時間を抜いて、そのスプリント内で自分の使える時間を把握する。
- タスクを洗い出し、それぞれのタスクに担当者を決め、今までの実績からどれだけかかるか予測を立てる。
- そのタスクの時間についてチームで共通認識を持つ。
- その予想を元に 1 スプリント内の割り当てられる時間に作業を割り当てはめていく。もちろん、何か急な作業が入ってきた、作業が実は難しかった、といった不確定要素に備えてバッファ(約 2 割)は入れておく。
- ふりかえりではプランニングよりも進んだ、遅れたを顧る。
- 次のスプリントではより差が小さくなるようにプランニングをする。
以上を繰り返していった結果、スプリントから漏れるタスクがどんどん減っていき、
最終的にはタスクがスプリントから漏れることなく消化していけるようになりました。
以上より、若手はアジャイル開発からでもできなくはないですが、それぞれの工程に集中でき、
メンバーも同じ工程で人材育成がしやすく、チーム体制にある程度自由のある、
ウォーターフォール開発から参画し開発の基礎を先に学んだ方が良いと私は思います。
しかし、それでもアジャイル開発から行っていく場合は、
上記の 3 つをチームとして取り組んでいき、若手を育てていくことで、
若手でもアジャイル開発を進められると思います。
また、アジャイル開発では短い期間で一通りの開発を行うので、
ウォーターフォール開発と比べて短期間での若手の戦力化を期待できます。
上の示した 3 つの中でも作業の見積もりはウォーターフォール開発でも活用することができます。
アジャイル開発は自分に関係ないと思わずに学んでいくことも大切だと思いました。
