 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 | ||||||||||||
|
||||||||||||
| 「アジャイル」と「Ruby on Rails」による高い保守性 | ||||||||||||
|
TISの社内SNSは1年4ヶ月ほど運用しています（2007年4月現在）。最初のリリースから何度も改修と拡張をしつつ、リリースを繰り返してきました。これは、積極的な機能拡張の結果です。 この考え方のベースには、Web 2.0のキーワードの1つである「永遠のβ版」があります。スモールスタートではじめ、利用者の増加とともに機能を増やしてきました。そして、今もなお週に1度ほどのペースでリリースを実施しています。 このように、何度もリリースを繰り返すためには、一般的なシステム開発の進め方では無理があります。そこで、筆者たちの開発チームでは、開発の進め方として「アジャイル開発」を採用し、プログラミング言語に「Ruby」、そのフレームワークに「Ruby on Rails」を採用しました。 |
||||||||||||
| プロジェクトの頓挫を防ぐアジャイル開発 | ||||||||||||
|
アジャイル開発とは、ビジネス環境や仕様の変化に対して柔軟に対応することのできるソフトウェア開発手法の総称です。 従来のシステム開発との違いは、要求の変化に対するスタンスです。これまではシステム開発の最初の段階で、作るべき要件をすべて定義して計画に落とし込み、数ヶ月から数年をかけて開発していきます。このスタンスは、最初に決めた要件や計画が変化しないというものです。 それに対して、アジャイル開発では「変化は必ず起きるものとして考え、いかにその変化を乗り越えていけるか」という点に注力します。 開発途中の変化に対応するために、アジャイル開発では短いスパンでリリースまでの開発を繰り返します。  図8：従来の開発とアジャイル開発の違い 引用：オブジェクト倶楽部 - eXtreme programming FAQ （http://www.objectclub.jp/community/XP-jp/xp_relate/xp-faq） （画像をクリックすると別ウィンドウに拡大図を表示します） それを実現するために、ドキュメントよりも動くソフトウェアを重視するなど、いくつかのコンセプトがあります。それが、アジャイル宣言と呼ばれる形でまとめられています。
アジャイル宣言
http://www.agilemanifesto.org/ 筆者のチームでは、アジャイル開発の中でも、もっとも有名な「eXtreme Programming（XP）」という手法をベースに使っています。 アジャイル開発を採用したことによって得た最大のメリットは、週単位でもリリースを繰り返すことができるチーム体制を作ることができた点です。作るべきドキュメントの量を最小限に抑えることで、保守改修の際のコストを最大限下げることができているため、リリースごとの負荷を減らすことに成功しています。このことによって、機能のスモールスタートが実現でき、利用者の声を聞き入れつつ、よいソフトウェアに仕上げていくことが実現できています。 また、アジャイル開発を採用したことはプロジェクトマネジメントの観点からもリスクヘッジに効果がありました。今回のプロジェクトの最大のリスクは、自分たちで内製しているために、別の業務が割り込んでしまったら、開発がストップしてしまうことです。 実際に、社内の業務で本プロジェクトに従事できない時期が3ヶ月ほどありました。確かに、機能的にはまだまだ足りない状態でしたが、スモールスタートですでにリリースは完了していたため、利用者はその間も増え続け、本プロジェクトに戻ってきてからも開発を続けることができました。もしこれが従来の開発手法を採用していたら、設計の途中で中断を余儀なくされて、おそらくはプロジェクトは頓挫していたことでしょう。 |
||||||||||||
| 保守改修時に真価を発揮する「Ruby on Rails」 | ||||||||||||
|
Ruby on Railsは、日本発のプログラミング言語「Ruby」で動くWebアプリケーションを開発するためのフレームワークです。Ruby on Railsは最近のインターネット上のWebサービスでも多く利用されています。 Ruby on Railsの最大の特徴は、「Javaの10倍」といわれる「生産性の高さ」にあります。一般には、自動生成の仕組みがあることで最初の開発生産性が高いと思われていますが、本来Ruby on Railsがその真価を発揮するのは保守改修時にあるのです。 DRY（Don't Repeat Yourself）というポリシーで作られているRuby on Railsに従うことで、改修時に変更する箇所を極力少なくすることができ、利用者の声に従って対応していく際に、非常にアグレッシブに対応できるようになりました。 このRuby on Railsとアジャイルを組み合わせることで、非常に柔軟なシステム開発を実現できました。「利用者のニーズに合わせて徐々に機能を改善していく」という方法は、常に要望の絶えない社内SNSの開発とうまくかみ合ったと思います。 次回は、このような利用者の声を取り入れつつ機能改善を行っていった運営方法について解説します。また社内SNSやブログを運営する際には必ず話題にあがる炎上問題と誹謗中傷の問題の解決方法や社内SNSのコミュニティ運営について、事例を交えて説明していきます。 |
||||||||||||
|
前のページ 1 2 3 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
