アジャイルジャパン2015のサテライト長野で発表させていただいた弊社の事例のスライドです。 スライドだけだと意図がわかりにくい部分については、手元の発表者メモを加えさせていただきました。

1. 株式会社ライジングサン・システムコンサルティング
代表取締役 岩佐 和紀
ICONIXプロセス FileMaker
アジャイルプロジェクト実践事例
アジャイルジャパン2015
サテライト長野

2. 自己紹介
• 岩佐和紀 （株式法人持ちですがフリーで動いています。）
• ITコンサルタント？ システムエンジニア？ プログラマ？
• システム企画、RFP構築、システム投資戦略構築のサポート
• FileMakerを用いた受託開発と技術コンサルティング
• 20年ほど前にF社のメインフレーマーからキャリアをスタート
• COBOL / dBase / VisualBasic / Delphi / MS-SQL / Access e.t.c..
• 国内外６社で、十数年、社内SEとして修行を積ませていただく
• 7年前に子供が誕生したことをきっかけにフリーランス
• 2009年に理想の仕事・育児環境を求めて横浜から長野県飯綱町に移住

3. 「アジャイル」をキーワードに
この１ー３月で手がけた事例を
お話しさせていただきます。

4. お題の「アジャイル(Agile)」
なのですが・・・

5. ドキュメントを書かない！
計画は立てない！
いきなりコーディング！
カウボーイコーディング！
スクラムこそアジャイル！
アジャイルについて でささやかれる残念な都市伝説

6. Agile【形】
敏しょうな、素早い、機敏な、身のこな
しの軽い、しなやかな、機動的な、鋭敏
な、いきいきした、活気のある、頭の切
れる、頭の回転の速い

7. アジャイル宣言！
いま一度基本に立ち返ろう・・・

8. 右側（古い） 左側（新しい）
プロセスやツール 個人との対話
包括的なドキュメント 動くソフトウェア
契約交渉 顧客との対話
計画に従うこと 変化への対応
アジャイル宣言が言ってること

9. プロトタイピングモデル
設計は基本設計（外部設計）まで
必要なドキュメントは書く
コーディングルールを厳守
リファクタリングを必ず実施
弊社が実際のプロジェクトでやっていること・・・

10. プロトタイピングモデル
まずプロトタイピングについてです。このモデルを採用する目的は、アジャイル宣言で言われ
ている包括的なドキュメント・・・つまり要件定義書や設計書といったお客さんにはわかり
にくいドキュメントで、合意形成をはかるのではなく、よりお客さんにもわかりやすいメディ
アを使って合意形成しましょうよということです。
こでの合意は、まさにシステム化要件であったり、スコープであったり、操作性であったり、
情報の網羅性であったりと様々なことですね。
また、そのプロトタイピングも開発フェーズによって、具体的な方法論を変えています。プロ
ジェクトの最初のほうで創るプロトタイプと、本格的な開発が始まってからつくるプロトタイ
プは、その目的とか情報粒度って全然違いますよね。
なので、プロトタイプをひとつとっても適材適所的な感じで進めます。こ具体的な方法論につ
いてはICONIXプロセスというキーワードで後ほどお話しします。
（発表者メモ）

11. 設計は基本設計（外部設計）まで
次、「いきなりコーディング」に対するカウンターになりますが、弊社では設計フェーズを設
けます。ただし、基本設計（外部設計）までとなります。
外部設計といっても、各社さんいろんな定義があると思いますが、弊社の外部設計の定義を申
し上げておきますと、実装環境に依存しない抽象度レベルの設計という事になります。これも
後ほど、どのレベルまでやるのかのお話しをします。
また、全ての設計が終わってないと次に進まない的なWFモデルのような縛りは設けていません。
要件分析や設計も、アジャイル的な表現をするとイテレーティブに進めます。イテレーティブ
は反復って意味ですね。
設計は全てソフトウェア設計専用のツールを使います。間違ってもExcelやPowerPointといっ
た汎用ツールでドキュメントを書くことはありません。
設計フェーズを設ける目的は、「木を見て森を見ず」の状態を避けるためです。プロジェクトの
開発計画を立案する、DB設計の妥当性を検証する、モジュール分割を戦略的に実施するといっ
たことをより効率的に行う場合には、やはり設計というアクティビティは必要だと思います。
（発表者メモ）

12. 必要なドキュメントは書く
こちらは「アジャイルはドキュメントを書かない」のカウンターですね。弊社では一定のド
キュメントを書きます。但し「納品を目的としたドキュメント」は書きません。ドキュメン
トを書く目的っていくつかあると思うのですが、私は設計とプログラミングの分業制に批判
的な立場なので、俗にいうSEからプログラマへの「製造指示書」的な設計書は書きません。
主にドキュメントを書く目的は２つです。まず開発中は、自分の設計思想の抽象度をあげる
ためですね。システム開発ってどうしても木を見て森を見ずになりがちですが、ドキュメン
トを書くことによってより全体を見渡すことが容易になりますよね。あと、レビューの為と
いうのもあります。やはり設計については効果的なレビューが必要だと思います。ひとりよ
がりのシステムってやっぱりいろいろと問題ですからね。
最後は、運用・保守に入った後に、そのシステムの概要を素早く把握するためですね。なの
で、弊社はシステムを完全にリリースした後に、設計書の最終的なトレースをします。一般
的にリリース後に設計書を書くってNG的な雰囲気ですが、先程も申し上げましたように、う
ちは製造指示書としての設計書は書かないので、リリース後に設計書をトレースするほうが、
よほどその目的にあっていると思っています。
（発表者メモ）

13. コーディングルール
コーディングルールは、「アジャイルはカウボーイコーディング」のカウンターパートですね。
弊社は基本的にFileMakerというどマイナーなプラットフォームを使って開発していますが、
コーディングルールというか、開発標準は文書にまとめて徹底しています。
また、必ずソースコードレビューを行ってルールに反するコードは基本書き直しになりますね。
これは個人的な経験則ですが、コーディングルールに関しては、私がこれまでに経験してきた
WFプロジェクトよりも、アジャイル手法のほうがより厳密なルール化が必要だと思います。
弊社では一定のドキュメントを記述しますが、それでも一般的なWFプロジェクトよりは、ド
キュメントの量が圧倒的に少ないです。
っということは、必然的にコードそのものが仕様書となる必要性が出てきます。汚いコード、
意図がわかりにくいコードは、それだけで負債となってしまうので、保守を担当する技術者で
も共通の理解が得られるように厳密なコーディング規定は、アジャイル手法を用いた開発にとっ
て極めて重要な事だと思います。
（発表者メモ）

14. リファクタリング
最後にリファクタリングです。リファクタリングって既にみなさんご存知かとは思いますが、
念のため簡単にご説明を・・・
リファクタリングとは、外側の振る舞い、つまり機能はそのままに、内部的なコードをより拡
張性のある、もしくは効率的なアルゴリズムにコードを改善・改修する一連の作業です。（ス
イマセン。もし違っていたら後で突っ込んでください。）
うちはプロトタイピングモデルでシステムを外堀から少しづつ埋めていくようなカタチで開発
します。なので、最初のプロトタイプは拡張性等を度外視して、とにかく早く動くものを目指し
て開発します。
そしてプロジェクトの後半になってきて「おおよそ必要とされる機能や振る舞いが見えた」状
態になってくると、今度はそのコードをリファクタリングして、拡張性やアルゴリズムの効率性
的なものを最適化していきます。
こんな感じで開発をしています。
（発表者メモ）

15. 前談はこの程度にして・・・

16. 案件の概要
ざっくり
サービス業さんのコールセンターの立ち上げに伴う
顧客管理システム（CRM）の開発・導入支援。
目的
問い合わせのあった見込客へ効率的にアプローチして
確実にクロージングへ繋げたい。（成約率を上げたい）
ポイント１ 社内にコールセンターの立ち上げ経験者はいない。
ポイント２
そもそもコールセンターを立ち上げてうまくいくか
どうかわからない。
ポイント３ CRMパッケージの導入したが、求める成果を得られていない

17. プロジェクトの体制
担当役員
情シス部門マーケ部門
RSC
PJコーディネータ プログラマさん
通常だと窓口は情シスか利用
部門になるが、今回は担当役
員が窓口を担ってくれた。
クライアント
チームRSC

18. ICONIXプロセス
FileMaker
開発手法とプラットフォーム

19. FileMakerプラットフォームとは？
AppleInc.の100%子会社であるFileMakerInc.が開発しているクロスプ
ラットフォームのデータベースソフトウェア。最新版は13。当初はカー
ド型であったが、バージョンアップ毎に様々な機能を追加してきた。
かなりマイナーな存在であるが、テラバイト・数千ユーザレベルのデー
タベースも構築できる。（海外では大規模な開発事例が多数あり。）

20. ICONIXプロセスとは？
ICONIXは、ラショナル統一プロセス（RUP）やアジャイルソフトウェア開発よりも前
から存在するソフトウェア開発方法論。
RUPと同様にユースケース駆動であるがRUPより軽量である。XPやアジャイルのアプ
ローチとは異なり、ICONIXは必要十分な要求と設計のドキュメントを作成する。

21. 要件分析 予備設計 詳細設計 実装
ICONIXプロセスの４フェーズ

22. より詳しい内容は、ICONIXプロセスと
FileMakerの説明動画をアップしている
弊社オフィシャルサイトの
ブログをどうぞ！
ICONIXプロセス FileMaker 検索

23. UIモックアップを使ってスコープをざっくり決定
FileMakerで最初のプロトタイプを作成
プロトタイプを徐々に熟成させていく
全機能を網羅したら一気にテスト
リリース（受入テスト・運用テスト）

24. 最初にGUIのモックアップを
作成するというところが
ユニークです
Balsamiq Mockupsという
専用アプリでモックアップを作成

25. Balsamiq Mockups プロトタイピング 検索
より詳しい内容は、
弊社オフィシャルサイトの
ブログをどうぞ！

26. モックアップの説明動画を作成してクラウドで共有
作成したモックアップは、全て説明動画を作成してGoogleDriveでお客さんと共有しま
した。弊社のプロジェクトではモックアップの説明以外にもかなり動画を使います。
動画を作成しておくことで、同じことを何度も説明しなければならないといった状況や、
ミーティング日時調整の煩わしさ等を防ぐことができます。またクライアントさんとし
ても、繰り返し視聴して理解を深めるといったことができます。
WFのプロジェクトってドキュメントが命って感じですが、メラビアンの法則ってのが
あって、その法則によると、文字に由る情報伝達は全体の７％しか伝わらないと言われ
ています。
そもそも日本の技術者には、テクニカルライティングについてしっかりとしたトレーニ
ングをうけたという人がほとんどいません。技術文書を書くという基本的なスキルをほ
とんどの技術者が持っていないにもかかわらず、ドキュメントの完成度を重視するプロ
ジェクトをやっているわけです。
（発表者メモ）

27. システムの輪郭をプロトタイピング
一般的なアジャイルだと、優先順位の高い機能から少しづつ創っていくの
が原則です。しかし弊社の経験上、その方法では、ユーザさんがシステム
の全体像を理解できません。
その結果、極めて限られた機能の操作性や機能の網羅性といった各論に終
始してしまう可能性があります。
弊社では、それを回避するために、まず開発スコープ全体の機能を実際に
操作することができるプロトタイプをつくって全体像を理解してもらい、
そこから各論の機能を作りこんでいくという手法をとっています。
但しこれは、極めて開発生産性の高いFileMakerプラットフォームを採用
しているからこそできる方法論だと思います。

28. 【超重要】
プロトタイプは
いつでも
クライアントさんが
評価できる状態にしておく！！

29. 最初の２週間はフィージビリティスタディ
つぎの１週間はペアプログラミング
担当を割り振って具体的な開発に突入
極めて順調に立ち上がった

30. コードレビューの様子を動画で共有
仕様変更内容の説明会議を動画で共有
設計レビューの様子を動画で共有
開発テクニックを動画で共有
弊社PJでの動画活用例

31. プロジェクトマネジメントには
Pivotal Tracker

32. テスト業務の管理にはTestRail

33. ビデオチュートリアルが充実

34. TestRailとPivotalTrackerの
自動連携でバグトラッキング

35. こういったプロジェクト運営の結果
契約期間満了の3週間前には
ほぼ全機能の開発を完了

36. プロジェクトに参加した
プログラマさんが
打ち上げの焼き肉パーティで
発したひとこと・・・
この仕事10年やってますが
こんなホワイトなプロジェクトは
はじめてでした・・・

37. Q & A

38. ありがとうございました！