協働 × コーディネーター
オープンリソース株式会社
Asako. O
Financial決済事業部
2019年入社
プロフィール
法政大学法学部卒。2012年、新卒でオープンリソース株式会社に入社。金融、百貨店、製薬会社など様々な業界に向けたシステム開発を経験したのち、現在はEngineeringチームを束ねながら、自分自身もエンジニアとして自社ソリューション「Redx」の開発に従事している。
新入社員の頃はどんな仕事をしていましたか？
webサイトの開発に、上流工程から携わっていました。
SESとして取引先企業に常駐しながら、EC決済サービスに関するwebサイトの開発を行っていました。
3年間に渡る大規模なプロジェクトだったのですが、新入社員の時点で開発の上流工程から携われたことは良い経験になりました。
３年間の中でもリリースのタイミングが特に大変で、設計・開発したものをテストする段階なのですが、やはり障害が出てしまうこともあり、不具合の修正に追われることも多くありました。無事リリースできたときはこれまでに味わったことのないほどの大きな達成感を得られましたし、3年間やり切ったという事実は、自分の中で揺るぎない自信に繋がりました。
またこのときの経験があるからこそ、マネージャーになった今、若い世代に同じ苦労を味わわせないためのリスクマネジメントを意識するようにもなりました。
現在は業務内容や、やりがいを教えてください。
実際にシステムが動いている場面を見られることが、やりがいです。
40名規模のEngineeringチームを束ねながら、自分自身もエンジニアとしてRedxの開発をリードしています。Redxには初期の段階から携わっているので、約半年間かけて完成した標準版の「Redxクラウド POS」を、某大手小売店様に受注していただけたときの喜びは、今でも印象に残っています。
納品後に実際に店頭を訪れ、自分が作ったものが動いているところを目にすると、やはり感慨深い気持ちになりますね。こういった点は、やはり流通小売業界という生活に密接な分野でシステム開発を手掛ける、当社ならではの醍醐味です。
開発者である猪俣が考える、Redxのバリューとは何でしょうか。
Redxの開発が、社会貢献に繋がると信じています。
社長の小倉とも、よく「Redxは社会貢献だ」という話をしています。標準化されたサービスを提供することで、お客様が開発コストや運用・維持コストを削減できれば、DXや新しいサービス開発に投資ができます。そうすれば、世の中がもっと良くなっていくと確信しています。
そのための自分のミッションは「標準化」です。Redxが流通小売業界においてスタンダードなサービスになるためには、やはり誰もが使いやすいサービスにしていく必要があります。例をあげるとiPhoneのように、Redxを誰もが納得するサービスになるよう、これからも育てていきたいです。
今後の展望はありますか？
Engineeringチームを、エンジニアの育成部署にすることです。
私個人としては、Engineeringチームを「エンジニアの育成部署」にしたいという展望があります。
当社には挑戦意欲のある、優秀な素晴らしいメンバーが揃っています。彼らを育てていくために、十分なスキルセットが出来る環境を作りたいです。更には、エンジニアという仕事の楽しさ・面白さもしっかり伝えていきたいですね。
私自身も若手社員のころから、上司にはエンジニアのロールモデルになれるよう育ててもらったと感じており、現在にいたるまで、様々なスキルセットの機会に恵まれました。今度は私が上司の立場として、他のどこに行っても通用するエンジニアを育てられるよう、人材育成にも力を入れていきたいです。
1日のスケジュール
- 9:00
-
タスク整理
前日発生したRedxの問い合わせ内容や各メンバーの課題を整理し、当日のタスクや今後のスケジュールの見直しを行います。
- 9:30
-
資料作成①
Redxを標準化するためのプロジェクトの資料作成や、開発・運用作業を自動化するツールの試作検討を行います。
- 10:00
-
デイリースクラム （定例ミーティング）
Redx開発メンバーと進捗や課題の状況を会話し、即断できる事項の解決と継続調査が必要な事項の指示出しを行います。
- 11:00
-
メンバーのサポート
業務的・技術的なフォローが必要なメンバーに対しサポートを実施します。
- 12:00
-
ランチ
テイクアウトしてオフィスで食べることが多いです。
- 13:00
-
Redx開発レビュー
メンバーが作成したドキュメントや実際に動くアプリケーションをレビューし、主に標準化の観点で方針に沿っているかを確認します。
- 14:00
-
顧客導入プロジェクト定例MTG
Redx顧客導入プロジェクトの定例ミーティングに参加し、開発状況の確認・レビューや課題に対する助言を行います。
- 15:00
-
Redx標準化レビュー
業務アプリケーションだけでなくクラウド環境等も含めたRedx標準化方針のレビューを行います。
- 16:00
-
他部門との情報共有
他部門の案件状況やリソース状況を確認します。
- 17:00
-
資料作成②
標準化資料の作成や、開発・運用作業を自動化するツールの試作検討を行います。
- 18:00
-
業務終了
他のメンバーをみる
どこにもない、ふつうを
一緒につくりませんか。