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

前回のエントリ、私とアジャイルとの出会い(1)で紹介した大炎上プロジェクト。

その後1年ぐらい経って、またリーダーをさせてもらう機会に恵まれました。
前回大炎上させてしまったことで、もう機会が巡ってこないかもと思っていたので内心ホッとしました。
新しいプロジェクトでも大変でしたし、色々失敗もしましたが、経験を重ねてコツが掴めてきたのか、なんとかリーダーらしきことができるようになってきました。

新しいプロジェクト

そんなある日、新しい案件があり、私をリーダーとする新たなプロジェクトを結成することになりました。それまでのメンバーは他に移り、私の他は入社2〜3年目の若い子が2人だけ。

2人とも真面目で素質はいいものを持っていましたが、あまりプログラミングの経験はありませんでした。

納期も短いうえに、私自身もこれまであまり使ったことのないミドルウェアやプログラミング言語を使っていく必要もありました。この状況は前の炎上プロジェクトより遥かに厳しいものでした。

でも、私はむしろチャンスと感じていました。

あれを試すときがきたかもしれない。

そう、前に日経コンピュータで読んだ、アジャイル的な開発プラクティスの導入です。
プロジェクトのリソースが貧弱で不確定要素が多いという、今回のような状況こそ最適だと思ったのです。

若い子ばかりですから、新しいやり方に対する抵抗感も少ないだろう、という考えもありました。

とはいっても、ウォーターフォール開発の契約ですから、基本的な開発プロセスを崩すわけにはいきません。

なので、

「できそうなプラクティスだけを選択し、アレンジして適用する」

やり方でいくことにしました。

取り入れたことは、

1. 朝会
2. タスク管理
3. 小さなウォーターフォール
4. ペアレビュー

でした。

当時は珍しかった朝会。

プロジェクト立ち上げの日、私は皆に言いました。

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

当時は朝会をやっているプロジェクトなどほとんどありませんでした。週1回の進捗会議を1〜2時間ほどやるのが普通です。
そんな中、いくら3人とはいえ、他の人が座って仕事している中で自分たちだけ事務所の片隅に立って朝会してるわけですから、相当目立ったと思います（私は当時は全然気にしてなかったのですが、メンバーの子はちょっと恥ずかしく思っていたかも・・・）。

いきなりそんなことを始めたもんですから、周りの人からも心配されます。

「なあ、毎日会議してたら時間のムダじゃないか？メンバーの負担も増えるぞ」

と言われたこともあります。

でも、

「いえ、今回のプロジェクトのメンバーは経験の浅い子ばかりなので、自分自身で問題を解決できないことだってあると思います。なので毎日細かくフォローして、問題点があったらすぐに解決してあげないといけないんです。わからないことがあるのに言う機会がなくて、翌週の会議までうまく作業が進まない。そのほうがよほどムダじゃないですか？」

という感じのことを言って、続けていたと思います。
実際、作業で困ったことを早いうちにキャッチアップすることができ、ありがちな「後で衝撃の事実が発覚し大混乱」のようなことはほとんど起きなかったように思います。

少人数のタスク管理はExcelが最強!?

タスク管理の方は、本当はホワイトボードに付箋紙を貼って、タスクかんばんを作りたかったのですが、当時の事務所にはホワイトボードを設置する場所がありませんでした。
ホワイトボードの数も限られており、わずか3人のプロジェクトで独占するわけにもいきません。

そのためExcelで課題一覧表を作り、毎日内容をチェックするようにしました。まあ、あまりExcelというのはイケてないし、Excel方眼紙は大嫌いなのですが、設備がない以上仕方ありません。
でも、少人数のプロジェクトでしたのでExcelで十分だったともいえます。むしろ検索とかデータの二次利用ができたので、このときはメリットの方が大きかったな、と思います。

ウォーターフォールも繰り返せばイテレーションになる

アジャイルの特徴である「イテレーション」「変化への対応」については、ウォーターフォールモデルを崩すわけにはいかなかったので、ちょっと難しい面はあったのですが、「設計に誤りがあっても仕様変更に迅速に対応できる」仕組みをなんとかして作ろうとしていました。

そのころ、一緒に仕事をしていたお客様側のリーダーの方も、アジャイルには興味を持っておられましたので、やり方を提案してみようと考えました。ウォーターフォール的なものを維持したままアジャイル的な考えを取り入れるにはどうすればよいか・・・私の考えはこうでした。

開発量や期間を短くした「ミニウォーターフォール」を定義し、それを複数回繰り返す。

この「ミニウォーターフォール」には「フェーズ」という名を付けて「フェーズ1」「フェーズ2…」と呼ぶようにしました。1回のフェーズがアジャイルでの1回のイテレーションにあたります。

各フェーズはそれぞれ実装すべき機能が決められており、「設計」「プログラミング」「テスト」の工程順で機能を実装していきます。もし工程の途中で問題が発生したり、作りきれなかった場合は、フェーズ終了後にお客様と話し合い、次回のフェーズで開発する内容を見直していきます。

今回は特に、使ったことのなかったミドルウェアやプログラミング言語を使いこなす必要があり、開発途中で何が起きるかわからなかっただけに、フェーズを繰り返せたことは大変効果がありました。1回毎のフェーズが短いので早い時期にテストできたため、問題点を早期に見つける事ができましたし、問題が起きても次のフェーズで作戦を立て直すことが可能になりました。

あとはテスト駆動でできればよかったんですが、ちょっとそこまではできませんでした(笑)

ペアプログラミングには不安が…ペアレビューを導入

当時XPの特徴的なプラクティスと言えば「ペアプログラミング」でした。
ただ、これはマネージャ層の受けがとにかく良くなかったです。

1つのプログラムを2人で作ったりしたら、生産性が半分になるじゃないか！

必ずしもそうではないとは思うのですが、なにせこちらも初めてですので結果がどうなるかはわからない状況でした。あまり無理を通してプロジェクトを失敗させては元も子もありません。
自分自身も以前少しだけペアプロを試したことがありましたが、(やり方の問題もあったのか)予想外に疲れるもので時間もかかった経験がありました。なので、無理にペアプログラミングを導入するのはやめて、
「ペアレビュー」という仕組みを取り入れてみました。

当時のレビューと言えば、会議形式で大人数で行うことが主流でした。今ほどペーパレス化が進んでいなかったですから、ソースコードはいちいち紙に印刷して配布していました。

ただ、このやり方だと手間がかかりすぎ、頻繁に行うことはできません。
会議室を押さえたり、印刷して仕分けして、大勢の人のスケジュールを調整して・・・意外とレビューの準備というのは大変なのです。

さらに、今回は経験の浅い子が多いですから、もし間違ったプログラムを作っていて、工程の最後で発覚したら直す時間が取れなくなってしまいます。
そこで、プログラミング工程の途中に軽めのレビューを挟んでいくやり方を考えました。
ソースコードの印刷や会議室の確保など、手間のかかることは行わず、座席でdiffをかけたPC画面を見ながら2名で実施します。レビューの範囲も狭くして、時間もごく短時間で終わらせます。
これにより、気軽にレビューを始められ、比較的早期にプログラムの問題点を見つけて対策する事ができたと思います。レビューで指摘があってもその場でプログラムを直せるし、正しく直せたか確認する手間もかかりません。

ただ、このやり方だとレビューの観点が局所的になってしまい、全体的な問題点を見つけられなくなるのでは、という不安もあったので、最終的にはこれまで通り会議形式のレビューも実施するようにしました。

これらのおかげもあり、色々苦労もあったもののなんとかプロジェクトは終了し、無事に納品を迎える事ができました。

既存のものを小さくして繰り返せば、アジャイルっぽくなる？

後で振り返ってみると、私がやったことにはある共通点があることに気付きました。
それは、

• やる事そのものは従来どおり。
• 単位を小さくする。
• 繰り返す。

だったと思います。

• 会議の時間を短くし、毎日繰り返す「朝会」
• 期間やスコープを小さくして繰り返す「ミニウォーターフォール」
• レビューの時間や人数を減らして繰り返す「ペアレビュー」

といった具合です。

このように、

やることそのものは変えられなくても、大きさや回数を変えることで違った効果を得ることができる。

というのは大きな驚きでした。

まあ、実際のアジャイルの手法からは大きくかけ離れていますから、あまり人に自慢できるようなやり方ではないかもしれません。アジャイルと呼べるような代物ではないかもしれません。
でも、自分の中では色々な制約の中でやれるだけのことはやれたという充実感がありました。

ちなみに、こういった開発手法を取り入れた成果はそれだけではありませんでした。

自分にとっても予想外の、嬉しい出来事が起こったのです。

〜つづく〜

次の記事：私とアジャイルとの出会い(3) - ConaCona Engineering

私とアジャイルとの出会い(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中四国大会に出場

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