ID:3884さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


別の武器を作りたいと思っています。現在挑戦を考えてる分野はインフラ、デザインです。半年ほどこの2つを浅く勉強して、興味を持ったほうをより本格的に学びたいとおもっています

- Webフロントエンド領域は流行り廃りが早いわりにはできることはそれほど変わっておらず、ものを作るという視点では別の領域に足を伸ばしたことが、できることも視野も広がるのではないかと思っています - その中で今まで触れてこなかったインフラはエンジニアとして興味があり、またデザインはエンジニアという枠を離れるとともにWebフロントエンドと密接に関わりがあることから興味をもっています - マネジメントにも興味があり、経験もあるのですが、もう少し別の領域のスキル・知識を得てから再度挑戦したいと考えています

年収評価シート

2015年/2年以上

プロトタイピングツール Prott 開発

# プロダクトの概要 高速プロトタイピングツールの開発・運用 # プロジェクトの目的 コードを書かずに本物のアプリのようなプロトタイプを作成できるサービスです。 プロトタイピングすることによって早い段階での価値検証を可能にし、フォードバックサイクルを細かく回し、それによりプロダクトの品質を良くしていることを目的にしています。 競合とは違い、「早く」「簡単に」プロトタイプを作成できることを売りにしています。 日本だけでなく、海外でも使われるプロダクトを目指しており、3ヶ国語対応、海外に営業拠点を設置など海外展開にも力をいれていました。 # チーム体制 - プロダクトマネージャー: 1人 - UIデザイナー:2人 - バックエンドエンジニア:3人 - フロントエンドエンジニア:3人 - iOSエンジニア:1人 - Androidエンジニア:1人 - MacOSエンジニア:1人 # プロジェクトにおける自身の役割 - フロントエンドエンジニア(バックエンドも少々) - エンジニアリングマネージャー(最大12人、最終的には5人) - 評価、採用、人員計画、勤怠管理 - プロダクトマネージャー補佐 - KPIの設定、進行管理、カスタマーサクセスと # 課題とアクション、結果 ## エンジニアとして ### ランディングページリニューアルの遅延への対処 リリース一周年を記念して、ランディングページのリニューアルプロジェクトを別のエンジニアが1人で対応していたのですが、スケジュールに大きな遅延が発生し、急遽対応を行いました。状況としては約3ヶ月とっていた期間のうち、2ヶ月半経過したところで半分程度しか実装が終わっていない状況でした。 原因としてはプロジェクトマネジメントする人がおらず、進捗やタスクの管理をすべて担当エンジニアに任せていたことでした。そのため、エンジニアは実装に手がいっぱいで残りのタスクはどれぐらいで終わるのか把握しておらず、気づいたら期限まで2週間というところになっていました。 そこで私がやったことは以下の3点です - 残りのタスクをすべて洗いしてホワイトボードに張り見える化。ゴールを明確にする - 上記のタスクの優先順位を決める - 優先順位とボーダーラインをステークホルダーと相談 - 私も入れても期日までにボーダーラインに到達することは難しいということを伝え、急遽もうひとりヘルプを打診しました タスクが見える化してあったので、3人での実装もスムーズに行うことができ、期日どおりにリリースすることができました ### コーディング上の課題への対応 コーディングしている中で、ここが書きづらい、もっとこうしたほうがいいのでは?などコーディング上の課題をしばしば感じることがありました。ですが、それをチームメンバーへ伝える場がなく、チャットで流す、一部の人と相談などで対応していたのですが、それをメンバー各々が続けているうちに人によってコーディングにばらつきがでていることに気づきました。これ以上ばらつきを広げてはいけないと思い、コーディング上の課題をストックしておく場をつくりそれを定期的にふりかえり、対策・方針を決める場をつくりました。 これにより、決めた方針をもとにコードレビューをすることができるようになったのでコーディングのばらつきが抑えられました。また、メンバー各々が考えていることをオープンにすることにより相互に学習できる機会にもなりました。 ※ なお、既存のばらつきに関しては以下の方針をとることにしました - リファクタリングの期間を改めてプロダクトマネージャーと相談する - 機能実装のついで修正できるものを修正してしまう(ボーイスカウトルール) こうすることにより、機能実装を遅らせることなくコードの品質を少しずつ上げていこうという共通認識をチーム内でとることができました。 ### 各種botの作成 社内でSlackを日常的に使っていることもあり、できるだけSlackで完結できるように様々なbotを作成し、生産性の向上につとめました。 - フィードバック登録bot - Slackのあるチャンネルにユーザからのフィードバックを投稿するとフィードバックを管理しているシートに文字列がたまっていくbot - 日常的に使用しているSlackに投稿することにより、ちょっとしたユーザからのフィードバックを登録しやすくなった、どのようなユーザニーズがあるのか可視化されるようにエンジニアもユーザの要望から機能を考えることができるようになった - フィードバックは定期的に棚卸しし、開発計画の参考になった - 例) 解約率が上がってる → 解約者のフィードバックをみるとワイヤーフレーム機能に不満が多いことがわかる→ワイヤーフレーム関連のフィードバックをまとめ、優先順位と期間を決めて改善プロジェクトを行い解約率の抑制しよう - プルリクエスト作成bot - developからmasterへの差分が機能単位でわかるdescriptionが設定されたプルリクエストをslackから生成できるbot - リリースされる機能がひと目でわかるようになり、関係者の確認が大幅に軽減された - KPI投稿bot - 追っているKPIと現在の数値のギャップを報告するbot - チーム全員に数字の意識をつけるために - これによりslack内でKPIへのアクションの会話がうまれた - 数字への意識が向上した - GitHubメンション通知bot - GitHubでメンションされても気づかないという問題があったためGitHub上でメンションされたらSlack上でもSlackのユーザ名でメンションするというbot - これにレビュー漏れが少なくなった - 退職後、機能をブラッシュアップしたbotを個人的に開発しました - https://github.com/deepblue-will/mention-to-slack ### 作業と進捗の見える化 当時、ある機能の実装することを決めたらエンジニア、デザイナーがアサインされ、プロダクトマネージャーと相談したながら進めていくという流れでした。明確なリリース日は進めながらリリース日のスコープを決めていくというやり方でした。 ここで、問題だったのが作業の終盤にならないとリリース日が決まらず、ステークホルダーにうまくコミュニケーションができないという問題、また、進捗を見えないので、どこまでやっているのか、なにをやらないといけないのか各々のよくわかっていませんでした。 そこで私がやったことは以下のことです - 仕様ドキュメントを作成しプロジェクトメンバーとプロジェクトのスコープの認識を揃える。想定外のことが発生したら都度ドキュメントを修正して共有する - タスクを1日以下の粒度で分解し、大体のリリース可能日をきめる - 一日の終わりにテスト環境に成果物をデプロイし、プロダクトマネージャーやデザイナーからフィードバックをもらう これにより以下の効果がありました - スコープ外のことはやらなくなったため工数が削減 - スコープと早めの成果物の共有で、手戻りをすくなく - 仕様ドキュメントが最終的に残るので、のちのち機能の概要を確認するのに役に立った - 早めに想定リリース日がわかったこと、仕様ドキュメントがあったこと、テスト環境に実装中のものがデプロイされていたため、ユーザーへの周知を行うカスタマーサクセスチームへの連携がスムーズになり実装のリリース可能日にユーザーへの周知の準備の行えた - ステークホルダーに進捗を伝えやすくなった。これぐらいタスクがあって、いまはここです。テスト環境で最新の実装状況は確認できますなど 結果としては以下の通りです - プロジェクト開始から終了まで待ち時間が発生することなく、最短でユーザーに価値を届けることができるようになった - プロジェクトメンバーから、いままで1番仕事がしやすかったと褒めの言葉をいただけた ## マネージャーとして ### 評価の納得度の向上 導入した評価制度の設計上の問題やメンバーとのコミュニケーション不足により社員の評価への不満が大きいという問題があり、この問題に対して以下のことを行いました - CTO主導でのエンジニア評価制度の策定 - 1on1の内容を再考 まず、評価の満足度が低い問題の原因の1つに発揮した技術力が評価されないという点がありました。 これを解消するためにCTO、他のエンジニアマネージャーでエンジニアの評価方法を検討するプロジェクトを開始しました。 評価方法のプロトタイプ作成とフィジビリティテストでの被評価者からのフィードバックを何度か行い約半年でエンジニア評価を行うことができるところまで完成させることができました。このプロジェクトではCTOは他社、各エンジニアマネージャーはメンバーからのヒアリングを担当し、週または隔週で情報を持ち寄り方向性を決めていくという形で進めてきました。 つぎに評価の満足度の低かった問題として、半期に1回しか評価に関するコミュニケーションを行ってなかったことです。そこで私は隔週で行っていた1on1の時間をつかい、評価の認識のズレを少なくなるようなコミュニケーションをとるようにしました。やったことは以下2点です。 - 期首に立てた目標の進捗の確認 - 普段の業務に対してのフィードバック - 良いことも悪いことも 評価制度の策定と1on1でのコミュニケーション改善の結果、半期ごとにとっている従業員サーベイのスコアが改善しました。また、エンジニア評価導入前に聞こえていた評価に対する不満は導入後には聞かなくなりました。 ### ユニット定例の開催 会社や部署、プロダクトの動きをメンバーに伝える場がなく、先が見えなくて不安を感じていたメンバーが多いという問題があったので、定期的にそういった情報を伝えたり疑問に答える「ユニット定例」を週1、30分で開きました。 このユニット定例の結果として、1on1でより深い話ができるようになりました。 ユニット定例で共有可能な情報はすべて開示しているので、1on1ではよりプライベートな相談やフィードバック、目標の進捗確認などに時間をさけるようになりました ### 開発合宿の開催 以下の問題を解決すべく開発合宿の企画、実行を行いました 1. エンジニアチーム内に閉塞感・マンネリ感がでてきた 2. リニューアル後の技術のキャッチアップが全メンバーできてない - ※ 一部のメンバーで新しい技術スタックでのリニューアルプロジェクトを進めていた 開発合宿を行おうと思った背景として、私は1.の問題を解決したいと考えていました。その解決策として場所を変えてエンジニア全員で集まって集中してなにかに取り組むのはどうだろうかと考えました。この案を実行するために以下のことを行いました。 - エンジニア全員にヒアリング。開発合宿があったらやりたいかどうか - 開発合宿で何をやるか有志のエンジニアとディスカッション - これにより2.の問題の解決も開発合宿の目的に追加されました - 上記を踏まえ上司と相談 開催後、再度参加者にアンケートをとった結果このような声が聞けたので成功だと思っています。 - 普段見れない笑顔がみれた - 邪魔されずに集中して技術のキャッチアップにとりくめた - 新しいことに挑戦するのに前向きになれた また、開発合宿の内容はブログにして発信しました https://goodpatch.com/blog/gpdevcamp-vol-2/

プロジェクトカテゴリ
担当工程
役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

このマネージメント能力は公開されていません

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
あり
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

- デザイン

エンジニアとして影響を受けた本を教えてください

- アジャイルプラクティス

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

- チームメンバー各自が同じ方向に向かってものづくりをしている環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 調整力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
SI / 広告 / アダルト / 仮想通貨
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
RubyMine
希望勤務地
東京都
希望年収
700万円
ただいまの期間
ドラフト開催中

  • 参加者は企業から指名が入ります
  • ドラフト指名に返答できます
  • レジュメを更新できます
  • 審査は停止しています
ご意見箱

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

ID:3884さん
今年で30代中盤
RubyMine
参加ステータス
不参加
転職意欲
参加回数
1回
累計平均提示年収
690 万円
SIGN UP
SIGN IN


このサービスを友人に薦めたいですか?