アジャイル開発の士気管理(後編)
プラクティスは実践知

2020年9月14日公開

ニコニコカレンダーは著名なアジャイリストが発明したプラクティスではなく、ふつうの人たちがつくり出したプラクティスです。ここでは士気管理プラクティスとしてのニコニコカレンダーについて考察します。

ソフトウェアメトリクスとして

2005年、当社における「ソフトウェア開発の見える化」という流れ、つまり「測定し、可視化し、改善する」という方針のもとで、製造業の視点である生産管理指標(QCD,IP,SM)に着目し、ソフトウェア開発の見える化を図ったことが、ニコニコカレンダー誕生のきっかけのひとつです。

表 ソフトウェアメトリクスとしてのQCD,IP,SM
    
項目 意味・測定方法
Q(Quality:品質)
C(Cost:原価)
D(Delivery:納期)
いわゆるQCDです。
これらは直接にあるいは代用特性を利用して測定されます。
I(Inventory:在庫)
P(Productivity:生産性)
ソフトウェア開発では、バーンダウンチャートで見える化が実現されています。
縦軸が在庫。傾きが生産性と考えてよいでしょう。
S(Safety:安全性)
M(Morale:士気)
精神的な健康、目標の達成や能力向上の意欲のことです。
測定は困難です。

測定困難なSM(Safety,Morale)、"安全性"と"士気"について見える化を試みたのが、ニコニコカレンダーであるといえるでしょう。

見える化

ここまで「見える化」ということばを度々使いました。日本語として少々奇妙なことばのように感じますが、元々は製造業に由来しているようです。

異常の露出

見える化で最も重要なことは"異常"を見えるようにすることです。この"異常"ということばも製造業にかかわる人たちの中では少し特殊な意味で使われています。

異常とは、“不良ではないが、正常ではない状態”、“正常と不良の間にある状態”

例えば、

  • 機械は異音を発しているが、不良品を出すことなく動作し続けている。
  • 目の下にクマを浮かべているが、バグをつくりこむことなく開発し続けている。

「決して正常ではない状態」、「不良に至りそうなサイン」を指すことばです。

いきなり不良が発生する状態は、決して好ましくありません。ましてやSM(Safty,Morale)における不良とは、人の安全にかかわることです。

「正常ではない状態」や「不良に至りそうなサイン」を見逃さないために、「日々少しずつ変化を見よう」、「傾向を見よう」ということなのです。

これを異常管理といいます。

フィードバック

いくら異常を監視していても、なにも対処しなければ管理・マネジメントしていることにはなりません。フィードバックがあることが重要なのです。異常管理の原則といえます。

ニコニコカレンダーの場合、そのフィードバックとはいったいなんでしょう?リーダーやメンバーがケアする。手伝う。仕事をシェアする。いろいろあるでしょう。単に話をきくだけでも大きな効果があるでしょう。(看るではなくても)見ていることが伝わるだけでも、そのストレスは軽減されるようです。

フィードバックがなければ、嫌になってしまいます。絶対嫌になってしまいます。そしてやらなくなってしまいます。

しかし、ニコニコカレンダーは継続性が高いプラクティスであることが、多くの現場から伝えられてきます。それは、リーダーやメンバー以外からの重要なフィードバックがあるからです。

擬人性

重要なフィードバックは自分自身から発せられます。毎日自分自身でシールに顔を書きニコニコカレンダーに貼る。その際、小さなふりかえりを実施しているためです。

カレンダーに貼ったシールの顔と見つめあいながら、一日をふりかえり「よかったこと」、「よくなかったこと」、「ああすればよかった」、「今度はこうしよう」という思いが巡るのです。
顔があることでシールはある意味、擬人性を帯びるのではないでしょうか?

感情を露わにしない習慣のなかで過ごしてきた開発者たちが、小さなふりかえりをおこないつつ、チームの仲間へもサインを送る。そんな毎日の繰返しが、精神的浄化作用を生んでいるのではないでしょうか。毎日浄化。少しずつ浄化するプラクティスがニコニコカレンダーです。

メトリクスからプラクティスへ

このように、SM(Safety,Morale)のメトリクス、あるいはメトリクス測定のツールだったニコニコカレンダーは、測定の営みの中で、日々を"ふりかえり"、"貼る"、そして"みる"といった一連の行動そのものが、SM(Safety,Morale)そのものを高めるプラクティスへと変遷していったのです。

プラクティス

アジャイル開発の主要な方法論の1つであるエクストリームプログラミング(XP:eXtreme Programming)は、価値(Value)、原則(Principle)、プラクティス(Practice)の3階層で記述されています。しかし、なぜか"プラクティス"を日本語に翻訳された例を見かけることはほとんどありません。
(エクストリーム・プログラミング入門の初版では、「実践」と訳されていましたが、2版からはプラクティスと訳されています)

しかし、「プラクティス」ということばはどうもピンと来ない気がします。

Niko-Niko

ニコニコカレンダーは「This Isn’t Kindergarten」などいくつかの批判はあるものの、多くの言語で紹介され論文からの参照も少なからずあります。

また、"Niko-niko Calendar"としてアジャイルアライアンスのWebサイトにアジャイルプラクティスとして掲載されています。

Subway Map to Agile Practices(アジャイルアライアンスのWebサイトから引用)
https://www.agilealliance.org/agile101/subway-map-to-agile-practices/

アジャイルアライアンスのアジャイル用語集プラクティスタイムラインにも掲載されており、スタンダードなプラクティスの1つと認識されているようです。

経験則

「ニコニコカレンダー」は「安全性や士気を高めるプラクティス」であることは、おそらく確かです。チームのムードをみてフィードバックし、安全性や士気を高める施策をとっているからです。勘定して帳面につけるだけの管理ではありません。アウトプットからプロセスを調整するフィードバックが存在する本来的な管理(マネジメント)プラクティスです。

そしてそれは、著名なアジャイリストが発明したプラクティスではありません。ふつうの人たちがつくり出したものであり、つくり出した人たちの役に立つものでした。

エクストリームプログラミングに詳しいある友人はこう云いました。

ニコニコカレンダーのいいところっていうのは「プラクティスって自分たちでつくっていいんだ」ってことを示したことじゃない?

プラクティスの中身も、プラクティスのつくり方も、自分たちが、自分たちをみて、自分たちで判断して、自分たちのやり方を変える。自律的につくるのがプラクティスです。

士気管理プラクティス「ニコニコカレンダー」そのものの効用よりも、「ニコニコカレンダー」が自分たちでつくったプラクティスであるが故に、安全性や士気を高めていったのかもしれません。であれば、士気管理を狙っていないプラクティスであっても安全性や士気は十分に高められそうです。

自分たちでつくったプロセスの中で、自分たちのプラクティスを活かすことこそが、士気を高めパフォーマンスを向上させる源泉であるということを、スクラムでは「自己組織化」として、エクストリームプログラミング(XP:eXtreme Programming)では「実践(初版訳)」として語られているのではないでしょうか。

さきほど、「『プラクティス』ってことばはどうもピンと来ない気がします」と述べましたが、書籍「ソフトウェア・テストの技法 第2版」で、"practice"ということばは"経験則"と訳されています。"経験則"、これが最もしっくりくる訳語であると思われてなりません。

参考文献

  • Agile alliance, "Agile Practices Timeline", https://www.agilealliance.org/agile101/practices-timeline/ ,(参照 2020-08-11)

  • Agilee alliance, "Subway Map to Agile Practices", https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ ,(参照 2020-08-11)

  • Kent Beck, "Extreme Programming Explained: Embrace Change", Addison-Wesley Professional, 1999, 224p, ISBN 978-0201616415

  • Kent Beck, Cynthia Andres, "Extreme Programming Explained: Embrace Change", 2nd ed., Addison-Wesley Professional, 2004, 224p, ISBN 978-0321278654.

  • ケントベック, "XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法", 長瀬嘉秀(訳), 飯塚麻理香(訳), 永田渉 (訳), ピアソンエデュケーション, 2000, 190p, ISBN 978-4894712751

  • ケントベック, "XPエクストリーム・プログラミング入門―変化を受け入れる", 長瀬嘉秀(訳), テクノロジックアート(訳), ピアソンエデュケーション, 2005, 189p, ISBN 978-4894716858

  • ケントベック, シンシアアンドレス, "エクストリームプログラミング", 角征典(訳), オーム社, 第2版, 2015, 181p, ISBN 978-4274217623

  • 江渡浩一郎, "パターン、Wiki、XP-時を超えた創造の原則", 技術評論社, 2009, 224p, ISBN 978-4774138978 ,(参照 2020-08-11)

  • extremeprogramming mailing list, "Re: "Niko-Niko" Calendar, feedback of team mood", https://groups.io/g/extremeprogramming/topic/39160290#116354

  • Nicole Forsgren Ph.D., Jez Humble, Gene Kim, "LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する", 武舎広幸(訳), 武舎るみ (訳), インプレス, 2018, 320p, ISBN 978-4295004905

  • Ken Schwaber, Jeff Sutherland, "The Scrum Guide", Scrum Guides. 2017. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf , (参照 2020-08-18).

  • Glenford J. Myers, Todd M. Thomas, Tom Badgett, Corey Sandler, "ソフトウェア・テストの技法 第2版", 長尾真(訳), 松尾正信(訳), 近代科学社, 2006, 221p, ISBN 978-4764903296

  • Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas, "The Art of Software Testing", Wiley, 2版, 2004, 256p, ISBN 978-0471469124

  • 野中郁次郎, 竹内弘高, "The New New Product Development Game", Harvard Business Review. 1986. ISSN 0017-8012. https://hbr.org/1986/01/the-new-new-product-development-game, (参照 2020-8-18).

  • 坂田晶紀, "ニコニコカレンダー", 2005, https://sites.google.com/view/niko-niko-calendar/home/ja , (参照 2020-08-11)

  • Sabrina Son, "Why a Niko-Niko Calendar Kills Workplace Morale", https://www.tinypulse.com/blog/sk-niko-niko-calendar-workplace-morale , (参照 2020-08-11)

   

執筆

  • 坂田 晶紀(さかた あきのり)

    株式会社富士通ソフトウェアテクノロジーズ Agile⁺開発センター
    ソフトウェア開発者、中小企業診断士(Registered Management Consultant)

    メインフレームOS、主にシステム資源最適化プログラムの開発に従事。
    その後、WEBアプリケーション開発業務に携わり、2002年からアジャイル開発を実践。
    アジャイルソフトウェア開発の品質管理、開発管理、組織マネジメントを中心に、約1,000の職場をコンサルティング。

   

テクノロジーコラム一覧

ページの先頭へ


後編 Subway Map to Agile Practices
後編 TOP
後編 NEW