ひとり出張の思い出(2)

前回のエントリ「ひとり出張の思い出(1)」、
まだ新米だった頃の私が、突然一人での出張を命じられたときのお話です。

動かないツール

現地に着き、テストツールのセットアップを始めたものの、

あ、あれ、ツールが動かない・・・

なぜかエラーになってしまい動きません。前日手順を確認し、ちゃんと動いていたはずなのに・・・

このツールはテストのためには絶対必要で、動かない状態ではまったくテストができません。

ものすごい焦りが私を襲います。

「ツールのセットアップに少しだけ時間をください」と言って、現地の方には待ってもらっている状態です。
時間は刻々と経過していきますが、事態は一向に変わりません。

設定を見直すも、全く悪いところは見つかりません。
こういう時って、本当に時間の流れが早く感じられます。

現地のリーダーの方も「どないしたん？時間かかるんかいな？」と気にしはじめた様子。
私も「は、はい、いまちょっとトラブってるんですが、すぐに直します！」というのが精一杯でした。

もうダメかもしれない・・

これ以上時間をロスしたら、実施できないテスト項目がでてくるかもしれない・・・
このままではいけない・・・

動かない原因

もう、なりふり構ってはいられません。
会社の先輩に電話して助けを求めることにしました。

私「あの〜、ツールが動かないんです。昨日はちゃんと動いてたはずなんですが・・・」
先輩「そうなの？エラーログは見た？」
私「あ、そういえば見てなかったです。ええっと・・・あれ？このメッセージって何ですか？」
先輩「どんなメッセージ？・・・ああ、原因はきっとそれだよ」

結局、エラーの原因はディスクの容量不足でした。
現地のシステムのディスク空き容量が少なかったため、容量が一杯になりエラーを起こしていたようです。

いま考えると、なんと初歩的なミス！と思いますが、前日手順を確認しうまくいったので大丈夫に違いないと思い込んでいたんでしょうね。当日緊張していたこともあってエラーログの確認が遅れたのも情けないです。ソフトウェアを導入するときには環境の違いに留意しないといけない、というのをこのとき学びました。

ハード担当者とソフト担当者

そんなこんなで、なんとかツールのセットアップは完了し、テスト作業に入ります。

テストでは、現地のリーダーからハードウェアのテスト担当として、私と同じぐらいの年代の方を紹介されました。
「はじめまして。今日はよろしくお願いします」
これまでいたのは年上の人ばかりだったので、ちょっと安心したのを覚えています。

今回、ここまで出張に来たのは「ハードウェアがトラブったときのリカバリをソフトがきちんとできるか」を確認するためのものでした。

ハードにトラブルがあっても、そのハードが扱うデータが壊れたり抜けたりすることはあってはなりません。その制御はドライバーソフト側で行っているので、それがきちんとできているかどうかの確認です。

かねがね、私は「ハードウェアのテストってどうやってやるんだろう。トラブルを意図的に起こすのってどうやってやるのかな」と興味を持っていました。
ハード担当の方は「それはこうやるんですよ」と手順を見せてくれました。「へえ〜、初めて知りました。すごいですね！」
一方、私の方もソフト側のテストノウハウを紹介しました。当時の私の知識の範囲では大したことは説明できなかったのですが、「再現性のないトラブルが起きたときに備えて常にトレースを採取する設定にしてるんです」「へえ、ソフトの方はそこまでやるんですか。さすが本格的ですね！」と感心してもらえたときは嬉しかったです。

ハードとソフトという、違う物を作っている立場でも、互いに相手をリスペクトすることができることを知りました。
よく、組み込みの世界ではハード担当者とソフト担当者の対立など悲しいお話を聞く事がありますが、このように自分たちの持っていないお互いの良さを認め合うような関係になれれば、改善していけるのではないかと思います。

大変だったけど、なんとかやり遂げた・・・

こうして、色々なことがありながらも、私が担当していたテスト項目は、すべて消化することができました。
あのとき、先輩に相談するのがもう少し遅れていたら、とゾッとします。
今思えば、もっと早くに相談してれば、と思うのですが、当時は自分だけでなんとかしたい！という気持ちが強かったんでしょうね。
やはりこういうときは早めの報告・連絡・相談が大事だと身にしみてわかりました。

最後に、検出した不具合などを報告し、今後の対応をどうするか決めた後、現地を後にしたのです。
最初は不安だったひとり出張、準備が大変だったり当日もトラブルに見舞われ、色々苦労しましたが、結果的には無事成果を上げることができました。ひとりで仕事をやり遂げた、という実感があり、当時の自分にとっては大きな自信になりました。

もちろん、自分だけの力でできたわけではなく、色々サポートしてくれた先輩のおかげでもあります。

次回は私にこの出張を命じてくれた、当時のリーダーについて書いてみたいと思います。この方と出会っていなければ、今の自分はなかったかもしれません。

〜つづく〜

ひとり出張の思い出(1)

もうすぐ4月。私のところにもお花見の案内がやってきましたが、4月といえば新入社員が入ってくる時期でもありますね。

前回のエントリ「私とアジャイルとの出会い」は、私が初めてプロジェクトリーダーになった頃からの話でしたが、今度は桜の季節にちなんで(?)、私が新入社員だった頃のお話を書いてみたいと思います。

入社当時、私はテストエンジニアをしていました。

プログラムを開発する立場ではなく、他部門の開発したプログラムの品質評価を行う仕事です。私の配属された部署ではハードウェアのドライバやユーティリティソフトの品質評価を行っていました。

配属されてようやく1年ぐらい経ったときでしょうか。その頃は新型ハードウェアの出荷を目前に控え、評価作業も大詰めを迎えていました。かなり忙しい状態になっていたと思います。

そんなある日の昼下がり、当時のリーダーに呼び出されました。

「すまんが、明日から出張に行ってくれないか？
ハードウェア製造元との合同テストがあるから、テスト要員として行って欲しい」

え、いきなり明日から？これまで出張になんて行ったことないんだけど・・・、でもきっと誰か一緒に行ってくれるだろうから大丈夫かな、と思っていたら次のリーダーの一言が。

「ひとりでテストできるよね？」

え、え、一人ですかぁ〜@_@

当時の私は文系出身で、コンピュータの知識など殆どない状態での入社でした。なので会社に入ってからも周りについていくのがやっとで、1年経ってようやく慣れてきたかな、という感じでした。でも、何かトラブルがあったら先輩社員に助けてもらわないと何もできない・・・という状態だったのです。

そんな私が、いきなり一人で出張に行く事になったのです。
さすがに不安になりました。

とはいえ、せっかく与えられたチャンス。ここで断るわけにもいきません。

「わ、わかりました。頑張ります」

と答えるのが精一杯でした。

リーダーは続けます。

「それじゃ頼む。さっそくテストのための準備を始めて欲しい。
テストに必要なデータやツールを集めて使い方を確認しておいてくれ。
詳しいことは○○君が知っているから」

どんなテストをするのか、それからあわてて調べ始めました。
これまで、わからないことがあったら先輩に助けてもらえばいいや、と甘えた気持ちでいたこともあって、いざ一人でやろうとするとわからないことの連続です。おかげでデータ集めやテストの手順確認には一苦労。その日はえらい夜遅くまでかかって準備したことを覚えています。

そんなことがありながらも、なんとか準備を済ませて翌日の新幹線でハード製造元の工場に到着しました。新幹線の中だけは「お～、なんか俺ってビジネスマンって感じ～」とちょっとだけ気分良かったような気がします（←今考えるとわけがわかりませんが）

到着したら、さっそく現地のリーダーの方に挨拶に行きました。

その方は関西弁バリバリの方で、

「お〜、よう来たな、これからよろしゅう頼むで！」

と気さくに出迎えてくれました。

部屋のあちこちに色々な機材があちこちに置いていたり、声が大きいというか威勢のいい方が多かったりと、ソフトウェア部門とは結構雰囲気違うなあ、と思ったのが第一印象でした。

さっそく作業に入る事になりました。

「すみません、まずはテスト用のツールをセットアップしたいのでパソコン使わせてもらえますか？」

とお願いし、テストツールのセットアップを始めたのですが、ここで試練が襲ってきたのです。

「あ、あれ？ツールが動かない・・・」

〜つづく〜

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

前回のエントリ、私とアジャイルとの出会い(2)で紹介したプロジェクト。
ウォーターフォールしかできない開発業務にアジャイルの要素を組み込む、という取り組みはある程度の成功をおさめました。まあ細かなところでは、ここには書けないような厄介な問題も起きて、かなり苦労したのですが、やらなかったよりはうまくいったのでは、と思っています。

さて、前回エントリの終わりに書きましたが、このプロジェクトで得られた嬉しい誤算、それは

「メンバーの成長」

です。

経験の浅いメンバーで、当初は不安視する向きもあったのですが、開発が進むにつれ、二人ともどんどんスキルアップしていき、開発終盤ではお客様や会社の上司からも信頼されるほどの存在になっていきました。

これはもちろん本人たちの能力の素晴らしさや頑張りが一番大きかったのだと思いますが、もしかすると次のような点が彼らの成長を促したのかもしれません。

1. インプットとアウトプットの機会が多かった。
2. メンバーに作業を任せることができた。

成長の理由(1)：インプットとアウトプットの機会が多かったこと

仮に伝統的なウォーターフォールで1年間開発を行ったとすれば、設計、プログラミング、テストの工程は1年に1回しか経験することができません。その経験を次回にフィードバックできるのは、さらに1年後になってしまいます。

今回は各プロセスを小型化し期間も短くしましたから、1年のうちに何度も工程を経験することができました。つまり1つの開発案件にもかかわらず、複数の開発案件に従事したかのような効果が得られたのではないかと思います。

成長の理由(2)：メンバーに作業を任せることができたこと。

プロジェクトリーダーにとって、メンバーに作業を任せることは意外と勇気が必要なもの。ついつい「自分でやった方が早い」と、作業を抱え込んでしまいがちです。その結果他のメンバーが抱えている問題もフォローしきれず、自分の作業も遅れてしまう、という状況に陥ってしまいます。私の初めての炎上プロジェクトもそのパターンでした。

しかし、今回は本人たちに思い切って作業を任せることができたように思えます。それがなぜなのか考えてみたのですが、

朝会やタスク管理などにより「プロジェクトの状況が見える化できていたから」

ではないかと思います。

プロジェクトの状況が把握できていますし、短い頻度で確認していくので、作業を任せて問題があってもすぐにフォローすることができます。それがる安心感につながり、作業を任せることができたのだろうと思います。
そうして作業を任せるから本人たちにも責任感が生まれ、スキルアップや成長に繋がっていく、というわけです。

「任せる」と「丸投げ」は違う

念のため断っておくと「任せる」というのは「丸投げ」とは違います。
曖昧なまま作業を指示し、経過もフォローせず結果だけを求めるのが「丸投げ」です。
作業を始める前は本人たちと目的や方向性についてじっくり話し合い、最終的に何がどうなればよいのか確認しあった上で作業を「任せる」ようにしていました。事前に意識を合わせておいたおかげで、おかしな結果になることは少なかったですし、問題が起きてもすぐに報告してくれたので、迅速に手を打つことができました。

このように、アジャイル的な開発手法は人の成長を促す、という効果もあるのだなと感じました。

その後

数年後そのプロジェクトは解散し、当時のメンバーは別のプロジェクトに移りましたが、皆さん腕利きのエンジニアとしてバリバリ第一線で働いておられます。

昨年ぐらいだったでしょうか。そのときのメンバーのうちの一人が転勤することになりました。能力を買われての抜擢です。

送別会の二次会、彼と当時のことについての話になりました。
結構酔っていたので、はっきりは覚えていないのですが、このとき確か彼はこんなことを言ってくれました。

正直、あの当時はリーダー(私)がなぜこんなことを言うのか分からないまま、やっていた部分もありました。でも、その後別のプロジェクトに移り、自分たちで開発をやってみて、初めてその意味がわかったような気がします。
この経験を活かして、次のところでも頑張ります。

いまそう感じてくれているのなら、やってきたことは間違ってなかったのかもしれないですね。

〜おわり〜

私とアジャイルとの出会い(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付)

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