2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
エンジニア経験が浅くともPOは務まるのか?(全1記事)
リンクをコピー
記事をブックマーク
堀内翔太氏(以下、堀内):エニキャリの堀内と申します。よろしくお願いします。(スライドを示して)本日のLTですが、このような流れでお話しできればと思っています。
自己紹介です。あらためまして、堀内翔太と申します。2021年6月にエニキャリに入社しました。それまで9年間ほどは法人営業ということで、IT業界とはちょっと無縁な、いわゆるレガシーな業界にいて、キャリアチェンジというかたちでエニキャリに入社しました。
なのでエンジニアとしての経験は1年半程度ですし、PO(Product Owner)を任されてからも1年程度というかたちになります。
今回の前提として、まだまだ経験が浅いので、試行錯誤段階です。なので「こうしたほうがいい」とか「ベストプラクティス」みたいな、そういったものを伝える意図はありません。
じゃあ目的は何かと言うと、私の話を聞くことで、例えば今POやってる方や「これからPOやってみよう」という方が、何かしら気づきであったり、「自分だったらこうするな」とか。そういったふりかえりとか、きっかけになればいいかなと思っています。
チームの状況です。今私が所属しているチームは全員で4人で、1人がフリーランスの方で2人が協力会社の方ということで、フルリモートでやっています。
プロダクトは大きくは3つ担当していますが、それぞれ完全に独立しているわけではなくて、関連性が高いということで3つ任しているというところです。
現在の業務としては、プロダクトオーナーとしての業務というところでは、いわゆる一般的な業務をやってるのかなというところです。並行して開発もやっているので、ビルドから本番リリースまで一気通貫してやっているようなところです。
振り返ってみると、POを任されたのは突然だったかなと。当時の業務を振り返ってみた時に、本当にタスクをこなす日々ということで、その時はPOを任せられる話はなかったと思います。
チームの状況としても、CTOの岩崎が1人でマネジメントをやっている状況で、やはりゆくゆくはその権限というか、マネジメントを誰かに委譲しなくてはいけない状況で。あと、その時社員は私1人でした。
そんな中、プロダクトのミーティングにCTOの代理で出席して、要件などをヒアリングしながら、初めてバックログ的なものを書いていって。いつの間にかというか、日が浅いうちに、POを任せられたというところです。
正直「非常に突発的だったなぁ」という気もするのですが、「それがベンチャーっぽいなぁ」というところもあり。前の会社じゃあり得ない(こと)ということで、「すごく新鮮だったな」という気持ちは覚えてます。
とはいえ、恥ずかしながら勉強不足で、POという言葉を知らなかったんですよね。よく“プロダクトオーナー”とか“プロジェクトリーダー”とか“プロジェクトマネジメント”とか、なんか似たような言葉がいろいろあると思うんですけれども、その時は「ざっくり全部同じような似たような」みたいな。そういう認識レベルで。
心境としてはすごく前向きなところもありつつも、よくよく考えたら不安要素しかない。挙げればキリがないんですけれど、不安な気持ちでもういっぱいだった。
ただ、入社してから放置みたいなことはなくて、何か困った時とか、困ったことがなくてもサポートをしっかりしてもらった経緯があったので、「まぁなんとかなる」という、勝手というか、そういった自信もあった記憶があります。
任せもらった時に取り組んだこととしては、「まずそもそもプロダクトオーナーって何か」という、そもそもそこを知らなかったので。まずきちんと自分の中で認識するべきだということで、教科書的な『プロダクトマネジメントのすべて』などの書籍的なものであったり、Webなどの知識を自分の中で整理しました。
(書籍やWebを)いろいろ見て、自分の一番の不安要素だった技術に関する知識不足。これが(POをするうえでの重要なスキルの中には)ない。これがないから、ちょっとホッとした。これでホッとする自分はどうなのかとちょっと思いますが、そこは1つホッとしたところではありました。
とはいえ、やはり技術的な知識がないと、ぜんぜん業務が円滑に進まない。やはり実務をやっていると、教科書どおりではないなと思うところではあるかなと思ってます。
円滑に進まない例もいっぱいあるんですが、本当に大事な仕事であるバックログを書くとかのところでも、外部の方に依頼しているところもあり、そこだけで解決する課題であればいいんですが、AWS serverlessの仕様とかを理解していないと適切なバックログが作成できないみたいな。そういったところもけっこう苦労した記憶はあります。
フルリモートの環境ではありましたが、非常に質問がしやすい環境ではあったので、もちろん自分でまずは調べて、不明なところはCTO岩崎であったり、わかる方にすぐの確認して、なんとかやっていけてたのかなというところです。
その中で私が大切にしてきたことでいえば、やはり一番は円滑なコミュニケーション。これはリアルでというところだけでなくて、テキストベースとか、幅広い意味でのコミュニケーションという意味です。
特に感謝の気持ちを表現するというところですが、やはり周りの方にすごく助けられてなんとか今までやってくることができたところがあるので、それはちゃんと表現して、「ありがとうございます」と言葉で表すようにしていました。
ちょっと話はそれてしまいますが、エニキャリで働いててすごくいいな、働きやすいなと思うところの1つが、「ありがとうございます」「助かりました」「それイイね」みたいな、ポジティブなやりとりがけっこう日常的に行われてるんですね。
それがけっしてメンバー間だけではなくて、経営陣の方、代表の小嵜であったりCTOの岩崎、また他の経営陣の方もそうですが、本当にささいなことに対しても「ありがとう」「それイイね」「助かる」とかの声かけがすごくされていて。それはすごく風通しがいいというか、非常に気持ちよく働ける環境なのかなと。そこは1ついいところかなと思っています。
ごめんなさい、(話が)それてしまいましたが今後の課題ということで、開発チームのミーティングをより建設的なものにできればと思っています。正直、これはPOとしてという意味では逸脱しているところではあるかもしれないんですけれども。
例えばですが、やはり開発とかの進捗が出た時に、どうしても工数が遅れてしまう時ってあると思うんですよね。そうした時に、例えば「こうで、これはこうだからできます。(でも)ちょっと時間かかる」みたいなことを聞いた時に私ができることって「あ、なるほどです。ありがとうございます。がんばってください」みたいな。それだけで終わっちゃう。
(それは)そうなのですが、CTO岩崎のやりとりとか、開発チームのミーティングを見ていると、わからない(ことや)つまずいたこなどに対して、「それはなんで?」と(聞く)。
その言い方だとちょっと詰めてるような感じがしてアレですが、できないことに対して掘り下げたり、解消する方法のアドバイスとか、建設的な議論ができるようにミーティングを持っていっているところがあるので、自分自身もそうしたことができるようになって、より(良い)開発チームを築けていけたらと思っています。
最後に。結論としては、周りからのサポートがあればなんとかなるのかなと思っています。
ということで、私のスピーチは締めたいと思います。ありがとうございます。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには