続・doiluxの検証生活

メインはQiitaで、こちらはQiitaに掲載するのにそぐわない内容(技術的な要素が比較的薄いもの)のものを掲載。なお、本ブログの内容は個人の意見を反映したものであり、所属組織のスタンスを反映したものではありません。

他チームのふりかえりのファシリをやったらよかった件

タイトル通り。訳あって、他のチームのふりかえりのファシリテーターをやったら、自分のチームの見えていないところが見えたのでよかった。

そのチームは「作業が属人化していること」がProblemで、原因は「納期が短するぎる(共有する時間が取れない)」に至った。 チームとしてスピード優先でリスクをとる選択もあると思ったので、「属人化のリスクを受け入れて、開発スピード上げる方針をとっているのはチームで話し合って決めてるんだよね?」って聞いたみたら、歯切れの悪い返事が返ってきたので、多分その意識はなかったのだと思う。つまり、属人化の原因は「短納期だから」ではなく、「チームが短納期の要求に応える方針をとっているから」ということ。

と、チームを外から見てたら上記のようなことが見えてきたわけですが、自分のチームも意識してなかったと思う。実際同じようなProblemがでて、「短納期だから(しかたない)」になったこともあった気がするし。

ということで、他チームのファシリをすると勉強になるという話でした。

ちなみに今回、時間的制約があったのでここまでだったけど、もっと時間が取れれば「属人化」の何が問題なのか?というところももっと掘り下げていきたい。

下町ロケットをこれから観る人は試しにこれやってみて

今この本を読んでます。

www.amazon.co.jp

チーミングについて書かれた本です。この本をよんで、佃製作所とサヤマ製作所を比較するとおもしろい。

例えば、この本に「心理的安全」を高めることの必要性について書かれています。「心理的安全」を高めるとは、一言で言うなら「意見しやすい雰囲気を作る」ということです。

それをふまえて観てみると、佃製作所の社員は上司部下関係なくすげー意見を言うし、社長も部下の意見を頻繁に聞こうとしています。

※参考(違

一方のサヤマ製作所は

「お前…もし間に合わなかったらわかってんだろうな…」(正確なセリフは忘れた)
「わ、わかってます(;゚Д゚)); ガタガタ」

※写真はイメージです www.instagram.com

超ワンマン!!

ということで、これから下町ロケットを見る方や、正月に2回目観ようと思ってる方は、まず

www.amazon.co.jp

この本を読んでからご覧いただくと違った見方ができてより楽しめると思います。

大都会岡山 Advent Calendar 2015 Day2〜ぼくのかんがえたさいきょうのチーム

www.adventar.org

岡山出身のdoiluxと申します。今の現場に来てから約3年が経ち、最初はお荷物、その後はコーダー、チームの技術リーダーをやらせていただいて、ここ数ヶ月は、チームビルディングとかメンバーの育成に力を入れたりとかしてます。

今回、チームビルダーとしてはペーペーの私が最強のチームを考えてみました。ただし、メンバーは岡山出身者に限定します。 チームメンバーは5人、戦隊もの(ゴレンジャー的な)のメンバーをモデルに選出したいと思います。

まず赤は私が担当します。もちろんチームビルダー/プロジェクトマネージャーを担当します。

青といえばやっぱり二枚目なので、B'zの稲葉さんに任せます。チームでの役割は技術リーダー。技術的なことで困ったらオレに聞け!!松本に相談しよう!!

黄色は青とは真逆の3枚目。ということで次長課長の河本さんに任せます。役割は営業/マーケティング担当といった、エンドユーザーに近いところで。

緑はあんまり華がない(失礼w)縁の下の力持ち的な位置づけかと。ということで雪舟さんにデザイナー職を任せます。理由は地味だから。歴史の教科書のなかでも織田信長徳川家康みたいな派手さがないことがポイントです。デザイナーが地味ってどうなんだ

そして、桃レンジャーは紅一点、女性であることが絶対条件ですが、残った役割は数字の魔術師、データサイエンティスト。Wikipediaで調べてみても、これだ!!って人が見つからない…ただ、どうやらNARUTOの作者は岡山出身らしいということで、NARUTOの登場人物から春野サクラをアサインしようと思います。調べたところ医者忍者らしいし、医者って数字も扱いますもんね(血圧とか)。問題は僕がNARUTOを1ページも読んだことがないという。

ということで候補者の選出は終わりました。そして、妄想を妄想で終わらせないのが我々エンジニア。僕たちにはそう、Hubotがある!!

                     _____________________________
                    /                             \
   //\              |      Extracting input for    |
  ////\    _____    |   self-replication process   |
 //////\  /_____\   \                             /
 ======= |[^_/\_]|   /----------------------------
  |   | _|___@@__|__
  +===+/  ///     \_\
   | |_\ /// HUBOT/\\
   |___/\//      /  \\
         \      /   +---+
          \____/    |   |
           | //|    +===+
            \//      |xx|

ということで夢のチームの様子をご覧ください。

f:id:doilux:20151115212734j:plain

クソだな。このチーム。

まとめ

開発は楽しい♪

明日はShoji Fujiiさんお願いします。

ふりかえりをふりかえってみた

この記事すごく参考になりました。 kuranuki.sonicgarden.jp

今の現場は2Wスプリントなので、1年で24回くらいふりかえってます。前述の記事に感化されて、24回のふりかえりをふりかえってみます。

うまくいかなかったTryその1:心構え系

「コミュニケーションを頻繁に取るようにしよう」とかそんな系のやつ。大体翌日には忘れる。忘れないように朝会のチートシートとかに書いておいても作業を始めて3時間くらいで大体忘れる。まるで二日酔いになるたびに「もうお酒は控えよう」と言ってる感じ。「それはお前の学習能力の問題だろ」って言われるとぐうの音も出ませんが、このTryは3回復唱したら捨てていいと思います(今思いついたけど、botに1日1回しゃべらせるとかいいかも)

うまくいかなかったTryその2:開発プロセス変える系

手軽にできるTryじゃなかったタイプ。具体的には、設計段階でミスがあってけっこう大きな後戻りが発生したことがあったので、「ここでレビューをはさもう!!」という感じで開発のプロセスを変えたことがあったのですが、全然まわりませんでしたorz 開発のプロセスを変えるってことは仕事のやりかたを変えるってことなので不慣れなやり方でパフォーマンスは相当おちるはず。なので目標ストーリーポイントも下げておかないと絶対バーンダウンしないなーと思いました。本当に開発プロセスが問題なら変えなきゃいけないですが、まずは手軽にできることから始めたい。

うまくいかなかったやりたくないTryその3:評価パターンを増やす系

バグが見つかった時とかに「このパターンを結合評価に入れる」ってやりがちです。もちろんやらなきゃいけないと思いますが、評価パターンがどんどん増える→評価に工数を取られまくる→よし評価パターンを減らそう!!→障害が起きるって未来が見える、見えるぞー。評価パターンを増やさなきゃいけない時は自動化する方向で考えたい(そもそもそれ本当に評価の問題か?ってのはあるけど

うまくいったTryその1:レビュワーいない→Findbugs導入

Javaのコードをレビューできる人がいないって問題が発生。最初はレビューできる人を育成するってTryがでていましたが、よく考えたらレビューがボトルネックになっているのに育成できる余裕なんかない(あと育成方法も知らん)。で、Findbugsを導入してレビュー観点が減ったので、大分スピードアップできました。

うまくいったTryその2:評価データ生成ツールの作成

結合評価の際に評価データの作成に時間を取られていたので、評価データ作成ツールを作りました。評価データの生成が楽になるだけでなく、このツールはインターフェースを変えただけで、中の処理は通常の業務の処理を呼んでいるだけなので、処理を変えた時のちょっとした動作確認にも重宝しています。

最近思うことその1:必ずしもPからTを出さなきゃいけないわけじゃない

今までうちのチームではProblemを出す→なぜなぜ分析をする→Tryをだすって進め方をしてましたが、「なんか面白そうやけ使ってみねー」ってTryも出せるようにしたいなーと思ってたりしてます。

最近思うことその2:Kを継続するTも出す

Keepは出しっぱで終わってたので、Tryを出す時にKeepをKeepし続けていく(もしくはよりよくする)Tryも出したいな〜なんて思ってたりします。

まとめ:開発は楽しい

そもそも普段開発をしてるんだから、チームの問題もツールの導入とか開発で解決するのが一番得意なはずって思いました。

寸劇botを作ってみた

最近チームビルディングを始めました。色々と勉強しながら手探りで進めているのですが、自分の中では一つ確信めいたものがあって、それは人間めんどくさいこととつまらないことは自発的に取り掛からない(もしくは取り掛かったとしてもすごくエネルギーを使う)ということ。逆に言えば、そういったことを楽しくできるようにして、チームメンバーの自発的な行動を促すことがチームビルダーのミッションの一つではないかと思ってたりしてます(WorkRolesにもそんな感じのことが書いてあった気がするような気がする)。

話は変わって、プログラムの品質を表す指標にカバレッジと複雑度というものがあります。基本的にはカバレッジが高ければ高いほど、複雑度は低ければ低いほどバグが混入しにくくメンテしやすいプログラムと言えます。チームメンバーにはこれらの数値を意識して欲しいのですが、現在我々のチームでこれらの数値を確認するのがやや面倒で、具体的には

  • Jenkinsのダッシュボードを開いてコードカバレッジを確認
  • SonarQubeのダッシュボードを開いで複雑度を確認

という2つのステップを踏まなくてはいけません(余談ですが、JenkinsのSonarQubeプラグインの設定がどうしてもうまくいかん…前やったときこんな難しかったかな〜)

こいうことでこれらの情報へのアクセシビリティ向上のためにbotを作りました。

※画面と数値は実験的に作ったプロジェクト環境のものです

f:id:doilux:20151122090414p:plain

チャットにredstarと投稿すると。

f:id:doilux:20151122090351p:plain

セイラさんがメトリクスを教えてくれる。 ちなみにどれだけ数値を改善しても、軟弱者!!と罵ってくる超ドS仕様です。

さらにJenkinsがコケている(=バグが見つかったなど)ときはちょっと違う動きにしてみました。

f:id:doilux:20151122090406p:plain

f:id:doilux:20151122090359p:plain

ブライトさんにオネエ言葉で怒られる。

こんな感じで寸劇が繰り広げられます(名付けて寸劇bot

ということで、ガンダム世代のハートをがっちりキャッチして、情報にガンガンアクセスしてもらい、気付いたらコードの品質が上がってた!!というのが狙いですw

あとは朝会の進行を一年戦争風にしたら気分はホワイトベースの乗組員ですね♪ (自分で言っといてなんだが一年戦争風ってなんだ?バーンダウンチャートの確認を戦況の確認とか言ったら一年戦争風になるのか??)

さて、これをプロジェクトに導入したいのですが、一つ問題があって、チームメンバーにガンダム世代が一人しかいないこと。(実は私も微妙なところで、はじめてオンタイムで見たガンダムはF91くらいの年代)

ということで、オチもなく唐突に終わりますが、以上!!!

余談ですが、セイラさんの動作確認のために作ったプロジェクトよりセイラさん自身の方が明らかに複雑度が高そうという(CoffeeScript書いたことなかったら、ググり駆動開発したらこうなったw)

job_url = 'http://localhost:8080/job/test-bot/'
sonar_url = 'http://localhost:9000/api/resources?format=json&resource+test-bot&metrics=class_complexity'

module.exports = (robot) ->
  robot.hear /redstar/i, (msg) ->
    request = msg.http(job_url + 'api/json?pretty=true').get()
    request (err, res, body) ->
      json = JSON.parse body

      last_build = json.lastBuild.number
      last_failed_build = json.lastFailedBuild.number

      if last_build == last_failed_build
        msg.send "右舷後方に被弾!!このままではもちません!!!"
        return

      test_report = msg.http(job_url + last_build + '/jacoco/api/json?pretty=true').get()
      test_report (err, res, body) ->
        json = JSON.parse body
        cls_cbrg = json.classCoverage.percentage

        cc =msg.http(sonar_url).get()
        cc (err, res, body) ->
          json = JSON.parse body
          ccc = json[0].msr[0].val

          msg.send "システムオールグリーン!!テストカバレッジ" + cls_cbrg + "!!コード複雑度" + ccc + "!!それでも男ですか!軟弱者!"