この記事はNTTコムウェア Advent Calendar 2022 25日目の記事です。

はじめに

NTTコムウェアの望月です。
「これからはアジャイルな開発ができるようになるべきだ…！」とその１つであるスクラムを取り入れた開発チームに参画したのはもう何年前か…。
その思想や営みを現場にどんな形で取り入れていくのか？広めていくのか？を考えるようになってからすっかり年月が経ちました。
ここ１、２年は若手社員育成にも携わっている中で強く感じることを書いてみました。

開発手法のトレンド：アジャイル開発と社内の現状

ビジネス環境が次々に変化し、未来を予測することが難しいVUCAの時代。
その不確実性に対処する手段の一つとして、アジャイル開発が注目されるようになりました。

社内でも従来のウォーターフォール開発に加えてアジャイル開発ができる人材を増やすべく、研修や育成施策をどんどん打ち出すと共に、アジャイル開発の知見蓄積・活用の流れが続いています。（※社内ではフレームワークの１つであるスクラムを中心に活用しています）

しかし、実際の開発現場を見ていると、まだまだその本質を正しく理解した上で活用できているところは少ないのではないかと感じます。
その背景として様々な事が考えられますが、誤解を恐れず一言でいえば、開発を依頼する側と開発をする側の間の相互理解不足だと思っています。（そもそもアジャイルってそういう間柄じゃないよねって話はもちろんありますが…）
つまり、お互いにアジャイル開発というものを都合良く解釈しすぎているということです。
忘れてはいけない前提を思い出し、相互に理解する努力と変わる努力を続ける必要があることを認識して初めて、この問題は解決に向かうのではないかと考えています。

忘れちゃいけない前提１：要求・要望の整理と定義

モノ作りの背景には必ず潜在的、あるいは顕在化した要求・要望があります。
これを正しく理解し、共有することでモノ作りは前に進みます。

この要求・要望には、ユーザーにとってわかりやすい機能要求と、ユーザー自身が認知しにくい非機能要求に大別されます。
アジャイルソフトウェア開発宣言にある「包括的なドキュメントよりも動くソフトウェアを」を重視して後者の実現に向けた営みの優先度を下げる場合もあるとは思いますが、あくまで優先度を下げるのであって、その要求・要望について明確にしない（あるいは議論を後回しにする）ということであってはならないはずです。

開発を担う側としては、機能要求だけでなく非機能要求についても考慮が必要であることをしっかりお伝えすると共に、要求を要件として定義し、都度、実現する範囲を明確にするための努力が必要です。

開発を依頼する側としても、いわゆる当たり前品質（≒非機能要求）の実現にも稼働が必要であることを認識した上で、開発者としっかりコミュニケーションする努力が必要です。

上記は、開発手法がアジャイル開発かどうかに関わらないことだと思いますし、仮にアジャイル開発を採用しているとしても、コミュニケーションや合意に一定のドキュメント化が必要と思われるなら作るべきです。少なくとも決めたことは明文化したい。

忘れちゃいけない前提２：開発手法の特徴

アジャイル開発（スクラムを想定）の大きな特徴の１つとして、少数精鋭が挙げられます。
少数精鋭が故に、アジャイル開発ではシステムの要件定義から、設計、実装、試験、リリース、運用まで、一貫して考え実行できる、いわゆるフルスタックな人材が求められます。
とはいえ、一人の人間にできることは限られるのでどちらかといえば小規模な開発に向いた開発手法と言われています。

一方で、ウォーターフォール開発は主に大規模な開発に向いている手法だと言われており、多くの人が開発に関与する場合が多いでしょう。
大きな会社である程、その傾向は強くなるのではないかと思いますが、開発の規模が大きければ、開発工程毎にその工程に責任をもって担うチームが存在する場合があり、一部のインフラ系チームを除いて、全工程に一貫して関与する人は少数になりがちです。
少し見方を変えると、ウォーターフォール開発では、特定の工程に対する知見・経験があればよく、必ずしもフルスタックである必要はない。

フルスタックの定義にもよりますが、一般にフルスタックな人材は引く手数多で、相対的に数が少ないと仮定すると、想定される開発規模、要件はもちろん、リソース（人材）状況を考慮して、適切な開発手法を選択する努力が必要でしょう。

アジャイル開発と一言にいっても様々なプラクティスが存在しますし、いわゆる ”Be Agile” を目指した取り組みであれば、どんな手法を採用していてもそれはアジャイル開発といっても良いのではないでしょうか。

忘れちゃいけない前提３：計画・目標の達成

前提１の内容に近い話ではありますが、大事なことなので…。

アジャイル開発ではスプリント単位で取り組むバックログを決めるわけですが、スプリント期間中にやり切れなかったものは次のスプリントに回す…といったことが行われるかと思います。

これ、単に次のスプリントに回しちゃってませんか？

アジャイル開発は、決められたもの（開発範囲）を決められた時期（期日）までにやりきるための手法ではない、というのは確かにその通りです。
が、「できなかったから後ろに回せば良い」、「次はバックログを減らせば良い」なんて考え方になっているとすればそれはアジャイルではないでしょう。

もっと効率的なやり方を模索・改善（ベロシティを上げる工夫）して取り返す。
どうしても困難を極める場合は、計画・目標の変更を相談する。
これが基本路線のはずです。

開発者は上記のような努力を怠らないことを前提として、それをサポートするための各種フレームワークやプラクティスがアジャイル開発の手法として定義されているのではないでしょうか。

上記の努力をする上では、開発をチームに依頼する側としても、開発チームの努力を知った上で、共に改善を考えるスタンスは必要…ということも念のため書き加えておきます…。

まとめ

トレンドということで「とりあえずアジャイル開発だ！」と本質を考えずに形から入ろうとする、いわゆる "Do Agile" な場面をチラチラと見かけることがあったので、今一度、基本に立ち返り、本質を理解することも大事だということが伝われば良いなと思い、今回この記事を書かせていただきました。

アジャイル開発はどうしてもフルスタックであることが求められてしまいますが、逆に言うとそれは実践してみるとフルスタックを目指す上で足りないことを認識できる手法でもあるということかなと。このように考えると、育成ツールとしてアジャイル開発を活用するのは有効だなぁと改めて感じる今日この頃です。

最後に、参考程度にアジャイル開発が育成に有効だと考えるポイントを挙げて終わりにしたいと思います。ここまで読んでいただいた方、ありがとうございました。
少しでも何かを変える原動力に繋がれば幸甚です。

#### 参考：アジャイル開発が育成に有効だと考えるポイント
- 小規模な開発に向いた手法であるためプロダクトの全体像が把握しやすい
- 各メンバーが担うタスクの幅が広い（インフラ、アプリ、運用と分野を問わない）
- チーム内外のコミュニケーションが鍵となるのでコミュ力を磨ける
- 開発者自身の意見をプロダクトに取り入れやすいのでモチベーションが続きやすい