SE目線でないアジャイル開発(1)

謎の題名であるw

私は現在、主にモバイルのアプリケーション開発を主事業とするスタートアップ企業にてバックオフィスを担当している。

※両者の概要と詳細はこちらより引用↓↓

アジャイル開発とウォーターフォール開発のポイント比較8つ｜メリットなども紹介 – IT業界、エンジニア、就活生、第二新卒、転職者、20代向け情報サイト

さすが元々SEの不満から生まれてきた開発方法だけあって、早い、柔軟性がある、ニーズを組み込みやすいといいとこどりである。SE目線から見ると、面倒なドキュメントも作らなくてよくて、とりあえず動くものを早くつくってバグ確認してどんどん進められる、というメリットが大きいやり方なのだろう、評価されるのも納得。

そしてSEではない私が関わっているのが、承認系のプロセスやapp内のモニタリングのプロセスの構築である。(その後appに実装)

私の知っているアジャイルはどう動くかのプロセスを簡単にべた書きしたものを下地に、直感的にUI（ユーザーインターフェース）を作画し、小さいモジュールを早くたくさんつくっていく。そのため、1週間前にはなかったプロセスがいきなり追加されてきて、このモニタリングどうしましょうか、と前触れもなく問われるわけである。

こちらとしては全体像を決めないままに作り始めている中で、モジュール間での関係性もわからず（というか最終的に上がってくるコンテンツすら決まっていないだろ、とw）、全体を俯瞰できる状態になってから初めて、どうモニターするかを考えられるという立ち位置である。

そう、ビジネスプロセス自体をappを作りながら考えているような状態なので、アジャイルが一通り終わってからでないとそもそも着手できないような性質のものである。

想像してみて欲しいが、ウォーターフォールの場合は設計段階できちんとシステムの全体像、コンテンツも決まり、モジュール間での取り回しも決まる。その中でもちろん承認系やモニタリングの手法、構造もきちんと検討する時間がある。ウォーターフォール型開発の中で途中で設計変更があれば大変だ、と言われているが、どこをどのように変えればいいかを遡ってロジカルに追加となる工数が算出できる、というのはそれはそれで価値があるように思う。少なくとも私の担当するパートは、「動けばいい」という代物ではないので、逆算できる開発計画がとても安心できる。

ここからは主観全開となるが、

・上述の理由から私のパートは最終盤の開発アイテムの一つとなるが、満足に考える時間もない

・開発終盤になっているためなぜかこちらが焦らされる

・動けばいい、バグ出し⇒直せばいい、異例ケースは考慮せず後から考えよう、設計資料はないけど動くからいいよね、バグの原因究明？もう直したからいいでしょ、で他箇所への潜在的な影響等も不明、次のスプリントで直しまーす(ﾃﾍﾍﾟﾛ)　　etc..

・ようはSEのSEによるSEのための開発手法で、彼らは気持ちよく開発できるかもしれないが、そのあおりを受けている、という感覚がある

ネットサーフィンにてアジャイル開発に対して私と同じような意見や感覚のソースを探したが見つからず…どうやら私のような特殊な経験をしている人は少数派であるようだ。

ただ素人ながら一定以上の規模の開発でモジュールの数が多く、その裏で2重3重で動くロジックが多いものはアジャイルよりもウォーターフォールが向いているのではないか、と感じている。

業界内ではウォーターフォール型で開発された古いシステムは皮肉を込めて"レガシー"と呼ばれるらしい。私がウォーターフォール型に少しでも価値を感じるということは、考え方が古いのだろうか、あるいは対象が部分的すぎてアジャイル全体のメリットが見えていないのだろうか、それとも少数意見すぎるのだろうか。。。

この内容を肴に違うことを書きたかったのですが、思わず色々吐き出して尺を取ってしまいました。続きはまた次回…