薄まる自分
PCやら育児やら、徒然についてメモります。
<< March 2024 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
 
デル株式会社 ブログパーツ
RECOMMEND
RECENT COMMENT
RECENT TRACKBACK
カウンタ
ブログパーツUL5
JUGEM PLUS
MOBILE
qrcode
PROFILE
PR
無料ブログ作成サービス JUGEM
 
スポンサーサイト

一定期間更新がないため広告を表示しています

- | | - | - | - | - |
2013/02/02 『JUnit実践入門』写経・実践会 in 横浜 #3 #junitbookに参加しました。

【送料無料】JUnit実践入門 [ 渡辺修司 ]

【送料無料】JUnit実践入門 [ 渡辺修司 ]
価格:3,465円(税込、送料込)


JUnit実践入門の写経・実践会は#2に参加しての二回目。
前回は、1日で4章〜10章と一気に飛ばしたので内容豊富でした。
今回は11章のモック系のみ。前回とは全くスピード感が違っていました。

今回の対象は第11章 テストダブル、モックのような代役を立ててテストを行う話です。
議論としては、モックに関するもの、それ以外のものもいくつか出て楽しかったです。

今回は、あの@t_wada さんがドタ参してくれたので、いろんなトピックについて深い話を聞けました。

いくつか、トピックを書くと

privateメソッドはテストすべきか?

→ Groovyなら private メソッドでもテストできるよ(違う)。
→ 否。private メソッドはpublic メソッドのテストによりテストができるはずである。また、private メソッドについてテストをしなければならないほど複雑であると考えているなら、private メソッドの責務が多すぎて、分割すべきである。

これも、よく自分も聞いてしまう質問だけど、再認識した。

リファクタリングの効果を示した統計情報などはあるか?

→ リファクタリングをやった場合とやらない場合で比較をしなければならないので、大企業が実験的に実施した結果として出てくる事がある。そのような情報があったとしても、定量的に示すのは難しい。リファクタリングの効果としては、機能追加を行う・バグ修正を行う速度を落とさないようにできるということであるが、あくまでも間接的な価値であり、直接的な価値を生むものしか評価されにくい。なので、リファクタリング自体はあくまでもプログラミングの一環として工数を積むのがよいと思われる。

「リファクタリング工数」という言葉が出てきた時点で、ほぼ敗北は決定している…。

「リファクタリングした」なら言ってもいい!


生産性って?

→ ソフトウェアの行数はプログラミング言語の特性にも左右されるし、長ければ機能が実現されているというものでもない。それを生産性として価値を生み出す速度として定義するのは全く馬鹿げている。生産性という言葉を使うのであれば、個人として予定と実績を記録し、過去の自分よりどれだけできるようになったのか。ということくらいだろう。

依存クラスのテストまで含めたテストはUnitテストじゃないの?

→ 急進的モッキスト(モック主義者)は、Unitテストとはクラスを結合させないテストであり、別のクラスを呼び出している場合、結合した状態で試験をするのは結合テストであり、Unitテストではモックかスタブを使うべきであると、言われていますが、理想的な振る舞いをモックにさせてテストを行うとテストの安定性は高まるが、モックのコード量は増えるし、依存オブジェクトを含めた振る舞いの試験が後回しになってしまう。
Unitテストは基本的には十分速いテストのことであるが、振る舞いを確認できる範囲とテストの安定性のバランスを考える必要がある。
(議論の内容をあまり追えてないので適当に書いてるところが多いです(^^;)

Javaのモックライブラリとしては何がおすすめ?

→ 黒魔法なモックライブラリはあるが、mockit が実装機能のバランスがとれているところ、xUnit本に出てくるモック・スタブ・スパイとの用語の対応がとれたままうまく実装されているのでおすすめ。


さらに、和田さんの出現が確定した段階で、タネマキの管理人さんに『SQLアンチパターン』を買ってきていただいた上で、和田さんにサインをいただくイベントが発生しました。


読みます。そして勉強させていただきます。

勉強会後には、中華料理屋でご飯を食べました。
そこでも、いろいろ含蓄のある話を聞くことができました。

みなさま、楽しかったです。ありがとうございました。

そして、私も社内での発表がんばります。
横浜道場「ストーリー収集ワークショップを開催しよう」に参加しました! #横浜道場 #agilesamurai
 http://connpass.com/event/834/

アットウェアさんで開かれた横浜道場アジャイルサムライ読書会「ストーリー収集ワークショップを開催しよう」に参加しました!

タイトルは
「ストーリー収集ワークショップを開催しよう」ですが、ワークショップではなく通常会です。

本日、まず議論になったのは、ストーリーとは、フィーチャとはなんぞや?でした。

私のイメージとしては、ストーリーというのが顧客の希望を含めた業務の流れであり、その中のひとつひとつの機能がフィーチャというイメージでした。
でも、アジャイルサムライで語られているフィーチャは、顧客がやりたい抽象度の高い機能をフィーチャといい、その中で書き下したユーザのさらに具体的な実施内容のことをストーリー、ユーザーストーリーと言うようでした。

6章について、ユーザーストーリー、フィーチャなどの用語が乱立していて、厳密に読もうとするとやや難解ですね。適当に流せばよいのかもしれませんが。

本日の議論で気になったポイント:

・なぜ、要求聴聞会ではなく、ストーリー収集ワークショップなのか、やることは変わらないのだけど、コンサル系では横文字をよく使う。そして、チームとして取り組む雰囲気を作る。

・ストーリー収集ワークショップには議事録は不要!なぜなら、議事録にとらないと忘れてしまうようなストーリーは重要ではない。また、議事録が必要なのは顧客との信頼関係ができておらず、防御壁(議事録)が必要であるから。

・よいユーザーストーリーとされるINVESTのEstimate(見積もれる)とは何か。十分小さくざっくりでも見積もることができる大きさであること。交渉可能とは、内容を決めすぎないこと、ストーリーが複数あった場合には優先順位をつけて落とせること。

でした。

また、たのっちさんから、DevLove Pub によるコミケで販売するLT関連本の話がでました。電子書籍で、コミケ終了後、一般のサイトからも購入できるようにするとのことです。楽しみですね! > ライトニング・トークス 驚異のプレゼン さあ、プレゼンに目覚めよう

スクラム道の本が来年1月に発売される。また10月にイベントが開催されるという話もありました。

@modal_soul から、XP祭り2012 〜ソーシャルチェンジ!〜の告知もありました。もう申し込み可能数が少なくなってきているので、気になる人はすぐに申し込まないといけないですね。


今日はいつもより酔っ払いました。新たにこられた方が3人もいて少し新鮮な横浜道場で、楽しくお酒が飲めました。議論ができました。
今後ともよろしくお願いします。

 @tw_takubon さんが横浜道場のTシャツを作られました。
表側はジョナサンの手書きイラスト入りで、自分でサインをもらったように見えます。
後ろは結構インパクトがあって、これを着ていくと素敵なステマになりそうですね。
私もほしいです。


最後に、スタッフの皆様、ありがとうございました。定期的な開催をしていただけるバイタリティに感動するとともに感謝しています!

アジャイルサムライ読書会 in 横浜道場(2回目)に参加した。#agilesamurai #横浜道場
 読書会というのにも参加したことなかったのに、初めて参加した読書会で、開始10分後には
ワールドカフェという知らない形式で議論をしていた前回…。

今回は、前回、全く本に触れなかったことを反省として?輪読して、ディスカッションを行うのセッションを
同じチームで繰り返し4回行った。

チームを最初から最後まで固定することで、メンバの方々のキャラが分かってくるという面があるものの、
やはり、意見が多少似通ってしまうというところはあったかもしれない。

しかし、この輪読+ディスカッションという内容はよかった。
声に出して音読というのは本当に久しぶりにやったが、改めて1行ごとに内容を吟味することができた。

今回のチームはNo.4で、4名+スタッフ1名構成で、その中の3名が割とSIerに縁が深かったので、
SIer色の漂う議論内容となった。

例えば、「本当にドキュメントと予算をだけを求めている顧客もいる」

「顧客に本当に価値のあるソフトウェアを届けるんだ」の対偶だったり。

発注側と受注側って本当は対等の関係なのに、間違ったお客様は神様ですみたいに絶対的な序列のある関係になることが多いよね〜。
みたいな議論があった。

確かにそうだ。

3つの真実
1.プロジェクトの開始時点にすべての要求を集めることはできない
2.集めたところで、要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって、当たれられた時間と資金よりも多い

というのは、話を聞けばみんな納得するんだけど、会社の中や、お客様との間の関係においては、
真実なんか無視して、計画通り実施し完了するのが真。要求は見積もり時点に出ているものが
そのまま解決されていること。とか、みたいな事になってしまったりするのは今でも平気である。

それによる弊害はやはりソフトウェア開発がナチュラルなのもでなくなり、不自然なものになっていったりする。
そうすると、開発者にとっても不幸なことにしかならない。

アジャイルサムライを読んでアジャイル開発の話を聞くと、一般的な受託によるソフトウェア開発に比べて
大変だけど、顧客が得たいものに近いものをデリバリできるような気がする。

SIerによるウォーターフォール開発でもそれがきちんと回って、きちんと開発できていればよいんだろうけど、
世の中との軋轢が高まっていて、競争力がどんどん低下しているのが昨今だ。

今日の議論でも、プラクティスはあくまでもこれまでのノウハウであって、銀の弾丸ではない。
成功するたった一つの方法というのはなくて、自分たちで考えて、自分たちのプロセスをまわすしかない。
というのがあった。
自分の会社でもアジャイルな開発をできるような日が来るのかわからないけど、
勉強会に出つつ、いつきても対応できるように、プラクティスを徐々に今のウォーターフォール的な
開発に適応しつつ準備をしていきたい。

次回のアジャイルサムライ読書会 横浜道場は3/8であることが濃厚らしい。
3/8はすでに何かのイベントにエントリしているので出られるかどうかあやしいけど、
なるべく出るようにしたい。

今回、出席して思ったけど、横浜道場は、アジャイルをバリバリにやっている人というのは少ないけど、
それだけに一見さんお断りみたいな雰囲気がなく、アットホームな感じがよいと思う。

次回は第3回の読書会で、おそらく輪読+ディスカッションだろうけど、第1回、第2回に出ていない人でも、
すっと入ることができるだろう。

ということで、次回は会社のメンツを誘っていきたいと思う。(いけるかわからないけど)

最後に、スタッフの皆様、本当にありがとうございました!
お疲れ様でした〜。

2012/02/16 デブサミ2012【16-B-1】極上のSI戦略 講演メモ #devsumiB
 デブサミ2012 2/16【16-B-1】極上のSI戦略 の講演メモです。
まとまってなくて、長いです。

極上のSI戦略

発表者:ウルシステムズ 漆原 茂 氏

お客様のビジネスを動かすSIは格好いい!
エンタープライズ開発は格好いい!!
10年前と比べてユーザ企業も技術者を欲しがっている。

■SIの問題点
・SIは失敗する(ことがある)
・大規模SIは儲からない
・小規模もっと儲からない
・開発者のスキルにばらつきがある(オフショアは典型例)
・単金のデフレが起きている
・品質が低い。価値が低い。

■極上のSIを目指して
・極上のSIとは何か?
 ・大型案件?儲かれば?最新技術を使えれば?自社製品売れればよい?
   検収がもらえればよい?
 →そうではない

■エンタープライズ開発の醍醐味
 ・顧客企業の命運がかかる。
 ・多くを任される
 ・期待が大きい
 ・ステークホルダーが多い
 ・ハードルが高い。プロフェッショナル分野
 ・業務知らないと大変
 ・技術知っていることが前提
→企業の命運がかかり、業務に直結して難しいことを開発するのが
  エンタープライズ開発であり、それが醍醐味。簡単なWebサイト開発などではない
 
■嫌なこと
・顧客評価が低い/顔が見えない
・多重請負い構造/日雇い派遣
・大量の人月で薄めて丸投げ
・商社的物販/作為的コンサル(開発取ること前提のコンサル)
・質が低い。年収低い
・過剰労働。無責任、他責にしたがる

■何故、そうなるか?
・受注型のビジネスモデルがそうだから
 ・人月の膨張を成長と勘違い(案件がでかくなって売上あげればよい)
 ・受託開発のリスクヘッジのために
   ・下請けに丸投げ、顧客への責任の押しつけ
 ・多重請負い構造
 ・無理な受注

■これらの真逆をやれば、どうなるのか…。
・人月拡大を狙わない。売上は追わない
・顧客満足優先、売上は後からついてくる
・品質、技術に徹底的に拘る
・アサイン兼務なし(1案件に100%):難しいエンタープライズ分野の開発だから兼務なんか無理
・外注や初心者で薄めない
・単金は下げない

これらをやるには経営者として覚悟が必要(ウルシステムズでは2002,2003の時期)
大きくわけると次の3つになる。
(1) 案件の「取り方」を全面的に変える
(2)「やり方」を変える
(3)「人事評価」も変える

(1)案件の取り方
・プリセールスに十分時間をかける。
  1年とか平気でかける、業務をよく知っていないと難しい開発はできないから、お金は取らない。
・顧客をよく知るための時間を投資
 ・「営業」ではなく、自分たちでやる
・提案内容で妥協しない
 ・言われたとおりに提案しても勝てない。顧客の考えを超えるような提案をする

(1)続き
・取らないものを決める
・プライム以外断る。普通な(誰でもやれそうな)案件も断る。
・正しいメンバがアサインできなければ、涙をのんで断る
 属人性は当然出る。〜がアサインできないので受注できない。
・理不尽に値切られるなら、涙をのんで断る
・こちらからの条件があわなければ、大泣きして断る。
 ・無理してとってもうまくいかない

(2)やり方を変える
・少数、プロパ純血主義でやる
  技術力の高いメンバじゃないと仕事をまわせないから、新人はあまり採らない
  採用するときにも徹底的にフィルタリングする。社員を成長させる。
・品質、技術に拘る。
・案件に100%アサイン、兼務なし
・効率良いコード、しっかりテスト
・先端技術にどんどんチャレンジ(例は、とてもOracle などのRDBMSでは全く間に合わないような
  データ処理をDataGridをつかうとか)
・生産性に拘る
・顧客と一蓮托生となる

(2)(続き)やらない事を決める
・パートナーに丸投げしない
・プロパを3割以上薄めない。(Maxでプロパ:7人、パートナー:3人など)
・言われたとおり開発しない
・意味が無い開発は全力で阻止する(システム開発をしない提案もする)
・他責にしない
・知ったかぶりしない、どんどん偉い人、怖い人にも聞く(業務を知るために)

(3)人事評価を変える
・顧客からの評価優先
・技術スキルに加え人間力を重視
・優秀なPM、プログラマを同等に評価
・年収1200万円のアーキテクトを作る

(3)(続き)評価しないものを決める
・個別のスキルが高いだけなのはNG
・受け身な姿勢、言われたらやる姿勢もNG
・チームの足を引っ張るメンバもNG
・成長をしようとしないメンバもNG
・あきらめ、チャレンジしない人もNG
・保身の屁理屈がうまい人もNG

(3)(続き)案件で進化してもらう
・SV(スーパーバイザー)制度で現場を厳しく手厚くみる
・リストラしない。代わりに成長させる
・アサインをキャリアパスを考えて細かく調整する
・PM等、アーキテクト、開発など、同じ傾向の人を集めると話があって
  成長しやすい
・社内ナレッジ共有

(3)(続き)メンバを刺激する
・チャンスを与える
・メディア連載、書籍の執筆を薦める。会社が積極的にアプローチしてとってくる。
  会社が取りに行かないと執筆などの依頼は来ない
・グローバルなベンチャとの交流
・コミュニティ活動支援
・勉強会
・顧客との飲み会をすすめる

→社員の技術力、開発力などのスキルを徹底的に高める、研ぐ。

■少数精鋭メンバでどこまでやれるのか
生産性を高めれば
・要件定義:少数人数で十分可能、むしろ少数が良い。
 ・業務例外の暗黙知を理解する。
 (設計は含めていない)

・開発
 ・生産性を上げる。自動生成を駆使する。
 ・コードは極力書かない
 
 実績値(100人月規模)
  ・業界標準の生産性        1.4
  ・ウル社の生産性    下手したら3倍とか
 実績値(500人月規模)
  ・業界標準の生産性  1.4
  ・ウル社の生産性    下手したら6倍とか
  ・数億円規模の案件ならば、少数精鋭でも全然できる。
 
・PM
  ・少数がよい。人数よりメンバの質
  ・大規模案件の場合、発注側がボトルネックになるので、
    発注側を支援することで大きな貢献ができる。
  ・ゼネコン型開発は不要にできる

・運用、保守
  ・少数で行う
  ・インフラを外に出す。クラウドの利用で少数でも行えるように。
  ・保守案件は、追加開発をアジャイル開発で行うのに向く
  ・業務運用特化型になる。

■このようなやりかたで利益は出るのか?
・ウル社の経常利益の推移
 3%、-8%、 ?6%、14%
 一旦、やり方を変えて投資(上記のいろんな変更)をしたためにしゃがんだが、
 2年後に上場を果たし、その後も増益傾向
・会社の資金繰りが劇的に改善できた

■例えばこんな案件をやっている
・次世代クラウド
・グローバルリアルタイムSCM
・B2B情報提供システム
  …
(その他沢山)

営業が案件をとってこなくても、顧客からや顧客のつながりから
新しい話がどんどん来るようになった。
案件自体は特別に大きい物ではないが、他でやっていないような
技術が必要なものなどもきている。

■まとめ
・「極上のSI」への道は確かにある。
  ウルシステムズは、頂は見えていないが稜線が見えてきた段階。
  完成していない、これからも課題はある。
・必ずしも大きなSystem開発が来るわけではない
・Developerの現場が喜ぶ仕事

■SIモデルを変革しませんか
・顧客満足が高い
・皆がヒーローになれる
  (地味な〜くんが顧客にはすごく評価が高いなど)
・個々人がものすごく輝ける
・すべてのパート−なー企業が幸せ
・自分たちの誇りのために各メンバは利益を出すから、
  それらの集合が会社の利益になる

以上。 
アジャイルサムライ読書会 in 横浜道場(1回目)に参加した。#agilesamurai #横浜道場
当日までアジャイルサムライの読書会が開かれるなんて知らなかった。
TLに @gantawitter が体調が悪いので今日はキャンセルするという発言をみて知った。
仕事も今日なら抜けられそうだったので、空きをみて参加を決めた。
読書会というのは一度も参加したことがなかったのでどんな内容なのか興味があった。

会場は横浜ハンズの近くの株式会社アットウエア様、地図に書かれた番地だけを頼りに行ったところ少し迷った。

緊張した面持ちで、会場に入ってみるとギリギリだったのでイスが埋まっていた。
空いているところになんとか座った。心に余裕がなく挨拶もせずに座ってしまった。

みなさんシステム開発を仕事にしている方々だろうが、いろんな会社の方が一同に介しているのは面白い。
今日の読書会は1、2章ということだった。アジャイルサムライを読んだのは少し前だったので、内容としては触れているけど、忘れているところもあるから、ついて行けるか多少心配だった。

というわけで、1、2章をパラパラみて始まる前に復習をしていた。

うむ、なんとかなりそうだ…。

と思っていたところ、@tw_takubon さんが開会の挨拶?をされて、始まった。

読書会ってどういうことやるのかと思っていたら、始まって5分後には知らない方々とディスカッションをしていた…。

何を言ってるのか わからねーと思うが

おれも何が始まっているのかわからなかった…

輪読とか講義形式とか

そんなチャチ?なんじゃあ 断じてねえ

もっと恐ろしいものの片鱗を味わったぜ…



実は部屋に入ってすぐアジャイルに関してのテーマの投票があり、8つ位から気になる話題3つに各自がマークをして、件数が多いものを議題にするということだった。

全部で6班あって3つのテーマをそれぞれ2斑ずつで議論した。議論は時間を分けて3回席替えをする。

しかも、ワールドカフェ形式…。

なにそれ?

私のテーブルの他の方はみんな分かっているようだったので聞いてみたところ、
テーブルの上に紙を置き、議論の経緯を書いていく、議論が終わった後に一人だけ残って、次のメンバに入れ替わる。
次の議論が始まるときに前の斑の議論の状況を説明してから、議論を始める。という形式らしい。

なるほど、議論の結果を踏まえてさらに議論をすることで、議論をどんどん深めていける画期的なやり方なんだろうなあ。

私ははじめてやりました。これも面白かった。

さらに、最初のテーブルでは、トークンオブジェクトというものを用いて発言する人はそのトークンをゲットしてから発言し、終わったら中央にトークンを返すという方式を取った。
このやり方も初めてだったのだが、なかなかよかった。

トークンを持っているという緊張感があり、一人の発言が短くなる。また、発言者が明確になる。
一人の人が何回もトークンを取っているというのが分かるので、いろんな人が発言するようになる。
これのおかげで、最初のテーブルはわりとみんな発言していたと思う。
#このルールは強制的なものではなくて、テーブル独自のものだったようだ。

さて、今回の議論テーマは、「アジャイルの導入」、「アジャイル導入時の困難な点、共有しづらい点」、「自己組織化」の3点だった。
私は「自己組織化」を2回、「アジャイル導入時の困難な点、共有しづらい点」1回議論した。

「自己組織化」について考えた。自己組織化とはアジャイル開発では命令に従って仕事をするのではなく、話し合いや自立的に動けるように個人がなっていくことだ。

自己組織化にの要素としてスキルもあるが、普段でもこのテーマは気になっている。
スキルを付けている人は自分でどんどん努力をしていく人だったりして、休日にも勉強会などに参加したり、自分で勉強してどんどんスキルを高めていき、そうしていない人との差はどんどん開いてしまう。
一方、そんなにスキルに興味の無い人たちというのもいて、自分ではそれほど勉強していない(ように見えたり)、会社がスキルを付けてくれるように思っている人もいる。

極論すれば、結局は自分が何をしたいかということに尽きるということになってしまう…。
これではスキルが高まっていかないか。

2回目のチームで議論した中では、他人への信頼が重要ということになった。
・他人を信頼しているからこそ、仕事を任せられる。
・仕事を任されるからこそ必要なスキルを付ける。
・スキルを付けるからこそ仕事ができる。
・仕事ができるからこそ信頼される。
という正のフィードバックループができあがる。というのだ。

難しいけど、確かにこれができればよいことだなあと思う。

会社の組織の中でも、そういう尊敬に基づいた信頼があるかどうかというのが重要だ。

会社では特に上下関係がある。
むしろそれがあるからこそ会社だと言ってもいい。
その中でも部下という立場の人にも尊敬を持って接することができるか、
上司に対して尊敬を持って接することができるか、
同僚に対しても尊敬を持って接することができるか。

これが重要な気がした。

いや、でも、これは本当に難しい。

アジャイルに特化しない話だけど、なんでもそうだよなあ。

忘れないように意識付けていこうと思う。

他にもいろいろあり、今回、読書会に参加してよい刺激を受けた。

また、他業種の方と話せて、面白かった。
ゲーム業界、プリンタ業界、Web業界など、、本当に開発スタイルとか違うんだなあと思った。

出来たら第2回も参加したい。

2回目はワークショップ形式ということで、また未知のものが広がっている。

最後になりますが、運営サイドの方には本当にお世話になりました。
また、一緒に議論していただいた方もありがとうございました。
デル株式会社

(C) 2024 ブログ JUGEM Some Rights Reserved.