KPTによるふりかえりの効用は仕事の効率化だけか?

f:id:naoto5959:20150502155448p:plain

先日会社のブログに、「ふりかえりのススメ!〜モチベーションのコントロール〜 | マネーフォワード エンジニアブログ」という記事を書きました。

KPTという振り返りのフレームワークがあります。

よかったこと(Keep)、うまくいかなかったこと(Problem)、改善するために試すこと(Try)に分けて考えるんですが、これを導入して仕事を改善しようと私のチームの若手を中心を中心毎週KPTすることを始めました。

元はというと、前職で「ソニックガーデンギルド」に参加していた際に、ソニックガーデンの倉貫さんやメンバーと行っていたふりかえりで、このKPTを使っていたというのがあります。このKPTで自身の成長を実感したのもあり、今の会社でも少しずつ取り入れています。

KPTのコツは、倉貫さんの記事にあります。

自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!

仕事の効率化につながるチップスとしては以前書いた

あたりを、アドバイスとして話すことが多いです。他にもこんなアドバイスをしてきました。

  • Problemとして「何かができない」という問題を持っていた場合、出来ない、ということはどんな理想に対するギャップがあるのかをしっかり考える
  • 人生の中では大量の惰性があるはずなので、本当に必要ではないことはやらないことも大事
  • 自分がフロー状態に入るコツを掴む
  • タスクは、溜めすぎると瞬殺タスクから普通のタスクになる。小さなタスクはすぐに倒す
  • 最短距離で最大限の成果を出すための優先度を考える

KPTで成長するメンバー

最近、社内でKPTをしているメンバーの姿がより良くなっていくのを感じています。なんていうか、輝いている感じがします。

また振り返りの際には必ず、 「今週楽しかったですか!?」 と始めるようにしてます。毎週を楽しく振り返る事が出来たら最高ですね。

これが大事だなと思ってます。

毎週金曜日に振り返りのではなく月曜日に先週の振り返りをしていたこともあったのですが、明らかに明らかに相手のテンションに違いがあることに気づいたのです。金曜日にやったほうが雄弁にKeep、Problemを語るのです。

その週のうちに、ふりかえる。鉄は熱いうちに打て、みたいなものでしょう。

「今週楽しかったですか!?」 この質問に「楽しかった!」と自身を持って答えられるような、1週間を過ごしたいですね。そのためには

  • 自分は何をしたいのか
  • 自分は何を考えているのか
  • 自分は何をしているのか

ひたすら自問自答し続けます。哲学を持ちます。芯があればブレない。ブレない気持ちを持つためのふりかえり、そんな効用もあるなと最近思い始めました。

パッションを軸にした、ふりかえり、オススメです!

あわせて読むといいかも

プリンテイルのtwitterのアイコンステッカーキャンペーンに応募した結果www

f:id:naoto5959:20150307215530j:plain

Twitter アイコンステッカーをゲットしたよ! - FAKELOGを読んで、アイコンシールキャンペーンに挑戦してみました。

そしたら、なんと当たりました\(^o^)/

どこに貼ろう?

どうでもいいですが、私のアイコンTシャツは、Naoto Koshikawa ( ppworks ) の【それいけマンボー稚魚たくさん】Tシャツ ∞ SUZURIから購入することが出来ます。

ステッカー欲しい方はどこかでお会いした時に、ちょうだい!と言って下さい。でも何に使うんですか?

WIPであろうと、情報共有すると何がいいのか?

口頭で話したことを文字に起こすことについての続編のような記事です。

消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。

  • 口頭で相談したことをesaqiita:teamにまとめる
  • 口頭でコードレビューしたことをgithubgitlabのコードレビューのコメントにも書き残す
  • 口頭で話したことをチャットにも書き残す
  • チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す

情報共有すると何がいいのか?

何がいいか。

  • 暗黙知を減らすことが出来る
  • 当事者に なろうと思えばなれる

なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるということです。

情報共有にはメリットしかないという話からもインスパイアされました。

情報共有において遠慮はらないと思っています。ノイズになるかも?なんて遠慮は不要です。繰り返しますが、共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるからです。情報共有がノイズだと思うのであれば、ノイズをノイズとして処理できない受け取り側に問題があります。

情報共有によるモチベーションの向上

チームが自律的に自走するためには、チーム内のモチベーションを高い状態にキープすることが大事になってきます。例えば、思いや感情を共有することで相互理解を深めることが出来る。そして、相互理解を深めると、人は互いに承認欲求が満たされ、モチベーションが高まる傾向にあります。

モチベーション向上のためにも思いや感情の共有は大事です。

slackに#current_status部屋を作ることで、slackを気軽な思いや感情を共有部屋とするのも、情報共有の第一歩として気軽に始められてよいでしょう。

WIPについて

また途中経過、WIP(Work In Progress)な情報についても共有をすると、良いことがあります。

  • 人は、 たとえ議論に参加出来なかったとしても、途中経過を知ると納得しやすい
  • 人は、結論だけ示されると 当事者意識を持ちにくく、納得感を得にくい

WIPな情報は、より早くより新鮮な状態の情報です。そして、完璧でもないし結論も出ていなかったりします。ただ、思いを共有したり、考えている事を共有するには十分な情報だったりします。

完璧を求めることで、途中経過を伝えることや他の人が当事者意識をもつ機会を損失します。何より完璧な情報は作った人間がそれに固執しやすいという特性もあります。

密室で行わる議論の何が問題なのでしょう。透明性がない、途中経過の分からない議論の結論は上記の理由から、自身が蚊帳の外にいる感覚を得やすいと考えます。たとえ、議論に参加出来なくても見えることが大事で結論がどのように導かれたか、プロセスが見えると人は納得するのです。つまり、WIPでも情報はオープンにすることが重要です。

マネージメント層の議論の結論がこのように密室で透明性のない状態で行われると何が起きるか、組織への不満、不信です。

短い経営経験の中で少なくとも2回この失敗を犯しました。失敗を繰り返さないために、WIPでの情報共有に気を配りたいです。

WIPの情報共有に適したツールは?

esaというチーム内での情報共有するためのサービスがあるのですが、そこの紹介文にこうあります。

f:id:naoto5959:20150222113616p:plain

情報共有ツールに、機能としてWIPが存在するということは、この情報共有ツールがWIPで共有することを正しいものとする哲学があると感じました。

また、qiita:teamでも、タイトルに [WIP] を付けるなど運用でカバーすることは出来ます。

自分たちに適した情報共有ツールを使って、WIPな情報を早い段階から積極的に共有し、よりよいチームを築いていきましょう。

それでもRailsを選択する3つの理由

スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。
みんなが使っているから使う?それだけではないはず。なぜ使うのだろう。

f:id:naoto5959:20150219230109j:plain

railsの特徴を考える。

  • 規約縛りの哲学
  • 周辺gemのエコシステム
  • webの進化への追従の速さ

規約縛りの哲学

Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。

外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。

スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話はないのだ。簡単に遠くまで行くには、それなりの覚悟が必要だ。規約を守るにはRailsの哲学を理解する必要がある。取っ掛かりとしては、

あたりだろうか。体系だった書籍や公式のチュートリアルは哲学に触れる第一歩としてよい。実際作ることにより規約があるからこその手軽さを体験し、運用からその思想の深さが理解できる。

規約縛りのさらなる魅力はなにか、Railsというレールがあることにより、チームの共通認識として Rails way に沿っているかという基準が出来ることは大きな魅力だ。チーム開発を加速するためにコードレビューの重要性が高まっているが、このコードレビューにおいても Rails way であるか?という観点がレビューの観点となるので、コードレビューを導入しやすいと感じる。Rails wayをベースにして、コードレビューの観点を育てて行けるのは魅力の一つだ。

地域コミュニティは、Sendagaya.rb | Doorkeeperが初心者におすすめ、もうすでにRailsで何かを作っているなら、ゆるふわ Development Club #yurudevもよい。

周辺のエコシステム

Railsがgithub上で開発されている事も大きいが、その流れで周辺のライブラリ群(gem)も同じgithub上にて開発されていることが多い。

githubにおけるpull requestの仕組みがこのエコシステムを広める根源となっている。

  • 議論に透明性がある
  • 誰にでもチャンスがあり当事者意識をもてる
  • エコシステムに貢献できる

逆に言うと、エコシステムには貢献する義務もある。gemに不都合や要望があるとき、 自身がエコシステムの一部であることを認識していれば、自然とそのgemにpull requestを送ることになる だろう。

Railsに乗るということは自身がエコシステムに入るということだ。Railsに乗り、OSSに貢献する気持ちを育てよう。pull requestはコミュニケーションだ。自律的行動でしか成り立たない。

pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーションはそういう事例を書いた記事。

webの進化への追従の速さ

#12 Rails sideshow | mozaic.fm で語られているように、Railsの進化はWebの進化である。

Railsはバージョンアップがつらいという話をよく聞く。フレームワークのAPIは驚くほど早い周期で廃れ、入れ替わっていく。それの影響もありエコシステムを形成するgemもその影響を受ける。つまり、バージョンアップへの追従のために対処しないといけない箇所は非常に多い。

なぜ、それほどまで変わるのか。

進化のために過去を切り捨てることが、Railsが今も進化し続け、多くの人に利用されていて、エコシステムが形成されることの鍵である。過去の互換性を残せば残すほど進化は鈍化し、身動きがとれなくなってくる。その為に良いもののためには捨てる。

追従するために必要なことはなにか。

  • レールに乗る
  • テストを書く
  • Rails本体を含めたエコシステムの動向をウォッチする

どれも必要であり、これらは生半可な気持ちでは実践できない。

それでもRailsを選択する理由

それでもRailsを使うのは、 規約縛り周辺のエコシステムwebの進化への追従 と言った点に魅力を感じるからであろう。

企業の活動において、railsを選択することはエンジニアリングにおけるただのフレームワークの選択ではなく、重要な経営判断である。 バージョンアップへ追従やテストを書くことを経営陣が意味ある活動であると理解することが大事 だ。

パーフェクトRuby on Rails

パーフェクトRuby on Rails

転職時に考えておくべきこと

何かしら失敗経験を踏まえて今度は成功するぞって気持ちや今までとは違う理想を描いて転職ってすると思うんですよ。

なので、失敗経験はちゃんと振り返る。どうすれば改善出来るか、どんなアプローチが適切かを分析しないと同じ失敗を繰り返すと思うんです。そして同じ理由で転職を繰り返す。 アプローチは圧倒的に変えないと劇的な変化は訪れないんですよ 。真逆の自分になることも必要かもしれません。また過去の失敗や後悔に論理的な理由付けをしておかないと過去に引きづられ続けます。

理想にどうたどり着くかというアプローチは圧倒的に変えないと以前と同じ失敗をする。理想にはたどり着けない。

理想を語るのは簡単。理想に向かうためのプロセスを見せるべきだし、行動で示すべき。人は議論では動かない、議論の前に行動を。よりよい仕事をしたいなら、不満を口にする前によりよい改善的行動を。

そりゃ入ってみたら思ってたのと違う、よろしくない部分もあるでしょう。文句も言いたくなるでしょう。そういうことに対してのアプローチ、問題提起するか、課題として解決していくか、どういったアプローチが適切なのでしょうか。

会社はチームであることを認識すると経営に知らん顔出来ないし、客人ではいられなくなります。この会社の経営者だったらどう行動するか?そう考えれば他人ごとではなくなるし当事者意識が芽生えると思います。会社は誰かがよくするんじゃなくて一人一人の行動でしかよくならないのです。