【書評】ユニコーン企業の秘密
「コンウェイの法則」では、システム設計は、組織構造を反映させたものになると提唱していますが、ソフトウェア開発に携わっていれば、この法則が直感的に正しいことはなんとなく分かるかと思います。本書では、ユニコーンと呼ばれるスタートアップから非常に大きな経済規模となった企業が、どのように組織をスケールさせたかを、著者が所属したSpotifyの事例を交えてまとめられたものです。
Spotifyといえば、「Spotifyモデル」という組織構造を導入したことで有名であり、日本でも多くのスタートアップ企業・エンタープライズ企業がこの構造を取っていますが、本書はその組織構造そのものより、どういった考え方、定義から社員をモチベートし、組織をコントロールしているかに重点を置いた内容となっています。
その中でも比較的面白かったのは、Spotifyがスウェーデンの会社で、北欧の文化を下敷きにした思想を企業文化にも持ち込んでいるということです。社員に権限と信頼を与え、当事者として事業を推進する。組織はそれをサポートする構成となり、困難な目標に向かって邁進する。それが優れた文化となって優れたプロダクトを生み出し、優れた人材を採用する、という考え方です。
これは私の所感ですが、本書に紹介されている考え方や、組織構造としてのSpotifyモデルをそのまま、日本のスタートアップが本質的な部分で理解せずにこれを真似しても大きな成果は得られないだろうと思います。本書の最後にあるようにその「コンテキストもあわせて取り入れ」る必要があるでしょう。他のテック企業の働き方を参考にしつつ、ミッションから来る自分たち独自の文化形成をすれば、組織は自律しよりよいプロダクトを生み出します。
これらを実現するために「あらゆる言い訳を取り除くこと」。組織開発を進める私にとって、常に呪文のように唱え続けなくてはいけない言葉でしょう。スタートアップの社員は常に権限を信頼を有し、責任を負い続けるからこそ、社会へインパクトを与えられるプロダクトを作ることができるのです。
【書評】Scaling Teams 開発チーム 組織と人の成長戦略
スタートアップがスケールするためには様々な障害を乗り越えなければいけない、ということは分かっていても、それらが具体的にどのようなことで、どう解決すべきかを理解するのは容易いことではありません。本書は、組織のスケーリングをテーマに、どのように組織を設計するかの一つのフレームワークとして書かれています。
内容としては、採用プロセス自体のスケーリングをどのように行うか、面接・採用・リファレンスチェックからオンボーディング、キャアリア形成までの人材の雇用という観点から見た内容と、管理者の雇用、チーム体制、チームの士気から組織文化までの組織形成という観点からの内容とで、網羅的になっています。
私個人として興味深く感じたのは、「チームの態勢固めに最も効果的でシンプルな方法は『今後、起こるかもしれないと予期しておくべきことをチームメンバーと話し合う』だ」と指摘している点です。急成長中のチームはプロダクトや顧客に注意が行くため、チームの士気を高く保つのが実は難しい状況に置かれます。これを自主的に回避するための方法をとして「チームで組織リスクを（腹を割って）話し合う」という手段を取ることを推奨しています。これはメンバー権限を委譲し責任を負うベンチャーならではの施策であると言えます。
本書の全ての施策をそのまま使える、というものではありませんが、ベンチャーがPMFのフェーズを抜けて拡大する際に、取りえる施策として取り込むことができるアイディアに詰まった一冊でした。
Dell U4021QW導入と、購入前に知りたかったKVM機能のこと
U4021QW購入までの経緯
コロナ禍において在宅勤務が継続している中、大型外付けディスプレイの導入を検討されている方も多いかと思います。
私自身もコロナ禍初期から在宅勤務を継続しており、つい先日までは32インチ4Kのディスプレイ（EIZOのEV3237）を利用していました。やや古いディスプレイながらも特に不満も無く使っていたのですが、在宅勤務が長引くにつれてケーブル接続や表示範囲など小さな不満を持つようになり、新しいディスプレイを導入することに決めました。
購入の際に検討した条件は以下になります。
- 【USB-C(もしくはThunderbolt3)接続】ケーブル一本でPDによる給電も可能となり、PCと接続できる手軽さが得られること
- 【KVM機能】仕事用とプライベート用の2台のMacを切り替えながら作業することが多く、また外付けのキーボード・トラックパッドを共有したいので、KVMで切り替えできること
- 【広い表示領域】「2台のMacを切り替えながら作業する」が苦痛なので、2つの画面を横に並べながら作業ができること(4Kでも画面分割すると狭い）
この条件を考慮した上でデュアルディスプレイ化も考えたのですが、この手の問題を解決する際に中途半端な投資をすると結局無駄になってしまうので、いっそのこと「一枚で全ての問題が解決できるディスプレイ」を探すことにしました。
U4021QWを購入
上に挙げた不満を解消できるディスプレイはDellのU4021QWしかありませんでした。ディスプレイにしては高額の投資になりますが、それ以上の価値を得られると考え、購入に至りました。
購入して1ヶ月、非常に満足しているのですが、できれば「購入前に知っておきたかった」こともあり、参考までにこちらに書き残すこととしました。
「知りたかった」KVM機能について
購入にあたって一番心配だったのがU4021QWのKVM機能でした。DELLが公開している説明書のPDFも読みましたが、機能の説明だけでは実際の操作イメージが湧きにくく、本当に快適に操作できるのか、が分かりません。実際使ってみて分かったことは以下の通りです。
2系統を切り替える場合
映像系統の切り替えとKVMの切り替えはどのように行うのか？連動しているのか？
- 連動している
- 映像系統を切り替えた際に、USBのアップストリームがThunderbolt3に行くか、USB-Bに行くかを選択できる
2系統を同時に出力するPIP/PBPモードの場合
KVMはどのように挙動するのか？
- メニュー画面からUSBの切り替えができる
- PIP/PBPで同時に映せる映像入力は2入力だが、そのどちらにUSBアップストリームが向くかスイッチできる
KVMで入力を切り替えるときの操作は？
- 基本的には、ディスプレイ右側裏面のジョイスティックを押し込み、メニュー操作する必要がある
- ショートカットキーと呼ばれるメニューはカスタマイズが可能であり、最小2手（スティック押し込み→初期で表示されている操作で押し込み）で切り替えができるようにはなる
- Windows/Macには常駐型のアプリケーション（Dell Display Manager）が用意されており、こちらで入力の切り替えやPIP/PBP時のUSB切り替えなどができる
評価
U4021QWの主体は5Kディスプレイであり、KVM機能は付随しているものですが、そこまで操作が煩雑ではありませんでした。一映像入力を頻繁に切り替えることはない、Windowsのみ複数台運用を行っているなど、ある程度妥協できる場合はケーブルの取り回しが減るのでおすすめです。
一方でボタン一つでKVMが切り替わるような、操作の手数を最小限にしたい方にはこのディスプレイのKVM機能は向かないでしょう。
また注意すべき点は、U4021QWのEtherポートはUSBに変換されて接続されるということです。当たり前ですが画面切り替えの際、USBに接続されている機器の接続は表示先の変更に追従します。元のCPU側は当然ネットワーク接続が外れてしまうので注意しましょう。
終わりに
いろいろ書きましたが、U4021QWは良いディスプレイです。これ以上を望むのであれば、複数ディスプレイを導入する選択をすべきだと思います。（もし私がそういう選択をするのであればEIZO の4Kを2台並べると思います。EIZOは画質に定評があり、導入コストはU4021QW 1枚と同じくらいで表示領域は上回ります。）
それでも1枚の大型ディスプレイを選ぶのは、それがロマンだから。ガジェットおたくとはそういうモノですから。
![＼初売り!!全品P5倍!!／ Dell U4021QW [39.7インチ] 機種で使える 透過率96％ クリア光沢 液晶保護 フィルム 保護フィルム メール便送料無料](https://thumbnail.image.rakuten.co.jp/@0_mall/casemania55/cabinet/item_thumb/clear-moni/k000133/k0001333946.jpg?_ex=128x128 "＼初売り!!全品P5倍!!／ Dell U4021QW [39.7インチ] 機種で使える 透過率96％ クリア光沢 液晶保護 フィルム 保護フィルム メール便送料無料")
【書評】どんな業界でも記録的な成果を出す人の仕事力
「成果にこだわる」ということはキャリア形成に対して非常に重要であり、また難しいことでもあります。
著者は、一見、一貫性のないキャリアを積みながらも、どの業務ドメインでも共通して成果を出せる方法を経験から導き出し、本書にまとめています。
内容は
- それぞれの業務ドメインでどのように成果を出したのか
- どの業界でも必ずやるべきことは３つ。「顧客の見直し」「チャネルの見直し」「勝てる戦いをする」
- リーダーのあるべき論
など、著者の経験から自らの成功要因を分析した上での主張を展開しており、若い方が経営者を目指す一つのロールモデルにはなるとは思います。
しかし、このような「常によそ者として乗り込む」仕事の仕方は、万人が実現できるものではないでしょう。直球があるからこそ変化球が生きる、そういった感想を抱いた書籍でした。
【書評】「よそ者リーダー」の教科書
著者は伊勢丹のバイヤー職から経営再建中の福助に招聘され、あの藤巻兄弟の弟の藤巻幸夫氏の後任として社長を10年努めた人物。その後複数の企業の経営に関わり、そのノウハウを込めた本になります。
内容は
- 外部から組織を任されるリーダーはどのようにチームを動かすか
- 意思決定の責任を自らが負うことの意義
- よそ者リーダーがハマるポイントとして「功を焦らないように」
など、経験則だが普遍的・実践的な内容が書かれており、外部から招聘された社長が短期間で成果を上げるためのポイントを押さえた良書と言えると思います。
ただ、「銀行との付き合い方」「コンサルの導入」など比較的社長目線で書かれた項目が多く、タイトルにある「リーダー」が該当する内容は感覚的には半分くらいです。部長・課長が担当組織を変わるくらいでは本書の半分くらいしか役には立たないでしょう。一方で、ある日突然の辞令で「よそ者経営者」とならざるを得ない方にとっては非常に参考になるだろうと思います。
どんな文章でも3行に要約してくれる「ELYZA DIGEST」が自分の3行説明と合うかを試してみた
先ほど書いたブログ記事
には3行まとめを入れているが、これをAIが3行に要約してくれるサイトに入れたら結果があうのか試してみた。
うん、惜しい。最後の結論が異なるが、それっぽい日本語になるのはありがたい。
技術系バックグラウンドのマネジャーが失敗するひとつの事例
技術系バックグラウンドを持った人材が陥りやすい事例として、「技術にこだわり過ぎるとマネジメントは失敗する」というものがあります。ここでは、私が当事者として失敗した事例についてご紹介します。
三行まとめ
- 技術系バックグラウンドを持った人は良い技術を導入すれば組織は良くなると考えがち。
- 技術者は、ソフトウェアエンジニアリングの世界と同じ確実性を、マネジメントにも求める傾向がある。
- マネジメントは不確実を孕むものである。これを見逃すとマネジメントは失敗する。
背景
私が所属していた企業は従業員数万人規模の比較的大規模な会社で、非常にボトムアップ文化が強い会社でした。それぞれの部門にプロダクト開発のためのソフトウェアエンジニアが所属するような体制を取っており、横断的な取り組みはごく一部で行われていたという状況でした。
社内で複数の大型プロダクトが開発されていく中、プロダクトのライブラリ管理がバラバラに行われており、それはリスクを孕むようになってきました。
- セキュリティ：オープンソースの適切な利用がされているかが把握できない。脆弱性が発見された場合に横断的な検査ができない。
- 効率性：ライブラリ利用に関するベストプラクティスのノウハウが分散し、開発リソースを無駄に消費してしまう。
- コラボレーション：社内エンジニアが学習やコントリビュートのために他のプロジェクトのソースコードを見たり、参画することができず機会損失する。
これらの問題を解消するために「ライブラリ管理共通化プロジェクト」が立ち上がり、エンジニアバックグラウンドであるA氏にプロジェクトリーダーの白羽の矢があがりました。
そして半年経ち、プロジェクトは失敗しました。プロダクトのライブラリ管理はバラバラのまま、リスクは孕んだままです。何がいけなかったのでしょうか？
失敗に至る経緯
「ライブラリ管理共通化プロジェクト」の推進にあたり、A氏は「このプロジェクトを推進すれば、セキュリティの問題が解決し、効率も上がる。開発現場は喜ぶだろう。」と考えていました。ライブラリ管理をするためのSaaSプロダクトを選定し、スケジュールを引いて予算を確保したまでは良かったのですが、これらを導入するにあたって各部署からA氏にとって意外な言葉が飛び出しました。
「このプロジェクトを推進する意義は何か？このプロジェクトに合わせてライブラリ管理を変更すると、プロダクトの開発スケジュールにも影響する。現在もセキュリティ問題は適切に対応しているし、効率がどれだけ上がるかも分からないものに対応できない」
A氏は「全社的に必ず必要になるもので、良いプロダクトだからなんとか対応して欲しい」と各部署と調整しましたが、理解を示した部署はわずかであり、当初のスケジュールやゴールイメージを大幅に見直す必要に迫られ、最終的には「本プロジェクトは適切な効果を得られない」ということで中止となりました。
要因
ここでのA氏とは私のことです。
プロジェクトは失敗に終わった原因の一つは、技術系バックグラウンドを持っていた私は当時「採用する技術」よりも「技術を採用する組織づくり」のほうが重要であることを十分に理解していなかった、ということです。そのためこのプロジェクトに関わる組織のステークホルダーに対して十分な配慮や検討を行わず、結果として選定技術やスケジュールが組織に受け入れられませんでした。
これは「事前配慮すべきだった」ということではなく、これらプロジェクトに関わる全ての部署や人を一つの組織とみなし、それを運営するというイメージを持ってプロジェクト設計していないことが、最大の失敗要因だったと考えています。
総括
プロダクトの導入先（顧客と見立てていいと思います）はソフトウェアにおけるAPIではありません。決まったデータを流し込めば確実に処理して返してくれるわけではありません。技術者は、ソフトウェアエンジニアリングの世界と同じ確実性を、マネジメントにも求める傾向があります。マネジメントには不確実性があることを見逃してしまうとマネジメントにおいて失敗を続けることになり、成長はないものと思います。
