技術広報と技術ブランディングの違い。そして、それを行う意味
こんにちは@techfavoです。最近、技術広報ということ役職を置く企業が増えていると思います。この職種を置く企業が増えている理由としては、個人的には主に下記が影響しているのかと考えています。
一応、考えの根拠になりそうなところも紹介しておきます。日本におけるエンジニア不足は周知の事実だと思いますが、2030年には45万人の人材が不足するそうです。
－ IT 人材需給に関する調査 －
https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf
また、最近はクラウドや情報発信のオープン化により、技術スタックが似ている企業が多くなっていると思います。
そうなると技術による差別化が難しくなり（実際はそんなこともないとは思いますが）、第三者から見るとどこの企業に行っても同じ、ということになってしまします。こういったコモディティ化が起こると、マーケティングの原則が当てはまり、自然独占の法則で大手に人が集まっていく図式になると思います。
また、エンジニアの過半数が1〜3回ほど転職をするそうですが、転職の主な理由が「給与」とのことなので、これからますます給与が高い大手への転職を目指す人が増えると思います。
結果として、一部の大手以外どの企業もエンジニアが不足するので、どの企業もエンジニア採用に力を入れるのに、専門的な技術のことを広報する役職が必要になってきたのだと思われます。
こういった背景を踏まえて、技術広報の役割としては下記が考えられます。
- 社内の技術力を広める & 発信の文化を作る
- 業界へ知識を還元する
- 社内のエンジニアにスポットライトを当ててエンゲージメントを高める（組織力の強化）
- エンジニア採用に貢献する
前述したIT業界の現状から一番の目的というか、技術広報の成果として求められている根底は採用が考えられると思います。
とはいえ実際に業務を行ってみると「技術力を広報をするだけで採用という問題を解決できるのか？」という考えに至ります。そこで、年末から年始にかけて採用やブランディングの本を読み漁っており、その中で自分なりに技術ブランディングが良さそうという解釈が出てきたのでブログにしています。
技術広報と技術ブランディングの業務の定義
まず初めに両職種の業務の定義を考えてみます。あくまで個人的な定義なのでお気をつけください。
広報は「PRのピラミッド」にあるようにパブリシティ（宣伝・報道）→ パーセプションチェンジ（認識の変化）→ ビヘイビアチェンジ（行動変化）を行うのが主な業務だと思われます。
広報を技術広報に特化するとパブリシティはブログ、勉強会、カンファレンスなどで自社の技術力をアピールすることだと思います。それで、その発信した情報に触れた人が「この企業はRustを使っているんだ」とか「この企業は技術力が高い」という認識が起こり、転職なり勉強会への参加なり何かしらの行動へと変化させるのが目標になると思います。こちらは社内の情報を拾ったり、社員にお願いしたりすることで少人数のチームでも動きやすい職種になると思います。
ブランディングというのは、その企業や商品に愛着(ブランドロイヤルティ)を持ってもらえるようブランドネームの浸透、わかりやすいコンセプトの策定、差別化のためのポジショニングなどを行なって行くことかと思います。
技術広報同様に技術ブランディングとして考えると、界隈で所属企業の名前を浸透させたり、エンジニア文化を明文化したり、ブログやイベントで伝えたいメッセージを書いたりして「この企業の情報はすごい」とか「この企業なら転職しても間違いない」とか、プラスの要員も思っていただけるようにすることかと思います。ブランディングは外部からのイメージに起因するものなので、外部の人にどう伝わっているのか、どう思われているのかを考えるのが重要な業務になると思います。こちらは経営者の考えを理解し、さまざまメッセージを社員や外部の方一人ひとりに浸透してもらう必要があるので、人手が必要になるかもしれません。
まとめると、技術広報はこちらから情報を投げて行動を変えてもらう、技術ブランディングは人々にどう思われているかをプラスの方向にしていくことだと思います。
技術広報と技術ブランディングの役割の違い
この2つの業務ですが、最終的なゴールは「転職時に自社を想起してもらえること」だと思います。転職を検討した際に最初に検討してもらえることをここでは第一想起と呼ぶことにしますが、この最初に想起してもらえることがエンジニア転職市場ではとてつもなく重要だと思っています。なぜなら、約45%のエンジニアが1社目の応募で転職を終えてしまうからです。
IT業界だと1社目に応募して転職を終えてしまう割合が異常に高いのですが、これはIT業界ではリファラル採用が多いというのが少なからず影響しているかと思います。
こういった事情から転職者から第一想起として認識されないと、採用に結びつけるのが難しいのがエンジニア採用です。
ここで最初の疑問に戻りたいと思いますが、技術力の高さを広報としてアピールするだけで、この第一想起になることは可能なのでしょうか？ 技術力に圧倒的な優位性がある企業であれば可能だと思いますが、技術力だけで第一想起になれるのはせいぜい2〜3社だと思います。なので、多くの企業にとっては第一想起になるには技術ブランディングをしてロイヤリティを高めるのが重要なのではないでしょうか？
このように書くと、技術広報は無駄のように感じてしまいますが、もちろんそうではなく、技術広報と技術ブランディングでは担当する領域が異なるのだと思います。当然ながらブランドのロイヤリティというのは、よくしっているものに対して感じるものです。一般的に未知の領域のものをブランディングをしていくのは難しいので、人々の認識を認知の領域へ持っていくのは技術広報の役割だと思います。
どうやって技術をブランディングするのか
（長くなるので技術広報に関しての説明を省きます）
技術ブランディングをするとして、一般的なブランディング手法同様にポジションによる差別化をするのが常套手段だと思いますが、今はどの企業も技術力が格段に上がっているので、ブログやイベントをただするだけだと差別化するのは難しいと思います。
では、どうやってブランディングをすればよいのか？ という点ですが、『組織力強化プロセスとしての 企業ブランディングとその効果』という論文にブランディング活動の共通ステップが紹介されているので引用します。
https://www.jstage.jst.go.jp/article/marketing/36/1/36_2016.026/_pdf/-char/ja
上記のステップを一つずつ検討していきたいと思います。
1. ブランド理念の明確化
ブランド理念の明確化は、理念を明確化できるように自社分析をすることです。CTO、テックリード、現場のエンジニアにインタビューすることで立場の違う意見が聞けるので良いと思います。個人的にはそのインタビューは記事にして公開すると、技術広報としての役割も担えるので一石二鳥ですね。
2. ターゲット顧客と提供価値の設定
ターゲット顧客と提供価値の設定は、自分たちが何を提供できるのかを考えるステップです。顧客(求職者)が期待していること、自社が貢献できることを踏まえて、価値の設定をします。ここは自社の開発体制やカルチャーのお話になるのかと思います。
3. 競合比較
競合比較では、競合と比較することで差別化を図るステップになります。ここでいわゆるポジショニング戦略を立てるわけです。競合はサービスの競合とは他に、似たようなエンジニア組織の企業を競合比較で考える手もあります。
4.ブランド・アイデンティティの策定
ブランド・アイデンティティの策定では、今までのプロセスから適したフレーズやポジショニングを選ぶステップです。例をあげるとゆめみさんが非常に素晴らしいブランディングをされていると思うのですが『ゆめみは成長環境しか提供できません』と明言しており、エンジニアが求めている「自身の成長可能性」というニーズ、ポジショニングを抑えているのかなと思います（違ったらごめんなさい）。
5. ブランディングの実践ガイドライン策定
ブランディングの実践ガイドライン策定については、どうやって実践していくかについてのガイドラインを作る事ですね。こちらはIT業界に関わらずさまざまな企業のガイドラインを見てみるといいと思います。
6.コミュニケーション発信(社内向け・社外向け)
コミュニケーション発信(社内向け・社外向け)については、技術広報としての専門分野だと思いますので、上記のブランディング戦略を今までの広報にプラスして組み込んでいくのが良さそうです。
終わりに
いかがだったでしょうか？
対社外の話しばかりしてきましたが、ブランディングは会社の理念を社内に浸透させるため、組織力を強化する役割もあるそうです。一般的なブランディング手法が技術の分野で同じように活かせるかは不明瞭ですが、試してみる価値はありそうです。
技術カンファレンスへ多くスポンサーをした起業ランキング2022
こんにちは@techfavoです。
先日、同業他社の人から下記の話を聞きました。
「カンファレンスで一番高いプランのスポンサーをしたら、それを見たエンジニアの方が応募してきてくれたんです」
上記の話の詳細は省きますが「見ている人は見ているんだな」と言うのがその時の印象で、今年の技術カンファレンスのスポンサー企業の様子が少し気になりました。お金を出した企業が偉いというわけではありませんが、2022年の振り返りとしてスポンサープランのカウントをしてみました。よろしければご確認ください。
カウント方法
カウントした技術カンファレンスは下記を参考にしました。言語被りの技術カンファレンスは申し訳ないのですが一旦抜かさせていただきます。またFlutterKaigiやiOSDC japanなどの規模が大きい技術カンファレンスは追加させていただいています。
カウント方法としては、一番下のスポンサープランを1点とし、プランが上がるたびに1点加算します。例をあげると以下のような形です。
- ダイヤモンドプラン：4点
- プラチナプラン：3点
- ゴールドプラン：2点
- シルバープラン：1点
プランの差の価値が単純に4倍ということはないのですが、便宜上このようにしています。なので、かなりガバなランキングです。
またロゴスポンサーやwifiスポンサーなどの特殊スポンサーもどこにカウントするか不明なので、今回はカウントしていません。
スポンサープランが掲載されていない技術カンファレンスも除きました。
それではランキングどうぞ。
スポンサープラン起業ランキング2022
1位：23点 株式会社ゆめみ
2位：19点 株式会社ディー・エヌ・エー
3位：15点
New Relic株式会社
STORES 株式会社
5位：14点
株式会社ココナラ
株式会社メルカリ
メドピア株式会社
LINE株式会社
9位：13点
ウォンテッドリー株式会社
株式会社サイバーエージェント
株式会社MIXI
サイボウズ株式会社
13位：12点
エムスリー株式会社
株式会社スリーシェイク
ヤフー株式会社
16位：10点
株式会社はてな
株式会社カオナビ
日本マイクロソフト株式会社
Rakuten Group, Inc.
19位：9点
株式会社アンドパッド
note株式会社
ランキング詳細
1位は皆さん予想されていたのではないでしょうか？ 総点数23点のゆめみさんです。2位はディー・エヌ・エーさんで、最多の9つの技術カンファレンスにスポンサーをしていました。
参加されたスポンサーは下記の通りです。
1位：株式会社ゆめみ
- Developers Summit 2022
- 技育祭 2022 春
- PHPerKaigi 2022
- DroidKaigi 2022
- Vue Fes Japan Online 2022
- FlutterKaigi 2022
- iOSDC Japan 2022
2位：株式会社ディー・エヌ・エー
- YAPC::Japan::Online 2022
- 技育祭 2022 春
- Go Conference 2022 Spring
- SRE NEXT 2022 ONLINE
- ISUCON12
- RubyKaigi 2022
- DroidKaigi 2022
- FlutterKaigi 2022
- iOSDC Japan 2022
3位：New Relic株式会社
- Developers Summit 2022
- Observability Conference 2022
- Day One - CTO/VPoE Conference 2022 Spring
- Cloud Operator Days Tokyo 2022
- ISUCON12
4位：STORES 株式会社
- Go Conference 2022 Spring
- SRE NEXT 2022 ONLINE
- ISUCON12
- RubyKaigi 2022
- Vue Fes Japan Online 2022
- iOSDC Japan 2022
その他の詳細はこちらからご確認ください。
protective-sweatshirt-2a0.notion.site
はじめてのコムウェイの法則と逆コムウェイの法則
だいぶ前になってしまいましたが、9月30日にFindyさんが開催してくださった『【エムスリー×MonotaRO】急成長メガベンチャーのエンジニア組織づくり最前線』というイベントに参加していました。
その中でふと話にでてきたのが『コムウェイの法則』でした。今回のイベントでは特に主題ではなかったので「コムウェイの法則を知らない人はググってください」と、いった形で終わってしまったのですが、個人的には気になったので調べてみました。
## コムウェイの法則とは
コムウェイの法則とは、1968年にメルヴィン・コンウェイという人が『Datamation』という雑誌に発表した論文で紹介された経験則の法則です。その内容は以下の通りです。
「システム（ここでは単なる情報システムよりも広く定義されたシステム）を設計する組織は、必ずその組織のコミュニケーション構造を倣った構造を持つ設計を生み出す」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
論文の原文はこちらにあります。
具体的な例を用いた言い方をすると「密結合組織の場合は、システムも自然に密結合に（モジュール性が低く）なる」という感じです。図にすると下記のようなものになると思われます。
なぜこのようなことが起こるのかというと、密結合された大きい組織でシステムを開発すると、誰が何の機能を開発しているのかがわかりにくく、多くの人たちに役割が割り振られます。そうするとたくさんの機能に触れることになるので、マイクロサービス化する意識が生まれず、モジュール性の低いシステムができあがるそうです。
反対に疎結合組織の場合（ちなみに、疎結合とは細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことです）は、小さなチームが独立して、それぞれのチームが担当するサービスを開発していきます。こうすることによって意思決定が早く勧められるうえ、モジュール性の高いシステムを作ることができるようです。
## コムウェイの法則の何が重要なのか？
上記のように組織のコミュニケーション構造が、システムのアーキテクチャーにまで影響するというのがコムウェイの法則です。しかし、この法則の何が重要なのでしょうか？
現在のソフトウェア業界ではサービスのリリース速度は他社との差別化をはかるうえでとても大切です。しかし、密結合の大きい組織で巨大なモノリシックなコードを相手にしていると、依存関係のエラーが起こってしまったり、活躍できない人材がでてきてしまったりするなどでリリース速度が落ちてしまいます。
疎結合の組織でモジュール性が高いシステムの場合、チームが開発のライフサイクルを管理し、スコープの調整やデブロイ速度の向上などができるので、結果的にリリース速度を早めることが可能となります。
この疎結合組織として有名なのがAmazonです。Amazonでは『ピザ2枚ルール』というルールがあり、これはピザ2枚で足りないような人数のチームを作らないというルールです。
このようにシステム改善を行うのにアーキテクチャーばかりを見るだけでなく、組織の状況をよく調べることが重要という理解につながることがコンウェイの法則の重要な点のようです。組織は大きくなるほど、システムの柔軟性が低下し、リリース速度が遅くなるので、コンウェイの法則を意識することが重要になるとのことです。
コンウェイの法則の付き合い方として、Youtube動画で良いまとめがありましたので、こちらに引用いたします。
- コードがすべてではない（It’s not all about the code!）
- 小さなチームは大きなことができる（Small teams can do big things.）
- フルスタックのチームはアーキテクチャーの柔軟性をキープする（Full Stack teams keeps your architecture flexible.）
- コムウェイの法則と戦わず、一緒に働く意識を持つ（Don’t fight Conway’s Law, work with it.）
## 逆コンウェイの法則
上記のようなことから、アーキテクチャーをマイクロサービス化し、システムを改善していくには、組織を疎結合組織にし、まずは組織を変えていくことが勧められています。近年では「アーキテクチャーが組織を変えることができるのではないか」という、別の見方もでてきました。まずアーキテクチャーを改善し、その後、プロダクトにそって組織を改善することを逆コンウェイの法則と言うそうです。
図にすると、矢印を逆にするだけなので、こんな感じですね。
少し調べただけなので、間違った認識のところもあるかと思いますが、参考にしたのは下記の書籍です。今度第2版がでるそうですね。
参考：
マイクロサービスアーキテクチャ
参考にした動画
「コンウェイの法則を忘れないでください」 - サラ・ノボトニー基調講演
なぜ締め切りは意味がないのか？ そして代わりにすべきこと
技術広報をしているとテックブログに携わることが多いと思いますが、記事の管理のために締め切りを設けている方も多いと思います。最近、この「締め切り」というものの必要性に違和感をもっていたところ、海外で参考になりそうな記事がありましたので、簡単に翻訳してご紹介します。
元の記事はこちらでコピーレフトです。
なぜ締め切りは意味がないのか？ そして代わりにすべきこと
締め切りはソフトウェアエンジニアにとって悩みの種です。2週間後に納期が迫っているのに全然終わらない……。なので、徹夜したり、いい加減なテストをしたり、手抜きをしたりして何とかやり遂げようとします。すると何が起こるのでしょうか？ プロジェクトはバグだらけになり、顧客は不満を抱き、エンジニアたちは疲れ果ててしまいます。
時にはバグが多すぎてソフトウェアエンジニアリングの基準に達していないこともあります。そのような場合、マネージャーは新しい期限を設定し、最初の期限はそもそも存在すべきではなかったことを明らかにします。さて、想像してみてください。2回目の締め切りを逃したらどうなると思いますか？ その通り、新しい締め切りが設定されるのです。締め切りが好きでしょう？
そろそろ「締め切り」を「プレッシャー」という本当の名前で呼ぶべきです。
締め切りがあるからといって、エンジニアのコーディングが速くなるわけではありません。ただ、労働時間が長くなるだけです。機能不全に陥っていないチームの場合は、締め切りの役割として、実装する機能の範囲を決められ、クライアントへ納品するための強制機能となり、早くクライアントへ納品でき早くフィードバックに対応することができます。
この記事では、なぜ締め切りがよくないことにも関わらず必要とされているのか、そして締め切りが生産性やモラル、ソフトウェアの品質にどのような害を及ぼすのかを説明します。
そして、より生産的でストレスの少ない代替案として「プリエンプションポイント」を提案します。プリエンプションポイントとは何か、なぜそれが有効なのか、そして締め切りと比較した場合の利点について説明します。
また、プリエンプションポイントについて説明した後、そのポイントの取出しポリシーがどのように価値を早期に提供し、締め切りを無意味なものにするかについても解説します。
この記事の最後には、チームを説得して締め切りを捨てさせ、これまで締め切りが役に立つと思っていた人たちを含め、すべての人がより快適に仕事ができるようにするためのちょっとしたまとめがあります。
なぜ締め切りは無意味なのか
締め切りの無意味さの根底にあるのは「結果をコントロールできない」という事実です。あなたがコントロールできるのはその結果を生み出すプロセスだけです。
たとえば今日からトレーニングを始めて、明日にハーフマラソンに出場することはできません。しかし、走る距離をコンスタントに増やしていくシステムを作ることはできます。
ベッドから出たくない日もあるでしょう。そのような日は、あまり走らないようにします。また、朝起きてから命がけで走る日もあるでしょう。バラツキがあるのです。それでも毎週コンスタントに走る距離を向上していけば、いずれマラソンを走れるようになります。
安定したペースで上達すれば、来年のマラソンを走れるかどうかの見通しがつくかもしれません。それまではどんな期限も無知な推測に過ぎないのです。
確かに、マラソンの時期がわかれば、その日に走れるように炭水化物の摂取量を調整したり、トレーニング方法を微調整したりすることができます。しかし、あなたが常に向上心を持ち、マラソン大会のかなり前の時期に走ることができなければ、期限を設定することは怪我やオーバートレーニングの元です。マラソンが開催させる日に走ることができない場合、参加することもできないのです。
長期的な目標には、一貫した短期行動と予測可能なパフォーマンスの向上が必要であり、無謀な一押しは必要ないのです。
また、締め切りは無意味であることに加え、次のような弊害もあります。
- 締め切りはチームのパフォーマンスを向上させません。締め切り目標を設定しても、納品が早くなるわけではありません。結果として、チームは実装する機能を減らすか、より長く働くようになります。
- 締め切りはインセンティブをずらし長期的な思考を妨げます。締め切りは長期的に予測可能で持続可能なパフォーマンスではなく、期限を守るために短期的な利益を優先させるインセンティブをチームに与えます。
- 締め切りは実行可能なものではありません。チームが期限に間に合わなかったとき、その後に生産的なことをするには遅すぎるのです。
それぞれのステートメントについてより詳しく説明します。
締め切りはパフォーマンスを向上させない
コンピュータの性能を上げるために「もっと頑張れ」「もっと危機感を持て」と応援する人はいないでしょう。コンピュータはいつもと同じ速度で数字を計算します。
確かにオーバークロックはできるかもしれませんが、マザーボードが石炭に変わり、電気代が破産宣告を受けるのは時間の問題でしょう。
コンピュータに特定の速度でプログラムを実行させたいなら、新しいハードウェアを買うか、より良いコードを書くべきです。目標を設定しても、システムの結果には影響しないのです。
ゴールを立てようが立てまいが、システムは出せるものを出す。
同様に、締め切りを設けたからといって、エンジニアリングチームのパフォーマンスが向上するわけではありません。
チームのパフォーマンスを向上させるには、マネージャーがシステムを改善する必要があります。たとえば、より多くの人を雇う、デプロイメントを摩擦のないものにする、自動テストを導入して手作業による検査の必要性を減らすなどの方法が必要です。
納期を早める唯一の方法は、プレッシャーによってチームを「過重労働」させ、メンバーの労働時間を長くすることです。一度や二度はうまくいくかもしれませんが、長期的に見れば過重労働は人を辞めさせることになり持続不可能な行為です。
一貫した体系的な改善によってのみ、チームはパフォーマンスの基準値を作成し、レバレッジを効かせ、継続的に成果を向上させることができるのです。
## 期限を区切ると、インセンティブがずれて長期的な思考ができなくなる
2つの営業チームがあるとします。一方は再現性のない予測不可能な収益の急増をもたらし、もう一方は一貫した継続的な成果を生み出しています。
期限に間に合わせ人に5万ドルのボーナスを支給するシステムでは、不安定なチームが運良く期限に間に合ったのか、過重労働をしたのかに関係なく報酬を受け取ることになります。
図1：5万ドルの期限を守る不規則なチーム
そのチームは、パフォーマンスの一貫した基準を設定していないため、四半期ごとに売上目標を単純に増加させることはできません。それは失敗のもとです。この場合、予測可能な収益がないため目標達成を運に頼ることになります。
さらにそのチームがすでに納期を守るために長時間労働をしていた場合、辞めてしまう人も出てくるかもしれません。
この矛盾は締切を設定することで生じることが多いです。そのせいでチームは長期的な一貫性や継続的な改善よりも、短期的な利益を優先するようになるのです。
W.E.デミングならこう言うだろう。
『短期的な利益は、経営のパフォーマンスを示す信頼できる指標ではありません。メンテナンスを先延ばしにしたり、研究を手抜きにしたり、他の会社を買収したりすれば、誰でも配当金を支払うことができます。- Deming, W. Edwards. Out of the Crisis, reissue (p.19). MIT Press. Kindle版』
では、その不安定なチームと、継続的にパフォーマンスを向上させながらも5万ドル達成の期限を逃してしまう予測可能なチームとを比べてみましょう。
図2：5万ドルの期限を守らない、一貫性のある予測可能なチーム
どちらのチームに所属したいですか？
私は間違いなく2番目がいいと思います。そのチームは、締め切りに間に合わなかったものの、常にパフォーマンスを向上させることができることを実証してくれたので、私は運に頼ることなく、より正確に売上を予測することができるようになりました。そうすれば、私は確かな根拠に基づいて意思決定ができるようになります。
さらに、長期的に見て継続的改善の原則を適用し続ければ、安定したチームはやがて不安定なチームのパフォーマンスを上回るようになるのです。
『余談ですが、私が「スナップショット測定法」を好まないのはそのためです。その代わりに、私はこの別の投稿で概説したように（https://lucasfcosta.com/2022/08/31/engineering-metrics.html）、一貫性と継続的改善のためにチームの勢いとコントロールを見る測定基準を好みます』
締め切りは実行可能なものではない
チームが締め切りに間に合わなかった場合、生産的な行動を起こすには遅すぎます。
締め切りに間に合わなくなったら、どのような行動をとればよいか考えてみましょう。
- 新しい期限を設定する
- 誰かを解雇する
- 機能をカットする
1つ目の新しい締め切りを設定することは、最初の締め切りがすでに無駄であり不要であったことを明らかにします。最初の締め切りがそうであったなら、2回目以降の締め切りもそうである可能性があります。
2番目の行動、つまり誰かを解雇することは、チームがすでに遅れているソフトウェアを提供する助けにはなりません。むしろコードを書く人が少なくなるため、ソフトウェアの完成が遅くなるのです。
3つ目の行動である機能をカットすることは、不要な作業をしていたこと、もっと早く納品できたことを明らかにするものです。機能をカットすることは有益ですが、締め切りのせいでそれを行うのは遅すぎるのです。
その他の行動には好きな名をつけてください。これらはすべて、行動が遅すぎたために非生産的なのです。
ルーカス、締め切りがないと何も納品できないぞ。パーキンソンの法則を知らないのか？
もし、あなたのチームが締切なしに納品できないのであれば、締切がないことが問題なのではありません。あなたのチームの顧客フィードバックに対する無頓着な態度が問題なのです。
顧客からのフィードバックにこだわるチームは、できるだけ早く納品し、顧客の声に耳を傾けることができます。
顧客中心主義のチームにとって、人為的な納期は無意味です。なぜなら、唯一の重要な「納期」はすでに存在しているからです。「価値あるものである限り、できるだけ早く」です。
さてここで「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」というパーキンソンの法則について触れておこう。
この法則が正しいかどうかは問題ではありません。なぜなら、締め切りを設けない場合、仕事は無限に拡大するとは言えないからだ。
さらに、パーキンソンの法則によれば、締め切りに安全バッファを加えると、仕事が膨張することになる。したがって、遅延の可能性と遅延の確実性を交換することになる。もしかしたら、仕事がわずかに膨張しただけで当初より遅れることになるかもしれない。
それは、パーキンソンの法則の当然の結果であることは言うまでもない。
"ギリギリまで待てば、1分でできること"
そして、たった1分でできることなら、どんなに素晴らしい結果が得られるか想像できるはずです。良いソフトウェアには時間がかかる。
締め切りでないとしたら、何でしょうか？
締め切りなしで活動するためには、チームはプリエンプションポイントを採用し、取り出しポリシーに注意する必要があります。
これでチームが短期間で同期的に実行可能なフィードバックを作成し、早期に軌道修正できるようにします。またチームが最も価値のある仕事を早期に、低コストで提供することを可能にします。
このセクションでは、これらの戦略についてそれぞれ詳しく説明します。
プリエンプションポイント
OSは特定のプログラムがいつ終了するかは知りません。実際、前もってそれを決定することはできません。したがって、プログラムが実行される時間のクォータを確立します。つまり、他のプログラムがCPU時間を確保できるように、そのプログラムの実行を停止するのです。さらに、OSは挙動不審なプログラムやメモリを過剰に消費するプログラムを終了させます。
製品開発ではOSの手法を模倣して、より良い結果を得ることができる。開発者が特定のタスクに取り組むとき、範囲を狭めるべきか、損失を減らすべきかを評価する一定の時間が存在することがあります。これがプリエンプションポイントです。
プリエンプションポイントは、同期的で一様なものであるため、締め切りとは異なります。
各タスクに任意に期限を設定するのではなく、タスクの状態を定期的にチェックすることで、同期的な決定論的フィードバックを実現するのです。
例えば、3日、5日、10日を超えたら、タスクマネージャーでタスクを色分けして表示させるのも一つの方法です。その都度、そのタスクを早く納品するための改善点はないか、機能を削減することはできないか、あるいは完全に破棄することはできないかなどを検討します。
朝会は、この同期的なプリエンプションフィードバックを導入する一つの方法です。朝会では、前述のようなアプローチについてチームと話し合うことができます。
プリエンプションポイントがうまく機能するのは、変動を蓄積させるのではなく、定期的にベースライン（望ましい最終状態）に戻すことで、望ましい最終状態からの逸脱を修正するのに役立つからです。
定期的なチェックと介入がない限り、このような小さな逸脱は蓄積していきます。そうなると、機能は当初意図したものとは全く異なるものになってしまいます。従って間違った機能を納品するか、その修正に余分な時間を費やすことになります。
図3：プリエンプションポイントにより、定期的に変動をベースラインに戻す
こうしたわずかなズレが時間とともに蓄積されていく様子を説明する方法のひとつに、ドナルド・ライナーセン氏が著書『製品開発フローの原則』で行っているコイントスの実験があります。この実験では、コインを何度もひっくり返します。コインを1回投げるごとに、表が出るたびに1加算し、裏が出るたびに1減算していきます。
下のシミュレーションでは、投げる回数が多いほど、合計がゼロ軸の上下に移動することがわかりますが、これは多くの人が予想するのとは異なるものです。
図4：トスの回数が増えるにつれて、合計が基準値からどんどん離れていく
プリエンプションポイントは、あたかもコイントスの回数を細かく分割してシリーズ化していくように作用します。その都度、蓄積された偏差を強引に基準値に戻す作業を行うのです。
それに比べて締め切りは、バラツキが蓄積されすぎてしまうことが多い。それは、タスクの状況を確認するのが遅すぎるか、不定期すぎるため、現状を基準値に戻すのが難しく、時間がかかってしまうからです。
先取特権は、変動要因の処理に有効であることに加え、次のような点でも締め切りより優れています。
- 実行可能で予測可能である。
- 見積もりが不要になる。
- 短期的な利益よりも継続的な改善を奨励する。
タスクの状態を定期的にチェックすることで、問題を早期に発見し、軌道修正することができるからです。もし、毎日タスクの状況をチェックしていたとしても、対策を講じるのがせいぜい1日遅れるだけでしょう。
また、プリエンプションポイントを使うと、特定の日に何かを完了させることから、「できるだけ早く」というタイミングに関係なく、小さな価値の積み重ねをできるだけ早く提供することに焦点が移るため、見積もりも不要になります。
プリエンプションポイントを使えば、3時間のミーティングを開いて物事がうまくいかない可能性のあるシナリオをすべて明らかにする必要はありません。その代わり、新しい情報には素早く対応することができます。
また、どんなに綿密な計画を立てても、すべてのエッジケースを予測することはできないため、プリエンプションポイントを使えば、本当の意味でアジャイルになる可能性が高くなります。
最後に、プリエンプションポイントは、短期的な利益よりも継続的な改善のインセンティブになります。なぜなら、締め切りが近づくと、開発者は、後で何が起ころうとも、締め切りに間に合うように手を抜かなければならないというプレッシャーを感じるようになるからです。
開発者が手を抜くと、バグが発生し、ソフトウェアのメンテナンスが難しくなり、さらにタスクが長引き、予測可能性が損なわれてしまいます。
締め切りとは異なり、先取りポイントでは、特定の期日までに納品する必要がないため、他のチームと協力しながら段階的に解決策を設計するスペースが自然に生まれます。
したがって、開発者とプロダクトマネージャーは、手を抜くのではなく、スコープを削減することに同意し、長期的な予測可能性とパフォーマンスを損なわないような代替戦略を考案するのです。
待ち行列のポリシー
あらゆるソフトウェア開発プロセスを待ち行列システムとしてモデル化することができます。このようなシステムでは、タスクが一方の端からソフトウェアに入ってきて、もう一方の端から結果が出てきます。
このシステムの性能は、時間に対する価値の関数で決まります。より多くの価値を提供し、その価値を提供するまでの時間が短ければ短いほど良いのです。
このシステムが提供する価値を高めるには、2つの方法があります。
1つ目は、システムの処理速度を上げてソフトウェアが結果を出す速度を速めること。
2つ目は、その時に最も短く最も価値のあるタスクをシステムに投入することです。そうすれば、処理速度に関係なく、常に最も価値のあるものを処理することができます。
この2つのアプローチの違いとして、1つ目の「処理速度を上げる」には、エンジニアの増員やプロセスの改善が必要なため、コストがかかることが多いです。
しかし、2つ目の方法はほとんど費用がかかりません。定期的にキューを見直し、タスクの優先順位付けを徹底することです。
病院が患者の健康状態に応じて治療を行うのと同じように、私たちはタスクの到着順ではなく、それぞれのタスクがどれだけ価値があるかによって処理を行う必要があるのです。
FIFO（先入れ先出し）は、エンジニアリングシステムにとって最適な待ち行列の規律であることはほとんどありません。つまり、作成された順番にタスクを処理しても、満足のいく結果が得られることはほとんどないのです。
私は、FIFOのキューイング規律を採用する代わりに、マネージャーには「重み付けされた最短の仕事」という手法を採用することを管理者に強く勧めます。
この手法は、最も短く最も価値のある仕事を次の仕事として選択するものです。
この手法を採用すると、マネージャーは特定の日付に価値を提供することにこだわらなくなります。その代わり、システムの処理能力が限られていることを認識し、その能力を最も価値のあるタスク処理に充てることに集中します。
つまり、システムがゴールの有無にかかわらずできる限りの出力をするのであれば、システムの処理能力を最大限に活用するためには最も価値のある仕事を投入する必要があります。
まとめ
私たちは締め切りを本当の名前「プレッシャー」と呼ぶようにしなければなりません。
締め切りがあるからといって、エンジニアが早く納品できるわけではありません。エンジニアを長時間働かせたり、不完全でバグだらけの機能を納品したりするだけです。
締め切りが無意味なのは、結果をコントロールできないという事実に起因します。コントロールできるのは、その結果を生み出すプロセスだけです。
結果をコントロールすることはできず、結果を生み出すプロセスしかコントロールできないという事実のほかに、締め切りの無意味さを示す理由が3つあります。
- 締め切りは、チームのパフォーマンスを向上させない。
- 締め切りは、継続的かつ一貫した改善よりも、短期的な利益を優先させる。
- 締め切りは、実行可能なものではありません。チームが期限に間に合わなかったときには、それについて生産的なことをするには遅すぎるのです。
「仕事は割り当てられた時間を満たすために拡張する」というパーキンソンの法則でさえ、締め切りが無意味であることは変わりません。
なぜなら、この法則は、締め切りが存在しない場合、仕事が無限に伸びるとは言っていないからです。むしろ、締め切りを設定すると、どんなに大きな安全バッファーを追加しても、その締め切りまで仕事が延びることを認めているのです。
それは、プロセスにプリエンプションポイントを導入することと、取出しポリシーに留意し冷酷かつ定期的に優先順位をつけることです。
プリエンプションポイントとは、チームがタスクの進捗状況を確認し、スコープを縮小するか、戦略を変更するか、タスクを中止して損失を完全に削減するかを決定するための一定の時間間隔のことです。
プリエンプションポイントは、実行可能で、予測可能で、ばらつきに強く、長期的な継続的改善のインセンティブを与えるので、締切よりも優れています。
最後に、待ち行列の規律に関して言えば、FIFO（先入れ先出し）がエンジニアリングシステムで使用するのに最適な待ち行列の規律であることはほとんどありません。それよりも、システムが常に最も短く、最も価値のあるものを処理していることを確認する必要があります。
そうすれば、システムの処理速度を向上させることはできなくても、その時点で可能な限り最高のものを供給することによって、システムが提供する価値を高めることができるのです。
30代ではじめてブリーチをした話
はじまり
リモートワークを推進している企業が多くなっていますが、リモートワークならではの悩みも多くなってきたと思います。個人的な悩みの一つに「社員の顔がわからない」というのがあります。これは入社したての方なら誰でも思い当たると思いますが、リモートワークだとそもそも挨拶できる機会もないのでなかなか解決が難しい問題です。しかし、これは新入社員だけでなく、既存社員も新入社員がだれだかわからない、という問題につながると思います。
そのようなことを金曜日に上司に相談したら、帰ってきた言葉がこちらです。
「金髪にしたら？」
え？
「髪染めるのは誰にでもできるし、セルフブランディングは大事だよ」
とのことでした。
今まで髪を染める理由を理解できていなかったのですが、この言葉を受けて、人生ではじめて髪を染めてみようかと思います。
店選び
さっそく土日に利用できるお店を探します。知り合いに聞いたら「少なくとも1万円は出してちゃんとした美容室行った方がいいよ」とのこと。［カラー うまい 美容室 メンズ］で検索をし、近い順にクチコミを見ながら決めていきました。それでも膨大なお店の数がありますので、男性もよく利用している所を探していきます。
メニューはブリーチとカラーが必要なので、ツーカラーで1万6千円という価格です。
施術中
施術中は特にこれといった話はしていないのですが、人生で始めて髪を染めると言うことで、経緯は結構聞かれました。「会社愛半端ないですねw」というノリでしたが、丁寧にカラーリングしてもらいました。
ブリーチをしてもらった結果がこんな感じ。
こんなに綺麗に金髪になるんだ、とわりと感動していましたが、完全にヤンキーですね。
美容師からも「ブリーチすると一人東京リベンジャーズになるのは避けられないのですが、もう一色塗っても東京リベンジャーズが追ってきますね」そこから2色目を塗るにつれて、テンションが上がってきたのか、「これって実はタイムリープしてます？」「握手するとトリガーになったりしますか？」と東京リベンジャーズネタでいじられつつも完成した色がこんな感じ。
「もう少し赤くなったら一人SEKAI NO OWARIですね」という仕上がりになりました。
最終的にはセックスピストルズのジョニー・ロットンみたいな髪になり、社会人として色々なものを置き去りにしてしまいましたが、職場ではどんな反応されるのだろう？ もう完全にセルフブランディングという言葉は置き去りになってしまっていますが、顔を覚えられたらいいな、と思います。
Rust勉強メモ1
7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。
インストール
curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
パス
export PATH="$PATH:$HOME/.cargo/bin"
バージョンの確認
rustc --version
バージョンのアップデート
rustup update
VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。
Hello Worldのコード
fn main(){
println!("Hello World")
}
rustc hello.rs
実行
./hello
Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。
文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。
fn main(){
let price = 300;
println!("ガムの値段は{}円", price)
}
四則演算の問題。答えを見ずになんとなくで書いたコード
fn main(){
let bike = 80.0;
let train = 300.0;
let moon = 384400.0;
println!("バイクの場合は{}日です", moon / bike / 24.0);
}
適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る（おもしろ）。
warning: unused variable: `train` --> q1.rs:3:9 | 3 | let train = 300.0; | ^^^^^ help: if this is intentional, prefix it with an underscore: `_train` | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted
実行結果
バイクの場合は200.20833333333334日です
Rustは型に厳しい言語なので、整数と実数は明確に区別される。
■for文の書き方
for 変数 in 開始地 .. 終値 +1 {
処理
}
■if文の書き方
if 条件1 {
処理1
} else if 条件2 {
処理2
} else {
処理3
}
■print!とprintln!の違い
print! = 改行がない
println! = 改行がある
■変数
letで宣言した値はイミュータブルな変数になる
let 変数名 = 値;
ミュータブルな変数にするにはmutをつける
let mut 変数名 = 値;
Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる
fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable
Rust勉強メモ1
7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。
インストール
curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
パス
export PATH="$PATH:$HOME/.cargo/bin"
バージョンの確認
rustc --version
バージョンのアップデート
rustup update
VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。
Hello Worldのコード
fn main(){
println!("Hello World")
}
rustc hello.rs
実行
./hello
Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。
文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。
fn main(){
let price = 300;
println!("ガムの値段は{}円", price)
}
四則演算の問題。答えを見ずになんとなくで書いたコード
fn main(){
let bike = 80.0;
let train = 300.0;
let moon = 384400.0;
println!("バイクの場合は{}日です", moon / bike / 24.0);
}
適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る（おもしろ）。
warning: unused variable: `train` --> q1.rs:3:9 | 3 | let train = 300.0; | ^^^^^ help: if this is intentional, prefix it with an underscore: `_train` | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted
実行結果
バイクの場合は200.20833333333334日です
Rustは型に厳しい言語なので、整数と実数は明確に区別される。
■for文の書き方
for 変数 in 開始地 .. 終値 +1 {
処理
}
■if文の書き方
if 条件1 {
処理1
} else if 条件2 {
処理2
} else {
処理3
}
■print!とprintln!の違い
print! = 改行がない
println! = 改行がある
■変数
letで宣言した値はイミュータブルな変数になる
let 変数名 = 値;
ミュータブルな変数にするにはmutをつける
let mut 変数名 = 値;
Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる
fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable
