ハンナ様 THE部活!web開発 アジャイル型開発モデル

THE部活!
THE部活!

「月刊ショパン」を発行している株式会社ハンナ様の季刊誌、「THE部活!WEB」開発を無事に終え、公開に至りました!!
ハンナ様より開発事例掲載許可を頂いたのでご紹介したいと思います。

THE部活!WEB」は部活目線で学校を探すというユニークなシステムです。
今回の開発は、アジャイル型開発モデルを採用しました。

アジャイル型開発モデルってなに?

システム開発プロジェクト手法のひとつです。
アジャイル(agile)は素早い等の意味で・・・
などといった詳しい説明は専門家に任せておき、大きく意訳して音楽家の方々でも分かりやすく説明したいと思います。

アジャイル型開発モデルは「お客様と一緒に技術的理解を深めながら開発する」といったやりかたです。

日本において、巨大なシステム開発はウォーターフォールモデルという手法が採用されることが多いです。

設計→開発→試験→公開

といった工程を経て、システム公開するやり方です。

これが水(Water)が上流から下流へ流れ落ち(Fall)、再び上流に戻らないことを前提とするやり方から、WtaterFall(水が落ちる=滝)モデルといわれています。

ウォーターフォールモデルはビルなどの建物建築と重ねるとイメージしやすいです。

設計図を書いて、お客様に説明・承認を経たら、基礎を掘って骨組み組んで、内外装を作っていく・・・
作り上げたらお客様が竣工検査
問題無ければ引き渡して竣工完了!!

巨大なシステム開発もやり方は一緒です。
ただ、ひとつだけ大きく異なることがございます。

それは、作り上げる対象が物理的か論理的かの違いです。

ウォーターフォールモデルの問題点

諸説ありますが、私がいままで経験してきて感じている大きな問題点は「設計書を技術的に読み抜く力が受発注者双方に求められる」という点です。

依頼を受けたシステム開発者(請負者)は、どのような機能を開発するかを設計書に明記します。
それを依頼主(発注者)が設計書をチェックします。

設計書を悪くいえば、「絵に描いた餅」です。

ウォーターフォールモデルで巨大なシステム開発となると、設計書は数千、数万ページ以上におよびます。

超々々々々~~~~ざっくり説明すると、

  • プロジェクト計画書(どのような期日になにを完了させるかの計画)
  • 外部設計書(見た目の設計)
  • 内部設計書(機能を実現するための技術的設計)
  • 試験計画書(仕様通りに動作しているかを確認するか?の計画)

など、膨大な書類の山が築き上がります。

システム開発者はレシピ(設計書)に基づき、料理(プログラミング)することで、食べられる餅にします。
そして依頼主はどのような餅を作るかをレシピ(設計書)で確認します。

でも、それは作ってみないと実際に味わうことはできません。

システム開発でよくある話は、絵に描いた餅(設計)段階で、受発注者双方で合意した内容を、食べられる餅(開発完了)段階で「味が違う!!」となることです。

建物建設の場合、開発対象は物理的です。
見た目でどのようなものができあがるか?という過程を目で確認することが可能です。

一方で、システム開発の場合は論理的です。
開発過程をどんなに詳細にお伝えしても、食べられる餅(開発を終える)になるまでわかりません。

作った後に、「思ってたのと味が違う!!」という話、よくあることです。
受発注側双方に不幸なことですね。

アジャイル開発モデル

絵に描いた餅を、早い段階で試食しながら食べられる餅に作り上げていく開発モデルといえます。

重厚長大な設計書を書き上げて「絵に描いた餅」の作り方を定義するのではなく、試作品を作り、実際に触れて確かめてもらうことを優先した開発モデルです。

受発注側双方で触って確かめながら開発を進めるため、完成形(=絵に描いた餅)をイメージしやすくなります。

これだけ聞くとメリットばかりなやり方ですよね!!
しかし、日本ではこのやり方がなかなか定着しません。
その理由は最後に言及したいと思います。

株式会社ハンナ様

ハンナ編集部とのミーティング
ハンナ編集部とのミーティング

「月刊ショパン」でおなじみの歴史ある出版社様です。
月刊ショパンは私がピアノを習っていた頃からの愛読書でした。

プログラム開発を伴うシステム開発は初めてでした。
当然ながら編集部にITに精通された方はいらっしゃいません。

この状態でいかにしてプロジェクトを成功させるか?

そこでアジャイル開発モデルの登場です。

THE部活!WEBシステム開発は、試作品を2度作り、実際に動作を確かめて頂きながら開発を進め、最終形を完成させました。

試作品開発を通じて、編集部の方に技術的理解を深めて頂きました。

THE部活!WEBシステムの肝は部活検索機能です。
開発過程で編集部からいろいろなご要望が挙がりました。
これについて、技術的にどのように実現するかを提案するだけはなく、実際に動作をお見せして、双方で確認しながら開発を進めていきました。

公開時点で、編集部の方が技術理解を深めることが実現し、データベース構造を議論できるレベルに達しました。

もし、ウォーターフォールモデルで進めてたとしたら、なかなかそうはいきません。

アジャイル開発モデルを採用して大成功でした!

アジャイル開発モデルはウォーターフォールモデルよりも優れているのか?

私はそうは思いません。
各開発プロジェクト単位で最適な方法を選ぶべきだと思います。

アジャイル開発モデルのメリットは柔軟性の高さです。実際に確認しながら作り進めるため、開発過程で細かな軌道修正が可能です。
でもこの柔軟性の高さがデメリットともなりえます。

開発と確認を同時並行するため、開発当初の要件以外の機能を求められることがあります。
機能が増えるとプログラム開発量が増えて、コストに影響します。
日本の商慣習では一度合意した予算を超過するやり方は好まれません。
また、意思決定者が複雑に絡み合うような巨大システム開発プロジェクトとなると、採用することが難しくなりがちです。(そもそも意思決定が複雑であることそのものが問題の本質ですが、本題から外れてくるのでここでは言及しません。)

これに対して、開発目的に立ち戻って判断していくことが大事です。
ハンナ編集部様とも開発目的に沿って建設的に議論を重ね、開発を進めました。

いずれの方法でも、双方の協力関係を築くことが大事ってことですね!!