社外常駐で学んだアジャイル開発
(1)今回の事例: 業務システムをWeb化で刷新
第2回では、新人のころに筆者がかかわった事例を取り上げ、「情報共有」の仕方と、「情報共有を通して、どのようにアジャイルの基礎的な内容を学んだのか」を説明しました。
前回の計画をチームで立てるというトピックで、「アジャイルでは、イテレーションを何度も継続して回す」ことを伝えました。ここで大切な点は、「ただ単に繰り返す」ことを意味しているわけではないということです。イテレーションで得られたフィードバックを、次のイテレーションでより良い活動ができるように生かすことが重要です。
今回は、この「フィードバックをもとに、より良くする(改善する)」ことに焦点を当て、筆者が社内SNS構築の次に参画したプロジェクトを取り上げます。まずは、今回の事例で取り組んだ「業務システム」について、簡単に紹介します。
筆者が所属するTISでは、プロジェクトが完了すると、プロジェクト・マネージャ(PM)から社内の生産技術部門に、プロジェクトの情報や結果を記した「プロジェクト完了報告書」を提出することになっています。
プロジェクト完了報告書には、「どんな規模」で、「どういった期間」に、「どんな技術」を用いたかなど、プロジェクトに関するさまざまな情報が書かれます。生産技術部門は、この情報を集計/分析して、生産性や品質を向上させる施策の検討に活用したり、社内に還元しています。
また、プロジェクト完了報告書の情報は、社内で共有します。あるプロジェクトを担当することになったPMが、担当プロジェクトに似た事例が無いかどうかを生産技術部門に問い合わせ、類似プロジェクトの完了報告書から得られた情報を生かす、という仕組みができています。
しかし、プロジェクト完了報告書を提出するワーク・フローは複雑かつメールが中心で、情報は一元管理されていませんでした。このため、作業担当者の負担が非常に大きくなっていました。また、類似情報を検索するシステムは、決して検索性能が良いとは言えず、うまく利用できないという不満が高まっていました。
そこで、これらの課題に対する取り組みとして、プロジェクト完了報告書を取り巻く既存業務の見直しとともに、Webアプリケーションによるシステム化を実施することになりました。
(2)経験豊富なアジャイル・チーム
2008年4月当時、筆者は社会人として2年が経過していました。社内SNSの開発以外にも、新人の教育や単独でのプロダクト開発なども経験し、社会人としての生活にも徐々に適応してきていました。そんな中、社内SNS構築当時の開発メンバーがPMとして活動している新規プロジェクトへの配属が決まりました。
以下は、私が所属していた期間の、プロジェクトの概要です。
表1: プロジェクトの概要
項目 | 内容 |
---|---|
参加期間 | 2008年4月~2009年9月 |
人数 | 3~6人 |
エンドユーザー | TIS社員(プロジェクトの責任者および現場部門の品質管理責任者、生産技術部門) |
ビジネス・オーナー | TISの生産技術部門 |
プロジェクトの大きな特徴は、開発言語がRubyである点と、協力会社としてアジャイル開発の経験が豊富な永和システムマネジメントに手伝ってもらう点です。同社は、アジャイル関連の書籍の執筆、監訳、講演などを数多く手がけていて、アジャイルを中心としたコンサルティングや開発協力を数多く実践している会社です。
TISのメンバーは3人(PM、移行担当者、開発担当の筆者)でした。筆者は、永和システムマネジメントの西村直人さん(開発リーダー)および浦嶌啓太さん(開発担当者)と3人で、開発チームを組みました。プロジェクトの開始から半年ほど経ったころには、永和システムマネジメントのオフィスに常駐して開発を行なっていました。
図1: プロジェクトの体制図(クリックで拡大) |
このプロジェクトでは、開発を取り巻く環境に大きな変化がありました。こうしたことから、さまざまなフィードバックを得ることができました。これにより、業務システムだけでなく、筆者自身の改善(成長)にもつながったと思います。
次のページからは、具体的に何が起きたのか、そして筆者自身と筆者たちのプロジェクトがどのようなフィードバックを獲得し、そのフィードバックをもとに何を実践したのか、について、「開発の効率化」、「プロダクトの成長」、そして、「改善」のための起爆剤となる「ふりかえり」を中心に、解説します。