見出し画像

ソフトウェア・デザインとPMのキャリア

ikutani41

先日Twitterで「デザイン・エントロピー」という言葉に出会って「良い言葉だなぁ」と思ったので、その勢いに任せて、僕が以前に考えたことやPMからPM & UI/UX Designerに舵を切ったときのことを書きたいと思います。


「デザイン・エントロピー」

まずは、あまりエントロピーという言葉に慣れていない方も多いと思うので、「デザイン・エントロピー」という言葉を僕なりに説明しておきたいと思います。


「エントロピー」は熱力学や統計力学の概念なんですが、簡単に言えば「平均化のされ具合」とか「情報量のなさ具合」といった意味です。

例えば、目の前に熱い物と冷たい物が2つ横並びで置いてあるとします。放っておくと、熱が移動して両方とも同じくらいの温度になっていきますよね。

これは「片方は熱く、片方は冷たい」という状態から「両方同じ」という状態への自然変化が起きたと表現できて、「平均化されたね」「情報量がなくなったね」と言えます。これを「エントロピーが増大した」と表現します。


放っておくと「増大する」

「あらゆるもののエントロピーは原則として自然増大する」という考え方がベースにあるので、人間がモノを作る行為は自然に逆らう（意思を持って力を加える）ことで行われているという考え方がされています。

意思を持たないでとりあえず意見を全部取り入れると何だかよくわからないゴミが生まれる という現象の裏返しみたいで面白いですね。

「~な人のための、XXができるプロダクト」として始まったものが、
「誰かが使ってくれるかもしれないAAとBBとCCがちょっとずつできるプロダクト」になっている みたいな事例です。


プロダクト作りやソフトウェアデザインの文脈では、こういったことはよく起きます。

・役割分担が明確だった機能の境界が、どんどん曖昧になっていった。
　・タイムラインとDMの住み分け
　・EC/ショップサービスで出品できる商品タイプの違い
・会員登録ハードルが高いのでゲスト機能を充実させていったら会員との差がなくなっていった。
・いろんなことができるように対応しようとした結果、条件分岐が複雑すぎてユーザが使いこなせなくなった。　※しかも開発・保守が大変

「XXはAで扱い、YYはBで扱う」と整理されていたものが、「XXはAで扱うこともあるが、Bで扱うこともある」状態になり、「そのケースの違いはユーザには理解できない」となれば、もはや「AとかBって何よ」という話で、既にAやBは情報量を失っています。

僕は、こういう状況をよく「モデルが破綻している」「設計が破綻している」という表現をします。


当然、デザイン・エントロピーの増大を抑制すべき

開発が進んでいくにつれて、最初は知らなかった知識が付いたり、世の中やユーザの行動が変わっていったりします。グロースハックの一貫でメインではないニーズへの手当を厚くしたり、様々なユースケースに対応したりします。流れに任せて場当たり的に新規追加を繰り返していたら設計はごちゃごちゃになるので、ちゃんと既存設計のロジックに則って整理していく意思が必要です。

もちろん、最初の時点で将来どうなっていくかをすべて予見できる人間はいません。ただし、物事の抽象化やモデル設計に長けている人であれば、今後の変化がすごく起きそうなところと起きなさそうなところを見分けたり、変化が起きたとしても対応がしやすいような初期設計をすることができます。AはA、BはBとして成立したままで、ある程度の機能を追加していけるように設計しておくのです。

言い換えれば、「エントロピーの増大をデザインによってコントロールする」のです。これは、初期設計時にしかできません。初期設計時を逃すと、大幅なリファクタリングやリデザイン工程を踏まない限り、後戻りできません。

「物事の抽象化やモデル設計に長けている人間 = デザイナー」を上流設計から参画させよ とはそういう意味です。

コミュニケーションに長けているデザイナーであれば、シンプルな設計されたアウトプットを出すだけではなく、「次に設計を見直すべきタイミングが来るとしたら、こういうときだ」「この仮説が外れたら作り直す」「こンな感じの施策をやろう という話にならない限りは大丈夫」「この要件さえ切ればシンプルになる。思い切って切りませんか？」など、判断の背景を言語化してビジネスの意思決定テーブルに乗せてくれます。


ピュアなPMには難しい。でも、デザイナーもいなかった。

これは僕の話ですが、PMになりたての頃に「これ俺の職務をまっとうするのって、俺だけじゃ無理じゃね？」と思ったことがありました。

僕はPM（プロジェクトマネージャー、開発ディレクターみたいな感じですね）として新規プロダクトの開発を進めていましたが、良い開発計画を引くこと、今後も中長期でユーザに使ってもらえる保守性の高いプロダクトを作っていくことで、最終的には事業を成功させることが職務です。

ビジネスとユーザと（ある程度の）技術が分かっていれば、あとは自分の頑張り次第で事業を成功させられると思っていました。でも、ユーザの業務と技術のことがわかったうえで、物事を抽象化してモデル設計をするプロセスに強い人がいないと、良いプロダクトができず（できたとしても時間がかかりすぎて）、事業を成功させられないと思うようになりました。社内にデザイナーがいないというのも理由の1つではありましたが、ベンチャーのチームは片手落ちが基本なので、人がいないならPMが埋めます。

「より良いプロダクトにしていく工程の解像度を上げたいので、あらゆる計画やデザインの基礎になる物事の抽象化とモデル設計に強い人になろう」

このときは、職種の境目とかはどうでもよくて、「優れたソフトウェアを作ってビジネス化するのが仕事なのに、どうやったら優れたソフトウェアができるか知らないのは無理ゲーだよね」という単純な考えで、ソフトウェアに向き合うことを始めました。


ソフトウェア・デザインに向き合う

とにかく抽象化とモデリングができれば良いという話で、データベース設計を学ぶのが1番わかりやすいと思います。とりあえずググってみて見つかる記事を数本読み込んで見ればなんとなく雰囲気は掴めます。

あとは僕がRESTful API設計のバイブルとしてお世話になったapigeeのebookなどもおすすめです。

この辺の知識を得たら、あとは日常で目に入るシステムやアプリを見たときに、どういうモデルになってるか自分で考えてみていくつも図にしてみる というのを繰り返すと良いです。また、この辺のデータやユースケース制御を目的としたモデリングを理解できたら、もう一歩踏み込んでユーザ目線での簡素モデル（メンタルモデル）を考え直す癖を付けるとなお良いです。


モデリングは、やりっぱなしじゃなくて、「これが現実をうまく反映できているか」をチェックしてadjustすることが重要です。DB設計やAPI設計は技術者に見てもらって「わかりやすいか」「ちゃんと動くものになりそうか」をレビューしてもらいましょう。メンタルモデルは実際にユーザインターフェースとして形にしてユーザテストを行いましょう。

ユーザインターフェースのデザインは、まずモデル検証のために行う程度のものやPMF取る前のプロダクトであれば、Web, iOS, Android, Windowsそれぞれの「標準」が記述されているガイドラインを読み込んで、プラットフォームごとの各コンポーネントの役割、通常レイアウト・動作を理解すれば、ある程度なんとかなります。

重要なのは、世界観の演出やアニメーションやクリエイティブまでがんばることではなくて、自分が作ったユーザインターフェースの理由をすべて説明できることで、ユーザテストの反応を仮説検証の解釈に落とし込めるように情報が整理されていることです。


モデル設計のことは、特にデザインの世界では情報設計（Information Architecture）と呼ばれることが多い気がしますが、それについて過去にまとめた資料があるのでこちらも良かったらご参考にどうぞ。

これをやりだしてから、僕は仕事のパフォーマンスが激増したと思います。Tryしてみて損はないと思います。


PMのキャリア

PMは扱う事業がtoCかtoBかでも重視されるポイントが違いますし、toBの中でもSMB向けなのかエンタープライズなのか、ソリューション事業や受託系なのかでも雰囲気が違います。

そんな中で、とりあえずtoB事業でPMとして活躍するためには、「ソフトウェア側に伸ばす」or「CX/マーケ/bizdev側に伸ばす」かの2択になるかなぁと思います。と思っていたら、SmartHRさんが面白い整理をしてくれていましたので参考に。

ソフトウェア側に伸ばす側の人について、僕の主張はこうです。

ソフトウェア・デザインや技術と向き合わないと、PMとして価値を出すのはそろそろ厳しくなってきている

ある程度以上の事業規模であれば、進行管理やbizとの調整やホワイトスペース埋めを専任でやっていてもバリューが出るとは思いますし、事業は好調だけど現場がぐちゃぐちゃ！みたいな状況でもバリュー出ると思います。

一方で、スモールチームで成長を目指すフェーズや「これから流れを生み出していかなきゃいけない」という状況では「この人がいるからプロダクトが良くなる」というバリューがないとPMは厳しくなってくるなと思います。

現に、スタートアップなどスモールチームで開発を行うところに来るエンジニアはコミュニケーション能力もそこそこ高くてビジネスにも関心があるので、PMが間に入らなくても進捗共有やアイディアブレストくらいは成立します。


「専門家としての自分の考えはあるけど、全体最適の意思決定はPMの方がクオリティ高い」という期待を持ってもらい、それに答え続けることが重要です。そのためには、ある程度のソフトウェア・デザインや技術の理解が必要です。

もう1つ、PMがソフトウェア・デザインや技術の理解を持つことによるメリットがあります。それは、要件定義・仕様策定の精度とスピードが跳ね上がることです。

何回か会議を重ねて作っていたものが自分の脳内会議だけで完結するようになります。そのアウトプットをたたき台に、各専門家と方向性のすり合わせや細部に神を宿すための議論をしていくことでクオリティアップに使える時間がとても増えます。


総合すると、プロダクトサイドでの活躍を目指すPMは、物事の抽象化とモデル設計のスキルを付けてデザイン方面を伸ばすのが早道だと思うということです。少し切り口は違いますが、最近言われている「デザイナーやること多すぎ」問題をPMサイドがヘルプしに行くイメージです。逆に、デザイナーがPMスキルを身に付けていくパターンも最近は出てきていて、とても理にかなっているなと思います。


実はPM & UI/UX Designerのキャリアも難しい

僕はソフトウェア・デザインと向かうようになってから、PM & UI/UX Designerを名乗るようになりました。

この辺りのスキルや実務感覚を身に付けたあとも、キャリア上の難しさは付きまといます。

プロダクトマネージャーとかプロダクト責任者とか、いろんな呼ばれ方をするようになりますが、キャリア目線で重要なことは2つかと思います。

1. パンクしないようにオペレーションを設計してチームマネジメントをすること
2. 経営側やビジネスサイドと「権限」の折り合いを上手に付けること

1つ目はまあ当然のことなので良いとして、難しいのは2つめです。

経営メンバーやビジネス側の責任者とうまく強みの分担ができている場合は良いですが、そうでもない場合の悩みをよく聞きます。

いくつも新規事業があるような大企業ならまだしも、スタートアップのように会社の経営と特定事業の運営がほぼ一体となっているようなフェーズでは、上手に権限分担ができずに最適解でない意思決定を飲まざるを得ない状況も発生します。

あまり良いことではないと思う一方で、僕の中でもこういう状況に対する最適解はまだ見つけられていません（誰か良い事例などを知っていたら教えて欲しいです）。僕自身、フリーランスとして独立した後に結局自分で会社を立ち上げるという選択をしました。その時に考えてたことはこちらのnoteにあるので良かったらご覧ください。

ずっと立ち上げ系の世界に身を置きたいのか、現場から離れて大きな事業を動かすロールにつきたいのかでも身の振り方は異なるように思います。

まああれこれ考えたところで、PMは事業特性やチームと切り離して客観的に評価できる能力やスキルが少ないので、結局はチームを強くして事業を勝たせるために必要なスキルを都度見極めて学習して成果に貢献して、一緒に働いた人から信頼を勝ち取ることだけ考えていれば良いのかもしれません。

最後にちゃぶ台をひっくり返してしまった気もしますが、これで終わります！

最後まで読んでいただき、ありがとうございます。 またタイミング見て記事を書くので良かったら見にきてください。