ETロボコン中四国独自勉強会0のボランティアを募集します。
募集は締め切りました。4名の方からご応募がありました。
大変ありがとうございました。
今年も4月27日(土)に福山大学宮地茂記念館で、ETロボコン2013 中四国地区独自勉強会0を開催することになりました。（昨年の内容はこちら)
…が、少し困った問題が。
初心者向けプログラミング実習の希望者が予想以上に多く、地区の実行委員だけではサポートしきれなくなりそうなんです。
（なんと11人の大所帯で参加するチームも！嬉しすぎる悲鳴です！）
中四国地区の実行委員は全国最少で、これまで苦労しながらもやってきたのですが、今回はさすがにピンチです。
そこで！
プログラミング実習をサポートしてくださるボランティアの方を募集します！
応募資格は特にありません。LEGO MINDSTORMS NXT走行体を取り扱いますので、ETロボコンへの参加経験がある方のほうがやりやすいかもしれませんが。
初心者向けの内容ですので、特に高度な知識は必要ありません。
メイン講師は地区実行委員が務めますので、ボランティアの皆さまには受講生の様子を見ていただいて、うまくいってない人がいればサポートしていただく形になります。
やってみたい！という方は、私の Twitter までメッセージを送っていただくか、このサイトのMessageLeaf(右下にある緑のニョキニョキっと出てくるやつです）からご連絡ください。
勉強会の詳しい内容はこちらになります。
http://kokucheese.com/event/index/85582/
今回はボランティアにさせていただくので、残念ながら交通費のお支払いなどはできないのですが、人に何かを教えることは、自分にとっても勉強になると思います。また、自分のチームに新人が入った方にとっては指導方法が参考になるかもしれません。
いずれにしても、貴重な経験ができるチャンスですので、興味のある方はふるってご参加ください。
ちょうどGW期間中ですので、ついでに中四国観光も楽しめるかと思います。鞆の浦や尾道、因島も近いですよ。
それでは、よろしくお願いします。
モノを持たない生活
今週末は低気圧の影響で大荒れの天気になりそうということで、久しぶりに部屋の整理整頓をすることにしました。
このところ仕事が忙しくて、かなり放置状態だったのですが意外と短時間で終えることができました。昔は部屋の掃除といえば一日仕事だったのですが。
モノを少なく保つ習慣に変えたのが効いたのかもしれません。
神戸に引っ越すことが決まったとき、いわゆる「断捨離」を行い、いらないものや使っていないものは、ほとんど処分してしまいましたし、残ったものも生活に必要なさそうなものは神戸には持ってきませんでした。こちらで生活し始めてからも極力モノを増やさないよう気をつけています。
（家具や生活用品以外で買ったのは、少しの服と書籍とMacBook Airぐらい）
以前の私は典型的な「モノを捨てられない人」で、色々溜め込んでしまうタイプだったのですが、最近はモノが多すぎてあふれ返ることにストレスを感じるようになっていました。なかなか改善するきっかけがつかめずにいたのですが、神戸転勤を機に思い切って習慣を変えたのがよかったみたいです。
モノを増やすということは、モノ自体を買う費用以外にも色々なコストがかかるんですよね。例えば、
- 設置・収納スペースを確保するためのコスト
- 維持管理していくための、いわゆるランニングコスト
- モノが多くなりすぎて整理整頓しないといけなくなったり、探し出すための時間
などです。
これらは長期にわたってジワジワと効いてくるので意外とわかりにくく気付かないですが、気をつけた方がいいように思います。これらのために本当に必要なものが手に入れられなくなったり、貴重な時間をどこかでロスしているかもしれないですから。
ITシステムにも、これらのことがあてはまるように思えます。
昔はサーバやソフトウェアを購入して、自分たちで維持管理するというのが当たり前でしたが、サーバの設置スペースを確保したり、運用やメンテナンスするための工数を捻出したり、サーバの利用状況やソフトウェアのライセンスを管理していくにはかなりの手間がかかるんですよね。
最近はクラウドサービスも普及してきていますから、こちらに移行したほうがコストダウンに繋がることが多そうです。
日本はまだまだオンプレミスにこだわる企業が多いですが、コスト的なメリットがわかってくると、そのうち変わってくるかもしれませんね。
オンプレミスを井戸、クラウドを水道に例えてみるとわかりやすいかもしれません。
昔は多くの家で井戸を持っていたようですが、最近は水道が当たり前です。
井戸を掘ったり維持管理できなくなったり、そもそも飲用に適した地下水が出ない場所に住んだりしていると、水道という外部サービスに頼らざるを得ません。
ITシステムも、井戸がなくなり水道に移行したのと同じようなことが起きてくるのではないかと思います。
いや、既にそうなっているのかも・・・
お客様が本当に求めているもの
この週末は勤務先の神戸を離れ、自宅のある岡山に帰省していました。
帰省の目的は「息子に入学祝いを買ってあげること」と「なじみの美容院で髪をカットしてもらうこと」でした。
そんなにオシャレに気を配るタイプじゃないので、本当は美容院じゃなくて安い理髪店でもいいのですが、美容師さんの明るい人柄がとても気に入っているので、家族ぐるみで何年もこちらのお店に通い続けています。
こちらのお店、美容師さんの出産を機にご自宅をリフォームされ、最近移転オープンしました。住宅兼店舗なので、ご家族の方に育児のサポートをしてもらえて、お仕事を続けやすくなっているようです。
私が髪を切ってもらってるときも、奥の方から赤ちゃんの元気な声が聞こえてきます。そろそろハイハイを始めたんだとか。
店内には開放的な吹き抜けがあって、シーリングファンが優しく空気の流れを作り出しています。内装も木材やレンガをうまく使って温かみのある雰囲気です。家具のセンスも良くて、すごく気持ちが落ち着きます。
思わず、
「いや〜、すごく趣味のいいお店ですね。やっぱりこういうのって美容院専門の建築士さんに設計してもらったりしたんですか？」
と聞いてみたのですが、
「それが違うんですよ〜。普通の小さな工務店さんにお願いしたんです」
と、意外な答えが返ってきました。
「えーっ、そうなんですか？専門の業者さんの方が色々知識があるからいいのかと思ってたんですけど」
「それが、専門の業者さんだと色々決まりごとがあるみたいで・・・こちらが何かお願いしても、『いや、それはできないことになってますから』と断られちゃうんですよ。
前のお店は美容室をよく扱う業者さんだったんですけど、あまりこちらの言うことを聞いてもらえなくて、けっこう我慢したんですよ」
たしかに、前の店も、私から見るとかわいらしい感じの良い店でしたし、美容院らしく機能的にまとまった内装ではあったのですが、今のお店とは比べ物になりません。
作り方がルール化されているというか、規格化されていて、大きな欠点もないかわりにどうしても画一的な感じになってしまいます。
「今のお店を作ってくれた工務店さんは、私の話をすごく良く聞いてくれたんです。美容院を作った事はなかったそうなんですが、『それじゃ、ここはこうやってみましょうか？』『それでは次はこれでどうでしょう』と色々な提案をしてくれたんです。だからイメージどおりのお店になって、まるで自分でお店を作ったような気分になったんですよ。自分が建てたわけでもないのにね(笑)」
そう話す美容師さんは本当に嬉しそうで、このお店にとても愛着を持っているようでした。
自分の気に入った場所で、好きな仕事ができている、とてもいい顔をされていました。
帰りのクルマの中で、私の中にひとつの考えが浮かびました。
お客さんは、その商品に対し「自分で作った」「自分で選んだ」という実感を持てたときが一番嬉しいんじゃないだろうか？
どんなよいものであっても、一方的に押し付けられたものに対しては、あまり人は満足感を持てないんじゃないだろうか？
人は誰もが意志を持って生まれてきます。
あるモノができる過程、選ばれる過程に自分が関与できること、これに人は満足感を感じるんじゃないか？
と感じた一日でした。
自分もエンジニアとして、お客さんにそういう喜びを与えられる存在になれればいいな、と思います。
お客さんに「自分で作った」「自分で選んだ」かのように感じてもらえるソフトウェア、いつかつくってみたいですね。
ETロボコン2012 チャンピオンシップ大会の動画
いまさらですが、昨年11月にパシフィコ横浜で開催されたETロボコン2012 チャンピオンシップ大会の動画がYouTubeにアップされていたのを見つけました。
照明条件の悪さからリタイヤ続出の波乱の大会になりましたが、そういう中でも上位チームはしっかり完走してましたね。リベンジを目指す皆さん、優秀チームの走りを参考にしてみてはいかがでしょうか？
ETロボコン2012チャンピオンシップ大会 - YouTube
ETロボコンをご存知ない方は、こちらの動画を見ていただければ大会の雰囲気が伝わるのではないかと思います。
私も選手として1回、実行委員として1回参加しましたが、この熱気に包まれた雰囲気は最高です！
ちょうどいま、2013年大会の参加申し込みも行っていますので、興味ある方はぜひ参加申し込みをお願いします。
2013年大会の詳細はこちらの公式サイトから。
http://www.etrobo.jp/2013/
ひとり出張の思い出(2)
前回のエントリ「ひとり出張の思い出(1)」、
まだ新米だった頃の私が、突然一人での出張を命じられたときのお話です。
動かないツール
現地に着き、テストツールのセットアップを始めたものの、
あ、あれ、ツールが動かない・・・
なぜかエラーになってしまい動きません。前日手順を確認し、ちゃんと動いていたはずなのに・・・
このツールはテストのためには絶対必要で、動かない状態ではまったくテストができません。
ものすごい焦りが私を襲います。
「ツールのセットアップに少しだけ時間をください」と言って、現地の方には待ってもらっている状態です。
時間は刻々と経過していきますが、事態は一向に変わりません。
設定を見直すも、全く悪いところは見つかりません。
こういう時って、本当に時間の流れが早く感じられます。
現地のリーダーの方も「どないしたん？時間かかるんかいな？」と気にしはじめた様子。
私も「は、はい、いまちょっとトラブってるんですが、すぐに直します！」というのが精一杯でした。
もうダメかもしれない・・
これ以上時間をロスしたら、実施できないテスト項目がでてくるかもしれない・・・
このままではいけない・・・
動かない原因
もう、なりふり構ってはいられません。
会社の先輩に電話して助けを求めることにしました。
私「あの〜、ツールが動かないんです。昨日はちゃんと動いてたはずなんですが・・・」
先輩「そうなの？エラーログは見た？」
私「あ、そういえば見てなかったです。ええっと・・・あれ？このメッセージって何ですか？」
先輩「どんなメッセージ？・・・ああ、原因はきっとそれだよ」
結局、エラーの原因はディスクの容量不足でした。
現地のシステムのディスク空き容量が少なかったため、容量が一杯になりエラーを起こしていたようです。
いま考えると、なんと初歩的なミス！と思いますが、前日手順を確認しうまくいったので大丈夫に違いないと思い込んでいたんでしょうね。当日緊張していたこともあってエラーログの確認が遅れたのも情けないです。ソフトウェアを導入するときには環境の違いに留意しないといけない、というのをこのとき学びました。
ハード担当者とソフト担当者
そんなこんなで、なんとかツールのセットアップは完了し、テスト作業に入ります。
テストでは、現地のリーダーからハードウェアのテスト担当として、私と同じぐらいの年代の方を紹介されました。
「はじめまして。今日はよろしくお願いします」
これまでいたのは年上の人ばかりだったので、ちょっと安心したのを覚えています。
今回、ここまで出張に来たのは「ハードウェアがトラブったときのリカバリをソフトがきちんとできるか」を確認するためのものでした。
ハードにトラブルがあっても、そのハードが扱うデータが壊れたり抜けたりすることはあってはなりません。その制御はドライバーソフト側で行っているので、それがきちんとできているかどうかの確認です。
かねがね、私は「ハードウェアのテストってどうやってやるんだろう。トラブルを意図的に起こすのってどうやってやるのかな」と興味を持っていました。
ハード担当の方は「それはこうやるんですよ」と手順を見せてくれました。「へえ〜、初めて知りました。すごいですね！」
一方、私の方もソフト側のテストノウハウを紹介しました。当時の私の知識の範囲では大したことは説明できなかったのですが、「再現性のないトラブルが起きたときに備えて常にトレースを採取する設定にしてるんです」「へえ、ソフトの方はそこまでやるんですか。さすが本格的ですね！」と感心してもらえたときは嬉しかったです。
ハードとソフトという、違う物を作っている立場でも、互いに相手をリスペクトすることができることを知りました。
よく、組み込みの世界ではハード担当者とソフト担当者の対立など悲しいお話を聞く事がありますが、このように自分たちの持っていないお互いの良さを認め合うような関係になれれば、改善していけるのではないかと思います。
大変だったけど、なんとかやり遂げた・・・
こうして、色々なことがありながらも、私が担当していたテスト項目は、すべて消化することができました。
あのとき、先輩に相談するのがもう少し遅れていたら、とゾッとします。
今思えば、もっと早くに相談してれば、と思うのですが、当時は自分だけでなんとかしたい！という気持ちが強かったんでしょうね。
やはりこういうときは早めの報告・連絡・相談が大事だと身にしみてわかりました。
最後に、検出した不具合などを報告し、今後の対応をどうするか決めた後、現地を後にしたのです。
最初は不安だったひとり出張、準備が大変だったり当日もトラブルに見舞われ、色々苦労しましたが、結果的には無事成果を上げることができました。ひとりで仕事をやり遂げた、という実感があり、当時の自分にとっては大きな自信になりました。
もちろん、自分だけの力でできたわけではなく、色々サポートしてくれた先輩のおかげでもあります。
次回は私にこの出張を命じてくれた、当時のリーダーについて書いてみたいと思います。この方と出会っていなければ、今の自分はなかったかもしれません。
〜つづく〜
ひとり出張の思い出(1)
もうすぐ4月。私のところにもお花見の案内がやってきましたが、4月といえば新入社員が入ってくる時期でもありますね。
前回のエントリ「私とアジャイルとの出会い」は、私が初めてプロジェクトリーダーになった頃からの話でしたが、今度は桜の季節にちなんで(?)、私が新入社員だった頃のお話を書いてみたいと思います。
入社当時、私はテストエンジニアをしていました。
プログラムを開発する立場ではなく、他部門の開発したプログラムの品質評価を行う仕事です。私の配属された部署ではハードウェアのドライバやユーティリティソフトの品質評価を行っていました。
配属されてようやく1年ぐらい経ったときでしょうか。その頃は新型ハードウェアの出荷を目前に控え、評価作業も大詰めを迎えていました。かなり忙しい状態になっていたと思います。
そんなある日の昼下がり、当時のリーダーに呼び出されました。
「すまんが、明日から出張に行ってくれないか？
ハードウェア製造元との合同テストがあるから、テスト要員として行って欲しい」
え、いきなり明日から？これまで出張になんて行ったことないんだけど・・・、でもきっと誰か一緒に行ってくれるだろうから大丈夫かな、と思っていたら次のリーダーの一言が。
「ひとりでテストできるよね？」
え、え、一人ですかぁ〜@_@
当時の私は文系出身で、コンピュータの知識など殆どない状態での入社でした。なので会社に入ってからも周りについていくのがやっとで、1年経ってようやく慣れてきたかな、という感じでした。でも、何かトラブルがあったら先輩社員に助けてもらわないと何もできない・・・という状態だったのです。
そんな私が、いきなり一人で出張に行く事になったのです。
さすがに不安になりました。
とはいえ、せっかく与えられたチャンス。ここで断るわけにもいきません。
「わ、わかりました。頑張ります」
と答えるのが精一杯でした。
リーダーは続けます。
「それじゃ頼む。さっそくテストのための準備を始めて欲しい。
テストに必要なデータやツールを集めて使い方を確認しておいてくれ。
詳しいことは○○君が知っているから」
どんなテストをするのか、それからあわてて調べ始めました。
これまで、わからないことがあったら先輩に助けてもらえばいいや、と甘えた気持ちでいたこともあって、いざ一人でやろうとするとわからないことの連続です。おかげでデータ集めやテストの手順確認には一苦労。その日はえらい夜遅くまでかかって準備したことを覚えています。
そんなことがありながらも、なんとか準備を済ませて翌日の新幹線でハード製造元の工場に到着しました。新幹線の中だけは「お～、なんか俺ってビジネスマンって感じ～」とちょっとだけ気分良かったような気がします（←今考えるとわけがわかりませんが）
到着したら、さっそく現地のリーダーの方に挨拶に行きました。
その方は関西弁バリバリの方で、
「お〜、よう来たな、これからよろしゅう頼むで！」
と気さくに出迎えてくれました。
部屋のあちこちに色々な機材があちこちに置いていたり、声が大きいというか威勢のいい方が多かったりと、ソフトウェア部門とは結構雰囲気違うなあ、と思ったのが第一印象でした。
さっそく作業に入る事になりました。
「すみません、まずはテスト用のツールをセットアップしたいのでパソコン使わせてもらえますか？」
とお願いし、テストツールのセットアップを始めたのですが、ここで試練が襲ってきたのです。
「あ、あれ？ツールが動かない・・・」
〜つづく〜
私とアジャイルとの出会い(3)
前回のエントリ、私とアジャイルとの出会い(2)で紹介したプロジェクト。
ウォーターフォールしかできない開発業務にアジャイルの要素を組み込む、という取り組みはある程度の成功をおさめました。まあ細かなところでは、ここには書けないような厄介な問題も起きて、かなり苦労したのですが、やらなかったよりはうまくいったのでは、と思っています。
さて、前回エントリの終わりに書きましたが、このプロジェクトで得られた嬉しい誤算、それは
「メンバーの成長」
です。
経験の浅いメンバーで、当初は不安視する向きもあったのですが、開発が進むにつれ、二人ともどんどんスキルアップしていき、開発終盤ではお客様や会社の上司からも信頼されるほどの存在になっていきました。
これはもちろん本人たちの能力の素晴らしさや頑張りが一番大きかったのだと思いますが、もしかすると次のような点が彼らの成長を促したのかもしれません。
- インプットとアウトプットの機会が多かった。
- メンバーに作業を任せることができた。
成長の理由(1)：インプットとアウトプットの機会が多かったこと
仮に伝統的なウォーターフォールで1年間開発を行ったとすれば、設計、プログラミング、テストの工程は1年に1回しか経験することができません。その経験を次回にフィードバックできるのは、さらに1年後になってしまいます。
今回は各プロセスを小型化し期間も短くしましたから、1年のうちに何度も工程を経験することができました。つまり1つの開発案件にもかかわらず、複数の開発案件に従事したかのような効果が得られたのではないかと思います。
成長の理由(2)：メンバーに作業を任せることができたこと。
プロジェクトリーダーにとって、メンバーに作業を任せることは意外と勇気が必要なもの。ついつい「自分でやった方が早い」と、作業を抱え込んでしまいがちです。その結果他のメンバーが抱えている問題もフォローしきれず、自分の作業も遅れてしまう、という状況に陥ってしまいます。私の初めての炎上プロジェクトもそのパターンでした。
しかし、今回は本人たちに思い切って作業を任せることができたように思えます。それがなぜなのか考えてみたのですが、
朝会やタスク管理などにより「プロジェクトの状況が見える化できていたから」
ではないかと思います。
プロジェクトの状況が把握できていますし、短い頻度で確認していくので、作業を任せて問題があってもすぐにフォローすることができます。それがる安心感につながり、作業を任せることができたのだろうと思います。
そうして作業を任せるから本人たちにも責任感が生まれ、スキルアップや成長に繋がっていく、というわけです。
「任せる」と「丸投げ」は違う
念のため断っておくと「任せる」というのは「丸投げ」とは違います。
曖昧なまま作業を指示し、経過もフォローせず結果だけを求めるのが「丸投げ」です。
作業を始める前は本人たちと目的や方向性についてじっくり話し合い、最終的に何がどうなればよいのか確認しあった上で作業を「任せる」ようにしていました。事前に意識を合わせておいたおかげで、おかしな結果になることは少なかったですし、問題が起きてもすぐに報告してくれたので、迅速に手を打つことができました。
このように、アジャイル的な開発手法は人の成長を促す、という効果もあるのだなと感じました。
その後
数年後そのプロジェクトは解散し、当時のメンバーは別のプロジェクトに移りましたが、皆さん腕利きのエンジニアとしてバリバリ第一線で働いておられます。
昨年ぐらいだったでしょうか。そのときのメンバーのうちの一人が転勤することになりました。能力を買われての抜擢です。
送別会の二次会、彼と当時のことについての話になりました。
結構酔っていたので、はっきりは覚えていないのですが、このとき確か彼はこんなことを言ってくれました。
正直、あの当時はリーダー(私)がなぜこんなことを言うのか分からないまま、やっていた部分もありました。でも、その後別のプロジェクトに移り、自分たちで開発をやってみて、初めてその意味がわかったような気がします。
この経験を活かして、次のところでも頑張ります。
いまそう感じてくれているのなら、やってきたことは間違ってなかったのかもしれないですね。
〜おわり〜
