写真のポートフォリオサイトを作った
今年に入ってからぼちぼち計画していた写真ポートフォリオサイトが、年末になってようやく公開できる状態まで仕上がった。
夏前には完成しているつもりが、サボっていたら冬至になってしまった。寒い。
作ったもの
実際の製作物はこちら ↓
なぜ作ろうと思ったか
今回、ポートフォリオサイトを作ろうと思った目的はふたつ。
- 趣味で撮り溜めた写真を、外に向けて発信するギャラリーを持ちたかった
- Web 開発の最低限のスキルを身につけたかった
まず、登山や写真を趣味にしてから 7 年以上経っているなかで、これまで撮ってきた写真を発信する場というのがあまりなかった。 Instagram や YAMAP に写真の投稿自体してはいるが、それよりも自分のポートフォリオとしての場を持って、そこに作品を並べたいと思っていた。
そんなサイトを作る手段として、今は WIX や STUDIO のようなノーコードでサイト製作ができるプロダクトがたくさんあるので、それを使えば時短になる。 時短にはなるが、今回はもうひとつの目的として、Web 開発のスキルがほとんどない自分にとっては、最低限のスキルを身につけておきたいという願望も同時にあった。
というわけで、写真のポートフォリオサイトを自作することにした。
どうやって作ったか
使用した技術は以下。
- React + Next.js → Web ページ本体
- microCMS → コンテンツ管理（写真・記事）
- Vercel → ホスティング（ドメインはお名前.com で取得。1 年間 380 円。課金したのはここだけ）
いわゆる Jamstack 構成をとっているが、完全ではない（一部ページに SSR を採用）。 アーキテクチャとしては一般的な構成なので、システムの詳細は割愛。
ところで、スキルとして JavaScript の基礎も怪しい自分が、いきなり React に手を出したのは悪手だったと思う（しかも TypeScript で）。 正直、基礎学習を雑にすっとばして雰囲気で実装しているので、まともなフロントエンドエンジニアにソースコードを見せたら卒倒するだろう。
それでもそれっぽいものができてしまうというのは、Web フレームワークのすごいところ。
サイトの構成
今回作ったサイトは見てのとおり、ページ数を最小限に抑えた非常にシンプルな構成にしている。 Next.js の pages/ 配下のソースファイルも 6 つしかない。
トップページ
トップページは、背景画像を 1 枚設定しているだけの単純な構造。 画像データは public ディレクトリに直接設置して、ハードコーディングした。 画面幅に応じて 2 枚の画像が切り替わるようにしている。
ギャラリー
ギャラリーページは、写真をいくつかの代表的なジャンルにわけてピックアップしたショーケース的なページ。
こだわりポイントとしては、読み込む枚数を毎回 20 枚に固定しつつ、シャッフルして表示している。 静的に生成するとビルド時にラインナップが決まってしまうので、サイト訪問時に毎回内容が変わるようにこのページだけ SSR になっている。
ストーリー
ストーリーは、ブログでいうところの記事。いつもは登山を通して撮影も楽しむといったスタイルがメインなので、写真単体ではなく、各登山でどんな風景に出会ったのかというのを、記事形式で文章付きで整理した。
プロフィール
一応ポートフォリオサイトなので、自分のプロフィールページも作った。
よりポートフォリオ色を強めていくなら、ここにフォトコンの入賞歴なども載せていけるといいかもしれない。最近フォトコン応募してないなぁ...
microCMS の API スキーマ
ところで、コンテンツ管理に使用している microCMS にはいくつかの料金プランがあり、hobby プランであれば無料で利用することができる。
個人開発の場合、メンバーは 1 人で済むので、API を 3 個以内に抑えられるかどうかで hobby プランで足りるかどうか判断することになる。
結局、今回はちょっとした工夫をすることで、使用する API を 2 個に抑えることができた。
- 写真 - image : 画像 - caption : リッチエディタ - tags : セレクトフィールド - ストーリー - title : テキストフィールド - text : 内容 - eyecatch : コンテンツ参照 - 写真 - photos : 複数コンテンツ参照 - 写真 - startAt : 日時 - endAt : 日時
ちょっとした工夫というのは、写真をうまく使い回すことでギャラリーとストーリーの両方で共有できるようにした。
ギャラリーページでは、写真のタグで絞り込んで画像を抽出して表示している。 また、ストーリーには複数の写真を紐づけることで、ストーリー側では直接画像フィールドを持たないようにしている。
こうすることで、写真とストーリーの 2 つの API さえあれば、今回のようなサイト構造は実現できる。
今後改善したいこと
画像の高速化
画像の表示には next/image を使っていて、これはパフォーマンスも最適化してくれるという代物なのだが、どうもパフォーマンスが悪い。純粋に、表示が遅い気がする。
img タグをそのまま使ったほうが明らかにパフォーマンスがいいということが起きていて、ちょっとここは勉強が必要。
ギャラリーページの SSG 化
これは真っ先にやらないといけない。 ほぼ静的ページなのに、画像を毎回シャッフルしたいというだけでサーバーサイドでレンダリングしているのは目的と手段がミスマッチしていると思う。 もはや、シャッフルする仕様じゃなくていい気がする。
ストーリー一覧ページの改善
7 年分の記事を単一ページに並べている現状は、年別のアンカーリンクをつけているとはいえ、さすがに長すぎる。 年ごとに別ページにするなどといった工夫をしたい
ストーリー詳細の内部リンク
現在はストーリー詳細がどん詰まりになっているが、ここから関連ストーリーに飛べるようなセクションを起きたい。 その場合、近い関係のストーリーを関連づけるようなフィールドを新たに作らないといけないので、どのようにカテゴライズするかは考える必要がある。
まとめ
ずっと作りたいと思っていた写真ポートフォリオサイトがやっとできたので、まずはよかった。
普段の仕事ではふわっとした事象を扱いすぎて、成果物としての絵姿が見えているものづくりは純粋に取り組んでいて気持ちがよかった。
ただ、フロントエンド界隈の技術の変化は早すぎて、片手間に触っているうちはすぐについていけなくなると思ってしまった。（2 年前くらいの記事はもう参考にならなかったりする）
いつかはこのブログも自作ブログに移行したいなんてことを思いつつ、まずは完成した写真ポートフォリオサイトを、自分のギャラリーとして運用していこうと思う。
ちなみに、登山と写真を始めた 2015 年まで遡って写真を microCMS に突っ込んで、ストーリーもひとつひとつ文章を手入力したのだが、この作業は修行だった。microCMS にアップロードされている写真は 7000 枚。こんなやつが無料ユーザーですいません。
高速道路の安全運転から考える、快適な登山のペース配分
登山をしていると、息が切れて思わず足を止めて休んでしまうことがある。
息が整ってきたらまた歩き出し、次第にまた息が切れて休む。歩いては休み、歩いては休みと繰り返す。
そして、登り切ったときにはすっかり疲れ果てている。
この登り方は、自分自身の心肺や筋肉にとって非常にリスクが大きく、安全な登山とは程遠い。
ペース配分に気を付けるだけで、そういった疲労とは無縁の、快適登山を楽しめるようになる。 しかも、頑張ってハイペースで登ったときと大して時間も変わらないのだ。
このことを、例え話と実際に行った検証結果を交えて説明してみる。
高速道路の運転で例える
登山の安全なペース配分は、高速道路を車で走る際のスピードで説明するとわかりやすい。 以下のパターンをそれぞれ考えてみる。
80km/h で走行車線をずっと走り続ける
ときどき前の車を追い越すために追越車線を使ったりしながら、100km/h で走行する
2 つのパターンを比べてみると、後者は前者に対して運転の疲労が大きい。 （これは乗っている車にもよるが、ジムニーで 100km/h なんかで走るとかなり疲れる）
しかも、1 時間走行する場合を考えると、両者はせいぜい 15 分の差でしかない。 サービスエリアでソフトクリームを食べてくつろいでいるドライバーの様子を見る限り、この 15 分の差はまったくもって重要ではないだろう。 つまり、速く走るために神経を尖らせたり必要以上のハンドル操作を行なうというのは、ほとんど余計なコストとみなせるわけだ。
登山のような有酸素運動においては心拍数が重要
話を登山に戻そう。
高速道路の例えで言いたかったことは「急いでも大した時間の差にはならない上に無駄なリスクを伴う」ということである。 車の運転の場合は、速度という定量的な指標があった。では、登山ではどうしたらいいか。 これは有酸素運動すべてに当てはまるが、登山では心拍数を意識することで運動負荷をコントロールできる。
以下は、実際に私が同じコースを 2 回歩いたデータである。
まず、心拍数を特に意識せずに登った。（左） このとき、冒頭に書いたように「息が上がっては休み、また歩き出しては息が上がって休む」という登り方になった。 全体を通してかなりキツかった。
次に、心拍数を 160 以下になるように意識して登った。（右） すると、途中で息が上がって立ち止まるということは 1 回もなく、頂上までノンストップで歩くことができた。 頂上に到着したときの疲労感も、心拍数を意識せずにオーバーペースになったときよりもはるかに余裕がある。
平均心拍数でいうと 15 程度の差。しかし、この差がかなり体感として大きかった。
しかも、運動時間に注目すると、たったの 10 分しか差がない。疲労感は 2 倍くらい違ったのに。
山に登るとき、少しでも早く進みたいと思ってペースを上げてしまいがちだろう。 そのペースは必ず最後までもたないため、途中でバテて立ち止まることが増えてしまい、結果として休まずゆっくり登った場合との時間差が埋まっていく。
こうしたことから、無理のないペースを維持して登ることは、オーバーペースで休憩を挟みながら登る場合よりも大幅に体力を温存できるうえに、余計な休憩を必要としないため時間はそれほど大きな差にはならないということがわかる。
実際に同じルートを使って検証したことで、身をもってこのことを感じることができた。 今後、自分を痛めつける目的の負荷トレーニングでない限り、心拍数 160 以下を維持して登りたいと思う。
ちなみに、この快適な心拍数は個人差が大きいため、これを実践する際はあなた自身にとっての「立ち止まることなく歩き続けられる心拍数」を見つけてほしい。
また、そのときの体調などにもよって適正ペースは変動するため、心拍数のみを見ていても不十分なケースもある。主観的運動強度や登高速度といった指標も同時に見ることで、適切なペース配分ができるようになるが、今回はこのへんにしておこう。
時間をかけただけアウトプットの質が約束されるような仕事はなかった
ソフトウェアエンジニアとしてのキャリアの限界
キャリアのスタートは iOS エンジニアで、ときどき Web をつまみ食いしながらも、2020 年まではそのキャリアの大半を iOS エンジニアとして過ごした。
しかし、数多の敏腕エンジニアと一緒に仕事をしているうちに、「この分野はこの人たちに任せた方がよい」と考えるようになった。
たとえば頭の中に思い描いている機能も、自分の技術力が伴わず思うような結果が出ないといったことはザラで、時間をかけただけの成果が出ないことにもどかしさ を感じていた。
そんな葛藤と闘っていたとき、あるきっかけでプロダクトマネージャーになった。ようやくこの葛藤から解放された、ように思えた。
無知の知
プロダクトマネージャーとして過ごした 1 年間は、とにかく考えることと決めることが仕事だった。それもエンジニア時代よりも広い視点で考えて意思決定しなければならない。 どのようなユーザー課題を、どのような優先度で解決するかを考え、そこにどれだけのリソースを投入して、どれだけのビジネスインパクトを得るか。といった具合に、持つべき観点は多岐にわたる。
プロダクトマネージャーの役割は、ビジネス・ユーザー・テックの 3 つが交わるところには居るのだと一般的には説明される。
半年ちょっと過ぎたあたりから、「無知の知」に辿り着いた感触があった。それまで先輩 PdM のやり方を真似したり、ときには自己流でチームを運営していたが、それではうまくいかない場面に何度か遭遇したことで、自分が知らないことに意識が向くようになった。
エンジニア時代に「プロダクトマネージャーになれば、"時間をかけただけの成果が出ないことのもどかしさ"から解放されるだろう」と盲信していた自分は、プロダクトマネジメントという仕事を深く理解していなかっただけで、蓋を開けてみれば結局あのころと同じ葛藤と向き合っている自分がいた。
このとき、プロダクトマネジメントも「時間をかけただけの成果が出ないことのもどかしさ」を感じる仕事なんだと悟った。それもエンジニア以上に。結局のところ、プロダクト開発に関わる以上、これとは向き合っていかなければならないのだろう。
自分の仕事を、代わりの効かない仕事にしなければならない
ここで大切になってくるスタンスが、情熱を持つということなのかなと思い始めた。
コードを書くわけでも UI デザインを作るわけでもない自分がなぜ開発チームにいるのか。それは、確かな価値を世の中に届け、ユーザーをよりよい方向へと導くためではないか。
時には真っ直ぐに「俺が最高のプロダクトを作るんだ」という強い情熱を原動力に、意思決定を繰り返してチームをたしかな成果に導く。
プロダクトマネージャーは、軸を持たないで惰性で仕事をしていると、ただの何でも屋になる。そしてその仕事はいともたやすく代替されてしまうだろう。
エンジニアのころの自分は「自分の仕事はより高いパフォーマンスを発揮できるほかのエンジニアによって代替される」と考えた結果、自分自身のエンジニアとしての価値を下げていた。
プロダクトマネージャーになってもこれは同じことで、自分の仕事は最終的には代替されてしまうのか、それとも唯一無二の価値ある仕事にしていくのかは、自分次第なんだろう。
はっきりとした軸を持てるようになりたい。まだそこは模索段階である。
プロダクトマネージャー 1 年目の振り返り
仕事でプロダクトマネージャーにロールチェンジしてから 1 年経つので、この 1 年間を振り返ることにした。それをブログに書き残してみる。媒体は普段使っている自分用のメモ帳（Notion）でもよかったのだけど、公の場に出す文章にすることでちゃんと自らを省みる気になるかなと思い、2 年くらい前に作っただけで放置していたブログを掘り起こした。当時のセンスでつけたドメインが気に入らないので早く変えたい。
あらすじ
エンジニアからプロダクトマネージャーへ
会社では、新機能開発が始まるたびに必要なエンジニアやデザイナーがアサインされて、プロジェクトが立つという流れだった。そこにプロジェクトリーダー的な役割がエンジニアから選ばれる感じ。自分はだいたい何らかのプロジェクトのリーダーとして仕様策定や進捗管理といったマネジメント業務をしつつ、エンジニアとして開発も兼務していた。これは正直回らないことが多くて、自分も iOS エンジニアでありながら、プロジェクトには別の iOS エンジニアをアサインして、開発をほぼ丸投げしていたりした。つまり、肩書きこそないものの当時から実質的にプロジェクトマネージャーとして立ち回っていた。
そして、ついに 2021 年 1 月からプロダクトマネージャーになった。きっかけは同じくプロダクトマネージャーだった同僚からの声かけ。これは素直にありがたい話だった。もともと自分はエンジニアとしてのキャリアを突き詰めていく構想は持っていなかったから。ここで転機が訪れたのは素直にラッキーだった。
チーム固定制
というわけで、自分は会社の 3 人目のプロダクトマネージャーとして合流した。そのタイミングで、これまで機能開発のプロジェクトが立ち上がるごとにチームを編成・解散と繰り返していた組織形態を変更し、プロダクトマネージャー含む各職能ごとに1 人以上ずつをアサインした「機能チーム制」をとり、チーム編成を固定してこれまでとは逆に開発プロジェクトをチームに割り当てていく方式になった。会社では 3 チーム制などと言っている。1 チームあたり 7,8 名で編成されている。
チームが固定になったことで、いくつかメリットが出てきた。
- プロジェクト未満のタスクでも必ずどこかのチームにアサインすることで、全体としてリソース状況が俯瞰しやすくなった。これまでは細かいタスクは職能チームに直接投げていたりして、見えないところでリソース過多が起きていたり、タスクの動きが追いにくかったりしていた。
- 機能をリリースしてもチームは解散しないので、継続的な改善がしやすい。
一方で、デメリットもある。ただいずれのデメリットもチームを固定したことに直接起因する問題ではなく、運用の問題。プロジェクトの割り当ての仕方や会議体の工夫でどうにかできるはず。
- 特定の領域の機能をひとつのチームで担当し続けることによって、チーム単位の属人化が起きやすくなっているような気がする
- 上記に関連して、担当領域の機能に対するオーナーシップが強くなりすぎるあまり、それがナワバリ意識のようなものに変わり、他チームの開発と干渉しようものなら建設的ではない議論が巻き起こる（しかもだいたいそれが相手チームの見えないところで交わされるので建設的ではないと書いた）
といった感じで、チーム固定制をとって、1 年間同じチームメンバーと仕事をした。
振り返り
よかったこと
- とにかくいろいろな機能をリリースした。会社の成長曲線の傾きを変えるような巨大なインパクトを伴うリリースこそできていないものの、限られた場面では確実に利便性が向上するような機能を着実に開発し、チームとしてフル稼働した。言い換えるとプロジェクトマネジメントは問題なくやれた。兼任プロジェクトリーダー時代は専門としていなかったステークホルダーとの折衝も今年に入ってからは積極的に行った。
- 8 月くらいから期間を空けて 4 日間にわたり、会社の指示で外部講師によるマネージャー向けの研修に参加した（経営層含む社員約 20 名が参加）。これが自分の考え方を変える大きな転機となった。具体的には、マネジメントとは人と仕事の両輪を回すことにあるということ。人を伸ばせば、その人から生み出される仕事の成果は大きくなるという考え。プロダクトマネージャーというと「ユーザーに価値あるものを届ける」などといった仕事としての成果にフォーカスしてしまうが、結局のところその成果を生み出しているのは人なので、人のマネジメントも同じくらい重視しなければならない。もともと自分はプロダクトマネージャーなのだから人のマネジメントは自分のい仕事ではないと考えて自分のチームメンバーのケアを必要以上にしないようにしていたのだが、これでどうもうまくいかなくて低迷していた時期が夏前にあったので、自らの課題にタイムリーな研修だった。
- 人が大事なんだとわかったところで、さっそく自分のチームで 1on1 を独自に実施した。うちの会社は 1on1 を導入していて、人事評価と紐づいている。しかし、3 チーム制のメンバーの 1on1 相手は別（そのメンバーが所属している職能チームの長であることが多い）なので、チームのプロダクトマネージャーである自分が、自分のチームのメンバーのことをよく知らないまま一緒に仕事をしているということが起きていることに気がついた。個々のモチベーションやキャリアプランに沿った適切な業務アサインをできるように、独自に 1on1 を実施した。たぶんこれは会社で自分が初めて。来年も定期的に実施してお互いの頭の中のギャップを埋めながら仕事をしたいと思う。
- 目の前の問題の解決策や新機能を考える時、解決したい課題や目的を明らかにしたうえで考えるようになった。当たり前のことなんだけど、解決策に固執しているうちに目的を見失って、「それで解決したい課題ってなんだっけ」ということがよくある。でもやっぱりたまに迷子になることがあるので、引き続き意識的に取り組んでいく。
反省点・課題
- 自分は完璧主義っ気があるのだが、それが悪い方向に働いているのではないかと思う場面があった。例えば、議論のたたき台を作ろうと思ったらほぼ完成形を作ってしまい、チームからすると細かい点のフィードバックしか差し込む余地がない状態になっていたりする（説）。自分が事前に煮詰めてチームに持ってきた話がすんなり決まったときは、案外これに陥っていて、チームの活気を殺してしまっているのかもしれない。これだと自分がもし病気で寝込んだらチームが方向性を見失ってしまう。プロダクトマネージャーとして自分は「なぜ作るのか」や「叶えたいことは何か」といった WHY の領域にできるだけ多くコミットして、WHY を深いレベルで共通認識にすることが求められるはず。HOW の部分はチームの文殊の知恵で組み立てるほうがいいだろう。
- 意識的にも、無意識的にも、チームにとって "良い人" であり続けようとしていた。その結果、チームメンバーに面倒な思いをさせないようにと雑務は自分が巻き取ってしまったり（その結果忙しくなって本質的な仕事に時間が使えなくなる）、チーム内で出てきたアイデアをなんでも取り入れて開発スコープを肥大化させたりした。
- 1 週間の自分の仕事の出来に納得がいかなくて、休日も仕事のことを考えっぱなしだったことが多かった。頭の切り替えがうまくできてなくて、翌週もそのまま中途半端な成果で終わるという悪循環。優秀な人ほど休日や夜の時間をしっかり自分のために使えている印象。
- プロジェクトマネージャー的なマインドが抜け切っていない。スケジュール通りに機能リリースするのが一般的にはプロジェクトマネージャーのミッションなのだけど、プロダクトマネージャーはその先の成果を追い求めなければならない。アウトプットではなくアウトカムにコミットすべしってやつ。
主に読んだ本
プロダクトマネージャーは経験値が物を言う職種ではあるのだけど、それでも知識の引き出しがないと、行動が起こせない場面が実際にある。とりあえず本が言ってたことをやってみて、うまくいったら自分のものにできるし、うまくいかなかったら反省を踏まえて改善して次のアクションに繋げればいい。簡単に言うけど、実際の現場では過去の学びを忘れていて同じ轍を自分で踏むことがある。まずはこれ自体を反省しないといけない。
まずは世の中的にプロダクトマネージャーってどういう役割の人なんだろうということを理解するために、とりあえずプロダクトマネージャーのバイブル的な本として筆頭に挙げられるようなものを何冊か読み漁った。
もともと読書が好きじゃなくて、本を読んでいる時間は基本的に面白くないんだけど、今年の前半はコンスタントに月 1 冊くらい頑張って読んだ。
- リーン・スタートアップ
- INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
- プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- 外資系コンサルが教えるプロジェクトマネジメント
- プロダクトマネジメントのすべて（読み通さず辞書的に使っている）
- プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ（読み途中）
来年の抱負
- 自分の得意領域・伸ばしたい領域を明確にしたい。究極的にはプロダクトマネージャーって全部できないといけないのだけど、関わる領域が広いからこそ、軸がどこかにないとただの何でも屋になる。今やっていることが自分がやるべきことなのかどうか分からないままやり続けるという状況に陥ってしまう。伸ばしたい領域がはっきりしていれば、その領域の仕事を積極的に取りに行ったり、自ら生み出したりといったプラスアルファの行動ができるようになるはず。
- 得た知見を概念化して再利用可能にする。セルフ車輪の再発明をしない。特に、「こういうときどういう流れでロジックを整理したらいいんだっけ。前もあったな」「こういうときどういう判断基準で意思決定すればいいんだっけ。前もあったな」ということがあっても、過去の似た場面で場当たり的に対応したせいで知見として身についていないのが現状。
- プロダクトのビジョンを確立して、自分たちのプロダクトはどこを目指しているのかを明らかにする。これがあれば、プロダクトのどこを伸ばしていくべきなのか、どのユーザー課題が重要なのかといった判断基準が持てるようになるはず。開発チーム全員の目線も揃いやすくなり、マネージャーが細かいところに入らなくてもチームが自走するようになるのではないかな。
- もっと情熱的になる。唐突に根性論だが、プロダクトマネージャーたるもの、人一倍プロダクトを良くすることに想いを燃やしていないとダメなんじゃないか。マネージャーになってからの自分はなんかすべてがいい感じに回るようにフニャフニャしている感じがする。
駆け出し期に立っている自分にとって、体系的な知識のインプットは大事だが、とくにプロダクトマネジメントのような抽象的な領域の職種は、会社の数だけ知見があるようなものなので、気をつけないと情報過多に陥る。インプットはほどほどにして、さっさと実践して、学びを概念化して再利用可能な知見に落とし込むほうが自分にとってプラスになるだろう。
あとは本やインターネットで得た知識をちゃんと自分の組織やプロダクトのコンテキストに合わせてアレンジして使わないと、現場感覚とズレてなんか変な感じになると思う。この点をしっかり意識しながら仕事する。ちゃんとジブンを持った骨太なマネージャーでありたい。
まだまだ書ける話はあるけど、いったんここで一区切り。 このブログが続いていくようなら、定期的に頭の整理を兼ねて小出しにしていきたいと思う。
