チームビルディングでドラッカー風エクササイズ！

チームビルディング

部屋の隅っこでチームビルディング中…

f:id:yudy1152:20190402172914j:plain:w300

背景

4月1日に入社された方を、私達のチームに迎え入れることになりました。

少しでも早くチームに慣れてもらえるように、チームビルディングをしてみたいなと思っていました。

たまたま「カイゼン・ジャーニー」を読んでいたところ、「ドラッカー風エクササイズ」というチームビルディングの手法が紹介されていたので、「これをやってみよう！」と思ったのがきっかけです。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

ドラッカー風エクササイズって？

以下の4つの質問を基に、チームメンバーの期待をすり合わせ、チームビルディングをする手法です。

  1. 自分は何が得意か？
  2. 自分はどうやってチームに貢献するつもりか？
  3. 自分が大切に思う価値は何か？
  4. チームメンバーは自分にどういう成果を期待していると思うか？

詳細については、たくさん記事があるのでそちらをご参照ください。以下は主に参考にさせて頂いたサイトです。

なんでこの手法をやろうと思ったのか

以下のようなことを考えていました。

  • 新メンバーが、どんなスキルを持っているのか、どんな想いで新しい職場でやっていこうとしているのかを知りたい
  • 既存メンバーが、どのようなスキルを持っているのか、どんな感じで仕事をしてきたのかを知ってもらいたい

つまり、相手の事を知りたいし、私達のことを知ってもらいたいという想いがあり、上にある4つの質問を基にしたコミュニケーションが、お互いの事を知るための良いツールだなと思ったので、実践することにしました。

やってみた

  • 付箋に各質問に対する回答を書き出します
  • 1人ずつ付箋をホワイトボードに貼り、発表をします
  • 全員のターンが終わったら、4つ目の質問（自分にどういう成果を期待していると思うか？）に対し、実際に他のメンバーが期待している度合を以下のように定義し、付箋に書き出します
    1. 完全に合っていない
    2. だいたい合っていない
    3. 普通
    4. だいたい合っている
    5. 完全に合っている

このような手順で実施しました。手順化すると少し機械的に行っている様に見えますね・・・。

実際には、付箋を貼って発表した後、「例えば？」とか「具体的には？」といったように質問を入れたりして、会話をしながら進めるようにしました。

特に既存メンバーが発表する時は、具体例を出すことで新メンバーがイメージしやすいかなと思ったことと、 普段のチーム内の雰囲気を新メンバーに知ってもらいたいと思ったため、会話主体で進めるように意識しました。

まとめ

よかったこと

  • 「得意なことは？」「どう貢献するか？」という質問に対し、ついスキル的なこと（どの言語ができる、とか）を回答しがちになってしまいましたが、 あるメンバーは「諦めない精神」や「みんなのモチベーションを上げる」といった性格的なことを回答していました。 特に新しくメンバーが入ってきた時にどんな人柄かを知る上で有効な回答だな、と思いました。

  • あるメンバーの感想で、「大切にしている価値観については知る機会がなかったのでよかった」というものがありました。 私達のチームは基本的にモブプロ（モブワーク）をしているので、普段からスキル的な事は把握し合えると思うのですが、価値観についてはそうそう話すことはなかったので、知る良い機会になりました。

反省点

  • 約1時間立ちっぱなしで実施し、思っていた以上に疲れてしまいました。 タイムボックスを設けていなかったというのも反省点ですが、せめて椅子に座ってリラックスした状態で実施した方がよかったなと思います。

まとめ

新しいチームでやっていくぞという時や、新しくメンバーが加わる時など、お互いの事を知っていく上で効果を発揮するなと感じました。

また、以下のサイトにもあるように、チームの初期段階だけでなく、 ある程度時間が経過した後でも質問内容を変えたりすることで、その時々のチームの状態（メンバーが何を考えてるか等）を知り、もっと深く皆と向き合えるんじゃないかと思ったので、今後も活用していきたいです。

チームの期待値を合わせる！ドラッカー風エクササイズとタックマンモデルを組み合わせた結果 | Backlogブログ

今はまさに新しくメンバーを迎え入れる時期かと思うので、是非「ドラッカー風エクササイズ」を実施してみてはいかがでしょうか！？ その際は椅子のあるお部屋で！

個人的ふりかえり

メモ

今月からブログを始め、心境や意識が大きくプラス方向に変化しました。

そのため、今月をふりかえり、出来事や思ったことなどを記録として残しておこう思いました。

チームの出来事

  • モブプロで成功記録をとるようにしてみた
    • 何が出来るようになったか（理解したか）、何が不明点なのか、を把握して成長を実感する糧になりました。
  • ふりかえりフレームワーク「Fun Done Learn」を試してみた
    • まだ1回しか試せていないものの、KPT よりもポジティブな意見が出やすくなる、ということを実感しました。
    • 4月から毎日のふりかえりで実施していきたいです。
  • チーム内勉強会（週3回、今のお題は PHP）
    • 皆でより成長するために、30分でも、1時間でもやっていこう！と始めました。
    • まずは継続！

個人の出来事

  • ブログ・twitter 始めた
    • 人生の転機と言ってもいいかもしれません。（機会をくださった方々に感謝です）
    • アウトプットのためにブログを利用する、というイメージは持てていたのですが、それ以上にインプットを意識するようになりました。
    • 本や、他の方が書かれた記事などを読むうえで、チームで取り組むとしたらどうか？自分で取り組むとしたらどうか？ということを意識するようになりました。
  • AWS SAA に合格した
    • 模擬問題65問を解くのは辛かった・・・。
    • 自分でちゃんと触って、構築して、もっと理解を深めていこうと思うようになりました。
  • 同僚が始めたコミュニティ「AliEaters Okinawa」に運営・企画のお手伝いで参加
    • Alibaba Cloud を扱うコミュニティ。まだ使ったことないですが・・・。

alieaters-okinawa.connpass.com

まとめ

ブログを始めたことで、この1ヶ月で自分でもビックリするくらいの意識の変化がありました。

同僚や会社、世の中に価値あるものを届けられるような、そんなエンジニアになりたいと思うようになった1ヶ月でした。

明日からも頑張ろう。

複数クラスを移動させた時に namespace も自動で変更したい

IntelliJ

こんにちは。沖縄移住組 IT エンジニアの勇大（@yudy1152）です。

開発する時に、JetBrains の IntelliJ IDEA という IDE を使用しています。

1つのディレクトリ内にたくさんのクラスファイルが出来てきて、適切な名前空間で区切ってファイル構成を変更したい時に便利な操作方法を紹介します。

また、操作をするうえで少しハマったポイントなども書き留めます。

やりたいこと

Kodama, Hikari, Nozomi の各クラスは SinkansenInterface を implements している関係になっています。 TestA は Sinkansen とは関係のない「その他」扱いのクラスを表わしています。

そのため、赤枠で囲まれた Sinkansen に関する4つのファイルのみを、下図右のツリーのように Sinkansen ディレクトリ内に移動させ、同時に namespace も変更させます。

f:id:yudy1152:20190328162113p:plain

f:id:yudy1152:20190328212022p:plain

操作方法

namespace で右クリック

  • 3行目で定義している namespace 名の箇所で右クリックします。
  • 「Refactor -> Move」をクリックします。

f:id:yudy1152:20190328150731p:plain

移動先となる namespace を入力

  • ダイアログが開くので「Sinkansen」を入力します。
  • 「Refactor」をクリックします。
  • ハマったポイント（原因は不明です）
    • ダイアログが開いた直後に「New Namespace name」の入力欄で文字を入力しようとしても入力出来ませんでした。 すぐ下にある「Target destination directory」のプルダウンを選択後、何もせずに再度「New Namespace name」の入力欄をクリックすると文字を入力することが出来ました。

f:id:yudy1152:20190328150752p:plain

  • そのまま「OK」をクリックします。
  • ハマったポイント（ここもよく分からない点です・・・）
    • App\Test の namespace 内にあるクラスが一覧で出てきます。
    • 最初に操作をした Hikari 以外のクラス（Kodama, Nozomi, SinkansenInterface, TestA）が表示されます。
    • 表の一番下は TestA です。なので、このチェックボックスを外せば移動対象から外せるかと思いましたが、そういうわけでもなさそうです。
    • チェックを外していたとしても、この後の画面を見ても分かると思うのですが、結局 TestA が移動対象として出てきてしまいます。

f:id:yudy1152:20190328220026p:plain

移動対象を絞る

  • 「Refactoring Preview」が表示されます。
  • 今回、TestA は移動させたくないので TestA で右クリックします。
  • 「Remove」をクリックします。クリック後、TestA は非表示になります。（実際に削除されるわけではないのでご安心を！）

f:id:yudy1152:20190328221538p:plain

  • または、TestA を選択し、バックスペースを押すと取り消し線が表示され、移動対象外にすることができます。

f:id:yudy1152:20190328221623p:plain

  • 移動対象を絞った後に、「Do Refactor」をクリックし、これで完了です！

補足

キャプチャを撮ったりするために、ファイル構成などをだいぶ簡略にしていますが、これら移動対象のクラスを new するなどして呼び出している側の use も自動で変更されます。

最後に

使用頻度は少ない操作だろうなぁと思ったのですが、忘れてしまいそうなので書き留めました。

そしてまだまだ IntelliJ を使いこなせていないので、もっと便利な機能とかを紹介できるくらいに使っていきたいなと思います！

AWSソリューションアーキテクトアソシエイトに受かりました！

こんにちは。沖縄移住組 IT エンジニアの勇大（@yudy1152）です。

先日（3/27）に試験を受けてきました。試験勉強をするうえで効果的だったな、やってよかったな、と思えたことについて書き留めておきます。

そもそも私の AWS の実務経験は、去年の半年間ほどではありますが、API Gateway + Lambda + DynamoDB を使ったアプリを作っていました。

なので、本試験にはあまり関係ない、と言いますか、よくて3、4問は勉強せずとも解けるくらいかな、というレベルでした・・・。

試験を受ける背景としては、せっかく AWS を触っているのだからもっと色んなサービスを知りたいな、勉強したいなといったことが、試験を受けてみようという動機になりました。

使用した本

各本には模擬問題が、本試験と同数の65問付いてきます！

最短突破（以下、白本）

各サービスを順番に紹介されており、これから勉強しようと思ってる方は、読み進めやすいのではないかと思います。（私がそうでしたので！）

最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本

最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本

徹底攻略（以下、黒本）

後述しますが、私の場合は AWS の模擬試験を受けた後に読むと効果てき面でした。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

やってよかった勉強方法

それは、本に付いてくる模擬問題や、模擬試験を受けること！です。

本の模擬問題を解く

白本、黒本には模擬問題（本試験と同じ65問！）が付いてきます。 なので、まずは「白本」を1度読んだ後、それぞの模擬問題を解きました。

その時の正答率です・・・

  • 白本の模擬問題：50 %
  • 黒本の模擬問題：60 %

この時、試験日の1週間を切っていて、絶望感を味わいました。。。

模擬問題を解いた後はしっかりと解説を読みました。感触としては白本の方が、解説が詳しく書かれていたと思います。

また、両方の模擬問題で出てくる内容や、被らない内容があるので、どういった点に気をつけたら良さそうか、が把握できたと思います。

AWS の模擬試験を受ける

その後、AWS 認定アカウントから申し込む模擬試験を受けました。

受けた後、メールが送られてきて、以下のように分野別にスコアが分かるようになっていました。

※ どの問題が合っていたのか、間違っていたのか、は教えてくれません。

f:id:yudy1152:20190329000643p:plain

ギリギリな数値なので安心はできませんでした・・・。

ここでよかったのは、分野別にスコアが出ていて、苦手分野を把握できたことです。

そしてさらによかったのは、模擬試験結果の分野と黒本の章の構成がほぼ同じだったことです。

なので、正答率が悪かった分野に付いて、それに該当する章を読むようにしました。

仕上げに白本の模擬問題を再トライ

仕上げとして試験の前日に、白本の模擬問題を解きました。

その時の正答率は9割を超えていました。1度解いてるとはいえ、10割にはならなかったです・・・。

間違った問題の解説や、合っていても気になった問題の解説を読むようにしました。

黒本の模擬問題は、もう力尽きてやれませんでした（汗）

最後に

  • 本に付いてる模擬問題を解いてよかったと思います。
    • 本試験と同数の問題があり、なかなかボリュームがあって正直キツイです。そのキツさを感じずに本試験を受けていたら、途中で集中力が切れていたかもしれません。
  • お金はかかるけれども（2000円） AWS の模擬試験を受けてよかったと思います。
    • 分野別にスコアが出るので、苦手分野に注力できました。
  • 試験に受かるための勉強法に偏ってしまったかもしれませんが、それでも AWS のよく分かっていなかったサービスのこと、Well-Architected の概念を勉強できたのでよかったです。
  • これからは、勉強した概念を元に、AWS をもっと実際に触って知っていこうと思います！

ありがとう波布食堂！

沖縄

こんにちは。沖縄移住組 IT エンジニアの勇大（@yudy1152）です。

せっかく沖縄にいるのだから沖縄のことについても記事にしたいと思い、先日会社の同僚と波布食堂に行ってきたことについて書きたいと思います。

波布食堂はデカ盛りで有名な食堂です。 味もすごく美味しいです！

2019年3月28日で閉店するとの情報を得た同僚が「伝説になる前にみんなで行こうじゃないか！」と立ち上がりました。

11時開店なので、20分くらい前に行けば大丈夫でしょ、ということで着いたところ既に長蛇の列・・・我々の認識が間違っていました。

f:id:yudy1152:20190322155651p:plain
開店前なのに・・・！

店内に入れたのは1時間以上過ぎた後でした。。。

店内の写真もあるのですが、モザイクだらけになりそうなので割愛させていただきます。

波布食堂と言ったらコレ！

f:id:yudy1152:20190322154455p:plain
これぞ肉盛りそば！

沖縄そばの上に野菜がてんこ盛りです。 素直に上から野菜を食べていたら、いつまでたっても麺まで辿り着けません！

お次はコチラ

写真をアップにしてたり、実はチャーハンを持ってる方の手が大きかったりで「そうでもなくない？」って思われるかもしれませんが、 中華鍋に入れたもの全部乗っけたんじゃないかと思うほどの盛り具合でした。

f:id:yudy1152:20190322160407p:plain
え？中華鍋まるごと？

私の撮った写真ではなかなか迫力を伝えられないので、ぜひこちらの記事も見てみて下さい！

mainichibeer.jp

今回は同僚10人で行ってきまして、なんだかちょっとした社員旅行のランチに行った気持ちになりました。（そう言っていたのは他の人ですが笑）

ちょっと足を伸ばしただけで、プチ旅行な気分を味わえるのも沖縄の魅力かなと感じています。

また沖縄の魅力を発見したら投稿しようと思います！

PHP のオートローダーでハマった話

PHP

こんにちは。沖縄移住組 IT エンジニアの勇大（@yudy1152）です。

最近は Laravel を触っています。

クラスを新しく追加したけれども、実行時に not found となり、どうもうまくオートロードしてくれなくてハマってしまったので、調査内容や解決方法を書き留めておこうと思います。

※ファイル構成やクラス名などはこの記事を書くにあたって簡易的にしたものです。

目次

not found and could not be autoloaded.

クラスやインターフェースを追加してテストを実行した時に、以下のようなエラーメッセージが出てしまいました。

Fatal error: Interface 'App\Test\TestInterfaceA' not found in /var/www/app/Test/TestA.php on line 5

静的解析ツール PHPStan を導入していたので実行してみたところ、以下のようなメッセージが出ました。（一部抜粋）

> phpstan analyse
Cannot load Xdebug - it was already loaded
Note: Using configuration file /var/www/phpstan.neon.
 59/59 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 ------ ---------------------------------------------------------------------
  Line   app/Test/TestA.php                                                    
 ------ ---------------------------------------------------------------------
         Class App\Test\TestInterfaceA not found and could not be autoloaded.  
 ------ ---------------------------------------------------------------------

理由は分からないけれども、オートロードしてくれないようで、以下のコマンドをとりあえず実行しました。

 $ composer dump-autoload

このコマンドを叩いた後、テストを実行すると正常に完了しました。

え？毎回実行しなきゃいけないの？

dump-autoload を実行した時にそれなりに時間がかかりました。（数十秒〜約１分）

クラスを新しく追加した時に毎回実行しないといけないのか、いやそんなことはないよね、何かしらの設定が足りてないのか間違ってるのか・・・？

ということで、調査し、解決できたので分かった事などを書きます。

ファイルの構成

ファイル構成は以下のようになっていました。

interface 2 つを TestInterfaces.php で定義。それぞれの interface を実装するクラスを 2 つ用意、という構成です。

  • ファイル構成
app
  ┗ Test
     ┣ TestA.php
     ┣ TestB.php
     ┗ TestInterfaces.php
namespace App\Test;

class TestA implements TestInterfaceA
{
    public function outputA()
    {
        echo 'Test A !!!';
    }
}

namespace App\Test;

class TestB implements TestInterfaceB
{
    public function outputB()
    {
        echo 'Test B !!!';
    }
}
  • TestInterfaces.php
namespace App\Test;

interface TestInterfaceA
{
    public function outputA();
}

interface TestInterfaceB
{
    public function outputB();
}

調査開始！

まず確認したことは、composer.json です。

autoload に関する部分は以下のように定義していて、app 以下はちゃんとオートロードしてくれるはずの設定になっています。

ふむふむ、PSR-4 の規約にのっとってオートロードしてくれるのね。その規約ってなんだろ？が、正直なところでした。

    "autoload": {
        "psr-4": {
            "App\\": "app/"
        }
    },

次に確認したことは、vendor/composer/autoload_classmap.php でした。

$ composer dump-autoload

を実行する前と後でどう変わるのか、を確認したところ、実行後には以下のようなマッピングがファイル内に追加されていました。

     'App\\Test\\TestA' => $baseDir . '/app/Test/TestA.php',
     'App\\Test\\TestB' => $baseDir . '/app/Test/TestB.php',
     'App\\Test\\TestInterfaceA' => $baseDir . '/app/Test/TestInterfaces.php',
     'App\\Test\\TestInterfaceB' => $baseDir . '/app/Test/TestInterfaces.php',

ここで思ったことは、composer.json でオートロードするための設定があるのに、autoload_classmap.php にも定義が必要なの？です。

次に、そのクラスのみで完結する TestC を追加してみました。（継承などしないクラス）

namespace App\Test;

class TestC
{
    public function outputC()
    {
        echo 'Test C !!!';
    }
}

TestA, TestB はいったん無視し、TestC の function のみを実行してみたところ正常に完了しました。

TestC を追加した後、$ composer dump-autoload は実行していないので、autoload_classmap.php にはもちろん TestC に関する定義はありません。

設定などの環境まわりというよりも、クラス内の構成について疑いが・・・

ここでようやっと基本に立ち返り、composer.json 内の autoload で指定している PSR-4 について調べました。

結論：ファイル名とクラス名を同じにしよう！

PSR-4 について参考にしたサイトがこちらです。

www.ritolab.com

私が今回ハマった内容に該当する箇所は、「ファイルのロード」項目の 4. でした。

４. ファイル名は終端クラス名の大文字と一致する必要があります。

このルールに沿って TestInterfaces.php 内に定義していた各 interface を、インターフェース名と同じファイルを用意し、以下のような構成に作り替えました。

  • ファイル構成
app
  ┗ Test
     ┣ TestA.php
     ┣ TestB.php
     ┣ TestInterfaceA.php
     ┗ TestInterfaceB.php
  • TestInterfaceA.php
interface TestInterfaceA
{
    public function outputA();
}
  • TestInterfaceB.php
interface TestInterfaceB
{
    public function outputB();
}

作り替えた後、autoload_classmap.php に APP\Test に関する定義が存在しないことを確認し、テスト実行をすると、無事に正常完了することができました！

まとめ

  • PSR に興味を持ちました

    • 今までは、PHP について調べた時に、PSR の内容が書かれている記事がヒットして参考にする程度でした。 PSR を必ず守らないとダメ！というものでもないようですが、どんな内容なのか一度熟読してみようと思います。

  • PSR に興味を持つついでに PHP もちゃんと勉強しよう！と思いました

参考サイト

モブプロで成功記録をつけてみることにしました

スクラム モブプロ

こんばんは。沖縄移住組 IT エンジニアの勇大（id:yudy1152）と言います。

2019年1月から3人でスクラムチームを組み、1日中モブプロで開発をしています。それまでモブプロの経験はありませんでした。

スクラムやモブプロについて日々試行錯誤しながらやっていて、モブプロのメリットやチームとしてよくなってきたという実感を得ています。

しかし最近、「成長を実感できていないな。言われれば分かるけれども身に付いてる気がしないな。」という問題点が出てきました。

チーム、個人に関わらず、成長を実感できたり、何かしらの形で可視化できれば、仕事がもっと楽しくなるんだろうな、と思っていました。

そんな中、以下の本を読んで、早速私たちのチームで取り組んでみることにした事について記事にしました。 （と言ってもまだ全部読みきれていません・・・汗）

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

本に書かれていた内容

1.3.2 成功をどのようにして計測するか に書かれていた内容を自分なりにまとめてみます。

  • 計測は難しい！

モブプロはフロー効率*1を上げるが、フロー効率が上がった状態になるまでにはある程度時間がかかる。 そのため、チームの短期的な「ベロシティ」を計測してもわからないし、数値で成功を計測するのは難しい。

  • 効果が現れる計測方法として以下の4つが挙げられています。
  • マージコンフリクトの解決にかかる時間の短縮
  • 本番システムに入り込む欠陥の数の減少
  • チーム内の経験の浅いメンバーの学習度の上昇
  • チームがモブプログラミングの導入を改善と感じているかどうか

これらについて、私たちのチームの現状はどうだろう？と考えてみました。

マージコンフリクトの解決にかかる時間の短縮

モブプロをしていなかった時には、1人1タスクで進めていました。その時はそれぞれでブランチを切り、プルリクを出し、レビューしてもらって、develop ブランチへマージ、という作業が発生していました。 もちろんこの時コンフリクトが発生することもしばしば・・・。

ところがモブプロを始めてからはこれらの作業が一切発生していません。

1日中モブプロをしていて、常にお互いレビューし合っている状態でブランチへコミットしていっているため、この時間の短縮以上に、コンフリクトの解決やレビューのストレスといったものが軽減されていることを実感しています。

本番システムに入り込む欠陥の数の減少

今の開発の流れでは、develop へマージした後は、開発環境にデプロイされ、UI ベースのテストをしてもらっています。

私たちのチームが開発した機能に関してはまだ不具合の報告がありません。（キリッ！）

いや、本当は不具合が出ているけれども、こちらにタスクが回ってきていないだけかも・・・？と若干疑っています（笑）

とはいえ、日々のモブプロで感じたことで、1人でタスクをこなしている時よりも、常に他に2人が目を光らせていることで、すぐに「あれ？そこのカラム更新されてなくない？」、「ん？そのコードだと不具合が起こる可能性あるかも」、「こういう操作した時はどうなるか確認した方がいいね」といった感じで、妥協させてくれません（笑）

もちろん私自身も、自分が1人で操作して確認するよりも、客観的に見ることで視野を広げて確認することができ、きっとそういった積み重ねが 本番システムに入り込む欠陥の数の現象 に繋がるんだろうなと実感しています。

チーム内の経験の浅いメンバーの学習度の上昇

私たちチームは確実に成長していると思っています。 しかし、冒頭でも書きましたが、3人で「成長してきているかな？」という話をたまにするのですが、あまりピンとくる反応がありませんでした。

チームがモブプログラミングの導入を改善と感じているかどうか

これはもうみんな「もちろん！」と答えてくれるでしょう。

2019年3月13日　記録開始！

今日がスクラムのふりかえりの日でして、成功記録をつけていこうという話し合いを行いました。

「例えば1ヶ月後、2ヶ月後、ふりかえった時に何があれば成長を時間できるだろう？」といった視点にたち、以下のようなアイデア出し、実行していってみよう！となりました。

  1. ポモドーロで作業した際に、気づいたこと、理解できたこと、ハマったこと、分からないことなど、小さいことでも記録する
  2. 作成した function、修正した function（たった1行でも！）の数
  3. タスク管理（Backlog）のタスク消化数

1. ポモドーロの際の記録に付いて

普段からモブプロを行う際に、ポモドーロ（25分の作業＋5分の休憩）で回していて、Slack に何のタスクをやったかを記録していました。その日の最後に1日をふりかえりしやすくする意図がありました。

なので、その時についでに何かしら思ったことなどを気軽にコメントとして残していってみよう、となりました。 記録する際には、 Slack だと埋もれてしまうので、Google スプレッドシートで記録するようにしました。

こういった小さな積み重ねを後で見返した時に、理解できた事や、できるようになった事が「これだけ増えたんだ！」というのが目で見て分かれば、きっと成長を実感できるんじゃないかと思います。

2. function の数について

以前チームのメンバーが上司と1on1を行った際にアドバイスとしてもらったアイデアです。

新しく作る function だけでなく、例えば100行を超える程の function のリファクタリングをして、適切な意味のある小さい function に切り分けていくだけでもスキルが求められると思いますし、コミット時に差分を見て、今回のタスクでどれくらいの function に携わったか、というのは簡単に数えられるので記録していってみよう、となりました。

3. タスクの消化数

function にも話が通じる部分があると思うのですが、単純にタスクを小さく切って数を伸ばそう、という事はもちろんせず、 タスクを切る際に、同じような粒度で切る、もしくはストーリーポイントのように、何かを基準にして○倍くらいのタスクか、といったように、 比較しやい粒度でタスクをうまく切っていけるようにする、といった狙いがあります。

最後に・・・

「成長を実感したい！」というみんなの想いから、まずはやってみよう！という所から始まりました。

1週間ごとにスクラムのスプリントを回しているので、この記録方法についてもふりかえりを行い、改善できる所は改善して進めたいなと思っています。

そして、この記録の経過や、チームメンバーの実感具合などブログで報告できたらなと思います。

※スプレッドシートに記録したことを定期的に Slack へ投稿したり、集計した結果を投稿したりしてみたら面白いかも？と思ったので、今度挑戦してみようかなとも思います。 その時のこともブログのネタにしようかな、と思ってます。

*1:機能を安く作るのではなく、早く完成させることを目標とし、機能全体を早く市場に送り出すことを重視する考え方。