2012年06月26日

会社を移ることになりました

 2012年6月末で会社を移ることになりました。
 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。

***********************

◆思い出1:Rubyとの出会い
 入社後しばらくして、(弊社では)お客様向けとして開発実績の無かったRuby(とRuby on Rails)を使いシステムを構築し、(お客様に)良い評価をもらったことです。
※1システムだけでなく、確か計4つほど作ったと思います。

 チームはRuby未経験者ばかりだったので、当時(Rubyで)社内SNSを作っていた@kuranukiさんや@nsgcさんが助っ人で来てくれ、合宿形式でペアプロをしたのも良い思い出です。

◆思い出2:スクラムとの出会い
 直近で長く携わった社内向けのプロジェクトも印象に残っています。

 この時のチームは(ボスを筆頭に)本当に仕事に対する姿勢が素晴らしいもので(もちろん技術力もですが)、私も本当に多くのものを得ることができました。
#チームを抜ける時には「卒業証書」をもらったりもしました(笑)。

 このチームでは「ここぞとばかりに」色々チャレンジしました。
 Redmine、Jenkins、テストコード、そしてファシリテーションやスクラムなどなど…。
  
 RxTstudyに携われたりスクラム道な方々と出会えたりする機会にもつながりました。
 またそれらをきっかけにして社内外で人前で発表するという貴重な経験もできました。

 アジャイル(スクラム)については「教科書的にはこうだけど、自分達のコンテキストでは…」という点が多く、大きい壁となり、その度チームで話し合って、自分達なりの開発のやり方とユーザへ価値を届けるベストな方法を模索し続けました。
 これも良い経験でした。

◆思い出3:社内コミュニティ
 アジャイルサムライの道場(社内読書会)ランチ勉強会を通じて、(サラリーマンSE色の薄い)前向きなエンジニアと出会えたことです。

 「勉強会」が全てではありませんが、こういうのが積極的に開催されていて、参加者も多い組織はエンジニアにとって魅力的だと思います。
 (夢物語な感じですが)「毎日どこかのセミナールームで(社内外を問わず)勉強会をやっていて、色々な人がやってきて交流ができる環境にしたい」と思っていたりもしました。

 この考えに影響を与えた方として、入社した当時に(社内SNSを通じて)出会った@papandaさんがいます。
 今ではDevLOVE関西でつながっていたりします。 

◆これから
 相変わらず大阪でエンジニアをしています。
 新しい職場のことはまた折を見て書こうと思います。

 これまでの勉強会にも参加したいですし、新しい技術要素に出会うと思うので、その界隈の勉強会などにも参加すると思います。
 よろしくお願いします。

***********************

 余談ですが、コミュニティの知人には「どこに行くの?」よりも「(弊社を使っている)勉強会やセミナーの会場確保は(これからも)大丈夫?」と聞かれることが多かったです。
 幸いなことにそれぞれのコミュニティに弊社社員が(スタッフ的に)いるので会場を使うことは(社内規則が変わらない限り)大丈夫なのでご安心ください。
posted by yohhatu at 08:20 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年06月21日

[勉強会]「Scrum Boot Camp in 大阪(通称:Scrum BC)」を開催しました

 「Scrum Boot Camp in 大阪(通称:Scrum BC)」を開催しました。
 「ScrumBC」とは?という方はこちらを見て下さい。
#参加していただいた皆さん、講師の皆さん、そして朝早くから準備等やっていただいたスタッフの皆さん、ありがとうございました〜

***********************

◆そもそもなぜ(主催してまで)やりたかったか?
1:ScrumBCの内容の濃さを知っていたので、ぜひもっと色々な人に体験して欲しかった
2:関西メンバー中心でScrumBCやScrum道場がやりたい(やる)ので、その視察を兼ねて(笑)
3:あまり直接話す機会のない(なんせ東京なので)講師の方々と話したかった
 という、1以外は自分都合な動機から主催しました。
#2については「それなに?おもしろそう!」と興味のある方は一声かけてください〜

◆詳しい内容はこちらを…
 色々な方が書いているのでそちらをご覧ください(漏れていたらゴメンナサイ)。
#scrumbc 大阪 に参加してきた(日々常々)
ScrumBC in 大阪に参加しました。 #scrumdo #scrumbc(Akt One.)
Scrum BootCamp大阪に参加してきました #scrumbc(亀岡的プログラマ日記)
#scrumbc 大阪に参加してきました(カイトカンネ)

◆自分用メモ
・スプリントの表現を「短いプロジェクト(の連続)」と伝えるのはウォーターフォールをの開発プロセスの方にもまずはイメージしやすいかも。
・「ウォーターフォールとは(プロセス的には)大きな違いがなく(ほぼ)一緒」と言うのは、よくある「アジャイル(スクラム)と聞くだけで拒否反応を起こすタイプ」に対していい表現かもしれない。
「的が遠すぎる」「的が止まらない」という表現も今度使おう。
「ルートの再検索」という表現も以下ry
・2週間(10日間)で1スプリントとした場合、「1コマ2時間で考えて1日3コマ(残業するとして4コマ)。なので、1スプリントは40コマ」「最初の日の2コマはスプリント計画、最後の日の1コマはスプリントレビュー、もう1コマはフリカエリ」という図や予めセットしておくというのもすぐ使えそうで、分かりやすい。
・ベロシティを「予測到達点を測るための値」というのも…。
・右手を上げてみんなの注目を集めるって方法はよく考えられているなぁと。
・質問タイムでのやり方は他でも使えそう(特に大勢がいる場で質問することに慣れていない日本人にとっては)。

 こう見ると内容云々よりも「自分が誰かに説明するには?」という観点での気づきが多くありました。

◆ちょっと気になったこと
 質問タイムや懇親会などで…
「〇〇(アジャイル開発/スクラム/デイリースクラム)したい((orうまくしたい)けど、どうしたらいいですか?」
 …という感じの質問が多かったように思いました。
 なんとなく「〇〇をやるための公式」を(回答者に)求めているような感じで。
#実際にそういう意図があるかどうか分かりませんが。

 コンテキスト次第ですし、うまくできる結果に至る公式などありません。

 その点では質問タイムでの講師の方々がしきりに…
「自分のコンテキストでは〜」
「これまでこういうケースがあった〜」

 …というフレーズを使っていたのは…
「なにをもって【上手く】かも人それぞれだし、それに至る方法を見つけて、やるのも自分達それぞれだよ」
 …というメッセージだったのかなぁ?と思ってたりします。

#「恐れずに自分一人からでも一歩やってみれば?それによってフィードバックを得ることができるよ」というのが私の回答だったりします。

◆その他の感想
 これまでScrumBCを神戸と今回の大阪の2回、そして、2012年1月に認定スクラムマスター研修を受講する機会に恵まれました。

 そして、それぞれの間に実際に(主にスクラムマスターとして)スクラムを経験できました(色々壁にぶつかったりもしました)。
 そのため【実践→自分なりのふりかえり→(ScrumBCなどでの)有識者とのディスカッション→またそれらをもって実践】という良い流れができていたように思います。

 (難しい面もあるかもしれませんが)実践したり、もっと深く考えてみたりして「自分はこう思う/こうやってみたけど、講師陣(他のみんな)はどうよ?」的な会話ができるともっともっと得るものが多くあるように思います。

***********************

 何はともあれ本当に楽しい、そして充実した1日でした。
posted by yohhatu at 07:13 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年06月19日

[仕事]「会社を移る」ことと「部署・プロジェクトを移る」こと

 主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。

**********************

 弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか…寂しいなぁ」という方もいます。
 ただ、たいがいそういう人とはTwitterやFacebookなどでつながっていたり、ブログを読んでいるので「元気にやっているなぁ」と分かります。
#そしてそれを励みに「自分も…」と思ったりします。

 ふと…
「同じ会社に所属していても、部署が変われば、日常的に言葉を交わすことは少なくなることがある。それって会社を移るのとそれほど変わらないのでは?」
 …と思ったりしました。
#もちろん事務手続きなどは別で。

 部署の異動以外でも、「自社での開発」から「お客様常駐(そのまま数ヶ月帰ってこない)」のパターンだと(同じ部署でも)言葉を交わすことは少なくなります。

 ただ、食堂で見かけたり、エレベータで乗り合わせたりしたら「久しぶり。最近どうよ?」てな感じで言葉を交わします。
 で、それは冒頭に書いたように(会社を移った人が)TwitterやFacebookで興味深い事をつぶやいていたり、書いているのを見かけたら「久しぶり。最近どうよ?」と声をかけるのと感覚的には一緒だったりします。

 部署異動したり、プロジェクトを移ると、(会社的に共通な)お作法以外に、ローカルルールや独自のやり方があり、けっこう覚えることもそれなりにあります。
#時にはそれまでのお作法が「間違い」と言われることもあったり(苦笑)

 また「知った顔」という意味でも、(プロジェクトによっては)ほとんど初対面ということもあり、結局(あまり価値の高くない)「まずはお互い知る」というチームビルディングにパワーが必要な状況も多くあります。
#組織としての成熟が足りないとも言えますが、そこそこ普通な光景だと思ったりします。

 「会社を移るとそれまでの人脈が…」という方もいますが、お互いが必要と思っていれば会社を移っても情報交換やディスカッションは続けます。
 むしろ、違うフィールドで新しい情報や視点を持ってディスカッションできるようになるので、刺激になります。
#「会社」という共通項以外でやり取りできないのであれば、あまり太い関係でもないと思いますし。
**********************

 こういう感覚は、どの程度「会社」「部署」などの組織を拠り所としているか…によりますが、自分の場合はこんな感じだなぁと思ったわけです。
タグ:考察
posted by yohhatu at 07:42 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年06月08日

[勉強会]社内でのランチ勉強会

 以前、「社内読書会をやってみて」というエントリを書きましたが、今度は社内でやってる「ランチ勉強会」のお話です。

**********************

◆どんなの?
 週に1回、(社内の会議室などで)お昼を食べながら、プレゼン+ディスカッションをしています。
 テーマはプレゼンする人が決めるか、参加者からリクエストがあったらそれについて話すという感じです。

◆きっかけ
 6,7年目頃の同期数人で情報交換のために集まったのが最初だったようです。
#私も途中から参加するようになったので。

 同期ばかりだと発展性のない雑談だったり、(年次が近いこともあり)同じ視点になりがちなので、「色々な人にも声をかけよう」と動いていきました。

 今では、部門もバラバラ…現場/本部系、開発部門/パッケージ導入などなど…ですし、年次も2年目〜10数年まで広がっています。人数も多い時には10人を越えるようになって、最初の頃にやっていた会議室では手狭になり、場所を変えたりもしました。

◆どんなテーマでやっているか?
 これまで20回以上やっていますが、テーマも様々です。
・Meteorの紹介とデモ
・CCPMってなに?
・RxTstudyの再演
・社内で作ったリッチクライアントフレームワークの話
・バーンダウンチャートの説明
・世代交代するためには
・お客さんとの付き合い方
・英語勉強会の進め方の相談
・インセプションデッキをつくろう
・社外勉強会ってどんなの?


 後、新しい参加者がいれば、その人の自己紹介もあります。
#同じ部門、同期でも「何をやってきたか?これから何をやっていきたいか?」は知らないことも多く、自己紹介をきっかけに話が盛り上がることも多くあります。
 
 出欠や資料、終わってからのやり取りはyouRoomを使っています。
 ランチ勉強会本編以外の話題…主に最近ネットで話題になったエントリとか…を起点に「youRoomでディスカッション」→「ランチ勉強会本編へ」という流れもあります。

◆「社内読書会」との違い
 冒頭に書いた社内読書会との違いは「組織有りきで考えるかどうか」というところです。
#感覚的でうまく表現できませんが。

 「社内読書会」のメンバーは社外勉強会にも多く出ていたり、若い方が多いこともあってか…
「自分はどうなりたいか?そのために〜」
「(自分のやり方、キャリアの)こんなことで悩んでいる。〇〇はどう思う?」

 …という感じがします(組織云々よりも)。

 一方、「ランチ勉強会」は、中心メンバーがそれぞれお客様と向きあって、また、プロジェクトリーダーなりでやっているからか…
「自分達のお客様とのビジネスをどうしたら良いか?」
「この組織のどこをどういう風にしていけば良いのか?」
 …というような「組織があって、その中でどうすれば良いか?」という話が多くあるように思います。

 良い/悪いではなく、それぞれの立場や考え方があるのですが、両方参加している自分としてはその対比がなかなか興味深いです。

**********************

 「ランチの時間ぐらい好きにさせてよ」と言う意見もあります(また、毎日やっていると疲れると思います)。
 が、普段あまり話さない別チーム、別部門の人と話すことで新しい意見や情報を手に入れる良い機会だと思っています。
#これをきっかけにして新しい何か…「〇〇さん、ランチ勉強会で△△に興味あるって言っていたから、このプロジェクトに引きこんでみよう」とか…が始まるかもしれませんし。

 「いつもの」同僚と「同じような」話をするランチも良いですが、たまにはこういう風に「違う」人と「違う」話をするのも良いと思います。

#ランチ勉強会を継続して続けている当初メンバーの皆さんに感謝です。
タグ:勉強会
posted by yohhatu at 08:14 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年06月05日

[勉強会]「TDD Boot Camp 大阪 1.0」に参加してきました。

 「TDD Boot Camp 大阪 1.0」に参加してきました。
 全国各地からスピーカー、TA陣が集まって非常に豪華な顔ぶれでした。
 
#スピーカー、スタッフ、参加された皆さん、楽しい時間をありがとうございました〜
***********************

◆会場
 楽天さんのカフェテリアが良かったです。
 プロジェクター(2台も!)も無線LANも電源(さすがに座席分はないですが、タップで分ければ全然問題ありません)も完備で良かったです。

 椅子が硬い材質で長時間座っているとツライかもしれませんが、事前に主催者さんが「クッション持ってきた方が良いよ〜」て言っていたので問題なかったです。

 主催者の@bufferingsさんが「今後も勉強会で使って行きたい」と言っていましたが、本当に良い環境だと思いました。

 以下、完全に自分用メモ。
◆和田卓人(@t_wada)さんの講演「TDD のこころ – テスト駆動開発に大事なもの」
・BC(ブートキャンプ)では、(TDDだけでなく)ペアプログラミングも経験できる
・同じお題を解く(ので)コードレビュー大会ができる
→コードレビュー大会は初体験でしたが「他の人ならどう書くだろう?」を知ることができて新鮮でした(実際にこんなことはなかなか業務ではないので)。

・ソフトウェア開発の三本柱
 ・バージョン管理
 ・テスティング
 ・自動化
→現代的、合理的に開発するのに必要ってのはまさにその通りで。イテレーション0ではまずこれをするってのは鉄則かなと思います。
 逆にここを取りこぼすとそれなりにしんどい思いをすることにもなったり。

・バージョン管理
 ・RPGをセーブ無しでクリアしようするもの
→このメタファは良いなぁと思いました。それにブランチを切る時のメタファにもしっくり来ますし。
 今度(バージョン管理に理解を示さない人に)使ってみようと思いました。

・テスティング
 ・開発者が自分の書いたコードに対してテスト(コードを書いて)する

・自動化(自働化)
 ・オートメーション
 ・人間がやっている作業を機械に肩代わりさせる
 ・コンパイル、FTP…などを自動化する
 ・人間が使える時間を増やそう(人間にしか使えないことに時間を使うようにする)
 ・「自働化」は機械がやった結果を人間に教えてくれるってこと
  依存の矢印を逆にする。
 ・ポーリングすることで思考を非同期化して進めることができる

・三脚椅子
 ・三本柱だと切実感が足りないので、三脚椅子というメタファを言うようにしている
  ・「一本もないと安定してしまう」って言われたけど(笑)

・まずはバージョン管理から始めるのが大事

・「テスト」にまつわる混乱
 ・「○○テスト」が多い
  日本語の中でも「ユニットテスト」「単体テスト」の違いがあったりする。
 ・なのでモデルを単純化している
  ・「誰が何のために」
   ・DeveloperTesting:開発者が開発促進のために
   ・CustomerTesting:顧客(のロール)が進捗管理のために
    ※機能が出来上がっているかどうか?価値が出来上がっているか?…を0か1で判断する。
   ・QATesting:品質保証担当者(のロール)が品質保証のために
   ・この話の中には「何を、いつする」てのは入っていない。
  ・というわけで今日は「DeveloperTesting」をする

・TDDとは?
 ・書籍「テスト駆動開発入門」
  何か分からないことがあったらこの本に立ち返れば良い

・動作する、きれいなコードへ
 ・その方法論は2つあって、良い設計をしてその後コードにする…これで「動作するきれいなコード」になる。
  きれいな設計というのは「沼地」であって「完璧な設計」を追い求めるといつまでも終わらない。
 ・動かそうとして初めて分かるということがソフトウェア開発には多すぎる。
  なので、頭の中で考えているよりもはるかに多い。
 ・なのでまずは「(すぐには)動かない」汚いコードから、動作する汚いコードにする。
  その後、キレイにしていくってのがTDD。
→この四象限のスライドは知っていましたが、初めて直にお話を聴いてやっぱり分かりやすいなぁと思いました。
 一方、自分の所属組織の状況に照らし合わせた時にプログラミングをせずに設計する(実際は「設計書を書くだけ」かもしれませんが)人にとってはこの四象限の話はイメージできないのかな?とも思ったりしました。

・TDDと黄金の回転
 ・四象限に当てまめる
 ・汚い→キレイにするには意思がいる
 ・大事なのは小さいうちから初めてやる
 ・よくある質問で「リファクタリングのコストをどう説明するか?」
  ・小さいうちからリファクタリングをやっておけば良い
   大きくなると投資効果や説明責任が必要になってくる
 →リファクタリングを「個別タスク」て考えると確かにその通りで、「テストコードを書く(もちろん通る)」と「リファクタリング」もセットにして「プログラミング」タスクという扱いにしていくのが良いアプローチだと思っています。

・TDDをこころ
・少しづつ、少しづつ
 ・小さいDoneを少しずつ定義していく
・複数を相手にしない。ひとりずつ対処する。
 ・1つてストコードを書いて1つ流す

・すばやくまわす
 ・早ければ早いほど良い
→チームやプロセスにボトルネックがあると素早く回せないので、それも明白になって改善活動につながると思いました。

・素早く回っていないと「問題が大きい」「ピントがボヤけている」証拠。
 ・小さくすることで「どこが」ピントがぼけているかが明確になる。

・自分が最初のユーザ
 ・引数にString×6あるようなメソッドって自分が使う際に使いやすいと思うか?
 ・ドッグフードを食べるのが大事

・不安をテストに
 ・祈るようではダメ
 ・命綱を編むようなものがテストコード
  ・リリース=バンジージャンプ
   で、バンジージャンプする前になって命綱を編むのではなく、日々ちょっとづつやっておく

・TDDをはプログラミング技法
 ・最大のメリットは「心理的」なもの
  ・即座にフィードバックを得るため
  ・書いたコードに自信を持つ
  ・これから書くコードに自信を持つ

・TDDの真の目的
 ・変化に対応できるのは「健康」なコード
  ・無駄がない:引き締まっていて、贅肉がない
   ・重複がない、分かりやすい名前で、分かりやすい構造になっている
 ・チームの「健康」
  ・日々毎日動くかどうか分からないようなコードを残業して書くようでは「健康」ではない

・実装時間具合は1〜2割増、不具合は半分位に減る
 ・デバッグの工数が減らす
 ・要求が洗練された
 ・コードの品質を上げる
 ・開発工数を減らす

・TDDを導入したことによって減る工数=デバッグ
 ・軽微なミスが減る(テストコードもカバーしてくれる)
 ・小さいバグはコードを書いているのでテストコードがあるのでデバッグをほとんど必要でなくなる
  ・テストコードがないとデバッグ(推論)をしないといけない
   時間が読めないデバッグの工数が減る

◆デモペアプロ
 プロジェクターとの接続トラブルで急遽デモマシンを交換していましたが、これがまたキーバインドが違っていて更に混乱を…って感じでした(笑)。
 ペアプロの場合、お互いのツールやキーバインドが違っていると生産性(や気分)に影響が出るので、「合わせる」か例えばキリの良い所でコミットなりして、マシン毎交代するなどの工夫がいると思いました(以前、ペアプロやっていた時にはeclipse派とNetBeans派がチームに混在していたので、そうやっていました)。

 またメモ。
・とにかく最小限で書くってことが大事
・ゴールの最小限から書いていく
・仮実装
 ・「今書いたコードが絶対通る」コードのこと
 ・これで失敗するってことはテストコードがバグっていることがすぐに分かる
 ・「テストコードをテストコードが必要になるのでは?」の前に、仮実装をすることで「テストコードのテストをする」ことができる。そのタイミングがTDDとして良いタイミングである。
  もしこれをしなかったらミューテーションテストが必要になる。

◆吉岡弘隆(@hyoshiok)さんの講演「大規模ソフトウェア開発とテストの経験について」
・今日のメッセージ「開発者の皆さん、テストを書こう」
・安定性に差こそあれ常に動くものがある

・学んだイロハ
 ・マニュアルを読むこと
 ・テストを書くこと
 ・デバッグの仕方
 ・質問の仕方
・環境は変化する
・自分は変化しているか

お昼直後、かつ、吉岡さんの声が心地よくて、うつらうつらしてしまいました…(すいません)。

◆関将俊(@m_seki)さんの講演「どこまでがTDD?−-TDDの引き算と足し算」
・TDDの場合、最初の「目標を考える」のがポイント。
・まずはそれを書いてRedにする。
 テストに沿って実装する。
・壊してみる活動をTDDのサイクルに入れても良いのでは無いか?
・より良く、より強く…動く、キレイに続く指針
・Destoroyがキーワード

◆ペアプロ
・久しぶりだったので余計に疲れた(心地良い疲れだけど)。
・ドライバーでもナビゲーターでもあれだけ集中すれば疲れる。
 反省点として(TAの方からも言われたけど)もっと頻繁に交代、休憩を取りながらしたら良かったかも…と思いました。
・(直接TDDの話ではないですが)ペアプロやると設計やプログラムに対して不安が少なくなり、自信を持って進める(少なくとも2人の知識が入っている)ので、精神衛生上、自分にはとても合っているプラクティスだと再認識しました。

◆その他、懇親会
・グリーンバンドの話
 ・(プロフェッショナルでも)テストコードを書くのが面倒くさいことがある。でもそのグリーンバンドを見て、「プロフェッショナルであるならば、自分の書いたコードは説明できるのは、当たり前だし、テストコードを書くのが当たり前」と思い直す。

・吉岡(@hyoshiok)さんとお話できて良かったです。
 (社内外の)勉強会を主催したり、お手伝いすることがちょくちょくあり、その中で「勉強会と組織との関係」みたいなことを考えていました。
 なので、吉岡さんがブログに書かれているこのエントリなど(たくさんある)について話をしたかったわけです。

・(Skypeでは話したことがあったけど会ったことは無かった)きょん(@kyon_mm)さんとも会えてお話して、Groovyをえらく薦められたり(笑)。

***********************

 何よりも(特にペアプロやってる時の)熱気というか集中力がすごかったです(後で写真見て余計に感じました)。
タグ:勉強会 TDD
posted by yohhatu at 07:58 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。