初めまして。GuuGuuGuu（グーグーグー）です。
40代のおっさんです。
3回ほど転職を繰り返しながら10年ぐらいプログラマー・エンジニアを続けております。
で。おっさんはオギャーしてからずっと聞こえないのです。
そんなおっさん、ウォーターフォール時代とアジャイル時代を経験しており、その中でも今はアジャイルが主流（というよりも人気？）ということで、それを中心に書いてみようかなと思っています。
まず前提としてウォーターフォールの説明をします。
ウォーターフォール開発とは
ウォーターフォール開発・・・「水のように上から下へ流れるイメージ」「滝」としてよく言われていますね。
それも間違いではないのですが、おっさんの解釈としては、
①要件定義
②基本設計
③詳細設計
④システム実装・テスト
⑤単体テスト
⑥システムテスト
⑦リリース
これが一般的な流れですが、
⑤の単体テストの時点で②基本設計の修正・追記をすることもあるし、⑥のシステムテストで③の詳細設計・追記をすることもあります。
そのため、厳密に言えば「上から下へ」「滝」のイメージではなく、結局はどこかしら絡み合っているというイメージかなと思っています。
ただ、１つ１つの作業をきっちり済ませないと次のステップには進まないという意味では、「ワンステップ開発」と言ってもいいのではないかな・・・とおっさんは解釈しています。
でもアジャイル開発ではない。
で、このウォーターフォール開発の良い点は、１つ１つのステップごとに抜けがないように調べながら開発すること。
それによって１つ１つお客様に確認しながら開発を進めることができるため、「手戻りが少なく抑えられる」ことだと思っています。
アジャイル開発とは
アジャイル開発は近年特に知られてきているようになっていますが、実は20数年ぐらい前に考え出された開発の考え方です。
アジャイルソフトウェア宣言⇒https://agilemanifesto.org/iso/ja/manifesto.html
引用
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
要は、「個人（お客様）との対話をしながら計画通りにすることよりも、その時その時のお客様からの要求に答えながら開発を繰り返していく」というイメージです。
ちなみにこの「アジャイルソフトウェア宣言」は、ただのスローガンではなく、アジャイル開発の“根っこ”にある考え方です。
最初の4行だけを見ると軽いイメージを持ってしまう人も多いのですが、本来はもっと深くて、12個の原則がセットで語られています。
その12原則を読み解いたのが、IPAの「アジャイル開発宣言の読みとき方」（PDF）で、
そこには「顧客満足」「変更歓迎」「短期間でのリリース」「共通の目標」「継続的な改善」などが丁寧に書かれています。
これらを読むと分かるのですが、
アジャイル開発とは本来「早く作ること」ではなく、
・顧客との信頼関係
・チームのコミュニケーション
・価値のある成果を小さく作り続ける文化
・変化を前向きに捉える姿勢
・人と協力して進める習慣
など、人間同士の関係構築の方がむしろ大事なんです。
……なのですが。
おっさんが転職した先の現場では、
この「アジャイルの本質」があまり理解されないまま導入されていました。
「アジャイル＝速い」
「アジャイル＝ドキュメント作らなくていい」
「アジャイル＝とりあえず会話すればいい」
「アジャイル＝何度も直してOK」
みたいな【誤解されがちなアジャイル】が横行していました。
そして当然ながら、こういう環境に 耳が聴こえないおっさんが入っていくと、色んな歪みや困難が一気に噴き出します。
ここからは、おっさんが実際にアジャイル開発の現場に入って、「聞こえない立場だと何が起きるのか」「どんな困りごとが発生するのか」「どうすればうまくいくのか」を正直に書いてみたいと思います。
つづく・・・