テクノロジーこんにちは。私は、以前にアジャイル開発を知って以来、アジャイルで開発を続けています。私がアジャイルにハマることになるきっかけを作ったのは、アジャイルサムライという名著でした。実際にアジャイル開発をやってみた結果、メリットやデメリットが色々と見えてきました。今回は、ウォーターフォール型の開発と比較しながら、考察していきます。アジャイル宣言アジャイル開発には、有名なアジャイル宣言があります。計画に従うことよりも変化への対応を、http://agilemanifesto.org/iso/ja/manifesto.htmlそれでは、アジャイル宣言に沿いながら、実際に比較検討をしていきます。プロセスやツールよりも個人と対話をアジャイル開発は、ドキュメントよりも動くソフトウェアを重視する傾向があります。実際には納品をしない仕様書を作り込むくらいだったら、コミュニケーションで仕様を伝達し、ダイレクトに動くソフトウェアを開発していったほうが早いのです。ところが、プロジェクトメンバーが増えれば増えるほど、コミュニケーションのコストは増大していきます。会議室にメンバーが一堂に会するだけでも、全員の15分が奪われてしまうのです。コミュニケーションに対するコストが馬鹿にできないプロジェクトの場合、アジャイル開発は不向きになり、ドキュメントによる情報共有の効率のほうが勝ります。アジャイル型の開発は少人数、ウォーターフォール型の開発は大人数のプロジェクトに適しているというのが、私の印象です。包括的なドキュメントよりも動くソフトウェアをウォーターフォールのドキュメントと聞いた時に、エクセルの仕様書や設計書を思い浮かべる人はいませんでしょうか?ウォーターフォールが嫌われやすい理由のひとつに、重厚長大で分厚い本のようなイメージの仕様書があります。これは仕様書を過剰に作り込んでしまうから発生してしまうことなのです。現在は、モックアップやプロトタイピングを利用した画面設計が流行っています。techlife.cookpad.com最小限のドキュメントで情報共有を図ることが最近の潮流であり「プロセスやツールよりも個人と対話を」とは限らないのです。これは、アジャイル型開発にも適用できます。アジャイル型開発のコミュニケーションコストの高さを、最小限のドキュメントで補うのです。アジャイルが定義している問題は包括的なドキュメントにあるので、それさえ解消してしまえば良いのです。最小限のドキュメントによる効率的な情報共有を、私は強くおすすめいたします。クックパッド様の開発手法は非常に参考になりますので、ぜひご参照ください。契約交渉よりも顧客との協調を顧客との協調を強くするためには、アジャイルな顧客が必要になります。アジャイルな顧客とは、平たく言ってしまえば協力的な顧客のことです。協力的な顧客を獲得できるのであればアジャイル開発は優位性を持ち、そうでない場合はアジャイル開発の強みは減少してしまいます。アジャイルは動くソフトウェアを重視しているので、実際に顧客にソフトウェアを触ってもらう必要があるのです。・・・では、ウォーターフォール型開発の場合は協力的な顧客は必要ないのかと言うと、そうではありません。ウォーターフォールが嫌われやすい理由のひとつとして、一枚岩の重厚長大なシステム開発によく用いられるので、後半の工程での手戻りが大きいといった理由があげられます。これは一枚岩だから発生するのです。ウォーターフォールであったとしても、まずは最小限のプロダクトでリリースしましょうといった取り決めを締結できれば、リスクは抑えることができます。そこから、少しずつ機能拡張していけば良いのです。何も、一度のウォーターフォールですべてを解決する必要はありません。結局のところ、アジャイルであろうがウォーターフォールであろうが、協力的な顧客は必要なのです。計画に従うことよりも変化への対応をアジャイルは変化への対応を柔軟にすることを重視します。言葉を言い換えてしまえば、アジャイルは変化が大きいプロダクトに向いているのです。アジャイルは頻繁に機能を見直すようなスタートアップの自社プロダクトに、ウォーターフォールは変化量の少ない請負や受託開発のプロダクトに向いています。請負や受託開発に向いているかと申しますと、請負や受託開発では、計画の尊守をどうしても求められるケースが多いのです。いった状況下において無理にアジャイルを回すくらいでしたら、素直にウォーターフォールで開発するという選択もありなのではないかと考えています。blog」様によくまとまっておりますので、ご確認ください。tasuwo.github.ioここで私が言いたいことは、一言に集約されます。blog」様で言及されている開発手法を列挙してみます。ウォーターフォールモデルプロトタイピングモデルスパイラルモデルインクリメンタルモデルイテレーションモデル開発手法は、さまざまな開発モデルの中から、取捨選択された結果として検討されることが望ましいのです。さいごに私が本記事において言いたいことは、アジャイルサムライの教えと似ています。今回は、アジャイル宣言に沿いながら比較検討をしてみました。大事なことは、自分の頭で考えることです。アジャイルを実践してみた結果、コミュニケーションコストの増加に悩まされることもあれば、ウォーターフォールでプロジェクトを進めた結果、手戻りの影響に悩まされることもあります。結局のことろ、自分のプロジェクトの性質にあったプロジェクト管理手法を選択する必要があります。どのプロジェクト管理手法が合うのかという、絶対的な最適解はありません。我々は考える必要があるのです。フロントエンド・モバイル・WEB・インフラ・アジャイルなど最近は忙しく、テック系ポッドキャストをあまり聴けていない日...2018-07-31受託開発のメリットを活かせ!失敗しないプロジェクト運営のコツを受託開発の極意で学ぶ受託開発の極意―変化はあなたから始まる。デスマーチはなぜなくならないのか久しぶりに図書館に行ったら、たまたま目に止まったので「デス...2018-05-02システム開発やプログラミングにおけるとバグの種類と、バグを防ぐための考え方について新人エンジニア応援記事の、第二弾です。はてなブログProWEB系エンジニア。ブログで趣味の映画・ゲーム・読書の感想を書いたり、技術系の知見を共有しています。技術書典7にサークル参加して、技術同人誌を頒布しました。BOOTHに電子版があります。(1)月別アーカイブスポンサーリンクはてなブログをはじめよう!konosumiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。