【若手を育てるOJTセミナー】に行ってきました。

今日、【若手を育てるOJTセミナー~どのように若手を育成してけばよいのか？~】に行ってきました。

半日のセミナーでしたが、非常に中身の濃いセミナーで、来週からの業務に活かしたい要素が何点がありました。

ということで、セミナーでの気づきや今後のトライをメモメモしよう。

メインの話は【経験学習】という普段聞きなれないキーワードでした。

経験学習とは、簡単に言えばPDCAサイクルを回そうということです。

具体的には、

　①具体的な経験（何かを経験する）

　②内省（振り返る）

　③持論化（教訓を引き出す）

　④新しい状況への応用（次に生かす）

の４ステップを繰り返すことが重要とのこと。

ただ、同じ経験をしても、成長する人と、成長しない人がいて、成長する人は経験から学ぶ力が高い。経験から学ぶ力とは、自分を成長させたい思いと他者とのつながりを大切にし、挑戦し、振り返り、楽しみながら仕事をするときに、経験から多くのことを学べることができるということ。

セミナーに参加した気づき。

• シニア層の経験を、同僚や部下に伝えることの大切さ。
• 部下から得られた知識をミドル層・シニア層に伝える大切さ。
• 部下の表面的な発言や態度で判断するのではなく、部下の考えをきちんと把握することの大切さ。
• 漠然と振り返るのではなく、テーマを絞って振り返ると効果的な結果が生まれる。
• 部下がチャレンジするときは、安心してチャレンジできる。という心理的な面からスタートすることが大事。

これからのトライ

• 毎日、振り返りを実施する。
• 成長した成果を部下に発表してもらうように促す。
• 管理職以上に、自分の失敗談というテーマで部下への熱いメッセージを伝えてもらうLT大会を企画しないな。っと。

【ビジネスパーソンのための”超実践的”コーチングセミナー】に行ってきました。

1/23（水）に【ビジネスパーソンのための”超実践的”コーチングセミナー】に行ってきました。

２時間という限られた時間だったけど、非常にためになるセミナーでした。

以下、箇条書きで学んだことを列挙。

　・コーチング：話を聞くだけで、相手のモチベーションを向上させる。

　　　　　　　　　　　　　　　　相手の目標達成を支援する。

　・コーチングの３原則

　　　　１．インタラクティブ　：　相互理解・コミュニケーション

　　　　２．テーラーメード　：　相手の情報を記録・DB化

　　　　３．オンゴーイング　：　継続的に実施

　・コーチング・カンバセーション

　　　　相手の話を聞いて、質問することにより、相手が新たな何か気づきを得る。

などです。

コーチングの説明もほどほどに、ほとんとが２人１組のワークでした。

実際、やってると、相手の話を聞いて質問する。だけなんですが、難しかった。

どうしても、自分の意見が言いたくなってくる。実際、自分の意見を言っちゃって、相手からのフィードバック時に、ありがたく指摘を受けました。

実際の業務を行う上でも、【コーチングスキル】はぜひ習得したい。

今、スクラムマスターという立ち位置で、仕事を進めているので、【コーチングスキル】はぜひ習得したい。

なぜかと言うと、スクラムマスターの役割に

　・チームメンバのマインドを変化させる。（自分自身で変わろうと思ってもらう）

　・チームメンバの学びの姿勢を引き出す。

があり、この役割に応えるためには、非常に【コーチングスキル】が重要になってくると思ったから。

これから学んでいこう。

刺激されたので、以下の本の購入Done。

コーチング・マネジメント―人と組織のハイパフォーマンスをつくる

書評 【アジャイルモデリング―XPと統一プロセスを補完するプラクティス】

本日紹介する本はこれ。

アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)

アジャイル開発をやり始めて、もうすぐ１年が経ちます。

今の開発プロセスとしては、設計書を作る機会がほとんどなく、要求事項（ユーザストーリ）から直接プロダクトコードを作成する。という感じです。

　※当然、TDDでやっているので、テストコードも作りますよ。

TDDで進めているので、クラス・メソッド単位でのリファクタリングをしながら作っていくんですが、僕の技術力不足もあって、最初にできあがったプロダクトコードのコードレベルがすげー低い状態で、できあがります。

この状態から、時間があれば、プロダクトコード全体のリファクタリングをやります。ただ、だいたいは、時間がないので、コードレベルが低い状態で、リリースして、リリース後に隙を見て、リファクタリングしているいうのが現状です。

リファクタリングをやる目的は、リリース後の追加機能に対応する場合で、既存のコードが汚くなってしまった場合にやるのが、本来の目的かなっと思っています。今のやり方だと、あまりいいプロセスではないので、どんどん汚いコードの量が多くなってしまいます。なので、最初からある程度のコードレベルの状態まで持っていきたいので、いろいろ悩んでいたところに、今回の本の存在を知り、読んでみました。

後、そもそ【モデリング】というキーワードはアジャイルやる前から気にしているキーワードだったので。

この本のコンセプトとして、モデリングの作成方法は記載されておらず、モデリングの進め方を記載しています。具体的には、XPで進める場合に、どうモデリングを開発プロセスに組み込んでいくか？等の話です。

基本的にXPのプラクティスを元にモデリングの組み込み方が記載されているので、アジャイル開発をやっている人には、ほとんどの内容がすんなり頭に入ってきます。

で、この本の中で、気になったことは以下。

　①モデル≠ドキュメントである。

　②これから作るものを理解するためにモデリングを行う

　③チームメンバと話すためにモデリングを行う。

①に関して、簡単に言うと、

　作ったモデルの目的を果たせば、モデルを捨てよう。

です。もし、本当に残す必要があるモデルのみ、残しましょう。ということです。

この考え方は、ものすごい共感できますね。僕がドキュメントを作りたくない最大の理由は、ドキュメントのメンテナンスができる自信がなく、ドキュメントの存在自体が邪魔になって、めんどくさいからです。

このやり方なら、メンテナンスも考える必要もなく、楽ちんです。

②に関して、簡単に言うと、

　コーディングを始める前にじっくり考えてみたら、生産性が向上する。

です。

コーディングを始める前にじっくり考えるということは、僕の悩みを解決してくれる一つの解決策ですね。やっぱり無作為にコーディングをやるよりも、１時間なら１時間、１日なら１日と開発する規模に応じて、ちゃんと考えようと思いました。

③に関して、簡単に言うと、

　チームメンバのコミュニケーションを促進するために良い方法の一つである。

です。

これも非常に納得しました。コードレビューは、クラス・メソッド単位で実施していくんですが、対象のプロダクトコード・テストコードを見て、判断できることもあれば、全体像が把握できないと判断できないこともあります。

自分が全体像を把握しているソースの場合は、比較的にスムーズにコードレビューができるんですが、把握してなかったら、コードレビューをやっても、きちんと指摘できているか自信がないです。なので、やっぱり全体像が把握できる資料があれば、いいなっと。これに関しては、クラス・メソッド単位でレビューする考え方と全体をレビューする考え方に分けたほうが良いかなっと思いました。

明日から実践したい内容としては、

規模がそれなりに大きな開発なら、コーディングに入る前に②の内容をチームメンバ全員でレビュー/全体像を全員が把握する。

これが終われば、作ったモデルは不要なので、削除する。

コーディング中は、クラス・メソッド単位でレビューする。

をがんばっていこうかなっと。

JsTestDriverのJavaScriptのTDD環境の構築

前々からJavaScriptのTDD環境を構築したかったんですが、ようやく重い腰があがりました。

現在は、これで勉強中。

テスト駆動JavaScript

ひとまず、JsTestDriverのインストールをメモっておく。

環境は、Windows7です。

①Javaのインストール

だいたいのパソコンにJavaがインストールされていると思うので、詳細は割愛。

• コマンドプロンプトで、【java -version】でインストールされているか確認できる。
• もし、コマンド実行できない場合は、javaコマンドに環境変数の設定ができていないので、javaコマンドに環境変数のpathに設定する。僕が設定したフォルダは【C:\Program Files (x86)\Java\jre6\bin】。

②JsTestDriverのインストール

• 【http://code.google.com/p/js-test-driver/downloads/list】にアクセスする。
• 【JsTestDriver-1.3.4.b.jar】をダウンロード
• 適当なフォルダに配置。（僕の場合はここ→C:\pleiades\xampp\jbin）
• jarファイルの格納フォルダを環境変数に設定する。名前は【JSTESTDRIVER_HOME】とする。

③JsTestDriverの起動および動作確認

• コマンドプロンプトで、【java -jar %JSTESTDRIVER_HOME%\JsTestDriver-1.3.4.b.jar --port 4224】を実行。ポート4224は、JsTestDriverのデフォルトポートみたいです。
• 【setting runnermode QUIET】が表示されれば、OK。

 

④動作対象のブラウザを設定

• 次に任意のブラウザを起動して、【 http://localhost:4224/】にアクセスする。
• 【Capture This Browser】と【Capture This Browser in strict mode】が表示され、ひとまず、【Capture This Browser】を選択する。
• これで、テストするブラウザの指定が完了。
• 複数のブラウザでテストする場合は、これを繰り返す。

 

⑤動作確認

• 設定ファイルを準備する。保存場所はどこでもよいです。ただし、srcフォルダとtestフォルダは、設定ファイルの場所から相対パスで指定すること。src配下がプロダクトコード置き場。test配下がテストコード配下。

server: http://localhost:4224 
 
load:
 - src/*.js
 - test/*.js

• テストコードを準備する

TestCase("convert_test", {
    setUp: function(){
        this.str = "aaa";
    },

    tearDown: function(){
        delete this.str;
    },

    "test convertNG": function(){
        var result = this.str.convert();
        assertString(result);
        assertEquals("AAA", result);
    },
}); 

• プロダクトコードを準備する

String.prototype.convert = function convert(){
    return this.toUpperCase();
};

• 今回は、指定された文字列を大文字変換するだけの簡単なコード。
• コマンドプロンプトを起動して、設定ファイルが格納されているフォルダに移動して、【C:\pleiades\xampp\htdocs\jstest>java -jar %JSTESTDRIVER_HOME%\JsTestDriver-1.3.4.b.jar --tests all】を実行する。
• 結果はこんな感じ。

2012年上半期 書籍読破リスト その②

2012年上半期に読んだ本の第二弾を紹介します。

今回は、アジャイル関連の本がメインになっています。

アジャイルサムライ-達人開発者への道-

アジャイルサムライ−達人開発者への道−

アジャイルと言えば、【これでしょ】というド定番の本です。

ものすごく読みやすいので、アジャイルをやったことがない方への入門書にはぴったりです。また、従来通りのウォーターフォールで開発をしている方にもおススメです。インセプションデッキに書くべき内容は、アジャイルだとうと、ウォーターフォールだろうと、大事にすべき事柄ですね。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

これもアジャイルサムライと同様に読みやすい本となっています。

一つ一つのプラクティスが分割されているので、トライアル的に一つのプラクティスを試してみるのもよいかと、思います。

結局、実際に試して→振り返って→改善して、のプロセスをどれだけこなして、より良いプロセスにしていくことが大事かなってアジャイルをやり始めてから感じるようになった。

Jenkins実践入門 ～ビルド・テスト・デプロイを自動化する技術

Jenkins実践入門　?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

アジャイル的なプロダクトは、初回リリースがプロダクトの最高の価値ではなく、継続的に価値を高めていこうというスタンスかと思います。ただ、継続して価値を高めていくためには、一定以上の品質確保をしつつ、機能強化を図っていく必要があります。既存部分のテストを手動でやっていると、本来やりたい価値向上に費やす時間が減少するので、テスト自動化は必須。テスト自動化の司令塔の役目を果たすツールがこのJenkinsだったので、買ってみた。

Jenkinsの概要はこの本で十分ですが、実践で活かすためには、もうちょっと内容を濃くしてもらいたかったところです。ひとまず、Jenkinsって何？っていう人がターゲットかなっと。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

プロのエンジニアを目指したい人に読んでもらいたい本ですね。

内容は、プロのエンジニアの態度・規律・行動について、いろいろ良い事が書かれています。

以下、気になった内容を記載します。

• 「なぜ」よりも「事実」のほうが重要。
  →上司への報告は、確かに「事実」のほうが大事。「なぜ」を上司に説明してもそこから判断できることは少なく、「事実」から判断してもらうほうが良い。
• 「ノー」ということ。
  →これは社会人としては、当たり前ですね。何かの依頼事項に対して、「イエス」と回答すれば、その瞬間からその依頼事項を完遂する責任が発生する。完遂する力や自信がない状況では、「ノー」と言いましょう。「ノー」を言うだけでも責任を果たしていると思います。
• プロダクトコードより先に書くテストコードは「攻撃」、後に書くテストコードは「防御」。
  →気に入ったのは、「攻撃」・「防御」というフレーズです。先にテストコードを書くということは、IF重視で、他モジュールと疎結合になる設計ができるようになると思う。このことを「攻撃」と表現するのは、おもしろかったです。
• 緊急時に安心して行動できる規律を決めて、そしてそれを常に守る。
  →緊急時に普段の行動とは、違う行動をすれば、普段の行動を信用していないということ。思い返してみると、確かに普段と緊急時の行動が違っているところがある。これを読んで、普段の行動を見直すきっかけになった。

2012年度上期に読んだ本は以上です。

次回からは、読み終わったタイミングで書評しようかと思っています。

　※一部、内容を忘れている本もあって、大変でした。

PHP 多次元配列ではまった。。。。。

久しぶりにＰＨＰではまってしまった。。。。。。

俺の２日間が無駄になってしまった。。。。

はまった内容としては、簡単に書くと以下のソースです。

$test[1] = '123456';
$test[1][1] = 'abc';
var_dump($test);

出力結果
array
  1 => string '1a3456' (length=6)

【test】配列が２次元になってないし、1次元目の要素もおかしくなってるし。。。

結構調べましたが、PHPとしては当然の動きの模様。

$test[1] = '123456';
echo $test[1][0];
echo $test[1][1];
echo $test[1][2];

出力結果
123

んー。２次元目の要素が1次元目の文字列の順番に対応していると理解！！

なので、さっきでいうと【2】の部分が【a】に置き換わったとのこと。

これに関して、いろいろ調べたが、回避策はなさそうです。。

残念。。。。。。。

ちなみに、連想配列なら、上記の現象は発生しないです。

2012年上半期 書籍読破リスト その①

2012年になってからアジャイル開発をやるようになって、いろいろな本を読みました。

今回は、プログラミングに関する本を紹介します。

パーフェクトPHP

パーフェクトPHP (PERFECT SERIES 3)

中級者向けの本となっております。

業務で使用している言語がPHPだったので、買いました。

PHPの文法から始まり、フレームワーク作成のチュートリアルで実践的な内容になり、セキュリティもこれでもか！っていうくらい記載されていました。

個人的には、フレームワーク作成部分が一番業務に活かせたので、読む価値ありです。

プロになるためのPHPプログラミング入門

プロになるための PHPプログラミング入門

これもパーフェクトPHPと同じ動機で買った本です。

アジャイルをやるまでは、プログラミングをやったことがなかったので、一般的なWeb開発の基礎と、フレームワーク（本だとCakePHP）の活用事例を勉強したく。

主な内容は、事例となるWebサイトをフレームワークあり・なしで作成していき、フレームワークの良さを伝えている感じでした。

確かに、フレームワークあり版だと、記述するソースコードの量が圧倒的に少なかったので、その分だけ品質・スピードの観点が向上しているが、CakePHPということもあり、いろいろ制約が多く、それを覚えるだけで大変という印象を受けました。

ただ、やっぱりフレームワークなしのWeb開発はちょっと非効率なので、自分にあったフレームワークを探してみようと思ったきっかけになりました。

ちなみに、業務ではZendFrameworkを使っており、気になるフレームワークはFuelPHPでございます。

Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

今の開発スタイルがオブジェクト指向なので、オブジェクト指向と言えばデザインパターンでしょ！と思ったので、買っちゃった本です。

いきなり、この本のレベルは僕には難しすぎました。。。。。一通り読みましたが、各パターンを業務で活かせるところまで、自分の頭の中を整理できなかった。。。。自分の技術力のなさを実感。。。。。

ただ、オープン・クローズドの原則は、意識してプログラミングをしていきたいと思っただけでも、成長の証です。

また、そのうち読みたい本ですね。

Java言語で学ぶリファクタリング入門

Java言語で学ぶリファクタリング入門

まだまだペーペーの僕がちょっとでも上級者の観点を身につけたく読んだ本です。

基本的には、リファクタリングのテクニックごとに説明されている感じでした。

こんな小さなことでも気にするポイントがあるんや！と関心した部分やこのテクニックを使うには、センスがいるな！と思わせる部分もあり、楽しく読めました。

リファクタリングに関する本は初心者の方でも、使えるテクニックがたくさんあるので、早めに読んでおくことをお勧めします。

プログラミングに関する本はこんな感じです。

次はアジャイル関連等の本を紹介したいと思います。