Csabiのキャリアの歩み

開発の世界へのきっかけは何でしたか？

比較的早い時期に始まりました。ビデオゲームをプレイしてコンピューターに興味を持ったことがきっかけです。大学の専攻を選ぶ際に、コンピューターサイエンスを選びました。

最初の瞬間から、最初に思っていたよりも多くのことが求められていると気づきました。最初のうち、プログラミングの授業はギリギリ合格という状態でした。

1年目が終わった後に立ち止まって振り返り、エンジニアになりたいなら科目でほぼ不合格になってはいけないと自分に言い聞かせました。

翌年は最高点で合格し、これがソフトウェア開発の知識の基盤となりました。これが学業中の収入源となり、他の学生への個別指導を引き受けるようになりました。次のセメスターには余裕のあるスケジュールを取り、大学では教えられない経験を積むためにテスターとしてLogMeInで働くことにしました。自動テストを学ぶつもりでしたが、手動テストしか機会がありませんでした。ある日、Craft共同創業者のViktorのメールが大学のメーリングリストに届き、Distinctionというモバイルエージェンシーでモバイルソフトウェアテスターの求人があるとのことでした。これは完璧だと思い、モバイル開発者へのシフトができると考えました。

はじめの頃

週16時間働く予定でしたが、仕事が本当に好きでチームにもうまく溶け込めたため、自由な時間をすべてそこで過ごしたいと思い、すぐに週30時間働くようになりました。もう虜になっていました！オフィスにたくさんの時間を費やし、授業に出て、そしてすぐに戻ってきていました。

Distinctionが成長するにつれて、もっと多くのテスターが必要になりました。この時期に20代前半でラインマネジメントのスキルを磨き始めました。それは大きな挑戦で、初めてのメンティーはDistinctionで初めてのハンガリー語非ネイティブの社員で、自分より年上でもありました。チームに溶け込む手助けをし、日常的な技術的なことを教えなければなりませんでした。

この時期は週60時間働いていたと思いますが、それは要求ではなく情熱でした。しょっちゅう仕事の後に残って他のメンバーとテーブルサッカーをしていました（クラシックなスタートアップの行動😅）。Skyscannerがバイスキャナーを買収した後、物事は変わりました。そのより大きな組織の中で、日常業務や貢献に対するアプローチを少し調整しました。大きな会社の中での自分たちの道を見つけていました。

Skyscannerへの統合後に何が変わったか？テストからリリースプロセスの自動化と管理に移ることができました。2週間ごとのiOSとAndroidの自動リリースを達成するまでに1年半かかりました。これは本当に誇りに思っていることです。リリーストレインがあり：水曜日に、翌週はAndroidリリース、その次の週はiOSリリースという具合でした。複数のチームがアプリに取り組んでおり、その週に間に合わなかった場合は2週間後の次の「トレイン」に乗ることができました。

これがキャリアのテスター/リリース自動化パートのピークでした。

新しいCTOの到来とともに、テストは開発者の仕事の一部であり、エンドツーエンドのオーナーシップとより良い品質を実現するべきという新しい考え方が生まれました。もちろんこの原則には同意しますが、それは自分の仕事が不要になることを意味し、別のロールに移るか退職するかを選ばなければなりませんでした。これがソフトウェアエンジニアリングに移行する時でした。最初はAndroidエンジニアとして働き、1年後にプロダクトマネージャーになりました。

ウェブ開発への転身はどのようにして？

Skyscannerでの激しい時期の後、3ヶ月間の休憩を取り、電気自動車で何かを作るという趣味のプロジェクトに没頭しました。車の種類、航続距離や価格などのデータをExcelシートに持っていましたが、ウェブページの方が適していると気づきました。

それまで経験がなかったので、ゼロから始めてプロとしてできるようになるまで学びました。

プロダクトマネジメントにも再挑戦しましたが、フォーカスがプロダクトよりもマネジメントに向いていると感じ、彼らは自分に満足していたものの、退職することにしました。

Craftにはどうやって入社したのですか？

フリーランサーとして働いていたとき、ViktorとBálintから安定性チームへの参加について連絡がありました。

Craftという製品と人々に非常に興味を持っていましたが、モチベーションが持てないためテストとリリース管理には戻りたくありませんでした。

機会があればウェブエンジニアとして参加したいと伝え、製品開発の経験はあるがウェブ開発の経験がないためジュニアだと言いました。スキルを向上させるために継続的に努力していると述べ、連絡を取り合うことで合意しました。

6ヶ月後、ウェブチームの空きについて連絡がありました。ポジションの保証はなく、当時チームを率いていたウェブチームのプリンシパルプロダクトエンジニアのSipiとの面接だけでした。面接を受け、ありがたいことに知識が十分あってジュニアの役割でスタートすることができました。

プロジェクトや役割はどのように変わりましたか？

Craftのクローズドベータ、その後オープンベータリリース、そしてウェブバージョンのパブリックリリースに関わり、合計30〜40の機能に携わりました。関わっていない部分を言う方が簡単かもしれません。おそらくコアデータ同期だけです。😄

入社時の最大の課題は何でしたか？

おそらく技術的な知識を習得することでした。Reactを扱ったことがなかったので、開始前にコードベースで効果的に作業できるよう準備するために時間を費やしました。チームが自分の高い知識レベルを見て驚いたことを覚えています。

2番目の大きな課題はCraft製品の複雑さで、製品のある部分に触れたときに他の部分にどのような影響があるかを理解することでした。

あなたの「赤ちゃん」プロジェクトはどれですか？

Craftの多くの部分が好きなので、一つだけというのは難しいです。でも2つの候補を挙げることができます。

まず、公開ページの共有アナリティクスを挙げます。今はあまり関連性がないかもしれませんが、素晴らしい機能で素早く提供されました。公開ページの使用状況と訪問者数に関する複雑なアナリティクスチャートを含む独立したコンポーネントです。アプリチームと同じものよりも効果的に、美しく、そして速く開発したという素晴らしいフィードバックを受けたことを覚えています。ユーザーアナリティクスと可視化にも興味を持っていたので、毎日使用されるわけではない特定のユースケース向けの機能であっても、自分にとって完璧なプロジェクトでした。

2番目の候補は、ページの背景とページセクションで、ウェブエディターと共有ページに導入されました。大きな視覚的インパクトがあり、それがドキュメントに追加された後、ページはまったく異なる見た目になりました。

エンドツーエンドのオーナーシップはあなたにとって何を意味しますか？

自分自身をソフトウェアエンジニアではなく、プロダクトエンジニアと表現しています。最も技術的に優れたソフトウェアエンジニアではなく、深い技術的専門知識で知られてきたわけでもなく、それを優先事項にしたかったわけでもありません。

むしろ、最高の製品を構築するためにフォーカスと知識を使いたいです：アイデアから、プロトタイプの構築、機能するかどうかの確認、スコープをどこでどのように削るかの理解、エッジケース、ボトルネックの解決、全ユーザーへのスケーリング、料金パッケージへの組み込み、リリースへの導入、そしてユーザーフィードバックのフォローアップまで。

Craftでの最も大変な時期は？

2つありました。1つ目は2022年夏にリリースされた「One-Click Team」で、チームベースのサブスクリプションと組織モデルへの変更が行われ、チームとチームサブスクリプションを管理するミニアプリも含まれていました。ウェブ開発の部分だけでなく、ネイティブアプリへの統合も困難でした。今年2月の「Craft Reloaded」リリース。これは昨年9月から始まった激しいドキュメントベースの共有プロジェクトから始まり、ウェブエディターへの大規模なレイアウトとUIの構造的な変更を含んでいました。1月にはまだ価格設定とパッケージングを実装する必要があり、作業を長引かせたくなかったので、2週間で急速に開発しました。この時期がCraftで残業が必要だった唯一の時期でした。

残業についてもっと話せますか？

妻と娘がいるので、あまり時間を離れたくありません。夕食で一緒にいて、お風呂や就寝時間などの質の高い時間を楽しみたいと思っています。

これが良い枠組みを与えてくれますが、残業をしなければならなかったことは一度もありません。デスクを離れたとき、翌朝まで戻らなくてよいような形で仕事を終えるよう常に心がけています。残業は期待されてさえいないため、良いワーク・ライフバランスが保たれています。私たちの働き方は非常に集中していて激しいですが、コアな時間内にベストを尽くす以上のことが期待されているとは感じません。

最大のミスは何でしたか？

大きなものはありませんが、RCA（根本原因分析）やポストモーテムミーティングにつながった小さなエラーを犯しました。本番環境に入るミスをしたとき、それを発見し、修正し、何が起きたのか、どうすれば将来回避できるかを議論します。

私はRCAの支持者で、ミスについて話すことを奨励しています。

これは改善のよく知られた方法です。私にとってフレンドリーなトピックであり、これらのミーティングに慣れていない人がいれば、それを責任の追及や何が悪かったかの細かい指摘として見るのではなく、単に学ぶためのものとして見るようにしています。

Craftで優れたプロダクトエンジニアになるための秘訣は？

主に、タスクの幅広い概観と理解です。
技術的な知識は一つのことで、プロダクト開発に使用するツールです。
もしChatGPTに何かを開発するよう伝えてニーズをうまく表現できれば、コーディングは不要になるので私はコーディングをしないでしょう。プログラミングはプロダクト開発の一形態に過ぎませんが、プロダクト開発のプロセス全体の実行部分に過ぎないので、AIツールがすぐにそれらを置き換えることはないと思います。

何に取り組むかを見つけること、正確に何をしているかを把握すること、コミュニケーションと計画、現在のシステムへの統合、ユーザーフィードバックの理解、リリース後に機能やコンポーネントがどのように使われているかをフォローアップすること、そしてそれをプロダクト開発に戻すこと。これらはコーディング自体よりも重要です。

ここでは、成長するにつれて特に、ビジネスとユーザーの理解を身につけることが期待されています。それはコアコンピタンシーフレームワークの一部であり、ビジネスの理解、私たちが向かっている方向、会社にとって重要なこと、ユーザーにとって重要なことを理解することを含んでいます。
もちろん、サポートは受けられますが、積極的に理解し、アナリティクスの理解に時間を費やし、カスタマーサポートチームのフィードバックを読み、プロダクトデザイナーと協力して結論にどのように到達するかを理解し、ただ好奇心を持つことは全員の責任です。

注記：コンピタンシーフレームワークは、現在の仕組みの中での自分たちのレベルを理解するためにCraftが使用するマトリクスです。人々の強みや成長の余地を理解するためのガイドラインとして機能します。