agile japan2014c...
TRANSCRIPT
アジャイル経験0から3年で3億以上を稼いだ道のり
～とある中小ソフトベンダーの請負アジャイル開発実績～
Agile Japan 2014 C-3セッション
2014年6月27日 株式会社 アドヴァンスト・ソフト・エンジニアリング 技術開発部 マネージャー 渡会 健
1965年6月17日生まれ。49歳。ふたご座のO型。
茨城県南部の田舎にマイホームを構える遠距離通勤者。多感な高校生の親でもある。
休日はPTA活動、地域の自治会副会長、地域の子ども会連合の本部役員として、地域に密着したボランティアを行う。
趣味はゴルフ。と言いたいところだがここ3年ご無沙汰してます。
その他の趣味は、写真、日曜大工、映画鑑賞等。
新しいもの好き。まずは何でも試してみるのが信条。
一人で仕事するよりもチームとして仕事をするのが好き。
若い後輩を育てるのも好きで、毎年新入社員をチームに加えている。
人と話をするのも大好きである。
まずは、自己紹介から
2
某工業大学機械工学科を卒業後、某財閥系の宇宙分野のソフトウェア開発会社に入社。
最初の3年は何故か防衛系のハードウェア開発に従事。その後現JAXA（当時はNASDA)のソフトウェア開発に従事する。
1996年～2000年にかけてJAXAに出向し、発注側の立場でシステム開発に関わる。その時にProject Managementに興味を得る。
出向から戻ってきた後は受注側としてJAXA向けのシステム開発に従事。この頃にPMP資格を取得した。
PMP資格を有効に生かすためにProject Managementを専門とするコンサル会社に転職。この頃にAgileに出会う。
2009年にやっぱり現場のモノづくりが恋しくなって現在の株式会社アドヴァンスト・ソフト・エンジニアリングに転職。現在に至る。
社会人としての略歴
3
社名 株式会社アドヴァンスト･ソフト･エンジニアリング 設立 1986年8月 資本金 9,500万円 従業員数 102名 ＊うち技術者は97名、札幌本社38名、東京支店64名
本社 札幌市厚別区下野幌テクノパーク1-2-16 支店 東京都中央区銀座1-28-13 ASEビル 事業 （1）ソフトウェア受託開発 ＊技術者派遣を含む
（2）システム開発、及び導入コンサルティング （3）ソフトウェアパッケージ開発、及び販売 部門 技術開発部、技術営業部（東京）、総務部（札幌） 認証 ISO27001 ＊2008年6月取得
Pマーク ＊2013年4月取得
所属会社の紹介（基本情報）
4
所属会社の紹介（理念・経営状況）
近１９年間、黒字経営と実質的な無借金経営
経営理念「ソフトウェア技術を通じて、社員と家族、そして関係するすべてのお客様の幸せを追求する」
5
所属会社の紹介（Agile事業の位置づけ）
アジャイル開発事業 3年半程前から取組みを開始 現在十数名体制
ベースとなる大手ベンダー系事業 （バリバリのウォーターフォール開発） 【社会インフラを支える事業】
• 航空管制システム • 警察通信指令システム • 消防通信指令システム • 自治体システム • ＥＴＣシステム 等々
現在売上の85％ 現在売上の
15％
6
所属会社の紹介（Agile事業の位置づけ）
アジャイル開発事業 3年半程前から取組みを開始 現在十数名体制
ベースとなる大手ベンダー系事業 （バリバリのウォーターフォール開発） 【社会インフラを支える事業】
• 航空管制システム • 警察通信指令システム • 消防通信指令システム • 自治体システム • ＥＴＣシステム 等々
現在売上の85％
アジャイル開発事業 対応できる技術者を増やして体制強化し拡大する計画
現在売上の15％
全体売上30％以上を目標 売上規模は変えずに現状維持
7
出会いはコンサル時代。2008年の秋頃でした。
ある企業の基幹システム再構築PJにPMOとして参加していた時のことでした。
再構築すべき対象システムのデータモデルを検証するために、プロトタイプ版を作成することになりました。
そのプロトタイプ版をAgileで作ることになりました。
自分自身はその営みには本格的にかかわっていなかったのですが、スプリント毎の打合せにPMOとして進捗管理の観点で参加させていただきました。
Agileとの出会い（経緯）
8
良かった面
現場が楽しそう。
本当に仕様変更を短時間で実現している。
スプリントごとに成果が見えるので逆に安心。
若手（当時の3年目くらいの技術者）が急速に成長しているのがスプリント終了時ごとにしか会っていないのに感じられた。
タスクボードやバーンダウンチャート、KPT等のプラクティスが新鮮に感じた。
疑問に思った点
CI等の道具立てを準備するのは大変そう。
メンバの役割を明確化していなくて大丈夫なんだろうかと不安になった。（テスト担当とか）
ゴールはどうやって明確化しているんだろうか？
Agileとの出会い（インプレッション）
9
良かった面
現場が楽しそう。
本当に仕様変更を短時間で実現している。
スプリントごとに成果が見えるので逆に安心。
若手（当時の3年目くらいの技術者）が急速に成長しているのがスプリント終了時ごとにしか会っていないのに感じられた。
タスクボードやバーンダウンチャート、KPT等のプラクティスが新鮮に感じた。
疑問に思った点
CI等の道具立てを準備するのは大変そう。
メンバの役割を明確化していなくて大丈夫なんだろうかと不安になった。（テスト担当とか）
ゴールはどうやって明確化しているんだろうか？
Agileとの出会い（インプレッション）
単純に面白そうだと感じました。 いつかは自分でもやれたら面白いのにと、
漠然と思いました。
（ただ、その時はその程度で終ってしまいましたが・・・）
10
現場が恋しくて今の会社に転職したのですが、驚くことに100名程度の会社の割にいわゆるGeek系のメンバが複数在籍していました。
最初に私がPMとして関わった比較的大規模なバリバリのWF業務で、たまたまこのGeek系メンバが配下に入ることになりました。
で、そいつがこう言うのです。
お恥ずかしながら、それまでチケット管理システムなんて使ったことが無かったので、不安もありましたが新しモノ好きの私としては反対する理由もなく導入してみました。
転職先にはGeekがいた！
Redmine入れません？ Geek
11
で次に彼はこう言うわけです。
確かに、Redmineを入れて構成管理ツールを入れるとあら不思議、最初は戸惑っていた10数名いた他のメンバ間の情報共有がスムーズになるじゃないですか。開発ツールって正しく使うととても効率化につながるなと体感した出来事でした。
今思えばタスクボードの基礎となる考え方がチームに根付いたのもこのPJで1年近くこのやり方に慣れてきたことも今思えば原因の一つだったかもしれません。
Redmineの次は構成管理ツール
Redmineに連携する構成管理ツール入れましょう！
Geek
12
工程が進みテスト工程に入りました。で更に彼はこう言うわけです。
テストコード書いたり、WF用の品質報告書を書くのは大変でしたが、結合レベルのバグ混入が減ったり、人為的ミスのデグレや再テスト時の工数削減効果に驚いたものでした。
WFでここまでやるのは結構勇気がいりましたが、ここで得たノウハウはAgileを始めた時にかなりのアドヴァンテージとなりました。
そしてCI、自動テストへ
Jenkins（CI環境）とUnitTest（自動テスト環境）も導入しましょう！ Geek
13
大型PJが終わってほどなく、規模は2人/月程度ですが研究開発案件を受注しました。
契約形態は準委任契約。
で、研究開発という特性から最初にきちんと設計をしてモノを作るというスタイルではいろんなことが試せないので、Agileとまでは行かないまでもかなり自由なスタイルで実施しました。
打合せは２Wに1回の頻度
最初に今回はこういうことを目指しましょうとお客様との方向性合せの打合せを行う
２W後にそこまで作ったものをお客様環境で動かし、その結果をみて次の目標を決める
どこかで見たようなスタイルですよね。Agileでやるって決めてたわけじゃないけど【もどき】を経験できたのが、本格的に私の中に眠っていた何かに火をつけたみたいです。
次なるはAgile【もどき】体験
14
きっかけは、弊社の営業部が持ってきてくれました。
「昔付き合いのあった人が独立してコンサルをやっているんだけど、その人のお客さんがシステムを作りたいと言っている。でも、そのお客さんは大手ベンダーに頼んで良い目を見たことないので知り合いの中堅どころのベンダーないですかと相談された。」との事。
そのお客様はいわゆるユーザ企業で、欲しいものが手に入ればどんな開発プロセスでも、言語でも何でもよい。ただし、欲しいものを完全に文書化することも難しいので相談しながらやりたいと言うお話でした。
そこでこれまでの経験が頭の中で突然つながって、、、
Agile始めました（ファーストユーザとの遭遇）
Agileでやってみよう！！！
じゃあ、ついでにScalaも使っちゃい
ましょう。
私
Geek
ボソッ
15
お客様は、「欲しいものが出来れば何でも良い」と言っていただけており、難なくAgileでやることを了承してくれました。
問題は自分の会社です。
ただ、弊社の場合マネージャーの権限はかなり大きなものを許されていて、結果を出しさえすれば基本OKと言う風土があります。
とは言え、WFしかやったことのない会社です。
正直、、、
「結果さえ出せば問題ない」と言う気持ちで始めちゃいましたと言うのが本当のところです。
Agile始めました（会社の説得）
業務を開始して暫く経つまで大々的には Agileでやるとは宣言しませんでした。
（部長にはコソッと言いましたけど。。。）
16
【契約形態】
やっぱり日本のユーザ企業。Agileだからと準委任にはしてもらえません。請負でした。でもそこはリスクを取って受入れました。
【見積もりどうした】
JUASが発表している1画面1人月という指標をベースに見積もって、「Agileでやるからこの7割の金額で請負います。」と言って納得してもらいました。見た目3割安で発注できるという割安感を武器にしました。自分自身それでもAgileなら実現できると言う妙な自信もありました。（今考えると根拠はほとんどありませんでしたが）
【要求はどう定めた？】
最初に要求定義フェーズと銘打って、徹底的にお客様から要望を引き出しました。その際にはどんな機能が欲しいかでなく、どんな業務を実現してそれにより何の価値を得たいかを中心に行いました。
要求定義書は作りましたが、あくまで指標であり、出来上がったシステムが正であるとはじめから説明して始めました。
Agile始めました（契約形態、見積、要件定義）
17
弊社内
【体制】
最初のAgileとしては、難易度の高めな10名越えの体制でした。
直接お客様と調整するのは現場非常駐のコンサルタントの方でした。そのため、弊社内にもプロキシプロダクトオーナーを置きました。
アジャイルコーチを呼ぶ余裕（予算）もなかったので、ちょっと外から見た経験しかない自分がコーディネータとして参画しました。
Agile始めました（体制）
スクラムマスター
プロキシ プロダクトオーナー
コーディネータ （私）
お客様
プロキシ プロダクトオーナー
引合いをくれた コンサルタント
打合せメンバ
メインPG （Geek)
メンバ メンバ メンバ メンバ
メンバ メンバ メンバ メンバ
18
最終結果として成功しました。黒字もでました。
メンバも仕事が楽しいと言ってくれました。
何より技術力の向上において本当に目を見張るものがありました。
Agileのノウハウを蓄積できました。特に教科書通りやれば良いってものじゃないことを一番学びました。
お客様にもご満足いただけており、現在も保守契約を続けさせていただいております。
社内でもAgileでちゃんと黒字が出せるんだって言う証明が出来たので、この後の社内説得がしやすくなりました。
Agile始めました（顛末：良かった点）
19
アジャイルコーチがいなかったので、全てが手さぐりで大変でした。
スクラムマスターの負担が大きくなりすぎました。最初のAgileとしてはメンバが多かったこともあり、主にチームビルドに苦しみました。
いくつかのプラクティスについては素地が出来ていたものの、初めてのものが多く、きちんと機能するのに時間がかかりました。
二重のプロキシプロダクトオーナーには苦しめられました。しかし、動くものをスプリントごとに提示することで、溝は徐々に埋まり、最終的にはご納得の得られる内容になりました。
変更要望はやっぱり出ました。当初予定していない機能もそれなりに実装しています。その代り、当初予定していて作らなかった機能もあり、差し引きで言うと、ちょっと増えたかな程度に収めることが出来ました。
テストファーストを目指しましたが、殆ど実現できませんでした。
Agile始めました（顛末：反省点）
20
弊社ではチケット管理システムJIRAの日本代理店であるRickSoft様とパートナー契約をさせていただいています。（販売ではなく、主にカスタマイズ開発において）
RickSoft様にパッケージ導入と言うことでお声掛けがあったものの、簡単なカスタマイズでは補え切れない要求だったので、弊社にやってみませんかとお鉢が回ってきました。コンペ案件でした。
概要としては医療系団体で最終的に5万人が利用する社内SNSを構築するもので、これが2nd Agileでした。
提案-コンペの時期は1st Agileの中盤のころで、勢いに乗っていた我々は最初からAgileでやると提案をしました。（実施は1st 後）
競合（ほとんどがパッケージベンダー）の有る中、価格では一番高かったようですが総合評価で上回り、コンペを勝ち抜くことが出来ました。（後で聞いたら、途中途中で動くもので確認できるという提案が決め手となったようです。Agileで提案して良かった。）
2nd～3rd Agile（次はコンペ）
21
2nd Agileを実施中に、今度は別のお声掛けを頂きました。まだ仕様も確定していないのに3か月で一つのWebシステムを構築しなければならないとの事。お声掛けいただいたのはネットワークインフラベンダーで、アプリ部分はあまり得意ではないお客様であり、何とか助けて欲しいというものでした。
仕様が決まっていない。でも短期でリリースする必要がある。これこそAgileに最適ではないか？むしろAgile以外では実現できないんじゃないかと思い、Agileで開発することを条件に受託しました。これが3rd Agileになりました。
ただ、当時は 2ndAgileの真っただ中。1st Agileの経験を積んだメンバは全て2nd Agileにアサイン済みでした。そこで2nd Agileチームを半分に分け、未経験メンバを増員して2チームに割り振り無理やり体制を作りました。
2nd～3rd Agile （2チーム並行）
22
元々のチームを2チームに分けた結果、2ndAgile事情をよく知るメンバが両方のチームに存在する状況が生まれました。
きっかけは2ndAgileの負荷が高くなったときに、2ndAgile経験のある3rdAgileのメンバを一時的に助っ人として運用してみたのが始まりでした。
やってみると、全体概要さえ把握して置けば、日々のタスクは毎朝その場で決めるので、PJを跨いだってある程度実施できることに気づいたのです。
そこでスクラムリーダーやプロキシプロジェクトオーナーを除きメンバレベルでは臨機応変にPJを並行して実施する様になっていきました。
これにより、特定技術に詳しいメンバを複数PJで使えるメリットや、どうしても発生する負荷の山谷を効率的に運用できるようになりました。
2nd～3rd Agile （メンバの流動化）
23
2nd、3rdとも納期を守り、黒字を出すことが出来ました。もちろんお客様の評判はよく、どちらのお客様も現在も継続して保守や追加機能開発を行っております。
キーメンバを除き並行してPJが存在してもメンバを流動的に活用するノウハウと実績を得ることが出来ました。
プラクティスもこの間に徐々に改善することができ、現在のスタイルの基礎を築けました。
1stに続き2nd～3rdと連続してAgileの実績を積むことが出来ました。
おかげで、社内でもAgile開発事業展開について理解を得ることが出来、HP等で対外的にアピールすることが出来るようになりました。今回この場に立っていられるのもこの頃の実績の積み上げのおかげです。
2nd～3rd Agile （顛末：良かった点）
24
Agileを行うメンバを社内だけでは確保できなくなってきており、常時協力会社がチーム内にいる状態となっています。
プラクティスもいろいろ試して、これって我々のスタイルには合わないよっていうものも出てきました。
CIや自動テスト、お客様に見てもらうためのステージング環境の構築、リリース手順等々Geekメンバに頼りきりの部分が増え、Geekメンバの負担が大きくなり始めました。
メンバの流動化もすんなりできる者もいれば、なかなか切り替えられない者もいて、全てのメンバが複数PJの掛け持ちをできるわけではないことも分かってきました。
2nd～3rd Agile （顛末：反省点）
25
一度Agileで実施したことのあるお客さまから、引き続きAgileでの追加機能開発や派生システムの開発等を頂けるようになりました。
HP等でアピールすることで、興味を持っていただいたお客様からのお問い合わせが切っ掛けになって受注につながるケースも最近増えてきています。
そんなこんなで気が付けば、次ページに示すような実績を積み上げることが出来ました。
ちなみに、各案件の累計売上には、その後に派生したAgileでの追加開発や年間保守費も含まれています。
その後はAgile実績を積み上げ続けた
26
これまでのAgile売上実績
●リース業向け問合せ管理（1st Agile 累計売上：100,000千円）
●官庁向けRSS配信情報のポータルサイト（3rd Agile 累計売上：20,000千円）
●放送業向けデータ放送用テストケース生成API（累計売上：5,000千円）
●医療系向けイントラSNS（2nd Agile 累計売上：36,000千円）
●ISP業向けバックボーン情報管理システム（累計売上：150,000千円）
●インターネット情報発信業向け基幹システム用API（累計売上：24,000千円）
全累計売上 335,000千円 27
ここまでは、どうやってAgile経験0からAgileを始めることになって、3億を超える売上実績を上げてきたかの道のりの説明をしてきました。
ここからは、この実績を上げるために模索してきた我々のAgileが現時点ではどういうスタイルなのかを説明していきます。
我々のAgile
28
基本的に請負です。
本来ならば準委任にすべきなのは知っています。請負だとリスクが高いことも。
ただし、日本のほとんどの企業がシステムを開発する場合、お客様のルールで請負しか選択できない場合が多いのも実態です。
お客様が契約形態を譲ってくれないとチャレンジできないというのもどうかと思い、リスクを取って請負でやっています。（リスクヘッジもしていますが。）
でも、一番はお客様が満足のいく価値（機能じゃなくて）を提供してお互いの信頼関係が築ければ、そもそも契約形態云々の問題に発展しないので、そちらを目指すべきだと考えています。
まさに「契約交渉よりも顧客との協調を」だと思います。
契約形態
29
我々のAgileの基本的な流れ
Scrumベースのアジャイル手法にて開発します。よってスプリント（原則2週間）毎にお客様に実際に動作するシステムを提供し続けていきます。
要件定義には、マインドマップやBPMN（Business Process Modeling Notation)を導入して、お客様が真に必要としている価値を掘り出します。
テストはTestLinkやSelenium、RSpec、Capybara等を導入し自動テストを原則とします。もちろんCI環境は必須です。
日々の作業はチケット駆動型で行い、ツールとしてRedmineを導入しています。もちろんタスクボードは付箋を用いて壁に張り出しています。
チーム内進捗はバーンダウンチャートで確認です。これも敢えてアナログで日々手書きで更新しています。
スプリントの開始時はメンバ全員でタスク洗い出しを行い、そのスプリントで実施すべき作業をチケット化します。
30
我々のAgileでのお客様に対する利点
お客様の負担を軽減した
Agile開発手法で実施します
スプリント１ スプリント１ Sprint 1
(2 Weeks)
例：データベース機能
Sprint 2
(2 Weeks)
例：フォーラム機能
コラボレーション機能
スプリント３
（２W） Sprint 3
(2 Weeks)
試用環境へ
リリース
試用 試用環境へ
リリース
例：ライブラリ機能
アンケート機能
試用 試用環境へ
リリース
以後繰り返し
お客様の負担を軽減するため、弊社で実績のある試用とそのFeedbackの組み合わせた形のAgile開発手法を提案します。
※ 本来のAgile開発の定義では、一日に何度も意思決定をしていただく必要があり、
お客様の負担が大きくなるため。
Feedback
Feedback
31
お客様に説明しているSprintの流れ
開発手法とレビュー方針
お客様との定例会 詳細設計
及び開発 タスク洗い出し
結合テスト
タスクごとに
繰り返し実施
初日 ２日目～最終日前日 最終日
試用の
Feedback
リリースと
デモンスト
レーション
設計の承認
（外部設計
レビュー）
進捗報告
次Sprint分の設計（外部設計レベル）
前Sprint分の試用（プロトタイプレビュー）
次Sprintへ
前Sprintで承認された
次Sprint分の設計
試用フェーズによる
Feedback
実施中のSprint 前Sprint 次Sprint
最終日に定例会にてまとめてレビューしていただくことにより、お客様の負担を軽減しつつ、よりシステムの利用イメージがつかみ易い流れとします。
実際に動作するプロトタイプレビューを体感しながら、Sprint
内で製造と次Spirntに向けた設計フェーズを同時平行で順次進めていきます。
32
【ショートミーティング（朝ミ・夕ミ等）】
朝ミーティングについては、大規模PJの時から習慣づけていたので特に混乱なく導入できました。ただ、その時何を話すかは少し紆余曲折を経ましたが。全体状況を話した後その日にやるタスクを個人個人でタスクボードから選択し、これをやります宣言をすることで落ち着きました。
夕方ミーティングについては、最初はどのタイミングで行うのが良いか探り探りでした。結局今は定時15分前に開始するという習慣が身に付きました。
朝ミ・夕ミ以外でもいろいろなショートミーティング（30分以内）を開催しています。例えば、お客様の打合せ内容のフィードバックとか、技術的に難易度の高い機能の実装方法の検討など。
目的に合わせてメンバを絞り行っているので、プロジェクトルーム内では頻繁にどこかでショートミーティングが開かれています。
我々のプラクティス
33
【タスクボード＆バックログ】
こちらはRedmineでのPJ運用について既にメンバが慣れていたことが功を奏し、スムーズに実施できました。
付箋を壁に貼るアナログで実感を得つつ、Redmineでバックログを残すという使い分けが出来ました。
ただ、タスクボードの前準備であるタスク洗い出しについては、現在でも難しい課題の一つとなっています。その主な原因は粒度です。PJの特性やその時々のチームメンバの力量によって最適な粒度が異なるからです。これについてはスプリントを重ねながら調整していく事でしか現在のところ対処できていません。
我々のプラクティス
34
我々のプラクティス
• 実際のタスクボード
A pj
未実施タスク 実施タスク 完了タスク
B pj
優先度
緊急度
35
【バーンダウンチャート】
これは最も苦労しました。現在も克服したとは言えない状態です。
それは、何度やってもスプリント開始時から終了時にかけてそうタスク数が増加するからです。
一時期は、その原因を探るため、バグのバーンダウンチャート、追加要望のバーンダウンチャートと分けてカウントしてみたりもしたのですが、原因を突き止めきれませんでした。
現在では総タスクが増えること自体は我々のAgileの特徴じゃないかとあきらめ、容認することにしました。
その代りあまり教科書には載っていませんが、消化タスク数（我々はベロシティと呼んでいる）という指標を加えて、それと残タスク数、総タスク数の相関をみてコントロールすることにしています。
我々のプラクティス
36
我々のプラクティス
総タスク数
残タスク数
理想の残タスク
総タスク数
残タスク数
消化タスク数
タスク数
タスク数
経過時間 経過時間
良くあるバーンダウンチャート 弊社のバーンダウンチャート
37
我々のプラクティス
• 実際のバーンダウンチャート
38
【テスト環境（CI＆自動テスト）】
こちらは大規模PJの時にノウハウをある程度貯めていましたので苦労はしたものの何とかこなせました。
これについては、Geek君の貢献が相当大きかったと思います。
メンバが作業しやすいように環境を常に進化させてくれていたおかげでメンバ自体は、やり易かったようです。
その代り、Geek君がいないと環境を作り維持することが出来ないのも事実であり、ここを担える後進を育てることが急務となっています。
我々のプラクティス
39
【ペアプロ】
このプラクティスは我々にはあまり定着しませんでした。と言うのも一部Geekを除くと4年目以下の若いメンバが多く、技術力の差があり過ぎて成立しなかったからです。
その代り、Geekのコードレビューを通らないとコミットできないルールを作り、教育と製造品質の担保の両方を保つようにしています。
ただし、メンバが増えてくるとGeekの負担が大きくなる仕組みでもあります。
テスト環境の問題と同じ構造なので、チームメンバ全体の技術力向上についても急務となっています。
我々のプラクティス
40
【テストファースト】
1stAgileの頃からチャレンジしていますが、我々のAgileではいまだに実現できていないプラクティスです。
と言うのも、テストファーストを実現するにはそれ相応の技術力が必要だからです。
現在はペアプロの時に述べたようなチーム事情でGeekを除くとその水準に達したメンバがとても少ない状況です。
これも遠回りになりますが、若手の技術力向上こそが近道だと思っています。
我々のプラクティス
41
【プロキシプロダクトオーナー】
請負契約で実施していることも遠因にありますが、お客様自身がAgileを負担に感じず、利益を享受するために我々のAgileでは必須のプラクティスになっています。
最初は教科書通りスクラムリーダと別の人を立てていましたが、必ずしもそれが良いとは限らないこともわかってきています。
最近では兼務するケースが多くなってきています。
また、プロキシプロダクトオーナーを用いる際に必要なのは、２Wに一度程度の限られた時間でどれだけお客様の意図を把握できるかのコミュニケーションスキルだったりします。
もちろん打合せ以外にも電話などで随時問い合わせることも行っています。
最近問題になっているのはお客様との打合せが長くなる傾向にあることです。長いときは半日に及ぶ場合もあります。改善ポイントだと感じています。
我々のプラクティス
42
【KPT】
やってみると、これほど面白く、為になるプラクティスはありません。
普段からチーム内コミュニケーションの活性化を図ってはいますが、全員の前でそのスプリント内で感じたことを自分の言葉で発表できるので、みながどんなことを考えてAgileを実践しているのが良くわかります。
でも、長く同じやり方を続けていくと、幾分マンネリになることが往々にして発生します。
その時は、ファシリテータを持ち回りにしたり、やり方を変えてみたり徐々に変化させていくと良いこともわかってきました。
プラクティス自体もAgileであり続けることが大事だという事なんだと思います。
我々のプラクティス
43
ASEでのアジャイル開発の進め方
• 実際のKPTT
Keep Problem Try
Thanks
44
本格的にAgileをやる前にAgileに必要な基本的なプラクティスを徐々に身に着けられる準備期間を偶然にも持てた。
準備が整ったところにタイミングよくAgileに最適なユーザ企業からの直需を受けることが出来た。
そして更にタイミングよくAgileに最適な次のお客様に恵まれた。
Agileにチャレンジすることを会社に見逃してもらった。
我々の仲間の中にGeekが居た。
まとめ（どうしてここまで来れたのか）
45
ラッキーでした
本格的にAgileをやる前にAgileに必要な基本的なプラクティスを徐々に身に着けられる準備期間を偶然にも持てた。
準備が整ったところにタイミングよくAgileに最適なユーザ企業からの直需を受けることが出来た。
そして更にタイミングよくAgileに最適な次のお客様に恵まれた。
Agileにチャレンジすることを会社に見逃してもらった。
我々の仲間の中にGeekが居た。
まとめ（どうしてここまで来れたのか）
46
ラッキーでした 本当にそう でしょうか？
まとめ（どうしてここまで来れたのか）
47
常に今以上を模索し、気になったら試し、準備をし、 チャンスが来たらリスクを負ってチャレンジしたこと。
仲間を信じ、提案を聴き入れ、良いと思ったら一緒になって行動したこと。
関わってきた様々な人たちと良い関係を築いてきたこと。
今以上に我々のAgileを進化させていきます。
Agileを行えるメンバを増やして業務拡大に臨みます。
Agileだけにこだわるのではなく、常に新しいものを探し、見つけたらチャレンジします。（ex. Ruby on Rails、Scala)
そして・・・・
この社是を実現していきます。
そしてこれから
48
経営理念「ソフトウェア技術を通じて、社員と家族、そして関係するすべてのお客様の幸せを追求する」
最後に
49
ご清聴ありがとうございました。 この発表で、Agileに今一つ踏み出せない方々の背中を少しでも押すことが出来れば、望外の幸せです。 ご質問・ご用命などございましたら、 下記までお願いいたします。 www.ase.co.jp [email protected] 渡会 健（わたらい たけし）