KADOKAWA向けの開発ができ、エンジニアの評価制度がある会社
入社のきっかけはKADOKAWA向けの新規Webサービス事業
ドワンゴでは、ゲームデバイス向けのニコニコのクライアントアプリや、ニコニコ生放送と連動したUnity製スマホゲームを開発し、エンジニアリングマネージャとして組織運営をしていました。その後、KADOKAWAに出向し新規Webサービス開発を行っていましたが、案件がひと段落するタイミングで、KADOKAWA Connectedへの転籍を薦められたのが入社のきっかけです。
当社はKADOKAWAの100%子会社のため、ほぼ同様の開発環境が用意されており、スムーズにKADOKAWAの業務を担当できるのが特徴です。また、エンジニアとしての評価制度が提供されており、総合的に働きやすいと判断し、転籍を選択しました。
KADOKAWAが運営するWebメディアの開発業務
多種多様なWebメディアサービス
KADOKAWAグループは、紙の書籍が全盛期の時代から情報誌を通じてエンタメ情報の発信に力を入れています。現在は、ニュース・行楽情報・サブカル・芸能・レシピ・ゲーム等、多種多様なメディアサービスを運用し、情報誌に加えてデジタルコンテンツとして発信しています。KADOKAWAグループのメディアは書店に置かれた情報誌のように、手に取れば誰でもアクセスできるメディアを目指し設計されています。さらに近年では、情報誌とデジタルコンテンツの同時発信や連動企画等もあり、Webメディアについても進化が求められています。
編集部と意見を交わしBtoC向けのメディアをより良くする仕事
よく相談を受けるのが、Webメディアのリニューアル案件や新規開発です。開発チームの特徴として、記事などのコンテンツを作る編集部の皆さんとの距離は非常に近いという点です。顧客でもある編集部の皆さんが求めるものに、どうフィットさせていくかを考え、実現に向けて動いています。心がけていることとして、そのまま作るというよりは、編集部の課題感や実現したいことをベースに、開発チームでもよりよい提案ができないかを意識して提案をしています。私はマネージャーのため、５～６プロジェクトを同時で見ていくことが多いですが、メディア毎にユーザー層も違うため、大切なポイントも違うことを忘れないように意識しています。
また、ピープルマネージャーとしての仕事では、適材適所にメンバーをアサインして活躍してもらうことが大切だと思っています。人によって得意なことは様々ですし、今後伸ばしたいスキルや経験も様々です。メンバーと1on1等で話しながら、次のチャレンジについて話し、それを実現できるよう支援しています。
ゴールやマイルストンを強く意識したチーム運営
真面目で朗らかなチームメンバーに支えられて
自部署でのコミュニケーションで大切にしているのは、暫定でも目的や目標を定めてチーム全員と常に共有することです。これは既存システム群が、近年では当たり前の開発プラクティスが採用されていなかったり、慣れない言語で書かれたコードを読まなければいけない場面があるからです。特定のエピソードというよりは、日々心がけとしてMTGでタスクを決める際、ゴールやマイルストンを強く意識するように心がけています。チームメンバーの努力と協力の甲斐もあり、今のところ発散せずにプロジェクトを進められていると思います。
また、当社の社員の特徴として、穏やかで話しやすく、年齢や立場に関係なく学ぶべき人がたくさんいるように思います。今のプロジェクトを進められているのも、真面目で朗らかな人が多いこともあるように思います。経営陣との直接的なコミュニケーションは少ないですが、定期的な情報発信や社内イベントで親しみを感じます。私は子供が二人いますが、子育てにも理解があり、柔軟なテレワークや休暇制度は助かっています。
Value(行動指針)の中で大切にしたいもの
最も大切にしたいのは「相手を理解する」
KADOKAWAの事業部の方と進めていたプロジェクトで、スムーズに開発が進まなかったことがありました。理由は、立場やバックグラウンドの違いなど様々あると思いますが、私個人としてもっとできたと思うことは、事業部の方の立場を理解して、案件の進め方そのものを提案すべきだったという点です。エンジニアはシステムや技術には詳しくても、事業ドメインには詳しくない。相手の業務の状況や意思決定プロセスまで気を配れておらず、エンジニアが考えるやり方で進めてしまったことがありました。もう一歩、相手側へ踏み込んでいれば違った結果が得られたかもしれません。当社のシステム開発の業務をすれば、多かれ少なかれ似た状況は起こると思うので、「相手を理解する」というValueは大切にしたいと考えます。
次に大切にしたいのは「自分への挑戦状を持つ」
プロジェクトを進める際に、エンジニアがベストを尽くしたのかどうかは、実際のところ顧客側からはなかなか判断が難しいと思います。顧客は求めているものが得られれば満足しますが、開発やシステムの具体的な中身までは伝わらないからです。エンジニアの自己成長のためには、顧客からの評価だけではなく、技術面でもビジネススキル面でも挑戦を掲げることが大切だと思います。私はピープルマネージャーでもあるので、メンバー一人ひとりと話しながら、次の挑戦について定期的に話すようにしています。もちろん、自分自身の挑戦も念頭におき日々の業務をしています。
※2025年2月時点の記事です。
