エンジニアから企画職をやって感じたこと・考えたこと
はじめに
今年1年、エンジニアと一部両立させながら企画職（モバイルアプリのプランナー・検索改善チームのPO）へのチャレンジを行いました。企画職の経験が全くない状態からの立ち上げにあたって、考えたこと・感じたことを記録としてここに記載しておこうと思います。
バックグラウンド
インターン・新卒と合わせて約5年ほどエンジニアとしてキャリアを積んできました。
基本的にはバックエンドを主軸としつつ、フロント・インフラなど（ここ数年はあまりできていないですが）、かなり雑食にさまざまな領域で開発を行ってきました。直近数年ほどは、ただもらったタスクを開発するというよりは、ある程度粒度の大きい施策や企画を、要件をプランナーと擦り合わせながら、開発可能な要件に落としていき、実際に実装を行っていくという動きをしていました。
なぜ企画職をやったか
前述したような、ある程度粒度や抽象度の高い開発タスクを一定こなせるようになった中で感じたことの一つが、自分が実装に入る前の段階の企画の重要性でした。
企画自体は、何かしらの課題を企画者がある角度で切り取ったものであり、その課題の捉え方が適切でない、もしくは解決可能でない場合、後ろの段階である開発や要件定義の段階で努力するといった作業では取り返しのつかないことになる場合が多いです。そしてその裏返しとして、適切な課題の設定による企画が実現されれば、より大きな成果が生まれます。
また、「仕事の中で行うエンジニアリング」というものへの興味が逓減してきたことも要因の一つかもしれません。
仕事の中で行う実装において、多くの課題が自分の手札で解決可能なものに見えることが増えてきました。もちろん、技術的により高度な実装を行う、といったHowの部分でよりこだわることはできたかもしれません。しかし、そうした部分で高度な実装を行う・高度な技術を身につけるといった部分も、自分の中ではある程度キャッチアップするのは難しくないだろう、という感覚を持っていました。また、仕事において行うエンジニアリングはチームで行うもののため、自分だけ高度なことをやっていても仕方がなく、80点ぐらいの実装でチームとして変更・運用可能な状態にシステムを置いておくのが最も良い状態ではないかと、個人的には考えています。
こうした中で、より課題解決において影響力が大きく、抽象度が高いもの、そして自分の中で比較的新たな領域であることから、取り組み方の糸口が見えづらい企画職にチャレンジすることを決めました。
何をやったか
モバイルアプリのプランナーとして1年ほど、プロダクトの検索を改善する検索改善のチームのPO（プロダクトオーナー）を半年ほど行いました。
モバイルアプリのプランナーとしては、グループで持っているKPIを向上させるための施策を立案し、それをエンジニアと協業しリリースしていくといった仕事を行っています。検索改善チームのPOについては、モバイルアプリのプランナーとはまた違った職責を担っており、別の難しさがあるため、ここでは主にモバイルアプリのプランナーとしての取り組みの中で感じたことを書いていこうと思います。
考えたこと・感じたこと
仮説のない企画は企画ではない
プランナーを初めてまず最初につまづいたことは「企画をどうやって考えるか？」ということです。
素直に取り組むとすれば、まずは自分たちのプロダクトを触ってみて、「いけてない」「使いづらい」といった部分を修正することを企画にすることでしょう。もしくは、「こんなものがあったら良いのではないか」といった機能を追加する企画を考えることです。このような形で生まれる企画が成功することも一定あるでしょう。しかし、そうしたあくまで「思いつき」と言えるような企画では不十分で、それによってどのように課題を解決し、グループのKPIを向上させるかという根拠が必要です。
根拠がなければ、それで何かしらの数値が改善したとしてもあくまで単発の改善になってしまい、企画による学習のループが回りません。また、本当の思いつきに過ぎないのであれば、「なぜ改善したか？」といった部分にも根拠が得られないことも多いのではないかと思います。
そうした根拠を作るために必要なのが、「仮説」であるという整理を自分の中で行ないました。
「この部分にこうした問題があり、この数値に改善可能性があるのではないか」という課題仮説、「この課題を解くことによって、このようにユーザーの動きが変容しこの数値が改善し、結果としてKPIが改善するのではないか」という打ち手の仮説をそれぞれ設定することによって、なぜその施策を行うかの根拠が生まれます。仮説については、課題仮説・打ち手仮説というようにざっくりと分けましたが、より詳細には分解していくことが可能であり、仮説の中により詳細な仮説、もしくは仮定が含まれ、それに対しても考えられる範囲でこうであろうという想定を持っておくことが重要だと感じます。
では、このような仮説はどのように作ることができるのか？というのが自分自身で感じた次の疑問でした。
仮説をどのように作るか
「自分たちのことをよく知ること」「周りのことをよく知ること」「ユーザーをよく知ること」の3点をこなすことが仮説を作るための最初のステップだと捉えています。この3点さえあれば、一定程度の施策立案はこなせるようになるだろうというのが自分自身の実感です。
自分たちのことをよく知ること
大きくは以下の3点で、自分たちのことを知るための作業を行いました。
- プロダクトの構造分解・KPI分解
- 事業の方向性・リソースの把握
- 過去の取り組みの学習
プロダクトの構造分解・KPI分解においては、かなり当たり前な作業ではありつつ、あらためて重要なプロセスだと感じました。
ただ漫然とKPIツリーを作るといった作業では不十分で、どこまで詳細に分解していけるか、これまでにない新たな切り口で分解ができているか、といった点が重要であるように思います。分解が不十分である状態で作る仮説においては、あまりに当たり前な仮説しか出てこないことが多く、ピントのボヤけたものになってしまいます。何かしら、他の人がやっていない程度に詳細な分解をする、新規性のある切り口で分解をする、といった作業を行わないとこれまでに生まれていない仮説は出てこないように思います。
そして、そうした作業を通して、自分の中にプロダクトの数値感がどのように動くのか、どのように連動しているのかのモデルをなんとなく想定できるようになることを目的としています。
事業の方向性・リソースの把握については、生まれてきた仮説の取捨選択をする上で必要な作業です。プロダクトを見ているだけで生まれてきた仮説だけでは不十分で、事業に存在する方向性やリソースの制限を受けつつ、優先度をつけ取捨選択していかなければいけません。
また、よく見落とされがちだが重要なプロセスとして「過去の取り組みの学習」というものがあると感じました。
より具体的には、これまでに行われた施策を全てリストアップ・分類して、どういった領域にどのようなアプローチがされ、どのような結果が出たのかということを把握することです。ある程度続いているプロダクトであれば、自分の前任に自分と限りなく近い課題に取り組んでいた人がいるわけで、その人たちの成果から学習し、それを踏まえて自分の仮説をブラッシュアップしていくことは必須であると感じます。
周りのことをよく知ること
「周り」とは、自分のプロダクトと類似している領域のプロダクトのことを指しています。つまり、自分のプロダクトと競合になるようなプロダクトのことをよく知ることが重要だと感じました。
前述の「過去の取り組みの学習」と取り組むべき理由については類似していますが、競合のプロダクトは、事業上のリソースの違いなどあれ、自分のプロダクト同様の課題に取り組んでいる可能性が高いです。他社のプロダクトについても自分たちのプロダクト同様の構造分解をするべきですし、数値分析はできないにしろ、プロダクトを触る上で機能の優先順位など数値感が透けて見える部分も大きいのではないかと思います。自分たちのプロダクトが解いている課題を別の方法で解いている場合、なぜそのような方法を取っているのか、という部分については何かしら自分自身で仮説を持っておくと良いと感じました。
ユーザーをよく知ること
自分たちのプロダクトを利用してくれているユーザーの行動や行動原理を把握しようとすることも同様に重要です。
ユーザーを知る方法については様々な方法がありますが、自分が行った方法としては、ユーザーごとの行動ログを一人一人ある程度観察することによって、それぞれのステップでのユーザーの行動原理を想像し、仮説を立てることです。行動ログから読み取れるものは非常に限られたものではありますが、それぞれのユーザーの行動をある程度の量を見ていくことで、共通している動き・異なっている動きなどが見えてくるため、改善の方向性なども見えやすくなるのではないでしょうか。また施策を考えるときにも、このような動きはユーザーは行わないのではないかという感覚も育てることができるように思います。
まとめ
約1年ほど企画職にチャレンジする中で、自分なりのやり方が少しづつ見え始め、成果も少しづつ出てくるようになりました。
取り組む中で感じたのは、企画・エンジニアといった領域にとらわれない、仮説的な思考や、自分・周りのことをよく知るといった基本的な思考の重要性でした。事業において新たな価値を生み出すことに仮説を立てることは必要不可欠ですし、自分や周りのことを知ることについては、「彼を知り己を知れば百戦殆からず」という古代中国の諺に始まり、何か戦略（≒施策）を考える上では常に重要なことであると思います。
企画職にチャレンジすることで、企画職だけにとどまらない汎用的な思考や方法論について学べたこと、新たな領域に取り組むときの自分なりの方法論が増えたと感じ、チャレンジによってとても良い経験ができたと振り返っています。
現在は検索改善チームのプロダクトオーナーも並行して行っていますが、また違ったチャレンジに取り組むことができていることから、この取り組みについてもいつかまた振り返って書ければ思っています。
11月に読んだ本
OSSのコードを読む時間を増やしたつもりだったけれど意外と3冊くらいは読んでいた。
Goインタプリタ本の影響で言語処理系への興味が出てきたので、コンパイラについても勉強していきたいと思い読んだ。証明の部分だったりをしっかり追っていたら割と読むのに時間がかかったが、本自体の説明はあっさりしていてコードを追わないと理解は進まない感じがした。コードはPL/0'というPL/0言語を少し変更したもので、これもどこかで別の言語にリプレースしてみたいなと思う。
会社に置いてあったので読んだ。「新人に読ませる本！」みたいな感じなのかなと思う。流石にこの辺りの本だとおおよそわかっていることが多くて、多少安心した。
低レイヤに降りていくにあたってOSの勉強を進めていきたいと考えていて、OSの軽めの本として読んだ。大まかな内容は基本情報や応用情報でやるような情報と変わらなくて軽く読めた。次はここらへんを読んでいきたいと考えている。
10月に読んだ本
10月前半は応用情報技術者試験があって、後半は https://github.com/ryo-imai-bit/Writing-An-Interpreter-In-Go-In-OCaml をやっていたので本はあまり読んでいない。
この頃から本を読むより、コードを書いたりコードを読むのが良いのでは？と思い始めてきた。本自体は新しい刺激があるし面白いが、受取り手のレベルによって受け取れるものが限られてしまうので、コードを書き、読むことで実力そのものを上げていきたい。脳に汗を書いていかなければ！
一応応用情報の本を読んだ。割と勉強したのに落ちていたら笑う。。。
9月に読んだ本
10月初めに応用情報技術者試験を受けることもあって後半はその勉強をしていて、4冊は読めなかった。
ソースコードを実行するまでの一つのやり方を学ぶことができた。lexer=>parser=>evaluatorという流れ自体は知っていたが、それがより意味として理解できたと思う。実際のところインタプリタを書くにあたってもバリエーションはもっとあるはずなので、この本でやっていることを再度０から自分で再現できるようになるところまでやりしっかり理解したいなと思った。のでOCamlで実装をしたりもしてみた。
この本は、マクロも扱っていてその実装なんかもとても勉強になった。この本きっかけに言語処理系に興味を持つ様になってきた。
先にGoインタプリタ本を読んでいたおかげで、多少理解しやすいところがあった。PHPではいろんな型のデータが最終的に同じ構造体で扱われている話などはとても面白かった。またGCなども参照カウントで判断しているのも興味深かった。本自体はPHPがどのように動くのかという話がメインというよりは拡張などを作ってその中で学ぼうという向きが強かった
8月に読んだ本
たまたま図書館にあったので読んでみた。業務でPythonは書くけれどPythonの細かい言語の機能みたいなところは全く把握していなかったので勉強になった。デコレーターとかFlaskで出てきた時に雰囲気でしか理解していなかったけれど面白い機能だなと思った。Pythonは構文レベルでの機能が多い割にごちゃごちゃしたコードにならないのは個人的に好きな部分である。
この本が今年読んだ本の中でベストだったと思う。
抽象度の高いベストプラクティスを扱っていながらも、内容が古びていないように思った。取り扱っている内容が、よりプログラミングにおける中心的、本質的なことがらをあつかっていて勉強になった。また基本C言語でプログラムが記述されているのでC言語の勉強にもなった。全体として理解しきれないとこもあり、特に9章の「記法」についてはこちらの息切れもあってコードと中身が理解しきれていないのでどこかで再読したい（コードはほとんど終えていない）。9章の内容としては、なにか問題を解決するプログラムを書く際の「記法」に注目して、問題に適した「記法」をもつ言語を選ぶ、もしくはない場合には自分で実装する方法について述べられている。そのなかでコンパイラやインタプリタ、JITなどの話もある。コードをしっかり追っていくと理解がかなり違ったので、他の本でも手元でコードを動かすことを心がけたい。
何か、課題解決であったりコードを書くときにこう考えるといいのだなと言うことが感じ取れたように思う。
学びが多い本だった。会社での実際の業務、ビジネス側とのコミュニケーションであったりといった部分や他のエンジニアとの関わりの中で活かせそうなことが学べた。ステークホルダーに共感したり、ステークホルダーの目的にそったソフトウェアをつくることがプログラムをつくるうえでの目的であることを割と自分は忘れがちだと思う。もちろん自分もステークホルダーで良いプログラムを書きたいといった目的はあっていいが、それより大きいものがあるはず。
エンジニアになる前にチラッと読んだことがあったが再読。色々なことをアルゴリズムで説明していくのが面白い。
7月に読んだ本
この月ぐらいから、重めの、技術について書いている本と、設計哲学だったりノウハウ本みたいな比較的読みやすい本を交互に読むようになった。
とても良かった。コンピューターという計算機が二進法の計算をしていて、それが積み上がっていくと実際に使っているような応用プログラムになるということ自体は知識としては持っていたが、そこのブラックボックスであった部分が少し理解できるようになった。特に、理論上の計算のモデルというよりも、電子回路で実際の物理世界の法則の中でどのように動かすのかという話が多くて新鮮に感じた。
この本を読んで、一番下の低レイヤの簡易的な構造を見たことで、それ以外のレイヤーのブラックボックスになっている部分の仕組みに興味が出るようになった。
いくつか哲学が書かれていたが、巷でよく言われているベストプラクティスみたいなものはここから来ているんだなと思った。早く試作品をつくることだったりは実際に意識したい部分である。特に考えすぎて手が動かない時とかは、作って失敗するサイクルを回す方が最終的に良いものができる感覚がある。
とても良かった。この本を読んで、一言にソフトウェアの文脈で「テスト」としてコードを書いたとしてもいろいろな種類があるんだということを初めて認識した。種類と言っても一般的によく言う開発段階でのテストの種類といったものではなくて、テストを書くとしても意図を意識してテストを書くべきだと思った。テスト駆動開発で書く種類のテストは基本的に「動作チェック」や「振る舞いのチェック」といった「自分の意図しているように動いているか」の確認の意味合いが大きいと思う。また、テストを書くにあたって自分の書くコードの第一の利用者になることから、コードのインターフェイスをまず考えるようになるのも良い習慣につながるのではないかと感じた。
実際に業務でのコードをTDDで書いて見たが、ミスも発見しやすく、良いものができた。TDDのプラクティスを実践する中で得られる習慣みたいなものは個人的にとても役に立っている。
一度読んだことがあったが、中身を忘れてしまったのでもう一度読んだ。何か、学習においておおよそのベストプラクティスは決まっている、そして世の中に出回っている気がしていて、自分としては受験勉強等で身につけたやり方でおおよそことがことが足りている様に感じている。書いていることはすごく良くて考え方として勉強にはなるが、特に新鮮なことは書いていないなと感じた。本自体はすごく考え方として勉強にはなるんだけど。
本当は「はじめて読む486」の方を読みたかったが、いきなり読むと難しい場合もあるそうなので、こちらを先に読んだ。
とても良かった。「CPUのつくりかた」でCPUが電子回路上でビット列を使い、データ、命令としてどのように実行しているかを理解することができたが、それより高いレベルの話として、実際にCPUでどのような命令が用意されていて、実際にレジスタやメモリへの命令を通してプログラムをどのように動作させるのかがより具体的に理解できたと思う。またCPUのアーキテクチャによって用意されている命令が違い、それが性能の差につながるといったことも理解しやすかった。
低レイヤについて学ぶと、ブラックボックスがなくなっていく感覚がありとても楽しいのでシステムプログラミングであったり、ネットワークプログラミングにも興味が出てきた。
OCamlでインタプリタを書いた
成果物
なぜ書いたか
読書記録にはまだ載せていないが10月ごろにGo言語でつくるインタプリタを読んで、使いたくてなかなか使えていないOCamlの練習がてらにOCamlで実装した。
書いてみてOCamlの勉強にもなったけれど、どちらかというと本の内容を再咀嚼するのにとても役立った。本のGoのコード自体を一応写経していたけれどOCamlに書き直すタイミングで、「あれ、これなんでこうなってるんだっけ？」というような部分が多々見つかったのでわかったようでわかっていなかった部分が潰せたと思う。特にEvaluatorについては処理のフローがあまり理解できていなかったし、マクロは書き直すまで何もわかっていなかったなと振り返ると思う。
OCamlに関しては、OCaml自体が書きやすく、Goの手続的なコードを割とそのまま書けてしまうためか、OCamlらしさのあるコードにはあまりなっていない。特にEvaluatorのところで相互再帰関数が長々と続いているところはかなり読みづらくなっていて、どうにかしたい。パフォーマンス的なこともあまり気にせず書いたこともあり、どこかで大きなリファクタリングはしたい。
OCaml自体は書いていてとても楽しい言語だった。型推論がしっかりしているので、固いコードの割に必要なコード量は少なくて良いし、コンパイラのチェックで全ての型のパターンを処理しなければいけないのもコーディング中に意図がまとまって良い。処理を細かい関数に閉じ込めて責務を分担させるとコード自体も読みやすくなるというのは、他の言語でコードを書いているときにも意識したい発見だった。本当に書きやすいのでちょっとしたCLIとか書くのにも良さそうだと思う。
実装を終えた後に、今回のインタプリタで動くMonkey言語の他言語実装を紹介している著者の方のサイトがあり、載せてもらった。
エンジニアを始めてから、社外の人が見るような形でコードのアウトプットをするのがほぼ初めてだったが、コードを書く際の意識も変わってくるので、どんどん外向きのアウトプットをしていきたい。
