Hatena::ブログ(Diary)

Munch Box

2014-04-29 新人君へのアドバイス集(その1)

 2月半ばから本社を離れ、(一応数ヶ月の約束で)別の現場の方にヘルプに出てます。
そこで今年の4月で2年目を迎える新人君と、今年で4年目(?)位だけど
今迄全く開発に携わる機会が無かったメンバー2人と仕事をする事になり、
老婆心ながらこの二人に何とか自分の持ってる知識の一部でも伝える事が出来ればと思い、
日々アドバイスやらレビューバックした事をメモして、月一回それぞれに振り返りの為に送る
なんて事をしてました。

 結論を言ってしまうと、残念ながら前者の2年目君については、、、これ以上の
続行が難しいと判断して、自分の中で終了としてしまいました。。。。

 ただ、それ迄に記録した事がムダになるのも勿体無いので、業務とか現場に特化したような
知識とかは(守秘義務的な観点からも)載せる事が出来ないので
一般的な話に絞ってアップしてみようかな、と。

 ⇒ 正直なところ、周りの同期からみても既に遅れが見え始めている彼に対して
   勝手にこっちが「焦り」を覚えて、少々キビシ目に言っていたという事もあって
   それがプレッシャーになり、反発を招く事になってしまったようです。

 と、いつまでもボヤいてても仕方ないので、本題へ。

(※)以下、2年目君と4年目君にそれぞれしたアドバイスを特に区別せず
  混ぜこぜに挙げてます。
 
 
【彼がファシリテートしていた会議が終わった後にしたFB】
 ・議事メモは(提出を求められていなくても)取るようにしておいた方が良い。
 
 ・今回の会議の目的はそもそもどういうものだったのか?
  ⇒ 「情報共有?」「何らかの決定?」「相談・依頼?」
    参加してて何がしたかったのかが良く分からなかった。
    また、「出席者が次にどういうアクションを起こしたら良いのか?」は
    明確にしておいた方が良い。

【ソースと単体テストのレビュー後にしたFB】
 ・テストで大切な事は?
  ⇒ テストは「バグを見つけること」が目的。バグが見つけられないテストケース
    テストコードは極論すればゴミ。

  ・今回の(単体)テストの「ポイント」は?
   ⇒ 今回は設計書に書かれてることが間違いなく(=過不足無く)実装されていることを
     確認するためのテストケース(すなわち設計書と1対1)でないとダメ。
   ⇒ 例えば異常系のテストが記載されていないが、(設計書に載っている以上)
     それもやる必要がある。
     今回であれば、同じ処理を2回繰り返せば一意制約エラーが簡単に起こせるので
     異常系テストケース確認はそれでやれば良いのでは?

  ・ソースはシンプルに。
   ⇒ ソースのバージョン管理をしておけば、不要なコードをコメントアウトして残す
     みたいなことはしなくて済む。
     そういうものも含めたソースのゴミは極力減らして、シンプルに書く事。

     半年後の自分から「なんだこのコードは?」というツッコミが来ないように
     メンテナンスを意識してシンプルに書くようにした方が良い。

【質問があった時の(設計)課題に対しての考え方についてのFB】
 ・設計に関して課題が見つかった時、どう解決していくか?
  ⇒ まず、自分でその課題に対して「どうあるべきか?」を考えて、
    レビューを依頼する。もしくは有識者に確認するというのでも良い。
    いくつかの方法はあるが、要は結局「自分で考える事」が重要。

    ⇒ 今回なら、A案、B案、複数の方法があると思うが、
      どれを選択するか?についても頭を使う必要がある。
      また、その選択に関して(レビュアー等に確認する時は)
      「根拠(とか何故そのように判断したのかの理由)」を示しながら
      聞くのが良い。

【システム設計の考え方についてのFB】
 ・各処理の前提条件を押さえている?
  ⇒ 全体の流れの中で、その処理がどの位置に存在するのか?

    例えばワークテーブルのデータ削除はそのテーブルを利用する処理が
    動く直前に行うことが多いが、それはなぜか?(直後に動かさないのはなぜか?)

【レビュー後にFBした事】
 ・レビュアーは完璧ではない
  ⇒ レビューのレベルはレビュアーのレベルに依存するので、
    残念ながら100%の間違い・漏れぬけの指摘が出来るわけではない。
    (ハッキリ言ってしまえば、レビュアーのレベル以上の指摘は出来ないし、
     逆にあまりにも下らない誤字脱字等が多ければ、それらの指摘だけでレビュアー
     集中力・時間が割かれてしまって、レビュアーが指摘できる
     設計についての注意点等の指摘が半分も出来ないかもしれない)
    
    レビュアーの指摘にインスパイアされて、レビュアー
    指摘の漏れに自分で気づくことが大切。

    また、指摘点が100%正しいわけではない。
    勿論それなりの観点・根拠でレビューの指摘が上がってくるハズだが
    その指摘自体が妥当かどうかについても自分で一度考えてみる。
    妥当でない思ったら、その根拠を明示してレビュアー
    逆質問して、認識を合わせていく必要がある。

【作業の仕方についてのFB】
 ・SVNへのコミットはこまめにするべし。もしくは最低限ロックをかけて作業する事。
  (※)残念ながらこの指摘はこの後毎月のように指摘する事になったのですが。。。
  
っと、まだまだ1/3にもなってないけど、長文になりそうなんで、一旦区切りますか。
  

2014-04-26 AgileSamurai 埼玉道場に参加してました

 今年に入ってプライベートでも仕事でも色々あって
すっかりブログを書く、ということから遠ざかってしまってました。。。orz

 と、いうわけで短めですが、久々に(?)勉強会に参加したんで。
 
「第11回 アジャイルサムライ読書会 埼玉道場 - PARTAKE」
 http://bit.ly/1lrlJvQ
 
 当日はちょっと早めに出発してこれまた久々にアキバに寄ったりなんかして
USB扇風機やらを仕入れつつ、今回は赤羽ではなく王子の会場へゴウ。

 初参加の方も2人ほどいる中、3人3人のテーブルに分かれて例の如く
今回はユニットテストの章の音読と議論を開始。

 各自疑問に思う事とか議論のネタなんかを付箋に書き出しつつ、進行。
今回はワークショップは無く、章が短かった事もあり20〜30分ほどで
本は読み終わって後は議論でたっぷり2時間くらい?

 個人的に印象に残った話は、いんだれさんのAgileに対しての考え方。
WFが「系」の考え方を重視して整理・整頓して進める方向なのに対して、
Agileは「プロダクト」という枠を「TDD」「Scrum」「かんばん」等々で
埋めていくイメージである、というお話。

 ⇒ 陣取り合戦とか、塗り絵っぽいのかな、と。ご本人はまだしっくりきてはいない、
   ということを仰っていましたが面白い考え方だなーという事で
   新しい発見でした。
   
 後、みほらぶさんの「全体は部分の総和ではない」というお話。
こちらについては、個人的には大体理解できたつもりだけど、まだ腹落ちしきれて
ないかな、と。

 ⇒ 異論・反論がある、とかでは無くて、基本的に合意・同意なんだけど
   自分の中で他人に対してキッチリ説明できるロジックが構築できてないと言うか
   自分の言葉で説明できない感じかなぁ。

 と、いうわけで、今回は(引っ越して千葉になってしまったために)
懇親会はちょこっとしか参加できませんでしたが、いつものように
有意義な時間を過ごす事ができました。
どうも有り難うございました m(O)m

 あ、そういえば先日参加した新宿道場の方、まだアップしてなかったな。。。

2014-02-08

記録的な大雪!

22:11

 げ、気付いたら去年から更新してなかったのか。。。
 
 今日の東京地方は記録的な大雪で、朝から(正確には昨日の深夜から)
降り始めた雪が未だに降り続いてて、道路はもう20cm以上の積雪になってるみたい。。。

 いや、結局今日は近所の整体に行っただけで引きこもってたんで
特に何ということは無いんだけど、あまりの雪だったので書き留めておこうかな、と。

 これは1週間くらい雪残るなぁ、多分。。。

2013-09-14 「XP祭り2013 〜 XP 〜」に参加しました

 1年ぶりのXP祭り参加、ということで今年は去年途中からになってしまった
オープニング漫才(?)を始めから見ようと、ちと早めに出発、、、
したら、まだ開場準備中のタイミングで着いてしまいました(汗)
 
 ちなみに当日のまとめはこちら
 
 「『XP祭り2013 〜 XP 〜』のまとめ #xpjug」
  http://bit.ly/1eTSpuc
 
 午前中の漫才にはいつものお二人だけでなく、kawaguti さんも加わって
レッツゴー三匹状態でXPについての解説を。

 で、引き続いて kawaguti さんから
「高度12,000フィートからの Agile と Lean」のお話。
http://bit.ly/167ZPlU

 個人的には資料途中で話されていたバーンダウンチャートの
昇龍拳」と「かかと落とし」が面白かったなぁ、と(^^)

 で、例の如く(?)若干押し気味で、次の鷲崎先生にバトンタッチ。
 
 鷲崎先生からは「SEMAT」の内容についての講演がありました。
途中、チラッと呟いたんですが、AgileやらリーンやらDevOpsやらWFやら
色々ソフト開発に関する話(だけでも無いけど)がゴチャゴチャしてる
状況を整理しようとする試み自体は個人的に興味あります。

 が、確か自分の記憶ではOOの設計手法についてまとめようとして
結果的に纏まりきれずに、とりあえず記法だけでも統一するべ、
ってなって生まれたUMLの話と同じような事にならなきゃイイけどなー、と
思ったりします。

 お昼ご飯はコンビニおにぎりでチャチャっと済ませて、
(ちょこっとだけゲリラLT覗いて)昼イチのアジャイルセンター試験に参加。

 意外と参加者が少なくて(自分はすぐに満席になると思ってたのに)
結局自分入れて20人位だったかな?

 セッション中の静かな事(ワラ)
こんなに静かなセッションってのも初めてでは無かったでしょうか(^^)

 40分程度で39問、しかも半分は(センター試験だけど)記述式という
結構ハードなものでした。自分は試験やる時のクセで、問題用紙に回答を
書き込みながらそれを解答用紙に転記するという手間のかかるやり方で
取り組んだこともあり、結局3問程度空白のまま提出する事になってしまいました(残念)

 解いている最中、思わず吹き出すような問題(選択肢)とかありましたが、
こちらとしては時間的なものもあり、一杯一杯になってしまってボケる余裕も殆ど無く。。。orz

 とりあえず、何とか終了。疲れたー。
 
 で、続いて、やっとむさんの「宝探しゲーム」のワークショップに参加。
以前から幾つかのイベントで開催されているのは知ってたんですが、
どうもタイミングが合わず、今回ようやく初参戦。

 開発側とビジネス側が協力して如何に他のチームより
ユーザを獲得するか、というゲームなんですが、色々と示唆に富んだ内容でした。
(因みに4人チームで2人ずつビジネスとITの担当に分かれますが、
自分はビジネス側でゲームに臨みました)

 結果としては残念ながら4チーム中、最下位という結果でした。
ただ、戦略的には「追い込み方式」で「見せ場」は作れたと思うので
個人的には結構満足でした。

 ⇒ 負けた原因を分析すると、1.サイコロ運、2.最後のターンの
   仕掛けタイミングが1手だけ早かった、ということかなーと。
   1.のサイコロ運については、どうしようもないですが、
   2.の仕掛けタイミングはコントロールできたので、
   ビジネス担当として申し訳ないことをしちゃいました。。。
   それが上手くいってたら、多分トップ獲得も十分可能性があったかな。

 とはいうものの、何より良かったのは、ゲーム中にビジネスと開発が如何に協力・
ゴールの共有ができるかが、重要だという事が実感できるWSだった事です。

 市場の不確実性(変化)への対応や、ビジネスとITの協力、他チームの
動向を踏まえた戦略等々、こういう内容のWSを新人研修なんかでも取り入れられないか
チト検討したいですね〜。

 で、続いて、昼イチのアジャイルセンター試験の解説セッションに。
古文の先生っぽい(勝手なイメージ(ワラ))和服姿のマチ子先生、
ジャージを着た体育の(飲んだくれ?)nawotoセンセイ、
用務員のオジサンのm_pixyさんという3人が解説に。

 答案用紙の返却で中々名前を呼ばれず、「ヤバ、お前追試!というオチ?」と
若干ドキドキしてましたが、なんと結果は2位。自分でもちょっとビックリ。
平均は64.3点だったようですが、自分は何とか78点取る事が出来てました。

 ただ、個人的にはボケ切れなかった所がスゴく反省。。。解説中、
オモシロ回答を前で発表してたんですが、唯一取り上げられたのは
「旅に出る」という回答だけ。
もっと他にも色々ボケ方あったやろ、と・・・orz

 来年はキッチリとボケられるように修行を積んできます。。。

 で、最後はLT祭りにクロージングと続いて、今年の僕のXP祭りは終了となりました。
(懇親会の方、カード決済ができなかったので、参加を諦めたんですよね〜。
 まぁ、多分実行委員の人に掛け合えば現金払いとかでも良かったと思うんですが、
 余計な手間を増やすのも悪いんで、今回は素直に帰ることにしました)

 と、いうわけで1日充実した時間を過ごす事が出来ました。
スタッフの皆さん、登壇者の皆さん、並びにWSで同じチームだった皆さん
そして参加者の皆さん、どうも有り難うございました。
 

2013-07-28 「TDDeXchange in Tokyo 」に参加しました

 なんやかんやがあって、月が変わってからのブログになってたりして(汗)
 
 と、いうわけで、思い出しつつ感想を少々。
 
 「TDDeXchange in Tokyo」 http://bit.ly/16vRA3q
 
 ⇒ Togetterはこちら http://bit.ly/13hmtbk
 
 当日きょんさんが発表したスライドはこちら
 「TDD自殺http://slidesha.re/14ggWVI
 
 で、もって、きょんさんのブログはこちら
 「「TDD自殺」を発表しました。 #TDDeX - うさぎ組」 http://bit.ly/11JHrSu
 
 実はこの話、ブログ自体はかなり以前に読んでいて、
別のイベント(HCDのイベントだったかな?)の懇親会で
きょんさんに直接話を聞いたりしてたんで、
個人的には「スッ」と入って来たんですよね〜

 ただ、残念ながら自分の勉強不足もあって、まだ「Domain」という
単語がハラオチしきれてないので、若干理解が誤解になってたり
浅かったりするトコがあるかもしれませんが、
TDD自殺」を自分なりの解釈でまとめると

ソフトウェア(or システム)を作りたい場合は、何らかの理由(=解決したい問題)がある筈。
 その【理由】に対しての解決策が適切かどうかを確かめる為には、(TDDの場合)その理由を
 テストコードで記述する。でもそれって、ムダになるんじゃないの?(=わざわざ
 「テストコード」という形で擬似的な「理由」を書かずに、直接「理由」自身を書けばいいんじゃね?)」
 
 という問題提起なのかな、と。
 
 うーん、まだまだ未消化なんで、自分の言葉にしきれてないなぁ。。。
継続検討課題ですな、コレハ。

 さて、イベントの中身ですが、基本的にTDD知ってるよね、という前提で
集まってるメンバーなんで、言語や使ってる開発環境は違うかもしれないけど
何とかなるよね、みたいな感じで、後半はペアプロをメインに
各々のスタイルでTDDに取り組む感じでした。

 僕は久々にペアプロにチャレンジ、っつー事で手を挙げてペアに
なったんですが、環境が「Mac+USキーボードIDEAVimキーバインドGroovy」という
普段の仕事でも個人でも利用した事が無い組み合わせの環境でチャレンジ(^^;;
(普段はWindows+106キーボードEclipse+通常のキー設定というスゲー
ベタな環境なモンで。。。もうちょっと道具にこだわれよ、というツッコミが山のように来そうですが(汗))

 で、マズは(主に僕の)肩慣らしということで、
FizzBuzzペアプロで実装。いやー、手が動かない動かない(汗)
結局、結構時間がかかって(20分位やってた?)、第一ラウンドは
殆どきょんさんからの課題には着手できず。

 で、第二ラウンドは第一ラウンドの続きと言う事で、適宜
ドライバーとナビゲータを交代しつつ実装を進めつつ、リファクタリングもしつつ。

 やっぱり、自分と同等以上のレベルの人とのペアプロは(気が抜けないけど)楽しいな、と。
フツーに「ココはFactoryの方が良くねっすか?」「結果的にAbstractFactoryになるかな?
いや、Strategyの方が・・・」的な感じでコミュニケーションが取りやすいなという事を改めて実感。

 何とか自社の方でもそういう状況を作って行きたいなと色々画策中ですけど、、、
道は遠いなぁ。。。まぁ、ボチボチやりますけど(^^;

 で、最後は懇親会。結構な量のピザが出たけど、あっという間に消えてなくなったり(ワラ

 いつの間にかきょんさんが「品質特性」についての話を始めてたんで
その辺りの話も聞けたんで(で、いらん事ツッコんだりして)最後まで楽しく過ごせました。

 と、いうわけで遅くなりましたが、主催のきょんさん&素晴らしい会場を提供してくれた
すえさん&参加者の皆さん、どうも有り難うございました!