Embed Size (px)
Citation preview
株式会社ライジングサン・システムコンサルティング 代表取締役 岩佐 和紀
ICONIXプロセス × FileMaker アジャイルプロジェクト実践事例
アジャイルジャパン2015 サテライト長野
自己紹介
• 岩佐和紀 （株式法人持ちですがフリーで動いています。）
• ITコンサルタント？ システムエンジニア？ プログラマ？
• システム企画、RFP構築、システム投資戦略構築のサポート
• FileMakerを用いた受託開発と技術コンサルティング
• 20年ほど前にF社のメインフレーマーからキャリアをスタート
• COBOL / dBase / VisualBasic / Delphi / MS-SQL / Access e.t.c..
• 国内外６社で、十数年、社内SEとして修行を積ませていただく
• 7年前に子供が誕生したことをきっかけにフリーランス
• 2009年に理想の仕事・育児環境を求めて横浜から長野県飯綱町に移住
「アジャイル」をキーワードに
この１ー３月で手がけた事例を
お話しさせていただきます。
お題の「アジャイル(Agile)」
なのですが・・・
ドキュメントを書かない！
計画は立てない！
いきなりコーディング！
カウボーイコーディング！
スクラムこそアジャイル！アジャイルについて巷でささやかれる残念な都市伝説
Agile【形】 敏しょうな、素早い、機敏な、身のこなしの軽い、しなやかな、機動的な、鋭敏な、いきいきした、活気のある、頭の切
れる、頭の回転の速い
右側（古い） 左側（新しい）
プロセスやツール 個人との対話
包括的なドキュメント 動くソフトウェア
契約交渉 顧客との対話
計画に従うこと 変化への対応
アジャイル宣言が言ってること
プロトタイピングモデル
設計は基本設計（外部設計）まで
必要なドキュメントは書く
コーディングルールを厳守
リファクタリングを必ず実施
弊社が実際のプロジェクトでやっていること・・・
プロトタイピングモデル
まずプロトタイピングについてです。このモデルを採用する目的は、アジャイル宣言で言われている包括的なドキュメント・・・つまり要件定義書や設計書といったお客さんにはわかりにくいドキュメントで、合意形成をはかるのではなく、よりお客さんにもわかりやすいメディアを使って合意形成しましょうよということです。
こでの合意は、まさにシステム化要件であったり、スコープであったり、操作性であったり、情報の網羅性であったりと様々なことですね。
また、そのプロトタイピングも開発フェーズによって、具体的な方法論を変えています。プロジェクトの最初のほうで創るプロトタイプと、本格的な開発が始まってからつくるプロトタイプは、その目的とか情報粒度って全然違いますよね。
なので、プロトタイプをひとつとっても適材適所的な感じで進めます。こ具体的な方法論についてはICONIXプロセスというキーワードで後ほどお話しします。
（発表者メモ）
設計は基本設計（外部設計）まで次、「いきなりコーディング」に対するカウンターになりますが、弊社では設計フェーズを設けます。ただし、基本設計（外部設計）までとなります。
外部設計といっても、各社さんいろんな定義があると思いますが、弊社の外部設計の定義を申し上げておきますと、実装環境に依存しない抽象度レベルの設計という事になります。これも後ほど、どのレベルまでやるのかのお話しをします。
また、全ての設計が終わってないと次に進まない的なWFモデルのような縛りは設けていません。要件分析や設計も、アジャイル的な表現をするとイテレーティブに進めます。イテレーティブは反復って意味ですね。
設計は全てソフトウェア設計専用のツールを使います。間違ってもExcelやPowerPointといった汎用ツールでドキュメントを書くことはありません。
設計フェーズを設ける目的は、「木を見て森を見ず」の状態を避けるためです。プロジェクトの開発計画を立案する、DB設計の妥当性を検証する、モジュール分割を戦略的に実施するといったことをより効率的に行う場合には、やはり設計というアクティビティは必要だと思います。
（発表者メモ）
必要なドキュメントは書くこちらは「アジャイルはドキュメントを書かない」のカウンターですね。弊社では一定のドキュメントを書きます。但し「納品を目的としたドキュメント」は書きません。ドキュメントを書く目的っていくつかあると思うのですが、私は設計とプログラミングの分業制に批判的な立場なので、俗にいうSEからプログラマへの「製造指示書」的な設計書は書きません。
主にドキュメントを書く目的は２つです。まず開発中は、自分の設計思想の抽象度をあげるためですね。システム開発ってどうしても木を見て森を見ずになりがちですが、ドキュメントを書くことによってより全体を見渡すことが容易になりますよね。あと、レビューの為というのもあります。やはり設計については効果的なレビューが必要だと思います。ひとりよがりのシステムってやっぱりいろいろと問題ですからね。
最後は、運用・保守に入った後に、そのシステムの概要を素早く把握するためですね。なので、弊社はシステムを完全にリリースした後に、設計書の最終的なトレースをします。一般的にリリース後に設計書を書くってNG的な雰囲気ですが、先程も申し上げましたように、うちは製造指示書としての設計書は書かないので、リリース後に設計書をトレースするほうが、よほどその目的にあっていると思っています。
（発表者メモ）
コーディングルールコーディングルールは、「アジャイルはカウボーイコーディング」のカウンターパートですね。弊社は基本的にFileMakerというどマイナーなプラットフォームを使って開発していますが、コーディングルールというか、開発標準は文書にまとめて徹底しています。
また、必ずソースコードレビューを行ってルールに反するコードは基本書き直しになりますね。これは個人的な経験則ですが、コーディングルールに関しては、私がこれまでに経験してきたWFプロジェクトよりも、アジャイル手法のほうがより厳密なルール化が必要だと思います。 弊社では一定のドキュメントを記述しますが、それでも一般的なWFプロジェクトよりは、ドキュメントの量が圧倒的に少ないです。
っということは、必然的にコードそのものが仕様書となる必要性が出てきます。汚いコード、意図がわかりにくいコードは、それだけで負債となってしまうので、保守を担当する技術者でも共通の理解が得られるように厳密なコーディング規定は、アジャイル手法を用いた開発にとって極めて重要な事だと思います。
（発表者メモ）
リファクタリング最後にリファクタリングです。リファクタリングって既にみなさんご存知かとは思いますが、念のため簡単にご説明を・・・
リファクタリングとは、外側の振る舞い、つまり機能はそのままに、内部的なコードをより拡張性のある、もしくは効率的なアルゴリズムにコードを改善・改修する一連の作業です。（スイマセン。もし違っていたら後で突っ込んでください。）
うちはプロトタイピングモデルでシステムを外堀から少しづつ埋めていくようなカタチで開発します。なので、最初のプロトタイプは拡張性等を度外視して、とにかく早く動くものを目指して開発します。
そしてプロジェクトの後半になってきて「おおよそ必要とされる機能や振る舞いが見えた」状態になってくると、今度はそのコードをリファクタリングして、拡張性やアルゴリズムの効率性的なものを最適化していきます。
こんな感じで開発をしています。
（発表者メモ）
前談はこの程度にして・・・
案件の概要
ざっくり サービス業さんのコールセンターの立ち上げに伴う 顧客管理システム（CRM）の開発・導入支援。
目的 問い合わせのあった見込客へ効率的にアプローチして 確実にクロージングへ繋げたい。（成約率を上げたい）
ポイント１ 社内にコールセンターの立ち上げ経験者はいない。
ポイント２ そもそもコールセンターを立ち上げてうまくいくか どうかわからない。
ポイント３ CRMパッケージの導入したが、求める成果を得られていない
プロジェクトの体制
担当役員
情シス部門マーケ部門
RSC
PJコーディネータ プログラマさん
通常だと窓口は情シスか利用部門になるが、今回は担当役員が窓口を担ってくれた。
クライアント
チームRSC
ICONIXプロセス ×
FileMaker
開発手法とプラットフォーム
FileMakerプラットフォームとは？
AppleInc.の100%子会社であるFileMakerInc.が開発しているクロスプラットフォームのデータベースソフトウェア。最新版は13。当初はカード型であったが、バージョンアップ毎に様々な機能を追加してきた。 かなりマイナーな存在であるが、テラバイト・数千ユーザレベルのデータベースも構築できる。（海外では大規模な開発事例が多数あり。）
ICONIXプロセスとは？
ICONIXは、ラショナル統一プロセス（RUP）やアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論。 RUPと同様にユースケース駆動であるがRUPより軽量である。XPやアジャイルのアプローチとは異なり、ICONIXは必要十分な要求と設計のドキュメントを作成する。
要件分析 予備設計 詳細設計 実装
ICONIXプロセスの４フェーズ
より詳しい内容は、ICONIXプロセスと
FileMakerの説明動画をアップしている
弊社オフィシャルサイトの
ブログをどうぞ！
ICONIXプロセス FileMaker 検索
UIモックアップを使ってスコープをざっくり決定
FileMakerで最初のプロトタイプを作成
プロトタイプを徐々に熟成させていく
全機能を網羅したら一気にテスト
リリース（受入テスト・運用テスト）
最初にGUIのモックアップを 作成するというところが ユニークです
Balsamiq Mockupsという 専用アプリでモックアップを作成
Balsamiq Mockups プロトタイピング 検索
より詳しい内容は、 弊社オフィシャルサイトの
ブログをどうぞ！
モックアップの説明動画を作成してクラウドで共有
作成したモックアップは、全て説明動画を作成してGoogleDriveでお客さんと共有しました。弊社のプロジェクトではモックアップの説明以外にもかなり動画を使います。
動画を作成しておくことで、同じことを何度も説明しなければならないといった状況や、ミーティング日時調整の煩わしさ等を防ぐことができます。またクライアントさんとしても、繰り返し視聴して理解を深めるといったことができます。
WFのプロジェクトってドキュメントが命って感じですが、メラビアンの法則ってのがあって、その法則によると、文字に由る情報伝達は全体の７％しか伝わらないと言われています。 そもそも日本の技術者には、テクニカルライティングについてしっかりとしたトレーニングをうけたという人がほとんどいません。技術文書を書くという基本的なスキルをほとんどの技術者が持っていないにもかかわらず、ドキュメントの完成度を重視するプロジェクトをやっているわけです。
（発表者メモ）
システムの輪郭をプロトタイピング
一般的なアジャイルだと、優先順位の高い機能から少しづつ創っていくのが原則です。しかし弊社の経験上、その方法では、ユーザさんがシステムの全体像を理解できません。
その結果、極めて限られた機能の操作性や機能の網羅性といった各論に終始してしまう可能性があります。
弊社では、それを回避するために、まず開発スコープ全体の機能を実際に操作することができるプロトタイプをつくって全体像を理解してもらい、そこから各論の機能を作りこんでいくという手法をとっています。
但しこれは、極めて開発生産性の高いFileMakerプラットフォームを採用しているからこそできる方法論だと思います。
【超重要】
プロトタイプは
いつでも
クライアントさんが
評価できる状態にしておく！！
最初の２週間はフィージビリティスタディ
つぎの１週間はペアプログラミング
担当を割り振って具体的な開発に突入
極めて順調に立ち上がった
コードレビューの様子を動画で共有
仕様変更内容の説明会議を動画で共有
設計レビューの様子を動画で共有
開発テクニックを動画で共有
弊社PJでの動画活用例
TestRailとPivotalTrackerの 自動連携でバグトラッキング
こういったプロジェクト運営の結果
契約期間満了の3週間前には
ほぼ全機能の開発を完了
プロジェクトに参加した プログラマさんが 打ち上げの焼き肉パーティで 発したひとこと・・・
この仕事10年やってますが こんなホワイトなプロジェクトは
はじめてでした・・・
Q & A
ありがとうございました！
