インタビューア：
今日は、弊社の技術ブログ初めてのインタビュー形式での記事ということで「いまドリコムが求めている人と活躍イメージ」というタイトルで色々伺えればと思います。よろしくお願いします。
まずは、簡単に自己紹介をお願い出来ますでしょうか？
うめりん：
はい。
社内では「うめりん」のニックネームで呼ばれることが殆どの梅林（うめばやし）です。
僕がどんな人物なのかは以下の記事をご覧ください。
マネジャーが普段考えていること
ドリコムにおける活躍とは？
インタビューア：
では、早速ですが「活躍」って色んな形があると思うんです。
ドリコムにおける活躍ってどんな事を指しますでしょうか？
うめりん：
すぐに思い浮かぶのは「抜擢された役割を期待以上にこなせている状態」ですね。
インタビューア：
それは、クライアントエンジニアやサーバーサイドエンジニアといった
職能における役割分担ということでしょうか？
うめりん：
もちろん、1人のエンジニアとして難易度の高い機能の実装を不具合無くリリースしたり、より広い技術スタックや多くの物量をこなしたりといったことも活躍の1つに含まれます。
他に役割の具体例を挙げるなら、エンジニアリーダー・スクラムマスター・プロダクトオーナー・グループ長・部長・渉外窓口・委員会メンバー・技術支援・インフラ構築などでしょうか。
インタビューア：
すでに何らかの成果を出されている人がそのような役割に抜擢されるのは分かるのですが...。
抜擢されるような成果を出すためには、どうすれば良いんでしょう？
うめりん：
企業理念で掲げていることを中心軸として、行動で示すことですね。
社内では"Mission"・"Vision"と、"Value"をさらにブレークダウンした"Style"の4つの頭文字を繋げたMVVSという言葉で表現することが多く、発言と行動で示せていることを「MVVSを体現している」と言ってます。
活躍した人達の共通点
インタビューア：
大事にしている姿勢や価値観という意味では理解できるのですが、過去に活躍された人の例や、もう一歩踏み込んだ内容を聞けますでしょうか？
うめりん：
分かりました。
過去に表彰や昇給/昇格された人達を記憶している限り思い出して、主な共通点を出してみました。
以下の3つです。
- 対象の事業領域が好きな人
- 職種の枠を超えて行動できる人
- ピンチをチャンスと捉え、前向き/建設的に、チャレンジする発言と行動が取れる人
インタビューア：
少しイメージし易くなりました。1つずつ更に詳しく教えて頂けますか？
特に「対象の事業領域が好きな人」は、発言や行動という文字が入ってませんけど、好き嫌いは趣味趣向の要素が強いので、これで評価して良いんですか？
うめりん：
もちろん、単に好きという趣味趣向を評価軸にしている訳では無くて、好きかどうかが、その人の行動や他の人と仕事を進める上でのスピードに影響してくるため、結果として成果に結びつき易いと考えています。
具体的にいうと、プライベートな時間に普段ゲームをやらない・ゲームが好きじゃない人が仕事としてゲーム制作に携わった場合、ゲームをする人なら当たり前のように分かる用語や表現が「それって何ですか？」と伝わらない状態だと、開発/運用が進まないですよね？
新規開発をする場合にしてもチームスタッフ間で共通言語が無いとコミュニケーションコスト（説明時間）がかかり過ぎるので、同じゲームをプレイしようというような取り組みをしますし、運用においても自分が所属しているプロダクトタイトルを普段もプレイすることによって、ユーザーさんの気持ちを身をもって知ることであったり、変更開発においての調査時間軽減にも繋がる訳です。
なので「ゲームを好きじゃ無いけど必要だから仕事時間にだけ、言われた部分だけやる」という姿勢であれば、ゲーム事業に関わらない方が幸せだと思います。
うめりん：
現在はゲーム事業が主軸なのでゲームを例に挙げましたが、プラットフォームだったり、より大きなインターネットという括りでも考え方は同じです。
GREE・mobageなどのブラウザプラットフォームに触れたことが無い人、SNSのアカウントを持ってすらいない、スマホをそもそも持って無い人は、既存のサービスを知らないので、発明（まだ世の中に無い新しいものや組み合わせ）を産み出せない訳です。
普段から触れることの必要性が腑に落ちていれば、自発的に行動するはずなのです。
インタビューア：
よく分かりました。
「職種の枠を超えて行動できる人」は、クライアントエンジニアだけどサーバーサイドも担当する、のような意味でしょうか？
うめりん：
そうですね、それも1つの事例ですし、エンジニアがプランナー・ディレクター・デザイナー・QA・マーケティングなどの、他職種が担当している領域の仕事をこなせたり、他職種の仕事に興味を持って職種間の作業をし易くしたり、自ら要望をヒアリングしてエンジニアリングで課題解決するようなこともあります。
インタビューア：
3つ目の「ピンチをチャンスと捉え、前向き/建設的に、チャレンジする発言と行動が取れる人」は、どうでしょうか？
難易度が高そうだなという印象があるので、出来たら確かに評価されるのだろうと思いますが...。難しそうです。
うめりん：
もちろん簡単では無いのですが、限られた特別な一握りの人達だけが出来る事という訳でも無いです。
ピンチな状況というのは、計画外だが放置できない状況と言い換えることが出来ます。
何らかの事象によるスケジュール遅延、制作の手戻り、スコープ変化による物量増大と納期とのトレードオフ、技術的負債、不具合の発覚、セキュリティに関連する問題、人員に関連する問題、事故や目標未達に起因するリカバリなど多岐にわたります。
こういった事柄は、元々関わりのあった人達だけでは解決しきれないことも多く、色々な優先順位に鑑みて計画を組み替える必要性に迫られるのですが、それらの影響を受ける人達は、本来ならネガティヴな感情を抱いてもおかしくありません。
ですがそういった中でも、乗り越える事が自身の成長に繋がる、昔お世話になった人達のピンチだから恩返しの機会、うまくいくかは分からないけど出来る事は全部やろう、恥じることなく助けを乞おう、自分達が至らなかった点を見直そう、などのように考えたり行動した積み重ねの結果が、最終的にうまくいかなかったとしても、そのプロセスも含めて評価される形になります。
インタビューア：
なるほど！ 具体的なポイントをいくつもお聞きすると、確かに1つ1つは特別なことでは無いように感じました。
これら3つを全部満たす必要は無いけれど、当てはまる事が多ければ多いほど活躍していると言っても過言でなく、抜擢される機会が増えるということですね？
うめりん：
はい、その通りです。
今回は、技術ブログの性質上、主語をエンジニア中心に話しましたが、もちろんエンジニア以外の職種も同じ考え方です。
表彰は、ルール上ごく限られた人数に絞らざるを得ないのですが、昇給/昇格は年々対象人数を広げられている状態なのと、報酬の考え方として「仕事で報いる」という面もあるので、活躍した本人が関わりたかったプロジェクト/プロダクト/役割へ、優先的にアサインすることも並行して実施されます。
また、昇給/昇格に至るための評価時には、評価者(所属上長)の直接の目線だけではなく、被評価者が所属するチームで仕事ぶりを間近で知っているリーダーや他職掌からのヒアリングを通じて客観性を担保しながら、活躍度合いの評価視点が主観的になっていないかを同職種の管理職にてすり合わせを行うことで公平性を出来るだけ損なわないようにしています。
活躍した人達のエピソード
インタビューア：
それでは最後に、身近で活躍された方のエピソードなど話せる範囲で事例を頂けたりしますでしょうか？
うめりん：
そうですね。自身の所属部門ということでゲーム事業になりますが、2つほど。
1つ目は「所属のゲームプロダクトチーム内で、比較的新しく入られた方々に対して、雑談のような雰囲気でゲームの攻略方法のサポートをずっと続けてくれていた人」のエピソードです。
運用ゲームプロダクトは、自社や他社の攻略Webサイトが存在は当然するのですが、「初心者がまずやるべきこと」のようなページを一通りやった後は、ここから先どのように進めれば良いのかだったり、初期段階でランダム入手したキャラクターをどのように活用すれば良いかなど迷いがちで、その方々に合った方法の模索が必要になりますが、全員が高い熱量を持ってゲームプレイを続けるのは、なかなか難しい実状があります。
そんな中で、エンジニアの1人が熱心に攻略方法を各人の席へ事あるごとにサポートに回り続けて、ふと振り返れば両手で数えきれないくらいのチームメンバーに対して半年以上もサポートを継続し、その後サポートを受けた数人は、かなりの上位レベルまで達するコアユーザーになったことがあり、サポート継続の熱意と功績を称えて表彰されました。
ゲームが好きで、職種の枠に囚われず行動できた事例だと思います。
2つ目は「不具合発覚からリカバリした人達」のエピソードです。
エンジニアなら「不具合は完全にゼロにはしきれないもの」と、誰しも認識はしていると思いますが「この部分は今回のリリースで一番のポイントだから外せない（失敗できない）」というものもあるのは、想像に難く無いと思います。
ゲーム運営においては、ゲームアプリのバージョンアップと実際に投入するキャラクター等のデータ作成は、完全に同時期に行うことが難しい場合が多いのですが、その際に「一番のポイントだから失敗できない」部分に不具合があったことが、データを実際にリリースする直前のテストで発覚したのです。
こういった事が起きた際、一般的には当然データ作成者がもう一度不具合が起きないデータに変更すると思います。しかしこの時は練りに練ったアイデアで、1人で考えていたら従来のスケジュールに間に合わないピンチだったのです。
これに対し、データ作成者当人の他に企画職以外のチームメンバーが何名も集まって一丸となり2時間ほど議論した末、リリースできる基準を担保できるアイデアを出し無事に乗り切り、目標値を上回る結果を出せたという事例がありました。
まさにピンチをチャンスに変えた事例で、これらに関わった人達は、各々重要なポジションに抜擢されていきました。
このくらいで、伝わりましたでしょうか？
インタビューア：
はい。活躍の仕方、出来た際どんなメリットを得られるかがイメージできました！
本日は、ありがとうございました。
