最大手SIer出身者が語るウォーターフォールからアジャイルの会社に転職する時に意識すべきこと
おはようございます。
SUPER STUDIOのCOOの花岡です。
僕がNTTデータという大手SI企業でSEとしてキャリアをスタートしてから約10年になりますが、本当に開発の在り方って劇的なスピードで変わっているなぁと実感します。
僕はSI時代に担当させていただいていた大手金融システムではウォーターフォール型の開発を4年程度経験し、現在はSUPER STUDIOでは法人向けECプラットフォーム「ecforce」をアジャイル型で開発しています。
僕自身、プロジェクトマネジメントのノウハウはファーストキャリアで学んだウォーターフォール型の開発が原点にあったため、アジャイル型に慣れるのに苦労した経験もありますので、そのあたりのリアルな話を公開できればと思います。
ウォーターフォールからアジャイルの開発会社に転職を考えているシステムエンジニアやプログラマーの方々の参考に少しでもなれば幸いです。
いつもどおり、ウォーターフォールからアジャイルに変わる際の意識すべきことのまとめ。
・「詳細な設計書がないとコードがかけません」は通用しない
・工程が曖昧かつ、完全分業が成立しづらい開発体制のためコミュニケーション力（チームワーク）が重要となる
・一度決まったことや、開発の優先度は状況に応じて変わるため、そこでストレスを感じないようにマインドシフトが必要となる
※目的は納品することではなく、より良いものをつくることになるため。
1. ウォーターフォールとアジャイルの違い
ウォーターフォールとアジャイルの違いに関する一般論はググっていただけると幸いです。山程記事が出てくると思います。
ここでは、具体的に現場レベルで何が違うのかについてお話していければと思います。
僕がファーストキャリアで経験したウォーターフォール開発は、予算規模も非常に大きなプロジェクトだったこともあり、”THE”がつくウォーターフォール開発なプロジェクトだったと思います。
また、SUPER STUDIOで行っているアジャイル開発についても、スタートアップ・ベンチャーということもあり、あるべき論というよりは、どこの会社でもあるあるな現場に近い話をしております。
そういったこともあり、わかりやすく表現するために、一部極端な表現を使いますのでそこはご了承ください。
さまざまな観点で比較するとこんな感じかと思います。
①ビジネス
一般論としてウォーターフォールとアジャイルはそれぞれメリット・デメリットがたくさんあると思いますが、そもそもビジネスモデルによって適切な開発手法が異なります。
ウォーターフォール型はシステムを受託開発する多くのSI企業に採用されています。受託開発ですのでお客様の要望を叶えたシステムを開発して納品する必要があるわけなので、「お客様の要望」が途中で変わってしまうと大量の手戻りが発生してしまいます。そのため、要件定義や設計といった各工程ごとにドキュメンテーションして、合意をとっていかなければならないので、ウォーターフォールとの相性が良いというお話です。
一方で、アジャイル型は自社プロダクトをグロースさせていくSaaS等の事業会社に採用されています。事業会社は開発したシステムを納品する必要がなく、お客様のためにより良いプロダクトにしていくことが求められるため、プロダクトが良くなるためなら軌道修正はどんどんすべきなので、アジャイル型との相性が良いというお話です。
成長している事業会社でアジャイル型を採用していない会社を僕は見たことがないです。
※「SIとSaaSの違いと未来」については別記事で語っておりますので興味ある方は見てみてください。
②工程管理
ウォーターフォールは工程管理がしっかりと行われています。
ウォーターフォールはプロジェクト全体の要件定義を１つの要件定義工程で全て実施するため、比較的に１つの工程がアジャイルより長くなります。また、ビジネスのところでも触れた通り、SI企業に採用されていることが多いため工程ごとにドキュメントやソースコード等のアウトプットを納品し、費用を請求するモデルであるため、工程管理はより厳密にせざる得ません。
一方で、アジャイルは機能開発の単位をできるだけコンパクトにし、小さなチームで高速で回していくような運用を取ることになるので、各工程の期間が非常に短くなります。そのため、工程管理というものが曖昧になりがちです。
PMレイヤーで働く方にとって、工程管理は管理業務に直結するためギャップを感じるポイントだと思いますが、プログラマーなどからするとそこまで意識することでもないのかなと思います。
③ドキュメント
ウォーターフォールとアジャイルで全然違うのはドキュメントだと思います。
前述の通り、そもそもウォーターフォールはシステムを受託開発する多くのSI企業が採用している手法になりますので、ドキュメントを納品して工程終了し、費用を請求するという前提があったりします。SIにおいては納品したドキュメントに書いてるか書いていないかがプロジェクトの生命線になるため、炎上しないためにも非常に丁寧に書きます。
そのため、ドキュメントのフォーマットや記述内容の詳細さに加えて、ドキュメントのバージョン管理もソースコードレベルで行われているため、アジャイルと比べて品質面は非常に高いと思います。
一方でアジャイルは、伝わりやすいように極端な表現をあえてしますがWordファイルでつくられたTHE設計書のようなものは存在しません。
開発する上で気をつけるべきことなどのドキュメントはありますが、設計書は基本的に開発するために作成されたチケットになりますし、そこに書かれた背景・要件定義・設計といったものをもとに開発者は開発することになります。
現システムへの理解も、可読性の高いソースコードをそのまま読み解いたり、システムの利用ガイドやFAQなどをみて、動作の正しさを確認したりもします。
④キャリアと給料
キャリアについては次の章でも詳細に触れますが、ウォーターフォールでは膨大な時間をかけて上流工程のPM、場合によっては優秀なエンジニアなど詳細な設計書を作り込みます。そこで仕上がった詳細な設計書を元にプログラマーはコードを書きます。
これだけ聞くと一見、シンプルな分業に見えるのですが、開発している方ならわかると思いますが、設計段階であらゆる影響を読み切り、完璧なものとつくることはかなりの難易度ですし、やろうとすると膨大な工数がかかります。しかし、ウォーターフォールにおいて、設計段階の不備は炎上にもつながってしまうため、品質を高く作る必要があり、開発の難しさはかなり上流工程に寄ってしまいます。
プロジェクトによってはこの設計書のクオリティが過剰に高すぎることがあります。品質が高すぎる設計書だと使うメソッドや引数の指定までされており、僕が北京のオフショア先で経験したプロジェクトでは、未経験のアルバイトでもコードを書けてしまうんじゃないかというものもありました。
こういった流れが昔のSIの現場では行われていたので、上流工程のPMは給料が高めで、下流工程を担当するエンジニアは給料が低めという風習があるんだと思います。
一方でアジャイルでは、ウォーターフォールと比べると比較的、設計書の品質が低いため、プログラマー側も仕様やUI、実装方式などについて考える必要性が必然的に出てきます。
そのため、上流・下流という厳密な境界線がなく、チームで開発していくため上流工程のPMよりもエンジニアのほうが給料水準が高いなんてことが当たり前のようにあります。
もちろん、アジャイルであっても開発要件や設計が詳細にチケットに書かれているべきなのは間違いありませんが、現実、ほとんどのプロジェクトではそうなっていないということです。
2. ウォーターフォールからアジャイルの会社に転職する上での注意点
上記の通り、ウォーターフォールとアジャイルの違いはたくさんあります。
僕も今までたくさんのシステムエンジニアの方が転職相談を受ける中で、必ず聞かれる質問の１つに「ウォーターフォールしか経験していないので、アジャイルで自分が通用するのか心配です」というものがあります。
確かにウォーターフォールからアジャイルの環境に切り替える際に意識改革したほうが良いことはいくつかあるので、それらを紹介したいと思います。
2-1. 「詳細な設計書がないとコードがかけません」は通用しない
ほぼ例外なく設計書の品質はウォーターフォールよりアジャイルのほうが劣るため、コードを書く方は「詳細な設計書がないとコードがかけません」という思考は捨てたほうが良いんじゃないかなと思います。
昨今、アジャイル型の開発手法が増えてきている中で、PMやエンジニアと呼ばれる職種の守備範囲が大きく変わっています。
守備範囲の変化はわかりやすく給料なんかにも反映されているなと思います。（需要と供給のバランスは大前提にありますが。）
従来は上流工程を束ねるPMが詳細な設計書を作り込み、あとはコードを書くだけの状態まで落とし込む仕事をしていたのが、PMは要件定義・基本設計を行い、詳細設計以降はエンジニア側にバトンタッチし、PMとエンジニア/QAが日々コミュニケーションを取ることでアジャイル的にチームで開発するようになっています。
アジャイル開発において、膨大な工数をかけて設計書を作り込んでも、急に仕様を変えたり、戦略的に開発しないと判断してしまうようなケースもあるため、こういった進め方は非常に合理的だと思います。
つまり、優秀なエンジニアとは、ビジネス理解があり、詳細な設計書がなくても、要件を把握しているPMとコミュニケーションを取り、品質の高い機能開発ができることだったりします。
逆にPMのスキルは、PMM（プロダクト・マーケティング・マネジメント）といったようなお客様の要件を集め、マーケットにおける需要を判断してプロダクトに要件定義していくといったマーケティングの要素が求められたりしています。
アジャイルになると、従来のスキルセットよりも、より広いキャリアが求められ反面、それらのスキルを身に着けていけると自身の市場価値もドンドンあげていけると思います。
2-2 分業ではなく工程無視のチームワーク
上記書いたとおり、アジャイルでは役割ごとに分業というよりは、PMとエンジニア/QAが日々コミュニケーションを取ることでアジャイル的にチームで開発するようになっています。
ウォーターフォールでは上流工程で考慮漏れが起きないように設計段階で膨大な時間をかけていましたが、アジャイルではイメージとして設計の完成度を落としてPM・エンジニア・QAなど複数の目で見て、議論していくことで考慮漏れが起きづらいようにしていくため、チームワークの重要性が非常に重要になります。
そのため、PMもエンジニアもQAも開発に関わるメンバーはコミュニケーション力が求められます。
SUPER STUDIOでも意識していることですが、開発の過程で失敗が許容される心理的安全性の高いチームビルディングができるかが非常に重要となります。
2-3. 変わることに対してストレスを感じないマインド
ウォーターフォールとの大きな違いですが、要件そのものが変わったり、開発チケットの優先度が変わったりすることは日常茶飯事です。
なぜならアジャイルを採用している事業会社では、プロダクトを誰かに納品するなんて概念がなく、終わりがありません。とにかく、プロダクトを良くしていくことにコミットしなければなりません。
開発する目的が納品することから、工数など無視でプロダクトを良くしていくことに変わるわけです。
そして、プロダクトは生き物ですので、お客様のニーズやマーケットの状況が変われば、それに応じて優先度をコントロールしていくことが何より大切でもあります。
ウォーターフォールの感覚に慣れていると、”仕様変更”という単語にネガティブに敏感な反応をしてしまったり、一度決まったことが変わることにストレスを感じる傾向があると思います。
変わることがプロダクトの成長に必要だから変わっているはずなので、前提となる概念を変える必要があると思います。
3. アジャイル型なのにウォーターフォールのようになってしまう問題
ウォーターフォールとアジャイルは対照なものとして表現されることが多いですが、アジャイルと一言で言ってもいろいろな現場があります。０or１ではないということですね。
アジャイルであっても、開発プロジェクトやチームの切り方が大ぶりになってしまうと、結局ウォーターフォールのプロジェクトが複数走ってるだけ状態になっていることも多々あります。
お恥ずかしい話ですが、SUPER STUDIOも規模が大きくなってきたときに、気づかないうちにこの現象に近い状態に陥いってしまっておりました。笑
この内容については先日登壇した「すごいベンチャーを支えるプロダクト開発の裏側」のしくじりエピソードでもお話させていただきました。
SUPER STUDIOも開発メンバーの急増に伴い、開発プロジェクトの単位や、チームの単位をもっと小さくしていかなければならなかったのですが、それをしていなかった結果、ウォーターフォールが複数走っているような状態になってしまっていました。
SUPER STUDIOもアジャイルの１つであるスクラム開発を導入し、開発プロジェクトとチームの細分化を行い、より高速なPDCAを回していけるような体制に変更し、挑戦的な開発を実施しています。
このスクラム開発の導入は、ウォーターフォール経験者の僕から出たアイデアではなく、技術をリードするCTOが先導のもと、今の時代の開発組織を率先するエンジニアチームからボトムアップ的に上がってきた施策になります。
常に組織の状態にあった開発手法を適切なタイミングで反映していくことがイケてる開発チームを作っていくために必要なことだと僕自身もとても勉強になりました。
4. さいごに
今回はウォーターフォールとアジャイルについて書きましたが、開発手法に限らず、言語やアーキテクチャといった技術の情報は、世の中にたくさん転がっていますが、実際導入してみると本当にメリット・デメリットがたくさんあります。
新しいからといって良いわけでもなく、かといって旧態依然としていると気づかないうちにレガシーな運用となり、生産性が出なくなる。
技術に限らずですが、今の時代情報が溢れかえっているので、より本質を見極めて、情報を目利きする能力が求められているなと思います。
これからもこういった情報を発信していければと思いますので、よろしくおねがいします。
最後に、SUPER STUDIOではテレビCMで話題の「ecforce」のプロダクトマネージャー・エンジニアを絶賛募集しています。
僕はCPOでもあるので、是非、一緒に最高のプロダクトをつくりましょう。
ご興味ある方がおりましたら、カジュアル面談等も実施しておりますので是非とも、よろしくお願いいたします！
今ならなんと弊社のCTO村上ともカジュアル面談することができます！（※2021年11月末時点）
■プロダクトマネージャー募集
■エンジニア募集
■カジュアル面談
この記事が気に入ったらサポートをしてみませんか？