実際、舞浜に行くとよくわかりますが、少し過剰とも思えるくらい安全寄りにしていると感じることがあります。「どれだけ楽しくても、ケガをしたら楽しくない」というのを避けたいわけですね。安全であることを価値観としたサービスを提供する、という方向性が定まっているのです。それがわかっているゲストからすれば、安心して家族を連れて行きやすいのです。安全ブランドが売上につながっているかもですね。良い、と解釈することができるかもしれません。選択肢があるわけです。安全に寄せてリスクを回避した安定した楽しさどちらも効率が良いかもしれませんが、人類が時間を戻して同じ状況を繰り返せない限り、どっちの効率が良いのか厳密な証明はできません。キャストは迷うかもしれません。方を選ぶ人もいるかもしれません。方を選ぶ人もいるかもしれません。SCSEだから「Bだな」とすぐに判断して、行動に移すことができます。何を大事にしたいのか?その辺が組織として明確で、大きな方向性があり、それが浸透しているから、キャストは判断しやすく行動しやすいと言えるでしょう。「開発の現場で何かチグハグなことが起きている」10年以上現場にいますから、さんざん見てきました。その多くが、SCSE的なことが決まって無いから...個々の判断で迷い、行動を躊躇し、バラバラな価値観で決断して、チームとして問題になる。...こないだ、マイクロマネジメントのブログを書きました。jfluteの日記マイクロマネジメントの反対であるマクロマネジメント、何を大事にしているのか?の伝達と言えるでしょう。価値観があっても浸透してなければ同じです。価値観がない、価値観が浸透してない、のであれば、個々の人は好き勝手に最適と予想するものを選ぶわけで、そこでマイクロマネジメントが発生してしまうと。...こないだ、デザインの一貫性のブログを書きました。チグハグなことになるでしょう。逆に、価値観がしっかり浸透していれば、皆で決めても一貫性は保たれるかもしれません。今回のブログの内容からすると、行動規範という言葉が印象に残りますね。...そういえば、行動規範的なブログも書いていましたね。答えやすい質問をするもっと技術寄りの話でも...さて、もっと技術に寄ってみましょう。コードはどういう風に書いていこう?「最適なものを選ぼう、最適にやっていこう」という風に人は軽く言いますが、何が最適なのか?わからないのです。人によって違うわけです。ある程度は話し合います。証明できないことを論理で導こうと思っても、いくら話し合ってもなかなか決着はつきません。そのサービス開発で何を大事にしたいのか?(どういう開発のやり方に価値があると思うのか?)結局はそこに立ち返って決めるしかありません。それが明確でないなら、それ自体を話し合う方が良いでしょう。早いリリースを優先するのか?少ないトラブルを優先するのか?開発ストレスの少なさを優先するのか?採用ブランドを優先するのか?サービスの長持ちを優先するのか?エンジニアの好みを優先するのか?チームワークを優先するのか?オフィス環境を優先するのか?明るい職場環境を優先するのか?会社全体、部署、プロジェクト、チーム、オフィス、働き方、ツール、コード、様々な粒度とレイヤに価値観があるはずです。何を大事にしたいのか?があれば、迷うことも減るでしょう。迷わなければ、行動が増えるでしょう。異世代タッグが引き寄せる“便利な未来”https://www.fastgrow.jp/articles/base-tsuruoka-fujikawaこちらの記事が印象的でした。それに対する、jfluteのツイートです:「流行り廃りに関係なく、自分たちがそのツールを盛り上げるんだ、って意気込みがすごい。流行り廃りに右往左往するよりも全然かっこいい。それを明確にするのもすごい助かるよね。自分たちがPHPを盛り上げていくことが、自分たちのサービスを支える力になると。いったやり方に価値を見出していると。いう姿勢も表明されていました。(素敵すぎる)仮にそれが最良な選択ではなくても、その選択をしっかり追求して活かすことで、それが最良になるとも言えます。要は...使いこなさない良いツールよりも、使いこなす次点のツールのほうが効率良いということ。最良で最良であれば完璧ですが、別に世界選手権で優勝をしたいわけではありません。それなりの最良であれば十分でもあります。最良で最良かどうかも証明できないわけですから、悩んでいるよりも早く追求した方が良いでしょう。いう風に明確にするというのは、プログラマーにとっては、勉強もしやすく、判断もしやすいはずです。それによる効果は、もともとの最良の選択を超えているかもしれません。勇気の要ることですよね、こういうことを表明するというのは。Scala採用を決めて3年半たった、CTOの振り返り。アーキテクチャ刷新を成し遂げるために必要なことhttp://creators-note.chatwork.com/entry/scala3.5yearもう一つ印象的な記事です。こちらはアーキテクチャの刷新で、思いっきり言語も変えようとしています。ところがとくに興味深いです。違う選択肢もあったでしょう。そもそも最初から刷新しないという選択肢、いまから断念して違う改善を目指す選択肢、でも、アーキテクチャ刷新を必死に選んでいます。ある種の価値観になっていると思います。どれが良かったのか?もはやわからないことでしょう。そのこと自体が組織のレベルアップにつながっているのではないだろうか?という想像もできます。本当にやり遂げれば、新しいアーキテクチャに対する愛着も大きいでしょう。それに対する勉強も積極的になり習熟度も上がるでしょうし、サービスとコードを大切に大切にすることでしょう。実際には既存コードをメンテしている方もいるので、価値観のバランスは難しいとは思いますが、もろもろのリスクがある分、追求することで得られるメリットは大きいでしょう。それを明確にしている分、プログラマーは判断と行動がしやすいでしょう。価値観の違い途中から価値観を定めた場合、その価値観にそぐわない人もいるでしょう。実際にはケースごとに例外的な選択もあるでしょうから、そぐわないからといってすぐに問題なわけではありませんが、あまりに極端にそぐわない場合は、組織を去るという結果になるかもしれません。荒野で発生した問題がきっかけで組織を去るよりも、明確な価値観の違いで去るほうが健康的かもしれません。価値観にそぐわない人が募集してこないこともあるでしょう。自然フィルターがかかっていると考えれば前向きです。世に表明することでミスマッチを未然に防げるかもしれません。価値観の議論もちろん、価値観を見直すこともあるでしょう。それは悪いことではないと思います。状況も変われば価値も変わることもありますし。一つ言えるのは...私たちは価値観の議論にもっと上手にならないといけない大きな価値観を持つために。新しい価値観を知ることにもなるから。価値観を定めても、なかなかすぐには浸透しません。みんな...教室に貼られていた標語を無視するのに慣れているはずです。価値観の解釈がブレることもあります。先のマイクロマネジメントのブログで紹介した、新入社員マニュアルを思い出すと、行動に関する補足がよく書かれています。これは解釈の補足とも言えるでしょう。そもそもマニュアルがあること自体が、すごい浸透マネジメントです。伝えること、実践すること、お手本を見せること、浸透のための様々な施策を考える必要があるでしょう。後から入ってきた人は大丈夫でしょうか?普段のコミュニケーションで、価値観を語ることはあるでしょうか?ちょっと暑苦しいと思うかもしれません。「暑苦しいなぁ」と思われるのもイヤですから、なので、話をする方も躊躇します。なんてこともよく発生します。継続的な浸透、つまり継承の仕組みが、しっかり確立されていないと、いつしか価値観は消えるでしょう。価値観の模索コードレビューで、白熱してるのを時々見ます。それぞれのケースが特殊なので、その事象ごとに独自の結果も必要になりますが、ただ、SCSEがあれば、不毛な白熱は防げるはずなのに...と思うことがしばしば。不毛な白熱の積み重ねがきっかけで、仲が悪くなり風通しが悪くなっていく...それはただの荒野だと。【追記】このようなブログも書きました:あなたの大切にしたい開発スタイルTOP5は?...一方で、しっかり価値観を実践している現場、そこではその通りの良い結果を生み出しています。厳密に最適な価値観かどうかはわかりません。なくてもいいわけです。迷わず判断と行動ができるというのは、それはスピードにもつながるでしょう。...どんなことに対して、どのくらいの粒度で、価値観を探せば良いのか?もっと意識して悩んでいきたいです。価値観を大事にしていきたいですね。5年間の理事(うち4年は理事長...2018-02-07デザインの一貫性と皆で決める納得感こちらの記事が印象的でした。DBFlute...2011-01-012011年の始まりさて、2011年になりました。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。