エンジニア風林火山ー『その仕事、全部やめてみよう――１％の本質をつかむ「シンプルな考え方」』

hgsgtk

2020年9月5日 16:02

クレディセゾン常務取締役CTOの小野和俊さんの著書。

著者は、ベンチャー企業から大企業まで両方、いちプログラマの立場も、経営者としての立場も経験している方。それがゆえに、語られることばの幅・そのメタファの豊富さは、経営者とプログラマの複眼的思考を継続されてきた結果を感じた。

仕事をしていくうえで大切なのは、よいものを作り上げて世の中に届け、企業を成長させること。そして、みなが生き生きと仕事をして高く評価され、幸福だと感じることだ。

この大切なことを実現するための「仕事の本質」を迫った本。

ボリューム感は、通いの皮膚科の待ち時間と電車なのでたぶん2時間弱くらいで読んだ。

「谷」を埋めるな、「山」を作れ！

製品開発における価値において、競合製品に比べて不足している点（「谷」）を埋めるか、自社製品の長所・ユニークな価値（「山」）を作るか、という観点。

これは、サービス会社にいると、このバランスの難しさ故に「プロダクトマネージャー」という役割がいるんだな、と日々ありがたみを感じている。たとえば、日々顧客対応や営業活動をするような役割だと「谷」に特に気が取られると思う（実際、他社サービスとの比較に間近にさらされている）。

しかし、その声に対応していくのも、局所最適になっていき、そもそもサービスの存在意義に対して効果的なのか、むしろ逆効果にならないか、といった状況も生まれてきそう。

著者の経験では、DataSpider という製品が、参入してきた Microsoft の BizTalk という製品との戦いを事例にしていた。

口だけなら「大切だよね！」って言えるこのことが、説得力を持って語られていた。

そういえば、所属企業は割と理念を起点に進めていくような方法をとっている（よう）のだが、それはソートリーダーシップ型と呼ばれるのですね。

ソートリーダーシップとは、企業が特定の分野（業界・テーマ・社会問題）において、将来を先取りした革新的なアイデアや解決策をいち早く発見し、示すことでその分野における主導者となることです。

方法論の乱用

方法論の乱用について示唆深い言葉があった。

何らかの方法論をとり入れると、自分たちのチームが急に権威づけされたような気分になる。多くの人によって検証された方法で進めている「安心感」も得られる。何もない中で進めていくよりも、ずっと成功率が高まるように思える。

これは、他の言葉で言えば、「フレームワークの罠」と表現されていたりすると思う。

ソフトウェア開発の文脈では、「アジャイルではこうすべき」とかの理由で、特定プラクティスに権威付けをしているような重力が働きがちだろう。あるいは、「有名なあの人がこう言っていた」ということだけを理由で取り上げてしまう、といったこと。

一般化されて様々な現場で活用されて磨かれてきたアイデア・方法は参考になる一方で、「なぜ自分たちはこれをやるのか？」・「何を解決したいのか？」が語れない状況の場合は、己に危うさを感じたほうが良い。

本書では、こう締めくくられている。

創造力を発揮し、新規事業やプロジェクトを成功させるのに最も重要なのは、知識や方法論で武装することではない。チームメンバーが自分の頭で考え、同じ方向を向いて進んでいくことだ。

いろいろ、変化しないと飽き飽きしてしまう性格上、いろいろなことをチームに提案していたりするが、組織運営の出発点はここだろうな、と最近ぼんやり思っていたことをびしっと言語化していただいていた。

　体験の重要性

技術とか方法を広めていく一番のやり方が「体験してもらう」ことってのは、周りを見てもたしかになぁと。

裏返して言えば、体験さえしてしまえば、多くを語らずともそれがどんな感動をもたらし、どんな可能性を持つのかを瞬時に理解できる。

プログラマだと、オブジェクト指向プログラミングをすることの価値とかって、やってない人から見たら「クラスが増えて複雑そう」みたいな話になる。そして、そこに価値を感じてやってる人からすると、「何を言ってるんだ」とそもそもその感覚が理解できない。

でも、DDDやオブジェクト指向プログラミングを活用する方針のプロジェクトに参加したプログラマは、そこで、体験をして理解するという場面を最近見た。

体験の喜びがやる気とひとりひとりの才能を引き出すのだ。

いい言葉・・・。これは、「体験ができておらずその人の才能が引き出せていないと状況理解できる視点」となるので、組織を見る視点の一つになった。

「2ピザルール」

Amazonのジェフ・ベゾスでおなじみのこれ。本書でも8人以内なら会議で全員が一度は発言できるし良いと言っている。

また、スクラムチームのサイズもたしか、5〜8人という規模を推奨していた。2ピザで8人なのかもしれないが、なるほど8人というのは各方面から一致してくる数字だなと。

「ハンマーと釘」

これはとある英語のことわざに根ざしたもの。

この世界では新しい技術が日々生まれ、私たちエンジニアは「手にしたハンマーで釘を打ってみたい」衝動にかられながら仕事をしているからだ。

最近、この感情・衝動に対してどのようにチームとして向き合うか、について関心がある。これは、「みなが生き生きと仕事をして」と「高く評価され」の間をどうつなぐか、といった悩みかもしれない。一つのマネージメントのあり方として、この衝動を大事にしてそれを評価可能な形にビジネス価値に結びつけ可視化する努力のあり方も有ると思う。

これは、当人にその衝動に対してビジネス価値を言語化して説得可能な力を得てもらうとか、あるいは翻訳して評価対象へと昇華する、といった様々なアプローチが有るだろう。

これができないと、「何もせず現状維持」することが最適な行動原理になってしまうので、その重力をはねのけなければならない、と日々思う。

DCPAとPDCAの向き不向き

実行（Do）→チェック（Check）→改善（Action）→計画（Plan）と、計画より実行が先にある。

この向き不向きの分析は、同時にアジャイル開発とウォーターフォール開発（厳密にはシーケンシャル開発らしいが）、の分析とも言えると見て取れた。

「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイルの境界という言葉を使って、そこまでをアジャイルの範囲としているか定義する考え方を出していた。

そして、アジャイルの境界を意識した上で、シーケンシャル開発とアジャイル開発をうまく組み合わせることも、現実の開発現場でアジャイルの価値を引き出すために有用だと語っていた。

これらを踏まえて一つ考えとして整理に至ったのは、DCPAが不向きな領域の２つ目だった。

②関係者が多く、情報共有こそが肝である領域プロジェクトメンバーが何千人といて、精緻な計画書がないと意思疎通が困難な場合もＤＣＡＰは向いていない。もっとも、チームとタスクを細かく分割すれば検討できるだろう

自社で収まらないような開発においては、情報共有をした上で、不確実性を適切に低減させるための事前プランニング（つまり要件定義フェーズとも言える）が必要だろう。一方でそれらで合意が取れたあとのフェーズでは、開発における不確実性をDCAPで経験主義に基づいて実施していく。

こういう考え方は、ちょっと２つの書籍をmixした形で実行に移していけるAction Itemになりそうだ。

「ラストマン戦略」

この分野なら詳しい！っていうふうに領域を決めて実際に頼られる様になるという戦略。

「ラストマン戦略」とは、グループ内で自分が一番になれそうな領域を決め、「あの人がわからないなら、誰に聞いてもわからないよね」という、いわば最後の砦とも言うべきスペシャリストを目指す成長戦略だ。

僕は特段一つの分野に特化した人間ではないので、たまに業界レベルでこの戦略を取れる人に「すごいなぁ」と思う。実際に組織の中で存在感を発揮していただく、と考えたときに「ここはラストマンになりましたね！」っていうコミュニケーションは有効かもしれない。

また、自分はこういう考え方をしてきたのかな？と考えてみた。こういう言語化はあまりしていなかったのだけど、「あまり人がいないことに対する希少性」みたいなところで考えていたからそういう戦略だったのかも（過去の資料を見てそうらしいと思った）。

今はどうかな？って思ったら、「自分よりもすごいエキスパートを持ってる人達と働きたいよ」っていう観点で採用面接とか挑んでいたこともあって、ちょっと変わってるかもしれない。
それでも、その人たちが持ってるエキスパートに合わせて、自分がラストマンになるフィールドを変えている、とも言える。

長々かいたが、多分自分も自然と「ラストマン戦略」だったんだろう。

そういえばこういうのを誰かが「自分の畑を作る」って表現していたようないなかったような。

変化に応じた柔軟性に対応する職能横断性

変化の時代においては、やるべきことが突発的に変わることも有る。そのときに、「〇〇だけをずっとやっていた人」ではなく、それぞれのメンバーが多くの種類の仕事をこなせるようになっていることで、チームの柔軟性も高まっていく

採用面接をしていると、自チームの特性上「Goを書きたくて！」っていう応募があって、だいたいのケースでその方とのご縁がない結果になったりする。事業や外部要因が変わるから「Goだけをずっとやる」っていう未来に当人を固定できない。「言語で採用した人は言語で去っていく」というような感じ。

アジャイル文脈では、職能横断的であることを開発メンバーに対してある程度求めることがあるが、同じく変化・不確実性に立ち向かう組織の態度・あり方は、個人にも求められることが多いということだろう。

「『一番近く』と『一番遠く』だけを見る」

ゲームプログラマーの中嶋謙互さんの言葉らしいが、あぁそうだよなって共感した。

「一番近く」だけを見ていると、「自分はなぜこの場所で、この仕事をしているか」を考えることなしに、直近でやるべき仕事を機械的にこなしていくことになりがちだ。

「一番遠く」だけを見ていると、夢やアイデアは語り尽くされるものの、熱気と情熱だけが残って、現実的には何も得られずに終わってしまうことが多い。

現実で仕事はこなせていても機械的になっていて変化・カイゼンがされていない状況に陥りがちだし、理想を持ったとしてもそれだけで何も課題解決に至っていない、という状況にもなりがち。

とにかく、遠くに行くために思いついたことをDCPAで「えいや！」っと行動するしかない、と思い最近は落ち着かせたが、『一番近く』と『一番遠く』だけを見るという表現はいいなぁ。