AgileJapan2014 徳島サテライト感想(1)

AgileJapan2014 徳島サテライト感想

AgileJapan2014の徳島サテライトを開催した。当日は主催者としての裏方作業に追われてゆっくり話を聞く余裕がなく、コンテンツについては断片的な記憶しかない。主にその時に聞こえてきた内容にフォーカスして思うところも含めてとりとめもなく書き留めることにする。

徳島サテライト実施までの経緯

AgileJapan2014が今年も開催されると聞いた直後に、実行委員の羽生田さんから産直セッションの企画と実施依頼があった。更には、今注目の徳島県神山町からの中継をお願いされた。先日、未来ダイアログ in 神山のイベントに参加しそこねていたので、個人的にはチャンスだと思い羽生田さんの提案に飛びついた。

最初は産直セッションだけ、という話にして、松山からAgile459の面子だけで神山に伺って、産直セッションだけ実施しようとしていた。松山から神山町までは車で3時間半ほどであり、移動時間だけでAMを費やしてしまうからだ。

しかし話を進めていくうちに、せっかく徳島に行くのだからサテライト名義でやらないともったいないという気がしてきた。愛媛サテライトは、AgileJapanがサテライト開催をはじめた2011年からずっと開催していたこともあり、四国でのサテライト開催の歴史を止めたくなかった。

集客などはそれほどせずにサテライト開催で参加者を募ったところ、関西から馴染みの方々が来てくれたり、徳島県在住の方も来ていただけた。結果的には、無理やりだがサテライト開催にしてよかった。

産直セッションについて

私は司会と拠点とのSkype連絡なども同時にやっていたため、話を聞くことにあまり集中できていなかった。そのため詳細の部分については割愛するがが、リモートワークという観点で登壇者の皆さんの話を聞いた印象は拠点が離れていることを制約条件と受け入れて、徹底的に仕事上のインペディメント(障害となるもの)を発見し改善し続けているという印象を持った。どちらかの拠点が我慢するのではなく、両者が課題をつまびらかにした上で御互いに寄り添って改善していく。この地道な繰り返しが、ストレスのないリモートワークを実現したのではないか。

「プロジェクトがリモートで行われるから、その間に必要な設備を整えよう」という短期的視点ではなく、長い目で互いが快適に仕事をして成果をだすための設備投資のように思える。リモートワークにどこまで本気で取り組んでいるかという姿勢の現れなのだろう。

その姿勢の現れとして本気の設備投資が求められる。ダンクソフトの本橋さんのワークスペースには、東京の状況を常時映し出すするスクリーン、プロジェクター、スピーカーシステムがあった。逆に神山の状況を常に表示するカメラも設置されている。コンセプトはスクリーンの向こうに別拠点のオフィスがあるだそうだ。

この様子は、Agile459の荻野さんの事例と比較すると面白い。荻野さんの場合は、愛媛に移住した荻野さんが「愛媛でリモートワークをさせてもらっている」という恩義を会社に対して感じている状況の中で、本人が主体的に状況に適応し変化していった事例だ。ダンクソフトさんの場合は東京、徳島、神山の3拠点全体として変化していった事例と受けとった。両者に共通なのはリモートワークをうまくいかない理由にしないよう、妥協せず改善し続けたという点だろう。

広島サテライトの中継について

こちらも、回線品質の調整などのため裏方作業をしていてちゃんと聞けていなかったのだが、シャープさんが部署としてアジャイルに取り組む事例で非常に興味深いし、大きな組織の中でのチャレンジは様々な御苦労があったと思う。

ただ、その前の産直セッションである徳島のリモートワークへの取り組み事例と比較して感じたのは、徳島の事例はあくまでも「リモート拠点間で仕事をしないといけない」という状況の中で、少しずつ改善を積み重ねての現在があると感じたのだが、広島の事例は、「価値創造」という大きな御題目があり、その中でアジャイルの狙いは列挙されてはいたが、なぜそのプラクティスを実践する必要があったのか についてはそれほど深く言及されていなかったと感じた。

言い替えると、徳島の事例はベイビーステップで改善する理由があって、その都度階段を登ってきた自然なイメージを受けたが、広島の事例は、いきなり多くの階段を用意してしまい、無理矢理よじ登っていったようなイメージを受けた。

例えば、スタートアップ界隈で使われている、Experiment Boardというツールがある。これはビジネスモデルにおける仮設検証をスムーズに進めるためのツールだ。例えば開発プロセスの改善においても、このボードを使うことで、抱える課題に対しての改善、つまり「現在の課題に対しての解決策」を仮説として実施することで検証を積み重ねいったらどうだろうか？などということを想起した。

徳島県庁の事例について

徳島サテライトの独自コンテンツは、徳島県庁の山住さんの事例発表だった。徳島県のシステム開発のプロポーザル案件に「アジャイル開発」という言葉があるという話を鎌玉さんから聞いたので、徳島の鎌玉さんを通じて登壇をお願いしたという経緯があった。詳細は資料参照のこと。

徳島県とアジャイル from Kenji Yamasumi

徳島県オープンデータポータルサイト(Our-Stat（仮称）)構築事業委託業務概要説明書のP8を見ると、以下のような記述がある。

(1) アジャイルソフトウェア開発手法により行うこと。

(2) 作業工程毎に，作業内容，作業担当者，成果物，レビュー方法，懸念事項，開始・終了条件を明確にすること。

(3) 県担当者と調整し，月 2 回以上の進捗会議を設置すること。

(4) 稼働前にダミーデータ，ツールを用い，機能確認，性能試験（負荷試験）を実施すること。その際発見された問題について対応し解消すること。

(5) セキュリティ問題に対する十分なテストを行い，安全性について確認すること。

(6) 各設計書，各機能確認結果の報告は共同レビューとすること。

(1)〜(3)については、特にアジャイル的な進行の特徴を示していると言えるだろう。ただ、P2の全体概略スケジュールをみると、一ヶ月のシステム設計フェーズの後で、5ヶ月ほどのシステム開発フェーズ（アジャイル方式）の後、3ヶ月のテスト及びドキュメント作成フェーズがあり納品という形になっているのには着目しておきたい。（いわゆるハイブリッドタイプに近い）

徳島がOSSを採用する中で、RubyやRoRと出会い、2008年から結果的にアジャイル的な進め方になったそうだ。講演資料にもある「発注者として気をつけないといけないところ」は、いわゆるアジャイルの誤解でもあり、発注者も受注者も意識していないと「単にスコープが肥大化するだけ」「繰り返しても結局全部やるんでしょ」問題に陥ってしまう。この辺はまだまだまだ改善の余地があるだろう。（具体的には「目的や狙いの最小化とゴール設定」「やらないことを決める」など。）

山住さんのお話で印象に残ったのは二点。

一つ目は既存の県の制度の制約の中で「できない理由」を探すのではなく「できる部分」を少しずつ実施して、ありたい姿に一歩一歩近づけているという点だ。（こんな言い方はされてはいなかったが、私はこう解釈した）素晴らしい取り組みだと思う。こういう先駆者の試行錯誤の経緯が公開されてると、他の自治体が取り組む際の参考になる気がした。

二つ目は、山住さんが、倉貫さんの以下の言葉を大事にしているというエピソード。

TwitterやFacebookやGoogleはWFではなくAgileだからこそ生まれた

是非とも更なるチャレンジをし続けて頂きたいと切に願う。