2015アジャイルジャパン2015のサテライト長野で発表させていただいた弊社の事例のスライドです。スライドだけだと意図がわかりにくい部分については、手元の発表者メモを加えさせていただきました。(株式法人持ちですがフリーで動いています。お話しさせていただきます。プロトタイピングについてです。アを使って合意形成しましょうよということです。情報の網羅性であったりと様々なことですね。そのプロトタイピングも開発フェーズによって、具体的な方法論を変えています。プは、その目的とか情報粒度って全然違いますよね。プロトタイプをひとつとっても適材適所的な感じで進めます。いてはICONIXプロセスというキーワードで後ほどお話しします。基本設計(外部設計)までとなります。し上げておきますと、実装環境に依存しない抽象度レベルの設計という事になります。後ほど、どのレベルまでやるのかのお話しをします。全ての設計が終わってないと次に進まない的なWFモデルのような縛りは設けていません。要件分析や設計も、アジャイル的な表現をするとイテレーティブに進めます。設計は全てソフトウェア設計専用のツールを使います。汎用ツールでドキュメントを書くことはありません。設計フェーズを設ける目的は、「木を見て森を見ず」の状態を避けるためです。ことをより効率的に行う場合には、やはり設計というアクティビティは必要だと思います。こちらは「アジャイルはドキュメントを書かない」のカウンターですね。キュメントを書きます。「納品を目的としたドキュメント」は書きません。的な立場なので、俗にいうSEからプログラマへの「製造指示書」的な設計書は書きません。ドキュメントを書く目的は2つです。トを書くことによってより全体を見渡すことが容易になりますよね。設計については効果的なレビューが必要だと思います。システムってやっぱりいろいろと問題ですからね。最後は、運用・保守に入った後に、そのシステムの概要を素早く把握するためですね。弊社はシステムを完全にリリースした後に、設計書の最終的なトレースをします。その目的にあっていると思っています。コーディングルールは、「アジャイルはカウボーイコーディング」のカウンターパートですね。コーディングルールというか、開発標準は文書にまとめて徹底しています。ソースコードレビューを行ってルールに反するコードは基本書き直しになりますね。WFプロジェクトよりも、アジャイル手法のほうがより厳密なルール化が必要だと思います。キュメントの量が圧倒的に少ないです。いうことは、必然的にコードそのものが仕様書となる必要性が出てきます。重要な事だと思います。最後にリファクタリングです。張性のある、もしくは効率的なアルゴリズムにコードを改善・改修する一連の作業です。違っていたら後で突っ込んでください。