この記事はうるる Advent Calendar 2019の25日目（最終日）の記事です。
どーんと気合を入れて、さあいきましょう！わっしょい！
（最終日って何か締めくくるようなルールあるんでしょうか？）

はじめに

この記事は、これまで私が仕事で組織に関わる範囲について思考を巡らせた経緯の中で、
何かをクライテリアとして言語化しリスト化してきたものを一部アウトプットしてみると共に、
なぜこのような考え方をし始めたのか、
そしてこの考え方を用いてきたことでどのような変化が自分自身やチームにおいて起こってきたのか、
についてアウトプットした記事となっています。

ここに書いてあることが絶対ではないことを念頭にご覧ください。

なお、いいね！が多かったら一部しか公開していないリストをどこかに出してみようとも考えています。
興味がある方は是非押してみてくださると嬉しいです。

クライテリア思考とは

まず、クライテリア（criteria）とは、下記のような意味があります。
※weblio辞書から引用

①規範。尺度。判定基準。
②特徴。

ソフトウェア開発に関わる場面では、「受け入れ基準」みたいな意味合いで Acceptance Criteria と言っているのを聞いたことがあるはずです。

今回クライテリア思考という表現を用いていますが、自分自身が属する組織や組織にまつわる対象について、このクライテリアを通して見えないものを見えるようにする考え方をクライテリア思考と表現しています。

なぜこのようなクライテリアを用いるようになったか

私はこれまで組織について考えるようなマネジメントという仕事に責務を持つことが多くありました。
とてもたくさん失敗をしてきたと思いますし、モヤモヤを感じながら仕事をすることが多かったです。
この中で一番大きくモヤモヤを感じたことが、 自分が行った仕事の成果がわからないということでした。

組織について考えるような仕事をする前には、エンジニアとしてプログラムを書き、それによってできあがった成果物がハッキリと認識できる状況でした。
しかし、マネジメントという仕事に関わり出してから、何がうまくいっているのか/何がうまくいっていないのか、そしてこれらを何を見て判断したらいいのかがわからないという状況がありました。

このときに最初に知ったのが Joel on Software でした。
私はこの書籍の内容と考え方にとても深く共感をし、この考え方を用いて私自身やチームの状況を可視化していくことができないかといった考えを持つことになりました。

これまでに作ってきたクライテリア

こういった考え方を知ってから、私自身が関わる仕事においていくつかのクライテリアを用いたリストを作ってみることにしました。
ここでは大きく3つ、それぞれ一部ですが紹介をすることとします。

エンジニアのテクニカルスキル定義

これは、新卒で入社してきたエンジニアと会話していて「何ができるようになればいいかわからない」という発言が出てきたときの気付きから作ってみたものです。
普段の仕事の場面や業務内容から、どのような軸でできる/できないを考えるとよいのかを言語化しています。
なお、全体的な内容は Web Developer Roadmap を軸にしていますが、細かいところはお察しの通り雑な箇所も残っており、今後のブラッシュアップが必要です。

スクラム開発のPOロールにおける仕事定義

これは、私がスクラム開発におけるプロダクトオーナー（PO）の仕事のサポートをしていこうと考えたときに、POが行っている/行うべき仕事についてふわふわとして理解しか無かったために一度言語化してみることから始めたことがきっかけになっています。
厳密なスクラム開発の世界で言うとズレた内容も含まれてしまっていると思いますが、スクラムにおけるPOはスクラムチームという組織と会社組織という2つ以上の組織における役割を果たす必要があるので、それらを包含した内容を定義してみています。
なお、社内のメンバーから既に「使っている言葉がわかりにくい」といった指摘があるのでこちらも今後のブラッシュアップが必要です。

社内版ジョエル・テスト

これは、社内の経営者にプレゼンをする機会があったときに策定したものになります。
弊社では 「テックのうるるを実現したい」 という想いが代表から述べられたことがあります。
一方、代表と直々に「これを実現するために何をしたらいいかわからない。教えて欲しい」という会話をしたことがありました。
確かに代表はエンジニア畑の出身ではないため、 どういったポイントをどのようにしていくことでテクノロジーが事業成果に貢献できている状態（テックのうるる）ができるのかといったイメージが浮かびにくいのは仕方のない状態でした。
そこで私が思い出したのが Joel on Software の内容でした。
この本に書かれているジョエル・テストを、現代のソフトウェア開発トレンドに合わせ、さらに幾つかの視点から掘り下げたものを作ったのが以下のもの（一部）です。

なお、このリストについては具体的なリスト内容はお出しできないのが申し訳ないのですが、どういった軸で項目を出していったのかについては簡単ですが記載をしておきます。

• 観点
  • プロダクト開発文化
  • 技術文化
  • 組織文化
• 分類
  • 開発スタイル
  • 仕事上の関係性
  • 裁量と目的
  • UI/UX デザインフロー
  • データドリブン
  • コードレビュー
  • 開発環境
  • テスト
  • パフォーマンス
  • 技術的負債への対応
  • 学習および教育
  • などなど

クライテリアによって起こった変化

こういった形で幾つかの分野に対してリスト化したものをクライテリアとして用意をしていったのですが、正直なところこれで何かが劇的に変わるような感覚はありません。
ソフトウェア開発に銀の弾丸がないように、これも銀の弾丸にはなりえませんでした。

しかし、1つ確かな感覚として得ることができたものがあります。
それは 認識を揃える材料として大きな働きをしてくれる ことです。

組織の話になると抽象的な話が増えたり、組織に属するメンバーそれぞれの感覚からいつの間にか認識がズレていることが往々にして存在します。
人間は事実を基にして会話しているはずなのにいつの間にか感覚的にそれぞれの認識から会話を始めることがあるようなので、会話のベース/前提を確実に揃えておくことが大事です。
その点、これまで述べてきたようなクライテリアを用いた結果をベースにすると、現時点での自分たちの実態が明文化され、かつクライテリアによる判断結果も明確化されるため、会話が簡単に揃っていくようになりました。

事実と認識には大きな違いがあることを理解した上で、有意義な思考をしていきたいと思っている、もしくはそうしていきたいけど何かうまく進まなくて困っている、という方々にはクライテリア思考を用いてみることを強くオススメします。

まとめ

組織や人という不確実性の高いものに向き合うときには、不確実なものの不確実性をいかに減らせるかを考えることがとても大切です。
そしてそのための1つの方法としてクライテリア思考を用いてみてください。

あとがき

本当はそれぞれのクライテリア毎に、それを用いたことで具体的に変化が起こったことを記載してみたいと思いましたが、分量の都合から今回は見送りをしています。
そのうち、別記事にて公開をしていくことを考えています。
気になる方は、いいね！してみてください。

また、お知らせとして、今回のクライテリア思考といった考え方と同じようなアプローチで「日本の企業経営に先端のテクノロジーを」というミッションを掲げる日本CTO協会がDX Criteriaを公開しています。
是非みなさんの会社で取り組んでみてください。
今回はこの公開の波に乗ってクライテリアという言葉を使わせて頂いたという、ズルい感じを残して締めたいと思います。

今回でうるる Advent Calendar 2019も最後となりました。
ここまで一緒に記事を書いてきてくれた仲間たちと一緒にお祭り気分を味わえてとても素敵な気分です。
それではまた来年お会いしましょう！