システム開発

ここまで、いくつかの開発プロセスについて説明してきましたが、ある意味、これまで説明してきた開発プロセスよりも、大きな成果を上げている「やり方」 があります。それが、バザール方式です。

第1回でも説明しましたが、アジャイル開発はSaaSのビジネスモデルと非常に相性が良いです。それは、ソフトウエアのソースコードを提供するビジネスではな く、ソフトウエアを動かしてサービスを提供するビジネスになっており、ソフトウエアを継続的に改善していくことができるためです。ある特定のソフトウエア の完成を目指すのではなく、ソフトウエアで提供できる価値を継続的に高めていくために、品質の中でも特に保守性を重視して、環境や要求の変化に柔軟に対応 できるアジャイル開発が向いているのです。

本連載では、実際の事例をもとにアジャイル開発の紹介を行っています。事例の題材となるのは、オープンソースのビジネスユース向けSNS「SKIP」 です。SKIPは、当初は筆者の所属するTIS株式会社で開発を行っていました。

前回は、分散開発にアジャイルのメリットを取り入れるために、考慮すべき代表的なポイントをリストアップした後で、実際に製品開発に適用されているプラ クティス集としてEclipse Wayを取り上げました。連載の2回目と3回目は、このプラクティス集とこれが適用されている製品開発の様子を公開しているサイトJazz.netを取り上げて、前回取り上げたさまざまな課題をどのように解決しているかを具体的に見ていくことにしましょう。

「仕様書をレビューしても、文章表現上の指摘しかできない」「チェックリストに書いてあることの真意が分からない」「重要な問題なのに、つい見逃してし まう」。今回は、こんな悩みを抱える方にちょうどよい規模のレビュー課題を提示して、技術レビュー演習の機会を提供します。

前回は、ピアレビュー教育の概要を紹介し、教育の中でピアレビュー会議を実践することが効果的である、ということを説明しました。ピアレビュー会議のあ と、30分程度の時間を使い、ふりかえりを必ず実施するようにしています。

今回は限られた時間内でインスペクションを実施することを前提に、どんな欠陥を優先して指摘すべきかを意識した、優先度つきインスペクションを紹介しま す。また、優先して発見すべき欠陥を決めるヒントの1つとして、バグ票に含まれる修正工数の傾向を抽出した事例を紹介します。

今回は、インスペクション対象ごとの攻略方法やコツに焦点を当て、解説していきます。まず、プロジェクトの上流フェーズで要件定義書や設計書をインスペクションする方法について解説します。要件定義書や設計書のインスペクションは、ダイ アグラムや自然文で記載されることが多いため、以下の3つの難しさがもともとあります。

今回から深遠なるインスペクションの世界へと進んでいきます。第1回、第2回では物足りなかったという方にも今回以降は手ごたえを感じていただけるので はないかと思います。今回からは比較的かっちりとしたインスペクション／レビューの説明になりますので、これまでの「インスペクション／レビュー」という 呼び方も以降では「インスペクション」に統一します。

前回「RHELを題材にソースが見える環境を作る」の記事に従ってソースコードを手元に置くと、段々ソースコードを読む習慣がついてきます。習慣がつくに従い徐々に読む範囲をひろげ、量を増やしていくこと でしょう。しかし、いずれ壁にぶつかることになります。少なくとも筆者はぶつかりました。

「ソフトウエア開発において、レビューは大切ですか？」「もちろん」と答える人が多いことでしょう。さらに「大切なのにサボるのはなぜですか？」と質問すると、「時間がなくて」「短納期だから」と一生懸命に 理由を説明してくれます。ならば、さらに問うてみましょう。「サボれるなら必要ないのですか？」みなさんなら、何と答えるでしょうか。