アジャイル

ウォーターフォールというのは開発方式の呼称ですが、アジャイルは開発方式の呼称ではありません。同マニフェストが示すように、スタイルや方針や目標を表現する言葉です。繰りかえしますね。「アジャイル」は開発方式の呼称ではありません。改善し価値を高めつづけるため、変化をよしとします。ある時点で不可欠とわかっている機能の実装を優先します。先々を予測するのもたいせつですが、その時点の判断が優先されるので、とおーーくのことまで（わかりもしないのに）定義するのではなく、だいたい数週間程度先までを判断範囲とします。エンジニアの気持ちになってみてください。「よくわからないから、あとで変えればいいや。よろしく」と雑に実装を頼まれたら、どう感じますか？変化をよしとすることはすなわち、必要だからこそ変更するのを意味し、事前に決めた内容より、そのとき現在の需要の高さに配慮するということですはい請負契約消えたー請負契約は、納品物がどんなものか事前に決めないと、なにを請け負ったのか、なにを請け負ってもらったのか、わかりませんね。改善しつづけるアジャイルには向かないでしょう… Q. 決めながら進める（＝雑に始める）のがアジャイルだと勘違いしている人がいるらしいです。とくに営業フェーズで非合理的なことをしてしまうと、エンジニアたちが苦しみます。炎上して過労に陥り、やがて取り返しのつかない事態になりかねません。そういうの、もうやめましょう。「まるっと〇〇〇〇万円。〇ヶ月間アジャイルでよろ」はやめましょう派遣と準委任どうしようかー無期の派遣契約はあまり一般的ではなさそうです。更新の可能性があるとはいえ有期なら期限があります。期限が決まっているなら、なにをどこまでやるのかを決めたほうが合理的ですね。「この人はいついつまでしかいないのか…。なにをやってもらうと一番いいだろう…？」と考えるべきではないでしょうか。全体的にはアジャイル型開発を採択しながら、開発対象の一部を切りだしてウォーターフォール的に進めるのはアリだと思います。準委任契約に関しては、改正民法が発効すると「成果完成型」契約があり、あらためて弁護士の助言をじっくり咀嚼中です。別途まとめる予定ですので、しばらくお待ちくださいで、雇用契約？時給か月給か、社保加入するかしないかは問われませんが、有期雇用か無期雇用かは問われます（理由は派遣の項を参照）。つまり、無期契約があるのは一般に雇用契約だけなので、上述の結論を出したわけです。以下に開発スタイルをざっっっっくりまとめておきます。アジャイル型（月額制課金）品質改善を優先し、その継続により事業運営を維持向上する。期待している製品がいつできるか保証されないのが難点ウォーターフォール（購入時課金）事前の取り決めの実現度を優先し、その達成により、実現後の一定期間の事業運営を補助する。想像した製品が期待とずれても保障されないのが難点不確実な事柄に対する警戒心が強い日本人「失敗してもいい」前提なんて、ないと思うんですよ。失敗すんな圧がいくら高いとはいえ、アンチテーゼとしてそんな前提をつくる必要はありません。ただ、失敗を予防する方法について、いっしょに考えてみませんか？次の記事.

ソフトウェア要求仕様の変更などの変化に対して機敏な対応ができ、顧客に価値あるソフトウェアを迅速に提供することを目的とするソフトウェア開発方法論の総称。特に「アジャイルソフトウェア開発宣言」に合意しているもの、「アジャイルアライアンス」に参加しているものを指す。アジャイル（agile）とは「俊敏な」「機敏な」という意味で、軽量型（ライトウェイト）開発ともいう。上述のヘビーウェイトな手法は伝統的なソフトウェア開発のやり方としてさまざまなプロジェクトで実施されてきたが、近年、その欠陥が指摘されるようになってきた。それは、社会状況やマーケットの変動が激化し、また業務が複雑化するに伴って、ビジネスおよびシステム要件も日々変化するのに対し、従来の手法ではその変化に機敏に対応して、システム構築ができないというものだった。こうした状況を背景に、「変化への対応」をうたう開発方法論、プロジェクト管理手法が登場するようになった。それらの提唱者たちは2001年2月、米国ユタ州スノーバードに集まり、共通するコンセプトを説明する言葉として「アジャイル」を選択、を発表した。アジャイルソフトウェア開発とされるものには、以下のようなものがある。スクラム• 適応型ソフトウェア開発（ASD）• クリスタル・ファミリー• DSDM• フィーチャ駆動型開発（FDD）•

Contents• これまでの開発では、ソフトウェア全体の「設計」が終わったら「実装」を開始し、全体の「実装」を完了させたら「テスト」に進む形で、プロセスの一つ一つを頭から順に進めていくのが一般的でした。テストの結果、明らかになった問題や顧客の要望に応じ、要素ごとに修正・改良を加えながら開発を進めていきます。工業製品のモジュール化のように、ソフトウェアを構成する「要素ごと」につくり上げていくアプローチだと考えれば分かりやすいでしょう。アジャイル開発のメリットリスクを最小化しながら柔軟な対応を可能にするアジャイル開発の「アジャイル（agile）」は、英語で「機敏な」「頭の回転が早い」などの意味。名前の通り、細かなイテレーションを効率的に積み重ねていくことでリスクを最小化し、従来に比べて素早く開発を行いながら、仕様の変更に臨機応変な対応ができるようになっています。開発では、最初に細部まで決め込んだ「要件定義」を行う形ではなく、大まかな「リリース計画」を決めたら、スピーディーに設計に入ります。アップデートが頻繁に要求されたり、手戻りの必要が生じたりすることを想定し、計画のメンテナンスを重ねながら業務を進めていくわけです。もし不具合が発覚しても、およそ1〜4週間程度の1イテレーションで完結する部分の設計、実装、テストであれば手戻りの工数を抑えることができます。ポイントは「機能がどのように動くのか」をイテレーションごとに顧客に確認してもらうことで、問題点を早い段階で洗い出せる点。一方、従来の手法のように長期スパンで進行する工程の場合、不具合が発覚したタイミングによっては修正の影響が全体におよび、大きなロスにつながりかねません。アジャイル開発では、確認の際に顧客から新しい要望が出た場合にも対応しやすいのがメリット。さらに、工程が分割されているため「何の機能から進めるか」「どのプロセスが重要なのか」を判断し、選択できる利点もあります。ソフトウェアの軸になる要素が完成したら、残る工程や必要な機能などを考慮して、その時点で最適な作業の内容とスケジュールを組み立てることもできます。これらをまとめると、アジャイル開発は、仕様の変更や追加など、「当初の計画が変化していくこと」が予測されるプロジェクトに特に向いているといえるでしょう。従来の開発手法との比較大切なのは適切に使い分けることもちろん、どのようなプロジェクトにおいても、アジャイル開発が最も適切な手法とは限りません。案件の特性や規模によっては、「最初に決めた計画どおりに進めていく」開発手法が適していることもあるでしょう。例えば従来の代表的な開発の方法として、「ウォーターフォール開発」があります。ウォーターフォール、つまり滝が上から下へと落ちていくように、工程を一つずつ、順番に完了させていくスタイル。最初にプロダクトの最終形をはっきりと描き、ゴールを見据えて「要件定義」「設計」「開発」「テスト」を順番に終わらせていくため、プロジェクト全体のスケジュールや進捗状況を管理しやすい利点があります。伝統的に用いられてきた方法ですから、携わった経験が豊富なソフトウェアエンジニアも少なくないでしょう。また、各工程を担うチームの役割も明確で、最小限のコミュニケーションで作業が成立するため、細かいやり取りの必要も減ってコミュニケーションコストを抑えやすくなっています。アジャイル開発との大きな違いは、なんらかの変更点が発生した場合の対応力。途中で「やはりこうしたい」と顧客から新しい要望が出されたとき、それまで進んでいた計画を大幅に見直すことも起こりえます。ウォーターフォール開発は、比較的規模が大きく、仕様の変更が生じないものに向いていると言えるでしょう。アジャイル開発とウォーターフォール開発のいずれを採用するかは、開発期間や託された予算に加え、変化の振れ幅をどのくらいに設定するかなど、さまざまな要素を加味して判断することが大切です。アジャイル開発実践の心得開発宣言の4つの価値がヒントにでは、アジャイル開発を導入するとなったとき、どのようなことに注意して進めていくべきでしょうか。 2001年に17人のソフトウェアエンジニアたちがまとめた「アジャイルソフトウェア開発宣言」の中に、ヒントが隠されています。以下に全文を掲載します。アジャイルソフトウェア開発宣言私たちは、ソフトウェア開発の実践あるいは実践の手助けをする活動を通じて、より良い開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、• 包括的なドキュメントよりも動くソフトウェアを、• 契約交渉よりも顧客との協調を、• 計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、Jon Kern、Brian Marick、Robert C. これらの「価値」を重視しながら、イテレーション単位の開発を進めることで、素早い開発、柔軟な対応といったアジャイル開発のメリットが実現されていくわけです。留意すべき点としては、開発の方向がブレやすいことが挙げられます。計画が変化することを想定しているとはいっても、「幹」となる部分を決めておかなければ、完成は遠のくばかりです。仕様をある程度固めておくことはやはり重要になります。また、プロジェクト全体の進捗管理がしにくい点にも注意が必要です。開発は、最初に決めた「リリース計画」でプロジェクト全体を管理しながら、各イテレーションの実施計画となる「イテレーション計画」に沿って進めていきます。常に開発プロジェクトの全体を見据えて優先順位をしっかり踏まえながら、進行状況を把握し、計画のメンテナンスを行うよう心がけましょう。アジャイル開発のバリエーション最後に、アジャイル開発のさまざまな手法について触れておきます。ラグビーから名前を取った「スクラム」は、コミュニケーションに重点を置いた、チームで開発を行うための方法です。ポイントは、スクラムを組むようなメンバーの協力体制づくりとチーム内の活発なコミュニケーション。毎日の情報共有、イテレーションごとの計画・振り返りなどをチームメンバーが主役となって行い、プロダクトの最終的な決定権をもつ「プロダクト・オーナー」、プロジェクトのスムーズな進行をチェックする「スクラムマスター」などのサポートのもと、リリースに向けて力を合わせます。「XP（エクストリームプログラミング／Extreme Programming）」は、名前からも分かるように、プログラミングに主眼を置いた手法。開発メンバーは、初期計画に強くこだわらず、柔軟性を大切にしながら• 円滑な「コミュニケーション」• 「シンプル」な実装• ユーザーによる頻繁な「フィードバック」• 計画変更にひるまない「勇気」• 互いの「尊重」の5つの価値を共有し、コーディングとテストを繰り返しながら品質を改善していきます。開発単位となるのは「ユーザーにとっての機能」。まずは、顧客のビジネスの「見える化」を行い、その分析に基づき、最小限のプログラムによって一つずつの機能を短期間で実装していきます。スクラムに象徴されるように、アジャイル開発のカギを握るのはチームの力。新たな開発手法に挑戦してみることは、多職種による相乗効果が見込まれ、プロジェクトの管理やクライアントとの協働など、新たなステップアップのための経験値を高めるチャンスともなるはずです。

アジャイルソフトウェア開発宣言。アジャイルソフトウェア開発、組織の文化が依然として壁に