私とアジャイルとの出会い(1)

私がアジャイル開発を初めて知ったのは2001年頃、職場においてあった日経コンピュータの記事を見たときでした。

日経コンピュータ 2001/06/04号
特集　究極のソフトウェア開発　エクストリーム・　誌上体験
http://bizboard.nikkeibp.co.jp/kijiken/summary/20010604/NC0523H_421523a.html

そのころ私は初めてのプロジェクト・リーダーを任され、カットオーバーを終えた直後でした。この本に出会ったタイミングは本当に絶妙でした。

やり直せない設計

そのプロジェクトは、典型的なウォーターフォール型の開発プロセスを採用していました。
私がリーダーに任命されたのは、設計工程が終わってプログラミング工程が始まろうとしていた頃です。それまでは他のプロジェクトで開発を行っていて、前任のリーダーからプロジェクトを引き継ぐことになりました。
これまでリーダーをしている先輩たちの姿に憧れていましたので、当初は「初めてのリーダーだし。頑張るぞ！」と張り切っていたのですが、その後は大変な苦難の道が待っていました。

そのプロジェクト、ひととおり設計書はできていたのですが、他社製プログラムとのインターフェースが十分に設計されていなかったり、エラーが起きた後のリカバリー処理に不十分なところがあったのです。

なんとなく気になるところはあったのですが、時間にも余裕がないことからそのままプログラミングするしかない状況でした。大変だったものの、なんとかプログラミング工程は終わり、他社製プログラムとの結合テストが始まりました。

当然、インターフェース部分の不具合を抱えたままコーディングしていますから、結合テストではバグの連続です。

周囲からは「どうして動かないんだ！設計どおりに作っているのか？」「あなたのところが動かないから我々のテストが進まないんだけど」など厳しい声が飛んで来ます。

私としては「まだ設計に不十分なところがあるので、設計をやり直す時間が欲しい」と言いたかったのですが、ガチガチのウォーターフォールでは、そのような工程など用意されてはいませんでしたし、また私自身も初めてのリーダー経験で、状況をうまく説明できるだけの力もなかったのです。

いつまで経っても動かないプログラム、迫る納期・・・大変なプレッシャーが襲いかかり、身体も心もクタクタになってしまいました。
納期前にはお客様のところに長期出張し、関係者がみんな集まって連日遅くまでプログラム修正に励む毎日・・・まあ、典型的なデスマーチです。

最終的には私の上司やお客様が見るにみかねて、設計が足りない部分の再設計やコードレビューを行う期間を設けてくれました。そのおかげで不具合も解消し、メンバーのみんなの頑張りもあって無事納品にこぎつけることができたのですが、自分としては何もできなかったな、という感覚しかありませんでした。

たまたま日経コンピュータ

なんとか完遂できたプロジェクトではありましたが、私自身はひどく落ち込んでいました。

「自分はもうダメだなあ」「この仕事を続けていくのは無理かも」

と、自信もなくしていましたし、

「ソフトウェア開発とは苦しいもの。これからずっとこの苦しみと付き合っていかないといけないのか・・・」

といった仕事への失望感も広がっていたのです。

いまひとつモチベーションのあがらない日々。ある日休憩がてら会社の雑誌閲覧コーナーに行ったとき、たまたまそこに置いてあった日経コンピュータでアジャイルに出会ったのです（主にXPのことについて書いていました）

当時は開発プロセスといえば、ウォーターフォールしか知りませんでしたから、プロジェクトがうまく行かなかったのは「自分に能力がないせい」と考えていました。

でも、アジャイルの「変化を受け入れる」という考え方を知ってからは「設計が不十分だったり仕様変更は普通にあること。それらの変化に柔軟に対応できる方法があるんだ」と強い衝撃を受けたのです。

もしかしたら、この方法を取り入れれば、あんな目に会わなかったかもしれない。
この業界も捨てたものじゃないんじゃないか・・・。

私の中に、一筋の希望が見えてきた瞬間でした。

もし、会社に日経コンピュータを置いてなかったら、私はこの業界にいなかったかもしれないです。
オフィスには雑誌コーナーを設けましょうね(笑)

できるところからやってみよう

それからは「なんとか、このアジャイルの要素を開発業務に取り入れられないか？」が私のテーマとなってきました。

お客様との契約の関係もあって、ウォーターフォールというプロセスそのものを変えることは難しいですが、アジャイルの要素をうまく取り入れて、現状を少しでもよくすることができるかもしれない、という考えはありました。

「すべてを一気に変える事はできないけれど、できるところからやっていこう」

数年後、私は再び新しいプロジェクトを任されることになりました。
3人の小さなプロジェクト、私の他は入社して間のない若い子が2人です。
まだまだ技術も経験も十分とは言えない体制で、苦労は目に見えていました。周りの人たちも心配しています。

でも、私には不思議な勝算がありました。

「若くて真っ白な子たちと一緒なら、やりたいことができるかもしれない」

最初のプロジェクトミーティング、私は彼らに言いました。

「これから毎日、朝会をやろう」

〜つづく〜

次の記事：私とアジャイルとの出会い(2)

ETロボコン2013 中四国春季オープン大会

3月17日(日)、福山大学宮地茂記念館で「ETロボコン2013 中四国春季オープン大会」が開催されました。昨年につづいて２回目の開催となります。

春季オープン大会はETロボコンの参加申し込み期間中に行われるのが慣習になっていて、参加を考えている人たちに、実際にETロボコンというものを体験してもらうことを目的としています。
今回も12チームもの方に参加いただきました。なんと半数以上の方が今年初参加！大変ありがたいことです。

初心者向けプログラミング講習会

春季オープン大会は開発環境の構築とプログラミングの講習会とセットになっているのが大きな特徴です。NXT走行体を購入できていない人向けの貸し出しもあります。
開発環境の構築は意外と手間取るものですし、NXT走行体も安いものではありません。初参加の方にとっては意外と高いハードルとなります。
このようなサポートがあることで初心者の方でも気軽に参加する事ができます。

これだけのことができるのも、福山大学の手厚いサポートがあってのことですね。感謝！

「中四国限定じゃかりこ」の差し入れも。ついでにETロボコンロゴも欲しいところ(笑)

レベルアップした競技会

無事プログラム作成も終わり、午後からはいよいよ競技会です。
競技に慣れていない初心者の方が多いため、以下の特別ルールで行いました。

• スタート直後の坂道は設置しない。
• リタイヤまでの制限時間を120秒から180秒に延長。
• スタート失敗時の再スタートをOKとする（ただし、タイム計測は止めない）

難所に突入するチームも。2年目に入り、レベルアップしているようです。

初心者にとってスタートは大変。実行委員三輪さんによる講習中。

ワークショップ

競技会のあとはワークショップを開催しました。ただプログラムを作って走って終わり・・・ではないのはETロボコン本戦と同じ仕様です。
今回はこれから初めてETロボコンに参加する方が多いこと、学生さんなど、本格的なプロジェクトを未経験の方に向けて「ETロボコン 地区大会までの過ごし方」と題して発表を行いました。
ETロボコンは大会当日にできることは多くありません。如何に大会までの準備を周到に行っておくかが重要ですので、「ETロボコンで成功するための3つのポイント」について説明しました。

• 計画を立てて実行する。
• 情報を集める
• チームをつくる

皆さん、真剣な表情で聞いておられたのが印象的でした。
特に今年から参加する高校生チームの集中力はすごかったですね。目付きは真剣そのもので、こちらの言うことを一字一句残さずすべて吸収してくれる感じ。これはやりがいがあるなぁ〜と思いました。うっかりヘタなことも言えませんけどね^^;責任重大！

表彰式

最後に表彰式です。
地元・福山大学のチームが1・2・3位を独占しました。おめでとうございます！
昨年出場されたメンバーの方もおり、難所も楽々クリアしていました。かなり仕上がりが早く、今シーズンの活躍が期待されますね。

大会の後は・・・福山白熱教室

大会のあとは、有志による懇親会です。
毎度恒例の実行委員長・香川先生の「福山白熱教室」も健在です。
我々実行委員や学生さんに向けて、熱く含蓄のある言葉を贈り込んでくれます！
今年も福山の街は、ETロボコンの行事がある日は熱く燃えるのでありました。

ETロボコン2013 中四国地区実施説明会

3月2日、福山大学宮地茂記念館で「ETロボコン2013 中四国地区実施説明会」を開催しました。
今回は26名の方に参加いただきました。初参加の方や一昨年からの復活組の方などもおり、参加チーム数の増加が期待できそうな顔ぶれでした。

実行委員長　香川先生による大会概要の説明です。

会場では、NXT走行体のデモも行われました。さりげなく、「mruby-NXT」のリーフレットも展示しています。

毎度おなじみ、中四国ダミーカー「備中線行者」は今年も健在です！

質疑応答のコーナーでは、今年から新設される「アーキテクト部門」に関するもののほか、次のような質問がありました。

Q.技術教育ではモデルの書き方をどの程度教えてもらえるのか？事前の予習は必要か？

できるだけ初心者にもわかるように努力はしたいですが、実際には細かいUMLの文法まで教える時間が足りないと思います。優秀モデルのモデルを見たり、UMLの参考書で勉強しておくことをオススメしました。

以下は代表的な参考書です。興味のある方はご覧になってみてはいかがでしょうか。

その場でつかえるしっかり学べるUML2.0

はじめて学ぶUML 第2版

独習UML 第4版 (CD-ROM付)

これからも、よい参考書や問題集があれば、紹介していきたいと思います。

部屋がキレイな人は収納上手？

前回の、会話量とコミュニケーションにつづき、テレビで見たことのある話題について。

今度の番組では、

荷物が散乱し、とても散らかった部屋があります。この部屋を以下の2グループに片付けてもらいます。
・いつも部屋をキレイにしている人たち(Aグループ)
・いつも部屋が散らかっている人たち(Bグループ)
より短い時間で、荷物をすべて収納できたグループの勝ちとします。

という実験をしていました。

私は「それはもちろん、部屋をキレイにしている人が早く片付けられるに決まってるじゃん？」と思っていました。

しかし結果は意外や意外、いつも部屋を散らかしているBグループが勝つ結果になりました。
Aグループの方は、荷物を収納に収めることすらできず、ハミ出してしまっている、という有様でした。

これはいったいなぜ？ゲストの先生が説明します。

いつも部屋が奇麗な人というのは、「収納上手」というわけではなく「そもそも部屋を散らかさない」のです。
出したものはすぐにしまう、収納スペース以上にものを増やさない、という行動を取っているから、いつもスッキリした部屋を保てるのです。

う〜ん、確かに。そういえばいつも部屋がキレイな友人にコツを聞いたときも、「出したものは使い終わったらスグにしまうこと！」と言ってましたね。ディズニーランドにもチリトリを持ったお掃除スタッフがいて、ゴミが出たらすぐに掃除しに来ますよね。
常にキレイな状態を保っておくことが大切なんですね。

でも、逆にこういう人は、「散らかった状態」「荷物が有り余った状態」をあまり経験していないともいえます。
なので、多くの荷物を巧みに収納することには慣れていないのでしょう。

ここで思ったのですが、今回のようなケースは、

「人の得手不得手というのは、印象だけで判断してはいけない」

ということを表しているのではないでしょうか。

野球のピッチャーでも、

・試合を組み立てるのがうまい先発型
・ピンチに出てきて押さえることができるストッパー型

のように、単に「いいピッチャーだから」というだけでは決められない適正があると思います。

これをプロジェクトマネージャに当てはめてみると、

「Aさんは有能なプロジェクトマネージャだから、この炎上プロジェクトを鎮めてくれるはずだ！」
「Bさんは炎上プロジェクトの火消し名人だから、新しいプロジェクトを任せてみよう！」

のようなケースが考えられます。

これはもしかしたらうまくいかないかもしれません。

Aさんは事前にしっかりした計画を立てたり、人材やリソースをきちんと調達することでプロジェクトを成功に導いているのかもしれません。
計画を立て直す余裕もなく、リソースの補充もままならないプロジェクトの火消しができるでしょうか？

Bさんは臨機応変な判断力や、決断の早さにより炎上プロジェクトを救っているのかもしれません。
長期的な計画をじっくり立てるのは苦手かもしれません。

もちろん、どちらのパターンにも対応できる優秀な方もいるでしょうが、やはり人間である以上、得手不得手はあるはずです。

人員をアサインする人は、その人の得手不得手をきちんと見極めてアサインすれば、プロジェクトが成功する確率は高まるでしょうね。
また、アサインされる側の人間も、自分の得手不得手を把握しておくことは色々なプロジェクトへの対応力をつける上で重要だと思います。

ちなみに私は「散らかった部屋の片付けも苦手だけど、プロジェクトの火消しも苦手」というタイプです・・・
かと言って「部屋がキレイ」というわけでもないし、「綿密なプロジェクト計画を立てるタイプ」でもないですねぇ・・・
う〜ん、困ったもんだ・・・

会話量とコミュニケーション

今日、お風呂に入っているとすごーく昔に見たテレビ番組のことをふと思い出しました。
（なぜか風呂に入っていると、色んな事を思いついたり思い出したりするのです・・・）

どこの病院だか大学の先生だったか忘れたのですが、出演しているタレントさんに、
つぎのようなクイズを出していました。

Q. あなたは病院の診察室にいます。医療ミスの少ない病院は次のうちどっち？
　1. 医師と看護師、看護師どおしが頻繁に連絡を取り合っており、会話の多い病院。
　2. 会話が少なく、スタッフが黙々と作業をしている病院。

当時の私は「そりゃ1.の会話が多い方がコミュニケーションがとれて、情報もよく伝わるからミスも少なくなるのでは？」と思いました。出演してるタレントさんも同じような回答だったと思います。

でも、解説の先生の回答は「2.会話が少ない病院の方がミスが少ないです」というものでした。
理由は以下のようなものでした。

診察室は患者さんに接する、いわば本番。
本番で会話が多いということは「事前に決められていなかったことが起きた」とか「元々どのように行動すべきかスタッフ間の意思統一ができていなかった」ことの裏返し。
会話だとその場その場の判断になってしまうので、判断ミスも起きやすいし、作業にも集中できないのでミスも増える。
逆に事前にやることをきちんと決めておき、スタッフの意思統一も意識できていれば、わざわざ会話する必要はない。その場でやるべきことに集中できるので、ミスも減らせる。

といった感じの内容だったと思います。

これって、ETロボコンとか、システム開発の時にもあてはまるんじゃないかな、と思います。

ETロボコンだと、

Q. あなたはETロボコンの試走会会場にいます。上位に行くのはどちらのチーム？
　1. 選手どおしが頻繁に連絡を取り合っており、会話の多いチーム。
　2. 会話が少なく、選手が黙々とプログラム入れ替えや試走をしているチーム。

なんとなく、1.のチームの方が活気があって良さそうにも思えますが、もし会話の内容が「おい、ここの設定どうするんだっけ？」とか「次はどの難所の調整するんだっけ？」「ここ直したら動かなくなったんだけどなんでだっけ？」「え〜、どうだったかな〜」「それは○○に聞かないとわからないな〜」みたいな会話だったりするとどうでしょうか？
強いチームというのは「何番目にどの難所を走らせる」「このパラメタはこうやって調整」「もしこういうことがおきたらこうする」といったことを事前に取り決めておき、本番ではそのルールに沿って動いてるんじゃないかなと想像しています。だから短い試走時間を効果的に使えるし、実際に成果にも結びつくのでしょう。

システム開発だったら、

Q. あなたはとあるシステムの最終テスト工程に立ち会っています。安定したシステムをリリースできるのはどちらのプロジェクトだと思いますか？
　1. 設計者や開発者やテスターどおしが頻繁に連絡を取り合っており、会話の多いプロジェクト。
　2. 会話が少なく、テスターが黙々とテストを実施しているプロジェクト。

まあ、これは想像つきますよね。
きっと、1.のプロジェクトは「おい、またバグ出たんだけど！」「プログラム入れ替えたら動かなくなったぞ！」「ここの仕様どうなってるんだっけ？俺はこう言ったはずだぞ」「え、そんなの仕様書に書いてないですけど？」みたいな感じでしょうか（恐ろしや恐ろしや・・・）

本当の意味でのコミュニケーションとは、単純に「会話量が多い」とか「メンバどおしの仲が良い」とか「一緒にいる時間が長い」というものではないと思います。

単純に「会話が足りないから会議をすればよい」「メールを禁止して直接話せば良い」「離れてるからダメなんだ！直接会えばよい」では解決しないような気がします（状況によっては効果的なので否定はしませんが）

「相手に如何に正しく状況や目的を伝え、それを共有するか」こそがコミュニケーションではないかと思います。
きっと、それらの伝達や共有は、周りからは分からない「秘密の時間」の「秘密の場所」で「秘密の方法」で行われているのかもしれないですね。

ETロボコン2012 中四国地区大会

9月22日(土)、福山大学宮地茂記念館にて「ETロボコン中四国地区大会」が行われました。
大会結果は以下のとおりでした。受賞されたチームの皆さんおめでとうございます。

モデル部門

• エクセレントモデル：teamTAMA*華*　（株式会社 両備システムズ）　　　　
• ゴールドモデル：UNCTインスツルメンツ（宇部高専）
• シルバーモデル：B-dash!!（ヒロコン株式会社）
• IPA賞：SUSANOO（松江高専）

競技部門

• 1位：SUSANOO
• 2位：UNCTインスツルメンツ
• 3位：teamTAMA*華*

総合部門

• 総合優勝　：teamTAMA*華*
• 総合準優勝：UNCTインスツルメンツ
• 総合3位　 ：SUSANOO

チャンピオンシップ大会には、「teamTAMA*華*」、「UNCTインスツルメンツ」の2チームが出場します。
2チームの皆さんおめでとうございます。
チャンピオンシップ大会では他の中四国地区の皆さんの分まで頑張っていただければと思います。

以下、中四国地区大会に関連するWebサイトです。
トップニュース：宇部工業高等専門学校
松江工業高等専門学校 - ETロボコン2012中四国大会に出場

おまけ - お掃除ダミーカー：

モデルレビューのススメ

もうすぐ8月も終わり、ETロボコンの各チームの皆さんはモデル提出に向けて最後の追い込みに入っているのではないかと思います。
私も昨年の今頃は、毎日遅くまでモデルを書いていたのを思い出します（遠い目・・・）。

さてさて、ETロボコンのモデル作成って、えてして以下のようなモデルになりがちです。

• 自分たちの思いばかり主張し何が言いたいのかわからないモデル（いわゆる「オレオレモデル」）
• 記事は書いているが、審査員に誤解されたり見落とされたりして評価してもらえないモデル。

これはETロボコンのモデル審査が、

「読み手と書き手のコミュニケーションが全く取れない状態で行われる」

ことと関係していると思います。

モデルを郵送したら、あとは実行委員の方が審査するだけです。なので、

「内容を説明し、補足説明や質疑応答を行いながら理解してもらう」

ということができません。

審査時間も限られていますから、わかりにくい書き方だとなかなか理解してもらえません（実行委員の方も読み取る努力はしているようですが）

このため「いかにわかりやすく、誤解を与えないようにモデルを書くか」ということが非常に重要になってきます。

では、どうすればわかりやすいモデルが作れるのか？
いろいろ方法はあるでしょうが、やはり一番有効なのは、やはり

「レビュー」

だと思います。

自分たちが作ったモデルを他の人に見てもらい、コメントを聞かせてもらう。
原始的ではありますが、自分が作ったものを客観的に評価することはとても難しいので、これが一番有効だと思います。

ただ、レビューといってもただ「モデル見てください」というだけではなかなか問題点は見つけてもらえないんですよね。誤りがあってもスルーされてしまいがちです。

ではどうすればよいか・・・
ポイントは次の二つかなと思ってます。

• 軽めのレビューを何回も繰り返す

作りかけのモデルを貼りだすか、ファイルサーバに入れるなどしておき、気づいたことを自由に指摘してもらう。コメントを書き込んでもらったり、口頭で伝えてもらうなどする。
作り手は、もらった意見を元に検討し、有効なものをモデルに取り入れていく。
このような形式のレビューを複数回繰り返す。

• チェックして欲しいポイントを伝えておく。

こちらはある程度完成したモデルに対して行うものです。
「誤字・脱字をチェックして！」「UMLの文法誤りがないかチェックして！」「用語が統一されてるかどうかチェックして！」など、ポイントをはっきりさせてレビューしてもらう。
レビューの結果はきちんと記録し、確実に修正を行う。

レビュー技法的には前者が「ウォークスルー」、後者が「インスペクション」に近いですかね。
前者のレビューを繰り返すことで、色々な気づきを得られます。その結果言いたいことや書くべきポイントがはっきりし、わかりやすいモデルになってきます。
後者のレビューを行うことで、誤りをなくすことができ、減点されにくいモデルになります。
両者をうまく組み合わせるのがポイントですね。

次にレビューアの人選についてです。
レビューアは会社や学校にETロボコンOBの方がいればベストです。こちらが困るぐらいの色々熱い指摘をしてくれるでしょう。

では、「初参加のチームで、適したレビューアが身近にいない」という場合はどうすればいいでしょうか？

この場合でも誰かにモデルを見てもらうことをお勧めします。

社会人の方は理解のある先輩や同僚、学生さんは先生とか友達などにお願いすればいいでしょう。分担してモデルを書いてるときは、お互いにチェックしあうのもよいでしょう。

そのとき「わからないことがあったらなんでも聞いて！」と一言言っておくのがポイントです。そして質問があったら、その都度自分が説明していくようにするのです。

こうしておくと、自分自身が説明する過程で誤りやわかりにくさに気付くことができます。専門外の人の方がわかりやすい説明が求められますから、経験者の方よりいい気づきが得られることすらあると思います。

せっかく皆さん頑張っておられるのですから、しっかりレビューをして、自分たちの思いをきちんと審査委員の方に届けて欲しいなぁと思います。

まだまだ暑い日が続きます。体調には十分気を付けて頑張ってください！