まえおき
サービス開発の現場を想定していますが、どの組織でも応用できる話だと思います。
大きな価値観の不足
組織の中で、個人個人が...
「どう行動すれば良いのか？」
「A と B, どちらを選べば良いのか？」
というように迷う場面が多々あるかと思います。もちろん、それぞれの個人が、最大限の努力で最適な選択を探して判断します。
ですが、わたしたちは完璧に物事を知っているわけではありません。
何が良いのか証明できないことがある
のです。
「こうすればいいのかな？うーん...」
「Aとも言えないし、Bとも言えないし...」
ある程度は論理で「これだ！」と言えることもありますが、(最大限の努力はするべきですが) 限界もあります。
でも判断しないといけないので、経験や推測に頼ったり、場合によっては好みも影響したり、ときに思惑も影響することがあるでしょう。
多くの現場が抱える...
o 組織やチームの問題
o ツール選択の議論の問題
o コード品質の問題
世の中には様々な問題がありますが、その多くの原因の一つが、
大きな価値観が定まっていない
ことから来ていると感じることが多くなりました。
SCSE (えすしーえすいー)
SCSE, もはや有名な言葉なので、ここで自分が説明するのもなんですが...
東京ディズニーリゾートを運営する、オリエンタルランド社の行動規準です。
=> 【公式】行動規準「The Four Keys〜4つの鍵〜」
様々なビジネス書でも話題にされています。
判断の優先順位が定義されています。
S: Safety, 安全
C: Courtesy, 礼儀正しさ
S: Show, ショー
E: Efficiency, 効率
何かイレギュラーな事態が発生したとき、キャストにアドリブ的な行動が求められます。そのときの判断の軸として、SCSEがあります。
A. 多少ゲストが危険でも、
ゲストも運営も互いに効率良い(楽しい)
B. ゲストも運営も少し面倒で我慢もあるけど、
確実にゲストは安全
さあ、どちらを取る？
SCSE からしたら "B" になるわけです。「多少なら別に...」ではなく "B" なのです。
実際、舞浜に行くとよくわかりますが、少し過剰とも思えるくらい安全寄りにしていると感じることがあります。
「どれだけ楽しくても、ケガをしたら楽しくない」
というのを避けたいわけですね。安全であることを価値観としたサービスを提供する、という方向性が定まっているのです。
そして、それがわかっているゲストからすれば、安心して家族を連れて行きやすいのです。安全ブランドが売上につながっているかもですね。
...
ちょっと言葉遊びっぽくなりますが、結果的に安全寄りにする方が "効率" が良い、と解釈することができるかもしれません。
つまり、"効率が良い" に選択肢があるわけです。
A. 少し危険に目をつぶった手っ取り早い楽しさ
B. 安全に寄せてリスクを回避した安定した楽しさ
どちらも効率が良いかもしれませんが、人類が時間を戻して同じ状況を繰り返せない限り、どっちの効率が良いのか厳密な証明はできません。なので、キャストは迷うかもしれません。
もし、SCSEがなければ、"A" の方を選ぶ人もいるかもしれません。
もし、ESCSだったら、"A" の方を選ぶ人もいるかもしれません。
でも、SCSEだから「Bだな」とすぐに判断して、行動に移すことができます。
o どんな価値観を持っているのか？
o 何を大事にしたいのか？
その辺が組織として明確で、大きな方向性があり、それが浸透しているから、キャストは判断しやすく行動しやすいと言えるでしょう。
ほとんどの問題の大元
「開発の現場で何かチグハグなことが起きている」10年以上現場にいますから、さんざん見てきました。
その多くが、SCSE的なことが決まって無いから...
個々の判断で迷い、行動を躊躇し、バラバラな価値観で決断して、チームとして問題になる。
...
こないだ、マイクロマネジメントのブログを書きました。
=> 誰もマイクロマネジメントしたいわけではないだろう | jfluteの日記
マイクロマネジメントの反対であるマクロマネジメント、何を大事にしているのか？の伝達と言えるでしょう。価値観があっても浸透してなければ同じです。
価値観がない、価値観が浸透してない、のであれば、個々の人は好き勝手に最適と予想するものを選ぶわけで、そこでマイクロマネジメントが発生してしまうと。
...
こないだ、デザインの一貫性のブログを書きました。
=> デザインの一貫性と皆で決める納得感 | jfluteの日記
少し話の趣旨は違いますが、「何を大事にしたいのか？」が曖昧であればあるほど、"皆で決める" はチグハグなことになるでしょう。逆に、価値観がしっかり浸透していれば、皆で決めても一貫性は保たれるかもしれません。
...
ちなみに、こちらは教育面で考えさせられた記事ですが...
// 仕事に必要なのはモチベーションではなく、プロ意識である
http://blog.tinect.jp/?p=14310
> プロとしてのあるべき姿・規律などの行動規範
今回のブログの内容からすると、行動規範という言葉が印象に残りますね。
...
そういえば、行動規範的なブログも書いていましたね。
=> 任せられるディベロッパー、七つの姿勢 | jfluteの日記
o その一: 自分の道具は使いこなす
o その二: 三割でも仕組みに突っ込む
o その三: 三割でもビジネスに突っ込む
o その四: 全体を把握しようとする
o その五: ベストタイミングほうれん草
o その六: 隣の人を助ける
o その七: 答えやすい質問をする
もっと技術寄りの話でも...
さて、もっと技術に寄ってみましょう。
o なんのプログラミング言語を使おう？
o なんのフレームワークを選ぼう？
o このツールをどういう風に使おう？
o コードはどういう風に書いていこう？
「最適なものを選ぼう、最適にやっていこう」
という風に人は軽く言いますが、何が最適なのか？わからないのです。もしくは、人によって違うわけです。
ある程度は話し合います。ただ、証明できないことを論理で導こうと思っても、いくら話し合ってもなかなか決着はつきません。
そのサービス開発で何を大事にしたいのか？(どういう開発のやり方に価値があると思うのか？)
結局はそこに立ち返って決めるしかありません。もし、それが明確でないなら、それ自体を話し合う方が良いでしょう。
早いリリースを優先するのか？
少ないトラブルを優先するのか？
開発ストレスの少なさを優先するのか？
採用ブランドを優先するのか？
サービスの長持ちを優先するのか？
エンジニアの好みを優先するのか？
チームワークを優先するのか？
オフィス環境を優先するのか？
明るい職場環境を優先するのか？
会社全体、部署、プロジェクト、チーム、オフィス、働き方、ツール、コード、様々な粒度とレイヤに価値観があるはずです。
もちろんケースバイケースもありますが、大きなところで、
何を大事にしたいのか？
があれば、迷うことも減るでしょう。迷わなければ、行動が増えるでしょう。
明確にする勇気
// 「価値の交換をシンプルに」BASE鶴岡と藤川の
// 異世代タッグが引き寄せる“便利な未来”
https://www.fastgrow.jp/articles/base-tsuruoka-fujikawa
こちらの記事が印象的でした。
それに対する、jfluteのツイートです:
「流行り廃りに関係なく、自分たちがそのツールを盛り上げるんだ、って意気込みがすごい。流行り廃りに右往左往するよりも全然かっこいい。それを明確にするのもすごい助かるよね。」
自分たちがPHPを盛り上げていくことが、自分たちのサービスを支える力になると。そういったやり方に価値を見出していると。
別のスライドであったのですが、"オープンソースでの貢献を増やし..." という姿勢も表明されていました。(素敵すぎる)
仮にそれが最良な選択ではなくても、その選択をしっかり追求して活かすことで、それが最良になるとも言えます。
要は...
使いこなさない良いツールよりも、使いこなす次点のツールのほうが効率良い
ということ。
もちろん、最良で最良であれば完璧ですが、別に世界選手権で優勝をしたいわけではありません。それなりの最良であれば十分でもあります。最良で最良かどうかも証明できないわけですから、悩んでいるよりも早く追求した方が良いでしょう。
そして、こういう風に明確にするというのは、プログラマーにとっては、勉強もしやすく、判断もしやすいはずです。それによる効果は、もともとの最良の選択を超えているかもしれません。
でも、勇気の要ることですよね、こういうことを表明するというのは。
追求する勇気
// Scala採用を決めて3年半たった、CTOの振り返り。
// アーキテクチャ刷新を成し遂げるために必要なこと
http://creators-note.chatwork.com/entry/scala3.5year
もう一つ印象的な記事です。こちらはアーキテクチャの刷新で、思いっきり言語も変えようとしています。
"あきらめない心" のところがとくに興味深いです。
もちろん違う選択肢もあったでしょう。そもそも最初から刷新しないという選択肢、いまから断念して違う改善を目指す選択肢、
でも、アーキテクチャ刷新を必死に選んでいます。"あきらめずにやり遂げること" が、ある種の価値観になっていると思います。
どれが良かったのか？もはやわからないことでしょう。ただ、"やり遂げようと一丸となっていること" そのこと自体が組織のレベルアップにつながっているのではないだろうか？という想像もできます。
本当にやり遂げれば、新しいアーキテクチャに対する愛着も大きいでしょう。それに対する勉強も積極的になり習熟度も上がるでしょうし、サービスとコードを大切に大切にすることでしょう。
実際には既存コードをメンテしている方もいるので、価値観のバランスは難しいとは思いますが、もろもろのリスクがある分、追求することで得られるメリットは大きいでしょう。
それを明確にしている分、プログラマーは判断と行動がしやすいでしょう。
価値観の違い
途中から価値観を定めた場合、その価値観にそぐわない人もいるでしょう。
実際にはケースごとに例外的な選択もあるでしょうから、そぐわないからといってすぐに問題なわけではありませんが、あまりに極端にそぐわない場合は、組織を去るという結果になるかもしれません。
でも、荒野で発生した問題がきっかけで組織を去るよりも、明確な価値観の違いで去るほうが健康的かもしれません。
価値観にそぐわない人が募集してこないこともあるでしょう。自然フィルターがかかっていると考えれば前向きです。世に表明することでミスマッチを未然に防げるかもしれません。
価値観の議論
もちろん、価値観を見直すこともあるでしょう。それは悪いことではないと思います。状況も変われば価値も変わることもありますし。
ただ一つ言えるのは...
私たちは価値観の議論にもっと上手にならないといけない
大きな価値観を持つために。
違う価値観を受け入れることにもつながるし、
新しい価値観を知ることにもなるから。
価値観の浸透
価値観を定めても、なかなかすぐには浸透しません。
みんな...
教室に貼られていた標語を無視するのに慣れているはず
です。
また、価値観の解釈がブレることもあります。先のマイクロマネジメントのブログで紹介した、新入社員マニュアルを思い出すと、行動に関する補足がよく書かれています。これは解釈の補足とも言えるでしょう。
そもそもマニュアルがあること自体が、すごい浸透マネジメントです。
伝えること、実践すること、お手本を見せること、浸透のための様々な施策を考える必要があるでしょう。
価値観の継承
後から入ってきた人は大丈夫でしょうか？
普段のコミュニケーションで、価値観を語ることはあるでしょうか？ちょっと暑苦しいと思うかもしれません。
「暑苦しいなぁ」
と思われるのもイヤですから、なので、話をする方も躊躇します。
なので、意外に新しく入ってきた人が、"全然その価値観を知らない" なんてこともよく発生します。
継続的な浸透、つまり継承の仕組みが、しっかり確立されていないと、いつしか価値観は消えるでしょう。
価値観の模索
コードレビューで、白熱してるのを時々見ます。白熱にも "良い白熱" と "不毛な白熱" があります。
もちろん、それぞれのケースが特殊なので、その事象ごとに独自の結果も必要になりますが、ただ、SCSEがあれば、不毛な白熱は防げるはずなのに...と思うことがしばしば。
不毛な白熱の積み重ねがきっかけで、仲が悪くなり風通しが悪くなっていく...
それはただの荒野だと。
【追記】このようなブログも書きました:
あなたの大切にしたい開発スタイルTOP5は？
...
一方で、しっかり価値観を実践している現場、そこではその通りの良い結果を生み出しています。
厳密に最適な価値観かどうかはわかりません。別に "最" じゃなくてもいいわけです。
迷わず判断と行動ができるというのは、それはスピードにもつながるでしょう。
...
どんなことに対して、どのくらいの粒度で、価値観を探せば良いのか？もっと意識して悩んでいきたいです。
「何を大事にしたいのか？」
価値観を大事にしていきたいですね。
...
...
...
