Blog

アジャイル開発の原則 04

全員で共通の目的に向かう

原則:ビジネス側と開発者は、プロジェクトを通して一緒に働かないといけない。

旭川医大事件とうシステム開発における要件定義の判例となるべき裁判がありました。

事件の概要

  • 旭川医科大学は、2008年8月に、電子カルテを中核とする病院情報管理システムの刷新を企画し、NTT東日本に開発を依頼した
  • 現場の医師たちによる追加要件が相次ぎ、プロジェクトが混乱した。NTT東日本は、1000近くにのぼる追加項目のうち、625項目を受け入れた上で仕様を凍結 納期も延長
  • 仕様凍結後も現場医師らの要望は止まず、さらに171項目の追加項目が寄せられた
  • NTT東日本は、さらに追加された171件のうちの136件の項目を受け入れたが、開発はさらに遅延し、結局、旭川医大は期日通りにシステムを納品しなかったことを理由に、契約解除を通告した
  • NTT東日本は、「プロジェクトの失敗は旭川医大が要件の追加・変更を繰り返したことが原因だ」と損害賠償を求めた。
  • 旭川医大は、「NTT東日本が納期を守らず、テスト段階での品質も悪かった」と反論し、裁判になった。

いろいろと、判決を読んで見ると、どうも現場の医師が忙しかったらしい。要求は出すけど、どんなふうに作ればいいかの会議には参加しなかったらしい。

結果 札幌高等裁判所は、「旭川医大に100%の責任がある」として約14億1500万円の支払いを命じる判決を出した。

この様になると、責任のなすりつけになってしまう。裁判ってそういうことですよね。

でも思ったんです。結論からいうと、アジャイル開発なら、このような問題は起きなかったのではないか?

もし、これがアジャイル開発だとどうだろう。


2週間おきのスプリントで動くものを確認できる。

医師もなるべく早い時点で、要求と違う点を指摘できる。

NTTの開発者も、作りながら、現場でどのように使われるのか?が理解できる。

お互いが開発者なのです。だからアジャイル開発は良いのです。

ここがアジャイル開発と、ウォーターフォールモデルとの一番の相違だと思います。

私も、いましているプロジェクトでも。2週間でお互いの認識が違っていることがありました。
もともと2,3ヶ月で完成する小さな、プロジェクトでしたので、最小構成の顧客管理できるものがあれば良いと思っていました

でも、クライアントは、お店がオープンする際に、顧客管理はどうしても必要なので、6/1のオープンにはとりあえず、Airレジを使うと言われました。

Air レジ

全く聞いていなかったので驚きました。

Airレジがあるので、お客さんとのリアルタイムでやり取りできる手段がほしいと、スプリントミーティングで言われました。グループチャット機能をFirebaseで実装予定でしたが、Push通知だけといえど、あと1ヶ月で、iOSとAndroidを作るのは現実的ではないため、Twillioを選択しました。
SMSが送付できるサービスです。

これ結構おすすめのサービスです。

twillio

AWSでも同様のサービスがあるのですが、テストだけでも、サーバー代月額12万円位請求されます。しかも審査が大変厳しい。対してTwillioはというと、たったの450円/月額。ありえない金額でした。


話を戻します。アジャイル開発のスプリントの話でした。

スプリントミーティングの結果、次のスプリントでは、携帯へのpush通知機能を優先することになりました。
なので顧客管理のCRUD,ログイン機能の実装が完了したら、すぐにTwillio の検証に入りました。


以前、Pythonで検証していましたので、今回のnode.jsでもできるだろうと思っています。
1日あれば検証は完了します。

私は、最小構成の顧客管理システムがあればよいと考えていまいた。

でも違っていました。お客はAirレジの導入を決めて、携帯電話でのリアルタイムコミュニケーションが必要でした。

その定期的なミーティング(スプリント計画)がなかったと思うと恐ろしいです。

スプリント計画とは?

するべき作業を、付箋にはって優先順位をつけます。

今後の2週間のスプリントで何を優先するか?

ポイントは、動くものがあるということです。

もし、機能が大きくて2週間で仕上がらなければ、2週間でできる範囲に、機能を小出しにします。動くものがないと、ユーザーは理解できないからです。上記の場合だとお医者さんかな?

スプリントミーティングのときには、ボードに付箋をはって、機能と工数を書き出します。

私達は、GitHubを利用しています。

小さなプロジェクトなら、これで十分です。

GitHub

他にはREADMEファイルにER図要件環境構成図があります。


それをお互いが確認しながら仕事を進めます。
それだけあれば、どんどん開発していけるのがアジャイル開発のメリットです。

毎日、コードはGitHubにpushしていますので、コードが読めないクライアントも仕事が進んでいることを確認可能です。クライアントは Read権限で、編集はできないけど、見ることはできるようにしています。


そういうふうにすれば、別に会社に通勤しなくても、また海外からでも同じように仕事できます。
通勤時間もったいないです。

よく、家で仕事できますね!と聞かれますが、プログラミングは違います。

深い思考が求められる仕事です。話しかけられた、いままで考えていたものが、ぶっ飛んでしまいます。

会社で電話がなり、同僚から話しかけられる、お茶くんで、FAXもくる。そんな環境でよくプログラミングできると思います。


一つ前の記事 Swiftで日付の比較 SwiftDateの利用 Firebase 忘備録
次の記事 WordPress ページネーション実装