今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員･･･と言うほど、色々なことをしてもらっています。

使い始めるのは簡単だけど…

一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな！」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。

そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。

まずは軽く使い始める

そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは？」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

「構成管理からチェックアウトしてコンパイルエラーが出ないか？」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。

これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが･･･」なんて指摘はしなくて済みます。

静的チェックの次は…

JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど･･･」という状況も少なくなります。

そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

そして自動テストへ…

ここまで来ると「テストの結果も見えると良いよね？」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100％じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。

簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか？

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

先日、社内で「インセプチョンデッキ」のワークショップをやってみました。
社内SNSでの募集期間が1週間も無かったのですが、10人強の方が参加してくれました。参加者の皆様、ありがとうございました。

インセプションデッキとは？

詳しくは「アジャイルサムライ」や色々なブログで紹介されていますので、そちらを。

ワークショップの内容

定時後に約2時間で行いました。

インセプションデッキの説明を行った後、提示する架空のシステムについてグループワークを行いました。
グループは3つに別れ、「やならないことはなにか？」と「トレードオフスライダー」を話し合って、発表してもらいました。

休憩を挟んで個人ワークです。
それぞれの（今or過去の)プロジェクトのインセプションデッキを作ってもらうことにしました。
主に「パッケージデザイン」と「エレベータピッチ」を作って発表してもらいました。

これは社内ということもあり、包み隠さず良い感じの発表が続いたように思いました。
この辺は(部門は違えど)コンテキストが共有できている部分もある点かな？と感じました。

自分なりに考えたインセプションデッキの気づき

何度か作ってみたり、今回のワークショップにあたって思ったことです。
読み返してみるとこちらのエントリで書いたこととほぼ同じだったのですが…

ウォータフォール開発でも使える

「インセプションデッキ」は「アジャイル開発」の文脈で語られる/使われることが多いと思います。
しかし、アジャイルな開発以外でも、十分適用できるものだと思っています。
例えば、弊社でも「プロジェクト計画書」「プロジェクト憲章」を作りますが、それとインセプションデッキは(表現の仕方は違いますが)同じようなことを伝えてようとしていると感じるためです。

意外と(自分もチームも)分かっていない

実際に(自分の取り組んでいるPJについて)作ろうと、いくつかの質問に取りかかると「あれ？これってどうなんだろう？？」と思うことがあります。
特に途中参加したり、大きなPJだったりすると余計に顕著かもしれません。
チーム全員が同じような答えになるかと言うとそうでもなく、(エレベータピッチなどを書くと)少しずつ違った形になったりして、それぞれの想いが見えてきます。

10個もできないよ！！

インセプションデッキは10個の質問で構成されています。
「全て」をチーム「全員」でやろうとするとやはり時間がかかります。
そのような場合、2、3つを選んでやっても良いと思っています。
もちろん全てを関係者全員で出来るのが理想ですが。

今のところのオススメだと思うのは…
・エレベータピッチを作る
・何を諦めるのかはっきりさせる(トレードオフスライダー)
…辺りです。

またプロジェクトの途中では…
・やらないことリストを作る
・夜も眠れなくなる問題はなんだろう？
…あたりも良いと思います。

大事なのはインセプションデッキは1回作って終わりでは無いと思います。

継続的に、PJの状況が変化したら、インセプションデッキを確認して更新することで、より「PJの認識を合わせ、何を期待するか？」という点で効果があるように思います。
そのためにも(壁に張り出すなど、手段は色々ですが)「あぁ自分達はこのために、こんな方法で、このPJを進めているんだ」を意識するのが大事かと思います。

ロッカーの奥深くのキングファイルに入れてまま、とか、ファイルサーバの奥深いフォルダで、最終更新日がPJの開始日･･･なんてことのないようにしたいです。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt

お客様や同僚から言われる「この仕様をドキュメントにまとめてもらえますか？急いでいないので、”ゆっくり”で良いですよ」という言葉。
よくある会話ですが、この「ゆっくり」の捉え方によっては、ちょっと痛い目を見るかも知れません。

「ゆっくり」の違い

「ゆっくり」が具体的な時間、日にちでどれくらいなのかはその人、背景や依頼内容といった状況によって違ってきます。

その中で、依頼を受けた側は「ゆっくり」を”4日間”と思い込み、依頼を出した側は”今日中じゃなくても良いけど、明日くらい(2日間)”と考えていたとします。

この場合、2日後に依頼者は「ゆっくりとは言ったものの、ちょっと遅いなぁ」と気になり始めます。ゆっくりと依頼したため、「まだですか？」と催促しづらく、ひとりイライラすることもあるでしょう。

一方、依頼された側は、3日後に依頼を終えて返事をしたとします。その時、少しイライラして不満顔の依頼者を見て「あれ？ゆっくりで良かったんだよね？」とモヤモヤとした気分になります。
＃また逆に、「あれ、そんなに早くなくて良かったのに…」と言われ、別の意味でモヤモヤすることもあるでしょう。

絶対的な物差しにする

人や状況によって違う「ゆっくり」という相対的な物差しを、「○日の△時」という絶対的な物差しにすれば良いだけです。

文字にすると単純なことですが、話の流れ、場の雰囲気によっては、何となく流してしまったり、聞くことができず、そのままになりがちです。それを放置していると、冒頭のようなすれ違いが起きてしまいます。

絶対的な物差しにする際、「いつまでですか！？」と反射的に尋ねるのではなく「○日までに返事しますが、問題無いですか？」と自分なりの見解を伝える工夫をします。
こうすると依頼した相手も「ちゃんと考えてくれている」と信頼し、安心することができます。

ちょっとした(心遣いまではいかない)工夫で、少しでも円滑に回れば嬉しいものです。

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: malias via Visual hunt / CC BY

あるエンジニアと話した時に「雛鳥が親鳥からエサをもらうように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはどうか？」と思うことがあります。

やりたいことを周囲に伝えていますか？

「これからどんな仕事に携わったみたい？どういうことをやってみたい？」と質問を投げた時の反応は様々です。

「平穏にサラリーマンできればいいです」という声もあれば、「プロジェクトマネージャーになって大きなプロジェクトを回してみたい」「アーキテクトになって技術でリードしたい」「もっとお客様に提案したい」「今はJavaだけど、これからはRubyでプログラミングしたい」など、様々なやりたいこと、ありたい姿、キャリアプランなどその人の想いが出てきます。

このようなやりたいことは、何もせず待っているだけで実現することは稀なことであり、実現するためには「私はこれをしたい！」と周囲に知らせる、発信する必要があります。定期的にあるフォーマルな評価面談から、呑み会やちょっとした日常会話でのインフォーマルな場まで色々機会があります。
＃自分の経験で、ポロッと社内SNSで呟いたことが、関係者の目に止まってやりたかったことができるようになった話もあります。

このような発信を受け取った上司は「自分からやろうとしていることをなんとか実現してあげたい」という心境になるのが大半かと思います。

やりたいことを実現するために何かしていますか？

そこで「それをやるために、今まで何をしてきた？」「Rubyがしたい？ならサンプルで書いてみてどうだった？」「プロジェクトマネージャーになりたい？今一緒にやっているプロジェクトマネージャーから何を学んだ？」と”やりたいことに近づくアクション”の話になると、本人は途端にトーンダウンしまうことがあります。
「そこまではやる時間がなくて(ゴニョゴニョ)」「実際に使うプロジェクトに入るのが決まってから勉強しようかと(ゴニョゴニョ)」といった様子です。

今の自分が「できること」と「実際にしたいこと」にはギャップがあります。そのギャップを埋めるのは自分です。誰かが埋めやすくなるように手伝ってくれることはありますが、最後は自分で行動して埋めるしかありません。

こういう発信を受け取った上司はこのようなアクションをしているか？そのアクションのアウトプットはチャレンジしてもらっても大丈夫そうか？という視点でも見ています。

雛鳥が親鳥からエサをもらう時のように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはいかがでしょうか？

Photo credit: coniferconifer via Visualhunt.com / CC BY

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

「外部設計はこれでOKですね？ハンコ押してください。これで仕様凍結します。これ以降は仕様変更になります」なんて会話をお客様にして、良い気持ちで押してくれるお客様なんていないよ。

— yoh nakamura (@yohhatu) 2011年8月3日

これについてグダグダと考えてみました。
このつぶやきの元になっていたWFの開発プロセスでは「工程毎にキチッと終了し、その工程は簡単に後戻りしない」という前提です。

実際のPJではプログラミングやテストでの仕様追加や変更時は、それなりに発生します。
「WFでは後戻りしないんです！」と主張してもPJが進まないわけで、どうにか取り込もうとするわけですが、たいがいそれまでWFの各工程でキッチリやっていたプロセス(管理系もそうだし、設計や影響調査なども)がおざなりになることがあります。

その後のよくあるシーンとして…
・再見積や追加見積の数字が「なんでこんな簡単な機能追加なのに、こんなにお金/時間がかかるの！？」とお客様と乖離がありすぎる
・追加/修正した機能や関連する機能にバグが混入する(設計や影響調査、テストが十分でない)
…というのがあります。
これの要因の1つは(お客様のシステム開発の知識や経験も関係しるとは思いますが)自分達開発チームが仕様追加/変更を適切に行える状態になっていないことだと考えています。

1つは、開発インフラ環境の状態です。
開発インフラの三種の神器であるSCM/ITS/CIを使って、プロダクトコードが構成管理されていてベースラインが分かり、ITSで仕様やその経緯、リポジトリとの紐付けができて、CIで自動テストがグリーンになっている、そして失敗したらすぐに分かる…という状態なら、仕様追加/変更にも品質に影響を出さず、容易く対応できると思います。
特にCI(とテストコード)が無いと、大量の再テストを手動でしたり、バグの混入に気づくのが遅れ、大きな影響が出やすくなります。

もう1つはプロダクトそのものです。
プロダクトのコードは可読性/保守性が高く、DBなど含む設計もそれなりのレベルが必要です。
スパゲッティコードや拡張ポイントがぐちゃぐちゃな設計だと、仕様追加/変更のスピード、確実性が大きく落ちるので。

この2つが成り立たないと、工程途中の仕様追加/変更で(要求側が「なんでそんなになる？」と思う)コストや期日になったり、品質の劣化が発生します。
この話はお客様が使い始めた後の機能追加/修正でも同じです。

では、こういう条件を「使うアプリはパワポとExcelばかりで、プログラミングはパートナー企業やオフショアに丸投げしている」SE(や組織)がクリアできるか？というとNoなわけです。

「Noなら、どうしようか？」となって、冒頭の「仕様凍結」という言葉で、変更を抑止したり、お客様の費用感でなく、自分達の費用感でやれる材料にする動きになると思います。
当然、こんなことではお客様に価値を提供することは難しくなります。

ちなみにお客様の費用感を受け入れた場合、PJは赤字になり、品質は劣化し、デスマーチになって行くと思います。

(要求が変わることにより)仕様追加/変更が発生するんだ…と「変化を抱擁する」ことを前提に開発プロセスを考え直すのも1つの対応方法だと思います。
ただ、「変化を抱擁する」ことができる状態…開発インフラ環境の整備とプロダクトのコード・設計レベル…が実現できない組織では絵に描いた餅に過ぎません。

なので、そういうSEが多いSIerが、これから生き残るには…
1：自分達もモノ作りができるようになる
2：従来の開発プロセスで良いとするお客様だけをターゲットにしてやる
…かじゃないと思っています。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt

@kuranukiさんの「モチベーションの源泉：何のために働くのか、転職か起業か」(「Social Change!」より)を読んで…

「サポータータイプ」：7「クラフトマンタイプ」：3かな、私は。RT: モチベーションの源泉：何のために働くのか、転職か起業か http://t.co/peVEqyo via @kuranuki

— yoh nakamura (@yohhatu) 2011年7月8日

と言いました。
で、もう少し考えてみました。

「アントレプレナー」タイプ

その昔…前の前の会社にいた頃…「アントレプレナー」タイプの側面は(10のうち)1くらいはありました。
「開発者がもっと楽しく、自分の腕を活かして仕事ができる組織・環境を作る」という想いでした。
若かったもので、想いだけはたくさんありました。
　
今でも「開発者にとって…」の想いは持っていますが、それを自分が実現するという気持ちではないかなぁと感じています。

「クラフトマン」タイプ

「アントレプレナー」タイプの夢を実現するために磨いていたスキルがスライドして「クラフトマン」タイプの源泉になっている感じです。それが、ファシリテーション、チームビルディング、Agile開発だったり…。これらのことに携われるからモチベーション高く維持できるのは確かです。
なので、やっぱり3～4くらいです。

@kuranukiさんのエントリの文脈では「技術的スキル」(RailsのプログラミングスキルやOSSへの貢献だったり)にフォーカスしているように思えます。それならば、私の「クラフトマン」タイプの割合は0～1になります。技術的なことは好きですが、『自らの腕を磨いて「俺ってすげー」感を味わうことが幸せです』まではいけないなぁと。

「サラリーマン」タイプ

よくよく考えると2つの意味で持ち得る(こともある)と思いました。
1つは「評価が金でしか分からない」場にいる場合です。この時は1～3程度になります。
「あなた達の仕事っぷりに感謝したい」という声が届きにくい環境にいると、評価される側は金でしか評価が分かりません。

もう1つはダークサイドに落ちそうになっている場合です。
凹むような出来事…たいがいは、(組織など)何かに対する失望がその原因…があった場合に、モチベーション、情熱が一時的に冷え込み、「もらっている金額分、働きます(だけどそれ以上は自分のためだけに使う)」な気持ちになる場合です。
こういう時も1～3程度になります。

「サポーター」タイプ

「誰と（誰に）仕事をするか」は大きな割合…4～6くらい…で、あります。
自分のパフォーマンスを振り返ると、(自分基準で)「良い」と思えるお客様/上司/ボス/リーダーの時ほど、そのパフォーマンスが良かったように思います。
「このお客様の問題を解決したい(で、笑顔になって欲しい)」「このボスの目標を実現して欲しい(のために、手伝いたい)」が源泉になっています。

ありがたいことに、今のチームでも「この方達のために…」という想いが強くあります。
その状況でなくなれば、「別の誰かのために…」という想いで動くこともあるかもしれません。

まとめ

・アントレプレナー：0
・クラフトマン：(Javaなどの技術だけでなく、広い意味で捉えるなら)3～4
・サラリーマン：(普段は)0
・サポーター：6～7

年齢や経験で変わってその割合は変わってくるでしょうし、他の方から見ると(自分のそれと)違うかもしれません。
チームのふりかえりで(少しお酒でも入って)リラックスしながら、ディスカッションするとお互い気づきがあって面白いと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on VisualHunt

社内研修における受講者、講師について思ったことです。

社内研修には(自分から手を挙げる以外に)「3年目だから」や「主任だから」というキャリアによって必須のもの、また部長などが推薦するものがります。
いわば「自分の意志とは無関係」な研修です。
そのような研修で時々気になる光景、雰囲気があります。

「なぜ研修を受けているのか？」「研修で何を学ぼうとしているのか？」を持っておらず、「指名されたから…」「仕方ないから…」その場にいる…というものです。
その状態では「研修」自体の費用対効果は低いままです。
必須の研修でないなら、自分なりに考えてみて「その研修を受けない(辞退する)」選択をしても良い(むしろ…した方が良い)と思います。
(ほぼ全ての)研修に対して、評価、コメントを付けることができ、それが全体に公開されています。ですので、事前に研修の評価や内容を知ることができます。

一方、社内研修の講師側も「それはどうだろう？」と思うこともあります。
テキスト、スライドを読み上げるだけだったり、古い情報のままで更新されていない内容だったりすることもあります。
たまに「この資料は自分が作ったのでは無いので…」と言い訳する講師もいますが、論外です。

また「受講者に○○を身につけて現場に役立てて欲しい！」という想いが伝わってくる方はほとんどいません。
「受講者のやる気がないから…」等と言うのであれば、講師側が「やる気」を引き出す取り組みをする必要があると思います(研修本編か前準備かは色々ありますが)。

なので、講師は受講者に対し「(内容が)役に立たないと判断したら、途中退席もOK(もちろん社内的にペナルティなし)」と言える(少なくとも自分にとって)「良質」な研修を作り上げる必要があると思います。

社外勉強会やセミナーとの比較をすると、やっぱり受講者も講師も気持ちの入り方が違うためか、そんな光景はあまり見ません。
せっかく組織の力を上げることを目的としている「社内研修」なので、もっと「価値」を出せるようにしていきたいです。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by Anosmia on Visual hunt / CC BY

(時期を逃した感がありますが)、新しくできたグループなど、あまり知らない人同士が集まった宴会で使えるアクティビティです。

「Q&Aビンゴ」

ビンゴの数字を(「くじ」ではなく)「質問に該当する人」で決めていくものです。

お勧め参加人数

15人～50人位まで。

準備するもの

1：ビンゴ用紙
人数に合わせて3×3～5×5マスのビンゴ用紙。
市販されている「数字が印刷されている」ビンゴ用紙だとできないので、数字を自分で書き込めることができるタイプのやつがいいです。

2：ペン
3：(自己紹介を織り交ぜるなら)自己紹介テンプレ(使い方は後述)を書いておく大きめの画用紙

ビンゴのやり方

1：ビンゴに数字を書き込む
各自、0～参加人数の数字を(重複しないように)に埋めていきます。
例えば参加者が15人なら0～15までを書きます。
5×5なら真ん中はフリーの方が楽しめると思います。

2：ビンゴの数字を決めていく
任意に質問者を決めます。
質問者は「転職経験のある方！」「三度のメシよりプログラミングが好きって人！」「スマートフォンを3台以上持ってる人！」というような質問をします。
その質問に該当する人は手を挙げてもらい、手が上がった人数がビンゴの数字になります。

例えば、「社外勉強に行ったことがある人！」という質問に(15人の参加者のうち)9人が手を挙げたとします。すると「9」を書いたマスをチェックします。

これを繰り返していきます。
こうやってビンゴを作っていきます。

自己紹介のやり方

自己紹介をするなら、質問者は質問を言う前のタイミングが良いです。
ここではリズム良く行きたいので、用意しておいた自己紹介テンプレを使います。
以下は、新しい部門やグループのキックオフ宴会を例にしたものです。

—————
元気よく名前を！
これまでやってきたことは？
これからやりたいことは？
次の質問をどうぞ！
—————

この自己紹介テンプレを見えるようにしておけば割とリズムに乗って言いやすいと思います。

次の質問者の決め方

「質問したい人」と呼びかけて進行役が当ててもいいですし、質問者が次に指名しても良いです。

やってみて

(時間の関係もありますが)30人強の人数ならリズム良く、自己紹介+質問を繰り返した方が良いと思います。
人数が少ないなら、質問と質問の間に5分ほど間を設けて、質問に関すること…「へぇ～そうやったんやぁ」的なノリで…を話す時間を作れば、よりお互いを知るきっかけになると思います。

出た質問とその人数を画用紙に書いておけば、ビンゴが終わってからの会話のネタにもなると思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by elizaIO on Visual Hunt / CC BY-SA

以前エントリ「自分のテンションを維持する方法」で「朝早く出社する」ことを書きました。

これを少し詳しく自分なりに考えてみました。

まずはやはり朝早くの時間帯は静かで本当に集中できます。電話ももちろん話し声や人の気配もありません。
今いるフロアは次の人が結構遅いので、この時間を多く保つことができます。

この時間をより活用するように行動を変えてみました。

具体的には、『会社に着いて』やることを考えるのではなく、『通勤途中』できれば『前日の帰り』にやることをリストアップするようになりました。

前日に「やること」リストをアウトプットした上で、一晩過ごすと時々いくつかの考えが浮かんできます。
例えば「そのやることは(代替案がある/優先度が低いなどの理由で)今しなくていいのでは？」という考えで、それがYesであれば、不要な時間を使わずに済みます。
　
「やること」に関連して「これをやるということは、関係するこっちも…」と出てきます。これでタスクの漏れを防ぐことができます。

さらに退社時点で「明日のやること」ができあがっていると、行き帰りの時間で(ボンヤリとでも)タスク自体の段取りも考えることができます。そして、朝早くの時間をより効率的に使うことができます。

人それぞれのリズムがありますが、こういうアクションはお金をかけずに(自分の心持ち次第で)できる生産性の向上だと思います。

自分一人では朝起きるのはしんどい…というのであれば、チームなどで仲間を見つけてやってみると良いかもしれません。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Maarten Takens via Visualhunt.com / CC BY-SA

とある社内での打合せの席で思ったことです。
「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。

その打合せは部門も違い、お互い初対面でした。

ただ、事前に「○○さんと△△さんが出席する」ことは分かっていました。
なので、社内SNSなどの情報を少し検索して「これまでどういうキャリアを積んでいるのか？」「技術系なのかマネジメント系なのか？」など、いくつかのことが分かりました。

そういう事前情報があると実際に話をする時の基準(レベル)をどこにすれば良いのか分かりやすいです。
例えば「どういうアーキテクトで行くか？」と説明する際、バリバリ技術を10年やって来た方、経験1年目の方、また営業畑の方…それぞれ話し方やポイントが変わってきます。

また話の入り方で「あの(社内SNSの)エントリ読みましたよ～」「○○さんは×が趣味なんですね」とアイスブレーク的に使うだけでずいぶんその後の展開は違うと思います。
やりすぎるとストーカーちっくなので限度はありますが(苦笑)。とは言え、自分に興味を持ってもらうことをそう嫌がる人もいないと思います。

情報をインプットし過ぎて、先入観を持ちすぎるのも良くありませんが、想像(事前情報)と違っていたら、そこでその情報を修正すれば良いと思います。
ちょっとした労力でスムーズに打合せができるなら、そういう工夫も良いかと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt

先日、チームのフリカエリをして、その時の(自分の)ネタに半年前から付けている「ニコニコカレンダー」を見てました。
「ニコニコカレンダー」の説明はこちらで。

私の今の使い方はデスクの卓上カレンダーにちょっとした一言と一緒に書いています。
ただ、ここ1ヶ月程は(チームで使っている)Redmineにニコニコカレンダーのプラグインを入れて、そちらも使っています。

で、その卓上カレンダーのニコニコカレンダーをそのまま公開しようとしましたが、仕事のメモ書きもあったので、集計結果だけ。

こうして並べてみると、毎月の様子がなんとなく分かります。
3ヶ月目、6ヶ月目が他の月に比べ、「良い」が少ない(特に3ヶ月目)のは、リリース前でバタバタしていたせいです。
6ヶ月目はその反省も踏まえ、多少改善されていますが。

半年付けていて思ったことの1つは、あまりロジカルな基準を設けない方が良いということです。

人間なので昨日と今日では同じ出来事があっても感じ方が違うこともあります。
ある日は「良い」でも、また1週間後に同じようなことがあってとしても「普通」を付けても良いと思います。
「なぜ今日、これを『良い』と感じたのか？」とその自分の感覚を深掘りできれば、何か見つかるかも？と思いました。

また「今日は開発が進んだ！良かった！」と思って「良い」と付けたとして、それが(例えば)1週間続いたとすると、その進捗のパフォーマンスや「良かった」という感覚が慣れて「当たり前」になって「普通」を付けていたこともありました。
これはある種、自分のレベル(基準)が上がっているを示しており、「では自分が『良い』と思えるのはどんな価値を出した時か？」という切り口で考えみると面白いかもしれません。
やり過ぎると疲弊したりするので、あくまで持続可能なペースでレベルを上げていくと良いと思います。

日々のタスクが忙しいとなかなか付ける余裕が無いと思いますが、帰り際の数分、もしくは朝の数分をニコニコカレンダー(を使ったフリカエリ)を続けると、数ヶ月には何か見えてくると思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。