きこえない開発者にとってのウォーターフォール開発とアジャイル開発とは（前編）

こんにちは。まみねこです。

プログラマー時代とエンジニア時代それぞれで色々なことがあったのでそれを中心に書いてみようかなと思っています。
（年末年始は仕事もプライベートもどちらも多忙で、アドベントカレンダー遅れてしまいました。申し訳ありません・・・。）

ここでは、私が今まで経験してきた開発（ウォーターフォール開発）と、今後の開発（アジャイル開発）について色々と思ったことなどをつらつらと書いていきます。
※業務でのアジャイル開発の経験は厳密に言えば、まだありません。「モドキ」「それっぽい感じ」のだけはあります。


## プログラマー時代

新卒時代はプログラマーでの採用でした。
実はプログラマーに関する知識は全くなく、でも単純にパソコンで何かを作る仕事がしたい、と思ったのでプログラマーにチャレンジしました。今思えばすごく無謀なチャレンジだったと思います。
何も知識がない状態でいわゆる専門職に応募してしまったので・・。

そして、今話したら驚く人は多いかもしれませんが、その当時は「エンジニア」という概念はあまりなかったのです。
むしろ「エンジニア」といえば車の設計とか電気工事とかそんなイメージの方が強い時代でした。
なので求人も今で言うIT企業の「エンジニア」という募集はなく「プログラマー」という募集が多かったですね。

で、プログラマーとして転職して、当時プログラミングの世界はVBがメインだったのでもちろんVBプログラマーになりました。

そして客先⇒上司がヒアリングしてまとめる⇒上司から私に説明⇒私が設計・コーディング・テスト⇒上司に確認依頼⇒上司が客先に納品

という流れでやっていました。
当時、上司もプログラマーだったのでとてもやりやすかったです。

そしてその状態で数年が経ちました。

そして私はふと思うわけです。

「上流工程もやってみたい！」

上流工程というのは、今まで上司がやっていたようなことですね。
お客様と交渉して色々と一緒に考えながらお客様の要望をイメージ化するっていう部分です。
それを自分もやってみたい！！と思ったのです。

そして上司に話してみました。

そしたら「外部の人に対してだと、相手から一番先に、耳が聞こえないことへの理解を得る必要があるからそこが大変だと思う。だが、社内だと部署同士で私から説明するなどサポートできるからいいかもしれない」と言ってもらいました。

そしてまずは今取り掛かっている案件で相手先（＝同じ会社の他の部署の人）に上司から話してくれて、相手からも理解を得られたので、そこからは自分が直接相手先と連絡を取って話せるようになりました。

ちなみに、当時はまだメールより電話中心だったので、何か連絡がある時は上司を通して電話で話してもらったり、相手に直接部署に来てもらってやり取りしたり、また私から相手の部署に出向かってお話をすることもありました。
会話は筆談・ＰＣ内のメモ帳アプリを使っての文字やり取りです。

そうして上司のサポートもあり少しずつ上流工程の経験を積んでいきました。
これはとてもラッキーなことでした。理解ある上司と周囲の方々に恵まれたのだと思っています。

それから5年ぐらいして転職。転職先では今までとは畑が違うデザイナーのバイトをしていました。

その頃から徐々に「エンジニア」という言葉が出てくるようになりました。
それでもまだエンジニアというのは機械工学や電子回路設計みたいなイメージがまだ強かったです。

そしてこのころに<b>「ウォーターフォール開発」</b>という言葉を知りました。

## ウォーターフォール開発とは

ウォーターフォール開発・・・「水のように上から下へ流れるイメージ」「滝」としてよく言われていますね。
それも間違いではないのですが、私個人の今までの経験から捉えた解釈としては、

①要件定義
②基本設計
③詳細設計
④システム実装・テスト
⑤単体テスト
⑥システムテスト
⑦リリース

これが一般的な流れですが、
⑤の単体テストの時点で②基本設計の修正・追記をすることもあるし、⑥のシステムテストで③の詳細設計・追記をすることもあります。

そのため、厳密に言えば「上から下へ」「滝」のイメージではなく、結局はどこかしら絡み合っているというイメージかなと思っています。

ただ、１つ１つの作業をきっちり済ませないと次のステップには進まないという意味では、「ワンステップ開発」と言ってもいいのではないかな・・・と私は解釈しています。

そして、私が考えるこのウォーターフォール開発の良い点は、１つ１つのステップごとに抜けがないように調べながら開発すること。
それによって１つ１つお客様に確認しながら開発を進めることができるため、「手戻りが少なく抑えられる」ことだと思っています。


## それから更に数年後

そして５年ぐらい前からアジャイル開発というワードをちらほら聞くようになりました。

### アジャイル開発とは

アジャイル開発は近年特に知られてきているようになっていますが、実は20数年ぐらい前に考え出された開発の考え方です。

アジャイルソフトウェア宣言⇒[https://agilemanifesto.org/iso/ja/manifesto.html](https://agilemanifesto.org/iso/ja/manifesto.html)

引用
>プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

要は、「「個人（お客様）との対話をしながら計画通りにすることよりもその時その時のお客様からの要求に答えながら開発を繰り返していく」というイメージです。（間違っていたらすみません）

ちなみにこの「アジャイルソフトウェア宣言」はこちらに詳細が書かれています。
こちらも合わせて確認すると良いかと思います。

IPA情報処理推進機構　ーアジャイル領域へのスキル変革の指針ー
アジャイルソフトウェア開発宣言の読みとき方（PDF）⇒[https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf](https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf)


このPDFの解釈によると、以下の通りとなっています。（いくつか抜粋）

### アジャイル開発の原則

1. 顧客の満足を求め続ける⇒「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供します」

1. 要求の本質を見抜き、変更を前向きに⇒「変更の要求は例え開発の後期であっても歓迎します」

1. 成果物を2－3週間でリリースし続ける⇒「動くソフトウェアを、2－3週間から2－3カ月というできるだけ短い時間間隔でリリースします」

1. 全員で共通の目標に向かおう⇒「ビジネス側の人間と開発者は、プロジェクトを通して日々一緒に働かねばなりません」

・・等。（他にも全部で１２の原則があります）


しかしその頃はまだ開発畑に戻っていなかったので、アジャイル開発について考えることはありませんでした。

## 再就職して思ったこと

その後、また開発畑に戻ることになりました。
その当時思ったことは、「エンジニアの障害者求人が増えたな」ということ。
一昔前は「プログラマーでの求人」だったのに今は「エンジニアでの求人」が多数を占めていました。

もう一つ
、「エンジニアとプログラマーの違いをきちんと分かっている人はいるのか？」ということ。
私はプログラマー全盛期の時からの人間なので、ちょっと違和感が色々とありました。

### エンジニアとプログラマーの違い（個人的所感）

※ここからは私個人が思ったことを書きます。一般的に見れば間違っているかもしれないけど。

まず、プログラマーが下、エンジニアが上、エンジニアの方がかっこいい！というイメージに違和感があります。
本来はエンジニアはあくまでも設計（コードは書くけどプログラマーと比べたらそこまではできないということが多い）、プログラマーはコード開発という分け方だったのですが、今はそれがごっちゃになっているような・・・。

そして、プログラマーの方がコード開発の知識がダントツにあるのに、「エンジニアの方が上」という見方があったのもなんか違うな・・と思っていました。

実際はコード開発の知識があるのはプログラマーの方です。

ですが、今はコード開発も設計も全部ひっくるめて「エンジニア」という言い方になってきているので、まぁ、それならよいのかな？とは思っています。

ですが、「このほうがかっこいい」「このほうが上」という考え方はなんかもやッとしてしまいます。
本来はエンジニアもプログラマーもどちらもなくてはならないもので、どっちかが良い、悪いという次元ではないと思っています。

（話が逸れました、戻ります）

## 前編まとめ

長くなったのでここらへんで、続きは後編に託します。