はじめまして、プロトソリューション ソリューション開発部沖縄の岸本です。
表題の文化について、それがどの様に築かれたのか、私なりに会社の歩みを
振り返りながらお伝えできればと思っています。

私の学生時代

大学は商経学部経済学科を卒業しました。学生の頃からぼんやりと、地元沖縄の発展に貢献したいという思いがあり、経済について学べば学ぶほど、沖縄の特性を活かしつつ発展していくためにはITが必須である、という考えを持つようになり、大学3年あたりからITの仕事に就きたいと思うようになりました。また、大学時代、当時Jリーグを目指しているプロサッカーチームに所属し、授業以外はサッカーばかりやっていました。

就活時は、IT職か、サッカー選手か迷いました。最終的にはITの道に進みたいと思いながらも、「こんな経験は一生できない」と悩んだ末、「2年だけ!」と決めてサッカー選手を2年間経験しました。

サッカー選手時代-プライドの塊-変人-もしくはフィジカルお化けの集団

プロサッカーチームは厳しい環境でしたが、仕事内容は、「毎日体をいじめるだけの簡単なお仕事です」冗談の様ですが本当です。チームにより差はありますが、とりあえず、狂ったように走らされます。走るメニューが多いのと、通常メニューにおいても、常にダッシュで一般サッカーの倍位は走ります。仕事としてやっているからか、億劫な感情はなく、逆に多めに走ったり、ペースを上げたりして、その日の脈拍を見て体の調子を整えたりしていました。そして、あれだけキツイ練習の後に、チームの皆さんは楽しそうに筋トレをなさっていました。変態!

仕事としてやるサッカーは異質で、談笑したりはありつつも、常にピリピリとした緊張感があり、少しのミスも許されず、練習中に変なミスでもしようものなら、それが夢に出ることもありました。また、これはスポーツ特有かもしれませんが、良いプレーをする為、お互いに主張し、衝突することもよくありましたが、例え大喧嘩をしてもフィールドの外には持ち出さず、練習後、ロッカールームで喧嘩したばかりの相手と、今日夕飯何食べる?と何事も無かったかのように話をするような、清々しい関係はありました。お互い本気だからと、理解していたのだと思います。そんな仲間達と2年、サッカーをしていました。

ちなみに、私が現役時代対戦したチームの中には、今となってはJ常連の、FC琉球、Vファーレン長崎、ニューウェーブ北九州(現・ギラヴァンツ)、ロアッソ熊本、ヴォルカ鹿児島(現・鹿児島ユナイテッドFC)等があり、特に、地元FC琉球とは、私が出場した試合だけでも、大学時代から数えて4、5回位は対戦したことがあります。今となってはいい思い出です。

そんな私ですが、サッカーは2年、と決めていましたのでバッサリと引退し、それまでサッカーに注いでいた情熱を全てビジネスに注ぎ込んでやろうと意気込み、スポーツからITの世界へ飛び込みました。この2年の経験は今でも私の中で、仕事感、プロ意識、チャレンジ精神となって活きています。

そして、プロトデータセンター(現・プロトソリューション)に2008年に入社し、14年目になります。現在はチーム管理者、プロジェクトマネージャーとして案件推進しつつ、部署の人材育成・採用活動にも携わっています。会社内でも古参の部類に入ります。それでは、プロトソリューションの歴史を振り返っていきたいと思います。

創業期-自律自走してナンボ-自分でキャッチして調べて解決-指示待ちじゃ話にならない(部署人数5名)

さて、プロトデータセンター(現・プロトソリューション)ですが、創立が2007年4月3日ですので、私の入社時は創立2年目でした。当時は「中古車情報誌グー」の誌面制作を主な生業としており、全国で発刊されるグーシリーズの制作を担っていました。

私はその中に、情報システム部の一員として加わりました。当時、人数は責任者含めて5名の部署で、業務内容は、前述の誌面制作に関連するシステム全般の運用保守、改修でした。Webページ等ではなく、制作現場の方々が車両情報を入力するためのアプリ等、業務アプリケーションがほとんどでした。言語は、今となっては懐かしい、VB6が多く、その他、C#等の言語を用いていました。

またまだ仕組み化も進んでいない中、当時200名余りの規模の会社で起こる、全てのシステム、IT機器の不具合に関する問い合わせを部署の5名で捌いており、発生する事象もシステムエラーから、ネットの不調、プリンターの不具合まで、ソフト・ハード問わず様々な対応を行いました。

ナレッジもないですが、「自分達が解決できなかったら一体誰が解決するんだ」という想いで、業務遂行していました。制作現場の方々も頼りにしてくださっていたので、問合せを頂いた方に“分かりません”
とは言わない!分からなければ調べて理解して解決する、という考えで日々臨んでいました。

この期間で、問題が発生しても、慌てず調査をして自力で解決する、という能力は相当鍛えられたと思います。この経験を通じて、自律して考えることと、大抵の問題は自力で解決可能だという考えが体に染み付きました。この時、自律・自走、という考え・文化の基礎が出来上がったのだと思います。今思えば、指示されずとも、自分で考えて問題・課題解決するのは難しいことで、最初にこの経験が積めたのは非常に良かったと思っています。

フレームワーク-品質-標準化-部署人数10名規模

入社2年目、情報セキュリティの国際規格であるISMSの導入、というイベントが有りました。
この時、初めて部内の情報が一斉に整理され、規格に則った形式で管理がされるようになりました。
私はある意味初めて、フレームワークというものに触れました。仕組みを導入し、PDCAを回し継続的に
改善をする。当たり前のことかもしれませんが、当時の私にとっては、衝撃的でした。これをきっかけに、仕組みを作る、フレームワーク化する。ということを考えるようになりましたし、考える組織になったと思います。

それから更に2年後。2011年:「標準化」に出会うことになります。当社に、前職、バリバリの
大手SIerで働いていた、という人が入社してきました。現、当社役員の仲濱です。

当時、要件定義・設計・開発・テスト、という考え方、ドキュメント自体はあったものの、
管理はされておらず、内容・粒度がバラバラでした。そこに彼がメスを入れ、初めて、要求・要件定義、~リリースの工程を厳密に定義づけて、それぞれにチェック工程を設け、標準化を導入しました。

これにより、品質は格段に向上しました。今でこそ、当社内のメンバー間で共通語となっている品質基準や標準化は、この時初めて導入されました。現在行われている品質管理の原点であったと思います。

※沖縄本社ビルをご紹介 
左:プロト宜野湾ビル(2009年3月完成) 右:プロト宜野湾第2ビル(2013年12月完成)

挑戦するという文化(部署人数30名規模)

彼(仲濱)は上記をきっかけに、品質を高める為、テスト専任チームを立ち上げ、単身、半年ほど東京で業務をし、チームを軌道に載せ、現在の売上の柱を構築しました。同時期、スマートフォンアプリケーション開発が世間的にも開拓されており、そのニーズを受け、スマートフォン開発チームを立ち上げ、それも軌道に乗せました。

何が言いたいかというと、彼は、常に先頭に立ち、仕組みを作り、新たなものを生み出すことに挑戦をしていました。そして、彼自身、とてもイキイキしていたように思います。部署としても、新チームの設立等の変化が多く起こり、チャレンジの機運が高かったように思います。この時、チャレンジすることの楽しさと、あるべき姿を想像して物事に取り組むことで道が拓かれる。ということを数々の成功事例を前にして、実感しました。

当然、多くの失敗も経験しましたが、チャレンジし続けることでこの部署は発展をし続けていました。
この時、新チームやプロジェクトを立ち上げたり、採用したりと、ヒトの動きが多く発生しましたが、
一番大事にしていたことは、本人の「やりたいという意志」です。チーム・案件の人員募集を部内でかけた際、自ら「挑戦したい」と声を上げてくれた人を優先的にアサインするようにしていました。
この頃から、「挑戦」を奨励する文化が出来上がったと思います。

部署の拡大~現在(部署→部門へ、7部署120名規模)

そういった流れで、親会社のWebサービスの仕事が多く入ってくるようになり、短期間でいくつものチームを立ち上げましたが、この時、標準化された仕組みが大いに役立ちました。スムーズにセットアップできたように思います。その後、数年に渡り、Web案件は増加し、各サービスのスマホアプリ構築を行う様になり、部署は本格的に拡大していきました。
※この頃自社開発したスマホアプリがトレンド入りし、全国の朝の番組で紹介されたこともありました。

詳細は割愛しますが、拡大にあたり県の支援で教育事業などを手掛け、採用を生み出したりなどしておりました。また、親会社から仕事を受注するにあたり、お客様の近くで仕事をするという目的で、東京支社プリセールスの立ち上げも行いました。その後、2016年~グループ会社、アイソリューションズとの合併(現:仙台本社)を果たし、プロトソリューションとなり、ベトナム拠点設置などを経て、現在の形となりました。

現在は、大きく分けて、Web開発、スマートフォン開発、テスト、社内情報システム、外販(グループ外業務)、先端テクノロジーの、6つの役割で、沖縄・仙台・東京・ベトナムと4拠点で連携して開発を行うようになりました。上述の成長過程を経験したメンバーの多くが現在、役員・責任者、プロジェクトリーダー、マネージャーとして活躍しています。部門一丸となり、今後の自社の新サービスの創出・開発、さらなるチャレンジに向け、組織強化に取り組んでいます。

最後に

振り返りは以上です。上記の流れで表題の文化が出来上がってきたと思います。
現在は、自律・自走・挑戦し、且つ、それを楽しみましょう。と、方針にも明文化され、
メンバーにも展開がされています。

創業からフルスロットルで駆け抜けてきまして、ちょっとしたサバイバルな時期もありましたが、
仕組化・ナレッジ化も進み、働く・学ぶ環境も大分改善・安定してきた様に思います。このように、
挑戦により発展・成長してきた部門・部署ですので、そのDNAは継承しつつ、より働きやすく、
学べる環境、挑戦できるプロダクトを今後も生み出していけたらと思っています。

※文中にもありますが、現在、組織強化に取り組んでおり、共に働く仲間を募集しています。
 以下に当社のアピールポイントを紹介させて頂きます。興味をお持ちになられた方は
 お気軽にご連絡下さい。

自社メディアを運営しているということ

表題のとおりですが、当社はグループ企業のメディア開発を担っており、全員が高い当事者意識を
持っており、「自社メディアを運営している」という誇りとやりがいを持って仕事をしています。

顧客満足と品質を大事にしている

当社は顧客満足を大事にしています。上述の様に当事者意識を持つことで、顧客と信頼関係を築ける様、取り組んでいます。それらは基本的に、品質という土台の上でしか成り立たないと考えております。
その為、品質管理・向上の為の専任組織があり、日々、改善に取り組んでいます。また、定期的に顧客満足度アンケートを実施することで満足度を把握し、改善を行っております。

今後-どうしていきたいか

とにかく楽しい部署にしたいと考えています。チャレンジを楽しみながら、
結果的に多くの方に使って頂けるような自社サービスを創出できるような会社に成長していきたいです!
その為、採用・教育により力をいれて組織強化に取り組み、メンバーが学び、成長できる環境を
整えていきたいと考えています。

挑戦するということ

メンバーが「挑戦したい」と声を上げたことに基本的にNoとは言いません。
それを叶えるためには何が必要か、どうすべきかを一緒に考え、実現に向けて応援します。

求めている人物像

・挑戦できる環境を求めている方
・当事者意識を持って取り組める方
・自社サービスの運営・構築に携わってみたい方
・イノベーションを起こしたいと考えている方
・プロジェクトリーダー、プロジェクトマネージャーをキャリアプランとしてお持ちの方

プロジェクトマネージャー

プロジェクトマネージャー

沖縄本社では、一緒に働くプロジェクトマネージャー、リーダーを募集しています

AIエンジニア、システムエンジニア、その他多数募集中!

はじめに

皆さんはじめまして!
プロトソリューション ソリューション開発部沖縄の山川です。
Webアプリケーションのシステム開発・保守を担当しています。

▼プロフィール
1988年沖縄生まれの沖縄育ち。
趣味は料理とバスケットボール(見るのもやるのも好き)です!
幼いころから、絵を描いたり、工作したりして、モノづくり大好きでした。家に段ボールがあれば、必ず何かを作っては親に見せて驚かせようとする。そんな少年でした!

今回はそんな私のストーリーをご紹介いたします。

前職は調理師

23歳までは調理師として、沖縄のリゾートホテルで働いていました。
イタリアとスペイン料理がメインとなるレストランにてパエリアやアクアパッツァなどホットアペタイザーと呼ばれるポジションを担当していました。
レストランのオーダーも受けながら、披露宴やパーティー、ケータリングの対応もしていて、まさに戦場のような所でしたが、体力と根性はこの頃にだいぶ養われたと思います。

転職を決意した理由

調理の仕事は楽しくて、やりがいもありました。
ではなぜ転職を決めたかというと、ある日ふとシステム開発のドキュメンタリー番組を見たことがきっかけです。
そこでは、数名だけでシステム構築を行っており、世の中にサービスを提供していました。
そしてオフィスはおしゃれでイケイケな感じでした。
当時、文字通り汗水流しながら戦場のような環境で働いていた私にはとても衝撃で、キラキラして見えました。
また、調べれば調べるほど、ITはどんな分野にも関わることができて、沖縄にいながら世界中のユーザーにサービスを提供することができる。モノづくりという分野においては、すごい可能性を秘めた職業だと感じ、転職を決意しました。

プロトソリューション入社

プロトデータセンター(現・プロトソリューション)に入社を決めた理由ですが、当時、沖縄県のIT人材育成の一環としてプロトソリューションではエンジニアの教育事業を行っており、そこで未経験者の採用も行っていました。未経験だった私はすぐに会社説明会に参加しました。そこでフロアを見た時に、大きく開けた仕切りのないフロアでたくさんの人が活き活きと仕事をしているのを見て、「自分自身もここの一員になりたい・・」というめちゃめちゃ純粋な理由で応募しました(笑)

入社後は「グーネット」を利用する中古車販売会社の経営支援システムである「MOTOR GATE(モーターゲート)」のプログラマとしてエンジニア人生がスタートしました。
ただ当時は、キラキラした世界へのあこがれで入社したものの、本当に未経験の自分がエンジニアとしてやっていくことができるのか?という大きな不安がありました。

入社当時、心がけていたこと
右も左も分からないので「できる」「できない」や「仕事の好き嫌い」といった判断フィルターはとっぱらって、「やってみる?」といわれたものは全部「やります!」と言ってました。

自分自身、あまりチャレンジングな性格ではなく、油断するとすぐ甘えてしまうのは自覚していたので、自らやらないといけない状況に身を置くことだけを意識していました。

ただ結果的には、物理的に無理だったり、スキル不足だったりと、うまくいかないことだらけで迷惑かけたのですが、特技である「聞く」ということだけを武器にチーム内外の方からアドバイスをもらったり、フォローしてもらいながらなんとか乗り越えることができました。
面倒見が良くて、話しやすい人が多かったのは本当に救われましたし、その環境があったので、入社当時に感じていた不安はいつしか無くなくなっていました。
メンバー同士でチームの垣根を超えて助け合えるのは、プロトソリューションの魅力だと思います!

プリセールスへのチャレンジ

積極的に「やります!」「やりたいです!」と言い続けたことで、本当にいろいろな役割にチャレンジさせてもらいました。

▼これまで担った役割
・PG
・SE
・プリセールスとして東京常駐し、大手自動車ディーラー様への営業同行
・プロジェクトマネージャー
・部署のマネジメント

その中でも、印象に残っているのは、プリセールスとして東京支社に常駐していた時です。当時は営業チーム側では、客先での商談時にシステム観点の部分については持ち帰りになっているという課題がありました。そのためIT側の営業サポートが必要な状況にありました。
そこで私はプリセールスとして手を上げて、営業チームと首都圏の大手ディーラー様へ同行し、システム観点で商談をサポートする役割を担いました。
初めての経験で上手くやれたのかどうかは分かりませんが、実際にいくつかの商談を無事リリースまでもっていくことができました。
現場の生の声、温度感というのを実際に肌で感じることができたことは大きな経験でした。
開発をする中で、利用者の顔や気持ちを思い浮かべながら行うようになったため、早くリリースしたいという気持ちも自然と生まれました。
業界ではよく営業 vs IT(スピード 対 品質)といった構図がよくありますが、プリセールスとして直接お客様へ時間がかかってしまう経緯を理解してもらったこともあり、営業とITがお互いを理解し合いながら一丸となって仕事が出来ていると感じています。

このように、やりたいと手を挙げれば、どんどんチャレンジさせてもらえるのも、プロトソリューションの魅力です!

現在の役割と今後について

現在は、プロジェクトマネージャーとして、営業チームと要件定義を行い、プロジェクトの推進を行っています。決められた要件を言われた通りに作るわけではなく、沖縄にいながらも首都圏のお客様と連携し上流工程から要件定義ができるため、私個人としてはとてもやりがいを感じています。

さらに、もう一つの役割として、マネージャーとして部署運営にも携わらせてもらうようになりました。
少し前までは、個人的な成果だけを求めて働いているところがありましたが、現在は、部署としてより高いパフォーマンスを発揮できることを第一に考えています。
私の場合、個人で数百万を稼ぐスーパーエンジニアにはならない、というか、なれないだろうと思っています(笑)
ですが、メンバーがやりがいを感じながら活き活きと成長できる環境・組織を作ることで、私個人では達成できないことも実現できると考えています。
今使っているプログラム言語は数年後にはいらないものになっている可能性はありますが、組織をマネジメントするスキルは人間がいる限り絶対に必要なので、そこを伸ばしていきたいと思っています。

以下、そのほか今後やりたいことです。

マイクロサービス化の推進
現状、複数の機能がまとまってしまっている部分がまだありますので、マイクロサービス化を行い他社サービスも含めたサービス間の連携が複雑化していく中でも、少しでも早く連携が実現できる仕組みの構築を進めていきます。

タレントマネジメント
個性的なメンバーがたくさんいる為、それぞれのスキルや特性、やりたいことを可視化し、一人一人がやりがいを持って、楽しみながら仕事ができるような仕組みを作っていきたいです。楽しんでやっている人が集まった組織は最強なので!

※個人としてやりたいこと(いらない 笑?)
・ノーコード開発
・Bリーグ観戦部の立ち上げ(特に琉球ゴールデンキングス!!)
・週末だけの魯肉飯(ルーローハン)のお店(笑)

最後に

私個人がこれまで歩んできたエピソードをいっぱい書いてしまい、プロトソリューションの魅力を伝えられたか不安ですが、私のようにITとは違う職種の方が少しでも挑戦してみたいと感じて頂けたら幸いです!!ぜひ一緒に働きましょう!そして一緒にBリーグも見に行きましょう(笑)

最後までお読みいただき、ありがとうございました!

システムエンジニア

システムエンジニア

沖縄本社では、一緒に働くシステムエンジニアを募集しています

AIエンジニア、WEBディレクター、その他多数募集中!

はじめに
はじめまして。プロトソリューション東京支社の鈴木啓示(けいし)と申します。

※元プロ野球選手と同姓同名で、野球ファンだと反応するようです…

IT部門 ソリューション開発部東京2で自社初のSaaSプロダクト、受付クラウドシステム「ラクネコ」の営業をしています。

今回は私がどのようなキャリアを経てSaaS営業に携わるようになったかをご紹介いたします。最後までご覧頂ければ幸いです。

茨城から東京へ

1985年茨城県日立市出身。高校まで茨城にいて、中央大学入学とともに東京へ。

高校は野球部、大学はソフトボール部に所属していました。

大学卒業後、新卒採用を始めたばかりだということに魅力を感じ、外資系のゴルフ場運営会社に新卒1期生として入社、千葉のゴルフ場で1年間研修した後に本社配属になりました。その後、法人営業として4年間在籍した後、2013年3月に株式会社プロトデータセンター(現・株式会社プロトソリューション)へ入社しました。

初の転職

転職したきっかけとしては、4年間ゴルフの営業をしてみて、それ以外の世界を見てみたいというのが一番大きかったでしょうか。そこで、知り合いのエージェントから紹介頂いたのがプロトソリューションでした。はじめに採用担当の方と面談をして、その次が社長面談でした。初めての転職だったので、かなり緊張はしたのですが、同時に「なんとなく合いそうだな」という雰囲気が感じられ、思い切って入社を決めました。正直フィーリングだったのですが、入社してもう8年以上になるので正解だったのかなと(笑)

最初に、と言うかつい最近(2年前)まで私は営業部門の営業部という部署に所属していました。

営業部ではBPO(ビジネスプロセスアウトソーシング)業務の営業窓口を担当しており、沖縄拠点でオペレーションを行うコールセンターやデータ入力、Web制作などを商材として扱っていました。

前職では法人営業とはいえ、飛び込み営業など基本一人でかつ商材がゴルフでしたのでそこまで複雑な営業プロセスはなかったのですが、BPO営業ではそれでは通用せず・・・

・仕事は一人ではできない。周りを巻き込む

・まわりの人の短所を自分の長所で埋める

・営業は90%準備で決まる

などなど、その後の営業人生に大きな影響を与えたと言っても過言ではない基本を上司や周りの先輩方に叩きこまれました。

BPOの後はSNS広告やディスプレイ、リスティング広告などのWebマーケティングの営業に携わりました。金融や教育業界を担当し、自分で言うのもなんですが、それはそれは充実した毎日を送っていました。

SaaS営業は突然に・・・

そんな私が2019年の10月にIT部門に異動することになります。

Web広告案件も多く抱えており、ITの知識もお世辞にも豊富とは言えませんでした。かろうじてWeb制作の時にPHPという単語が出てきたかな、くらいで、あとはさっぱりでした。

ここで選択肢として頭に浮かんだのは

・広告営業として今まで通り頑張る

・IT営業としてチャレンジする

まあこの2択なわけですが、ちょっとだけ考えて後者にしました。ちょっとだけってどういうことかというと、どちらの方がいいか判断材料が皆無だったため、

・頑張る

・チャレンジする

ものすごく単純にこの言葉だけを比べてチャレンジしようかなと思った次第です。広告営業にも未練はありましたが、「人生はチャレンジだ」という先輩の言葉を胸にIT領域の営業として来ることを決意しました。(このネタ分かりますかね…)

その後、新規事業としてプロトソリューション初のSaaSである受付クラウドシステム「ラクネコ」の営業担当、そして責任者として白羽の矢が立ちました。ただ・・・最初は全くと言っていいほど売れませんでした!(ここで言って大丈夫かな…)

理由はいろいろあるのですが、今振り返ると、一番大きいのは自信のなさが伝わっていたのかなと思います。同じ営業だけどBPOとの違いに悩んだり、苦しみましたが、ある時点から少しづつ売れるようになりました。理由は以下の3つに集約されるかなと。

・SaaS(ラクネコ)をすべての業務の優先順位のトップに!

・基本に立ち返り、周りとの連携を密に!

・楽しむ!

SaaS(ラクネコ)をすべての業務の優先順位のトップに!

新規事業だったので他にも抱えている業務はあったのですが、お客様にはそんなことは関係ありません。結局、お客様にはいくつかある内の一つの商材に過ぎない、みたいなことを見透かされてしまいます。そうではなく、プロ野球選手は野球で、プロ棋士は将棋でご飯を食べているように、自分もラクネコでご飯を食べるぞ(笑)という気持ちでやりました(今も)。そうすると中途半端な気持ちは自然と無くなるものです。

基本に立ち返り、周りとの連携を密に!

うまくいかなくなった時、いつの間にか孤独になっていたりします。

(皆さんも経験ないでしょうか)

そんなときに周りにアドバイスや助けを求められるかどうか。特にラクネコの場合、マーケティング、開発、カスタマー、営業と大きく分けてもこれだけの役割に分かれており、どこが欠けてもプロジェクトは成立しません。なので営業のアドバイスというより一人一人の頑張りを見て刺激を受けたり、これだけの部署、人数がラクネコ成功のために動いていると思うと感動すらします。

楽しむ!

最後はこれに限るかなと思います。「好きこそ物の上手なれ」という言葉があるとおり、いかにラクネコを好きになり、営業を楽しめるかということを意識しました。楽しむを意識するというとなんだか変な気がしますよね。これは営業に限らないのですが、楽しいこと、うれしいこと、感動というのは伝わります。私は休みの日によく仲間と一緒に草野球やゴルフを楽しんでいるのですが、全く苦にならず、プレッシャーも感じません。

(ゴルフの自分のスコアも見ると苦しくなることはありますが)

もちろん、現在も課題はいろいろあるのですが、自分たちのチームであればなんとかなるという気持ちの方が強く、忙しくも楽しい毎日を過ごしております。

SaaS営業の今後について

今後、プロトソリューションではラクネコに続いて第2、第3のSaaSが出てきます。そのときに営業するうえで大事になってくるのが、圧倒的な商品知識はもちろんのこと、これまでお伝えした、

・SaaS(ラクネコ)をすべての業務の優先順位のトップに!

・基本に立ち返り、周りとの連携を密に!

・楽しむ!

の3つを意識していればだうまくいくと信じています!

また、嬉しいことに今年の8月に初めてSaaS営業の仲間が加わりました!これまでは担当役員と私だけだったのですが、新たに仲間が増えて、ラクネコはさらに盛り上がりを見せております。私としては、どんどん営業が増えていって、さらに周りを巻き込み、プロトソリューションの中で今以上に存在感をだしていきたいですね。

特にラクネコのようなSaaSは売上金額は最初は小さいものなのですが、それがどんどん積み重なって土台となります。この土台をつくることがプロトソリューションの未来を創ると信じて活動しているので、そういった仲間を増やしていきたいですね。

最後に

今回は私がSaaS営業に携わるようになったストーリーをお伝えしてきました。今後また機会があれば

・なぜSaaS営業なのか

・SaaS営業に必要な営業スキル

・うまくいった/うまくいかなかった営業事例

などなど紹介したいですね。

私たちプロトソリューションでは主体的に考え、動くことができる人、チャレンジ精神あふれる人であれば活躍できるチャンスは大いにあふれていると思っております。私が所属しているIT部門はほとんどがエンジニアなど技術職の方が多いですが、技術やサービスを広く伝える、つまり営業としても活躍できる土壌は十分にあります!私たちと一緒に働くことができる日を楽しみにしています。

最後までお読みいただき、ありがとうございました。

皆さん、はじめまして。
プロトソリューション仙台本社の岩間と申します。

今回、プログラマーからSEを経てマネージメントに少しずつ足を踏み入れてきた私のエンジニア人生をご紹介させて頂ければと思います。
最後までご覧いただけましたら幸いでございます。

自己紹介

幼少期から周囲に機械や工具が豊富にある環境で育ち、モノづくりに興味を持ち、工業高校で機械工学を専攻。
実習の中にBASIC言語を用いた旋盤(金属から部品を削り出す切削加工)実習があり、そこで、プログラミングに触れた事で興味・関心が強くなりITエンジニアになることを決意。
情報系の大学を経て、2007年株式会社アイソリューションズに入社。

これまでのエンジニア人生

私のエンジニア人生は入社前研修時から始まりました。
任意参加制で、あるシステム開発の一部を担当させて頂ける機会が提供されていたため迷わず食いつきました。
まだ入社していないですが、会社にかかってきた電話にも出る機会があり、先輩方から、彼もう電話も受けてるし(笑)って温かい眼差しで見守ってもらった記憶がとても印象的です。
同期に結構デキる人がいたので、負けたくないという気持ちや自分の力を蓄えたいという気持ちがあったので、入社前であってもそんな機会を提供してくれる会社にとてもマッチしてるなと感じたエピソードでした。

その後入社してすぐは、がむしゃらに色んな事に取り組ませてもらいました。
同じ案件を長く続けると経験できる事にムラが出てしまうと思ったので、短期的に案件を変えながら、
学びながら仕事することができたのも、意見を聞いてくれる会社があったからこそだと思います。
そんなとき、客先常駐の案件の話があり、経験を増やすために常駐を選択したのですが、その常駐先で、エンジニア人生における2つのターニングポイントがありました。

良き反面教師との出会い

仕様は俺だ!横暴なリーダーが進めるプロジェクトへの参画

まだエンジニアとして若く、エンジニア像というものを明白に持っていなかった頃のお話。
そのプロジェクトはリーダー配下に他社エンジニア5名、弊社エンジニア2名、半年くらいの規模の案件でした。
とある基幹システムの改修要件だったのですが、そこのリーダーが曲者でタイトルの通り、仕様は俺の頭にある。俺の言う通りにやれ。という独裁者。
そのくせ、毎日出勤時間は遅く、いつも赤ら顔で前日どんだけ飲んでたんだ?って感じの人でした。
ただ、当時の私は”仕様は俺だ”と自信満々に振る舞うリーダーを見て、「おおぉ、すげーな。こんなこと言ってみたい」と憧れのようなものを感じるペーペーでした(笑)
結局はチームから不満続出で異動となり、常駐先から謝罪を受け、その後は新体制のもと完遂。
チームをゴールに導くために必要な事、ナレッジを整理/共有することの大事さを教わるいい機会となりました。
(こんなプロジェクト中々無いので、良い反面教師に出会えて良かった)

地方・首都圏なんて変わらないと実感

大手有名IT企業におけるリーダー経験

そこは当時はまだ今ほどの大きさになっていない発展途上の常駐先でした。
プロパーが少ないためパートナーエンジニアを探しており、こんな有名企業だからこそ得られるものがあると思い参画。
面接の終わりに「うちはパートナーとかプロパーとか線引して仕事する人は要らないです。それでもやってくれますか?」と問われ、驚きました。
そもそも、良いものを届けるという思いで仕事していたので、線引はありませんでしたが、今までの常駐先では当然パートナーとプロパーには大きな壁があるのは痛感していたので、逆に火が付き、「プロパーと遜色ない成果を出しますので、やらせてください」と胸を張って返答しました。
大手だからこその多種多様なルールがあったり、仕事の進め方も独自性があったため、正直、失敗の連続でしたので、言葉の通りやれてなかったと思いますが、チームリーダーを任せてもらったのは、頑張った成果を認められた結果かなと振り返っています。
良いものを作り出すために妥協せず取り組んだ姿勢が良かったのかな。
そんな時、プロパーと一緒に東京本社に出向く機会を頂き、同席しました。
今まで東京に出張することは何度かありましたが、先輩の同伴程度で、議事録係&日帰りだったので、東京のエンジニアと話をする機会なんてありませんでしたが、こんな大手のIT企業で、かつ数日の出張。
これはどんな人と会えるのかワクワク!という感情で東京入りしました。
それを終えての感想。
東京=すごい人がいる。すごい事がやれる。
この考えが変わりました。

当然、人は多いし、情報も多いし、すごいなって人とも出会いました。
でも、母数が違うだけで比率変わらないじゃん。というのが私の感想でした。
その時、首都圏と地方では地方の方がレベル低い。という概念が完全に吹き飛んで、全然やれんじゃん。同じようなエンジニアなのになんでこんなに待遇違うの?という思いが強くなりました。

この2つの機会から自分のエンジニア像が形成されていったと思います。

  • チームで成果を上げる
  • 良いものを提供するために妥協(契約形態や勤務地)は不要

そんな経験を積んでいた最中、2016年10月株式会社アイソリューションズは株式会社プロトデータセンターと合併し、株式会社プロトソリューションとして生まれ変わりました。
当時の気持ちとしては、合併後、今までのようにやりたいことをやらせてもらえるチャンスが引き続きあるのか、エンジニアとして今後成長する機会が減ることはないか、という不安と、新しい会社になってイチから会社を再構築できるのでは、という期待感が入り混じっていました。

私は合併時はまだ常駐先で仕事をしていたのですが、現在の仙台開発責任者、進藤から戻ってきてほしいと言われ戻る事にしました。
それから社内に戻り、自社内にてプロトグループの大規模サービス案件や新規案件、新規サービス開発など、多岐にわたり携わる事ができたのですが、その中で先の不安は完全になくなりましたね。

アイソリューションズ時代もチャンスを掴み取る機会は十分あったのですが、チャンスの幅がより広くなった印象です。

  • 中々経験しようと思っても出来ない大規模なサービスを支える機会
  • お客様の要望するものをどういったテクノロジー/アーキテクチャで実現するか手腕が問われる機会
  • 自分たちで0からサービスを作りたいという思いを叶えられる機会

合併前では企業規模も小さく出来なかった範囲が、合併したことで機会を提供してもらえる良い環境になりました。

代表プロジェクト 開発時期 開発規模 使用アーキテクチャ
新規開発:自動車関連SNS 2019/07~2020/03 51人月 PHP、Angular、TypeScript、Aurora、PWA
新規サービス開発:JomoNex 2020/07~2021/08 33人月 golang、React、Aurora
研究開発:画像認識技術による判定 2020/07~ 8.5人月 Python、PyTorch、Detectron2
新規サービス開発:ラクネコ 2019/04~2020/02 80人月 Swift、Kotlin、Angular、TypeScript、DynamoDB

現在、私はAIテクノロジー推進室のシステム開発Section統括のポジションにいます。
こういったポジションに携われるのも、会社から与えられるチャンスに対して自分のとりあえずやってみる、なんでもやってみるという精神と苦難はありながらもそれに立ち向かっていくポジティブな考え方が認められた結果なのかなと思っています。

年間授賞式にて、特別賞を頂きました!

これからのエンジニア人生

今、私は現場主体のエンジニアからマネージメントの道に進む、大きな転換期の真っ只中にいます。
マネージメントはシステムのようにシンプルではなく、人と人との対話/関係性を築くとても難しいものだと痛感しています。
しかしながら、自分のエンジニア人生の中で今まで経験してきた事を軸に形成してきたエンジニア像を
後世に伝え、組織力を高める事のできる素晴らしい職務だと思います。
チームを纏めることの大事さ/大変さ、お客様へ良いものを届けるために妥協は不要。
これをこれからの若い人達に伝えると同時に、機会とチャンスを用意し、活躍する場を提供する。
そんなマネージャに成長できるよう邁進しているところです。

そして私には夢があります。
これまでのエンジニア経験の中で感じた、地方というマイナスイメージの払拭です。
昔と違い、テクノロジーの進歩で、どこでも仕事が出来る時代です。
そんな中、昔は首都圏だからこそ出来るという仕事も、今や場所は問われないですし、なにより地方にも優秀な人材は多いと考えています。先述したように母数が違うだけです。
それなのに地方だから、やりたいことができない、待遇が悪いというのは納得できません。 

おわりに

私のエンジニア人生が中心となる内容になりましたが、この会社にはやりたいという思いを叶え、評価されるよい風土が形成されています。
地方とか首都圏とか関係なく、ここには成長できる土台があります。
これからの日本には地方の力こそ、必要なものだと思います。
思い入れのある場所から世の中によい価値を提供する。
この思いに賛同頂ける方、エンジニアとして技術を追求していきたい方、マネージャーとして管理職へ挑戦したい方、今後のキャリアをどうしようかとお考えの方、ぜひお声がけください。
やる気さえあれば、チャレンジできるフィールドで私達と一緒にさらなる成長を遂げましょう。
プロトソリューションで共に働ける事を楽しみにしています。

最後までお読みいただきありがとうございました。

ITエンジニア

ITエンジニア

仙台本社では、一緒に働くITエンジニアを募集しています

自社プロダクト(SaaS)開発エンジニア、システムエンジニア、その他多数募集中!

はじめに

多くのブログ記事やチュートリアルは、機械学習や深層学習モデルのトレーニングに焦点を当てています。しかし、これらのモデルをWebサイトや他のシステムから簡単に利用できるように作成し、デプロイする方法については、あまり多くの情報がありません。

この記事では、これらのモデルのWeb APIを作成するためのアプローチと、AWSへのデプロイメントについて説明します。

この記事ではTensorFlow 2に焦点を当てていますが、いくつかの変更を加えることで、コードはPyTorchLightGBMなどの他のフレームワークにも対応できます。

自己紹介

私はアダムと申します。PROTO SolutionのAIテクノロジー推進室で機械学習/深層学習のシステムやプロトタイプを開発しております。

主な仕事は、TensorFlowを使った深層学習モデルの開発と、それらを使ってAmazon Web Services (AWS)にデプロイできるAPIやバッチアプリケーションの開発です。

アプローチ

機械学習モデルをデプロイするためにいくつかAWSサービスが使えます。例えば、

これらのサービスはそれぞれ料金、複雑さ、機能が異なります。

この記事では、AWS LambdaAWS Elastic Beanstalkへのデプロイに焦点を当てます。理由は、この二つのサービスが一番使いやすいですし、私のプロトタイプやアプリケーションはこれらでデプロイすることが多いです。

今後のブログでは、他のサービスについても記事を書いていきたいと思います。

API

API(Application Programming Interface)とは、ユーザーや他のシステムが、アプリケーションの内部を知らなくても、そのアプリケーションと使用できる方法を示すものです。

Web APIは、HTTPやその他のプロトコルを使用して、アプリケーションの機能をインターネット上で提供し利用することを可能にします。

この記事では、FastAPI フレームワークを使用してWeb APIを作成し、DockerおよびAWSサービスを利用してデプロイします。

ImageNetというデータセットに学習されたTensorFlowのMobileNetV2 モデルを例として使用します。

FastAPI

FastAPI は、PythonでWeb APIを構築するためのフレームワークです。

Flaskとその他のフレームワークも非常に人気がありますが、FastAPIはこれらのフレームワークに比べて、いくつかの利点と特徴があると思います。例えば、

  • ・モダンで非常に高速処理
  • ・コードの重複を最小限にしていますので、APIのソースコードが短い
  • Pydanticによるデータのシリアル化と検証が組み込まれています。
  • ・自動的にOpen APIドキュメント(仕様書)生成

Docker

Dockerは、アプリケーションをデプロイするための決定的な方法となっています。

Dockerで、アプリケーションと、オペレーティングシステムを含むすべての依存関係を、Dockerイメージと呼ばれるものにパッケージ化できます。

これらのイメージは、Dockerエンジンをサポートするさまざまなプラットフォームで実行できます。

Dockerエンジンで実行されるイメージは、コンテナと言います。

Dockerには、コンテナとイメージを管理するためのさまざまなコマンドがありますが、この記事では、buildrunコマンドのみを使用します。

チュートリアル

このセクションでは、APIの各部分を紹介し、説明します。

依存関係のインストール

最初のステップは、Pythonの分離されたコピーである新しい仮想環境を作成することです。

この記事では、Condaを使って新しいPython 3.7の仮想環境を作成し、それに切り替えます。

conda create -n ApiDeployment python=3.7
conda activate ApiDeployment

次に、requirements.txtに記載されている依存関係を仮想環境にインストールします。

pip install -r requirements.txt

必要な依存関係のパッケージを少し見てみましょう。

Pillow==8.2.0
tensorflow==2.4.2
numpy==1.19.5
fastapi==0.65.2
pydantic==1.8.2
aiohttp==3.7.3
uvloop==0.14.0
uvicorn[standard]==0.14.0
gunicorn==20.1.0
aiofiles==0.7.0
mangum==0.12.2

パッケージのインポートとロギング

まずは始めに、APIが使用するライブラリのインポートです。

これらのライブラリの使い方については、コードを読み進めながら説明します。

import argparse
import base64
import io
import os
import logging
import sys

from tensorflow.keras.applications.mobilenet_v2 import MobileNetV2, preprocess_input, decode_predictions

from urllib.parse import urlparse

from aiohttp.client import ClientSession
from asyncio import wait_for, gather, Semaphore

from typing import Optional, List

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

from pydantic import BaseModel, validator

import numpy as np

from PIL import Image

from mangum import Mangum

APIは環境変数を使って設定されますが、これらはコマンドラインで簡単にDockerに渡すことができます。

THREAD_COUNT = int(os.environ.get('THREAD_COUNT', 5))
"""The number of threads used to download and process image content."""

BATCH_SIZE = int(os.environ.get('BATCH_SIZE', 4))
"""The number of images to process in a batch."""

TIMEOUT = int(os.environ.get('TIMEOUT', 30))
"""The timeout to use when downloading files."""

また、メッセージをログに書き込むためのロギングオブジェクトも作ります。

logger = logging.getLogger(__name__)

データのモデル

次に、Pydantic というパッケージを使って、APIへのインターフェースを定義し、データ構造を作成します。

データ構造を作成するための詳しいチュートリアルはこちらをご覧ください。

class HealthCheck(BaseModel):
   """
  Represents an image to be predicted.
  """
   message: Optional[str] = 'OK'


class ImageInput(BaseModel):
   """
  Represents an image to be predicted.
  """
   url: Optional[str] = None
   data: Optional[str] = None


class ImageOutput(BaseModel):
   """
  Represents the result of a prediction
  """
   score: Optional[float] = 0.0
   category: Optional[str] = None
   name: Optional[str] = None

   @validator('score')
   def result_check(cls, v):
       return round(v, 4)


class PredictRequest(BaseModel):
   """
  Represents a request to process
  """
   images: List[ImageInput] = []


class PredictResponse(BaseModel):
   """
  Represents a request to process
  """
   images: List[ImageOutput] = []

PredictRequestオブジェクトは、APIに渡されるデータ、つまり処理したい画像を表しています。

PredictRequestオブジェクトは、予測結果がAPIの呼び出し元にどのように返されるかを定義します。

これらの構造を定義することで、画像のURLやBase64エンコードされた画像データを含むJSONリクエストを自動的にデシリアライズし、妥当性を検査することができます。

サンプルなリクエスト

{
 "images": [
  {
     "url": "https://localhost/test.jpg"
  }
]
}

また、各画像のImageNetカテゴリー予測値、信頼度スコアを含むJSONレスポンスをシリアライズすることもできます。例えば、

サンプルなレスポンス

{
   "images": [
      {
           "score": 0.508,
           "category": "n03770679",
           "name": "minivan"
      }
  ]
}

FastAPI アプリケーション

次のステップでは、FastAPIのアプリケーションのオブジェクトを作ります。これにより、次のステップでいくつかのアノテーションを使用できるようになります。

app = FastAPI()

例外処理

以下の例外ハンドラは、処理中にエラーが発生した場合に、呼び出し元に返されるエラーメッセージを生成するために使用されます。

class ImageNotDownloadedException(Exception):
   pass


@app.exception_handler(Exception)
async def unknown_exception_handler(request: Request, exc: Exception):
   """
  Catch-all for all other errors.
  """
   return JSONResponse(status_code=500, content={'message': 'Internal error.'})


@app.exception_handler(ImageNotDownloadedException)
async def client_exception_handler(request: Request, exc: ImageNotDownloadedException):
   """
  Called when the image could not be downloaded.
  """
   return JSONResponse(status_code=400, content={'message': 'One or more images could not be downloaded.'})

Image Classifier

このクラスには,学習されたMobileNetV2モデルが利用されています。

predictという関数を呼び出すことで、画像のリストに対するImageNetカテゴリを予測することができます。

画像は前処理され、モデルの入力に合わせてリサイズされます(224ピクセル×224ピクセル)。

class ImageClassifier:
   """
  Classifies images according to ImageNet categories.
  """
   def __init__(self):
       """
      Prepares the model used by the application for use.
      """
       self.model = MobileNetV2()
       _, height, width, channels = self.model.input_shape
       self.input_width = width
       self.input_height = height
       self.input_channels = channels

   def _prepare_images(self, images):
       """
      Prepares the images for prediction.

      :param images: The list of images to prepare for prediction in Pillow Image format.

      :return: A list of processed images.
      """
       batch = np.zeros((len(images), self.input_height, self.input_width, self.input_channels), dtype=np.float32)
       for i, image in enumerate(images):
           x = image.resize((self.input_width, self.input_height), Image.BILINEAR)
           batch[i, :] = np.array(x, dtype=np.float32)
       batch = preprocess_input(batch)
       return batch

   def predict(self, images, batch_size):
       """
      Predicts the category of each image.

      :param images: A list of images to classify.
      :param batch_size: The number of images to process at once.

      :return: A list containing the predicted category and confidence score for each image.
      """
       batch = self._prepare_images(images)
       scores = self.model.predict(batch, batch_size)
       results = decode_predictions(scores, top=1)
       return results

ロギングの設定

次に、アプリケーションのログを設定するための関数を作成します。

すべてのログのメッセージは stdout に出力されます。これにより、AWS LambdaやElastic Beanstalkは簡単にメッセージを記録できるようになります。

def configure_logging(logging_level=logging.INFO):
   """
  Configures logging for the application.
  """
   root = logging.getLogger()
   root.handlers.clear()
   stream_handler = logging.StreamHandler(stream=sys.stdout)
   formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
   stream_handler.setFormatter(formatter)
   root.setLevel(logging_level)
   root.addHandler(stream_handler)

モデルのロード

このステップでは,アプリケーションの起動時に、ImageClassifierオブジェクトを生成してロードします。

また、前のセクションで定義した関数を使って、アプリケーションのログを設定します。

@app.on_event('startup')
def load_model():
   """
  Loads the model prior to the first request.
  """
   configure_logging()
   logger.info('Loading model...')
   app.state.model = ImageClassifier()

ここでは、appstateImageClassifier オブジェクトを格納しますが,代わりにグローバル変数としてモデルを格納することも可能です。

画像処理

このセクションでは、URLから画像をダウンロードしたり、リクエストメッセージに格納されている Base64 画像データをデコードしたりするためのいくつかの関数を定義します。

ダウンロードするためにaiohttpというパッケージが使われています。画像のデータはPillowの形式に変換しています。

def get_url_scheme(url, default_scheme='unknown'):
   """
  Returns the scheme of the specified URL or 'unknown' if it could not be determined.
  """
   result = urlparse(url, scheme=default_scheme)
   return result.scheme


async def retrieve_content(entry, sess, sem):
   """
  Retrieves the image content for the specified entry.
  """
   raw_data = None
   if entry.data is not None:
       raw_data = base64.b64decode(entry.data)
   elif entry.url is not None:
       source_uri = entry.url
       scheme = get_url_scheme(source_uri)
       if scheme in ('http', 'https'):
           raw_data = await download(source_uri, sess, sem)
       else:
           raise ValueError('Invalid scheme: %s' % scheme)
   if raw_data is not None:
       image = Image.open(io.BytesIO(raw_data))
       image = image.convert('RGB')
       return image
   return None


async def retrieve_images(entries):
   """
  Retrieves the images for processing.

  :param entries: The entries to process.

  :return: The retrieved data.
  """
   tasks = list()
   sem = Semaphore(THREAD_COUNT)
   async with ClientSession() as sess:
       for entry in entries:
           tasks.append(
               wait_for(
                   retrieve_content(entry, sess, sem),
                   timeout=TIMEOUT,
              )
          )
       return await gather(*tasks)


async def download(url, sess, sem):
   """
  Downloads an image from the specified URL.

  :param url: The URL to download the image from.
  :param sess: The session to use to retrieve the data.
  :param sem: Used to limit concurrency.

  :return: The file's data.
  """
   async with sem, sess.get(url) as res:
       logger.info('Downloading %s' % url)
       content = await res.read()
       logger.info('Finished downloading %s' % url)
   if res.status != 200:
       raise ImageNotDownloadedException('Could not download image.')
   return content

画像の予測

最後の2つのメソッドは,上記のコードをすべて結びつけるものです。

predict_imagesは,Pillow形式の画像のリストに対してImageNetのカテゴリを予測し、その結果をImageOutputオブジェクトのリストとして返します。

process関数は、URLのリストから画像をダウンロードして処理し、レスポンスを返します。

app.postのアノテーションは、HTTP POSTによる関数を呼び出すことでき、関数のリクエストとレスポンスの構造がそれぞれPredictRequestPredictResponseによって定義されることを示しています。

def predict_images(images):
   """
  Predicts the image's category and transforms the results into the output format.

  :param images: The Pillow Images to predict.

  :return: The prediction results.
  """
   response = list()
   results = app.state.model.predict(images, BATCH_SIZE)
   for top_n in results:
       category, name, score = top_n[0]
       response.append(ImageOutput(category=category, name=name, score=score))
   return response


@app.post('/v1/predict', response_model=PredictResponse)
async def process(req: PredictRequest):
   """
  Predicts the category of the images contained in the request.

  :param req: The request object containing the image data to predict.

  :return: The prediction results.
  """
   logger.info('Processing request.')
   logger.debug(req.json())
   logger.info('Downloading images.')
   images = await retrieve_images(req.images)
   logger.info('Performing prediction.')
   results = predict_images(images)
   logger.info('Transaction complete.')
   return PredictResponse(images=results)

健全性のチェック

また、ロードバランサーがアプリケーションの健全性をチェックするためにHTTP GETによる呼び出すことができる関数も提供しています。

@app.get('/health')
def test():
   """
  Can be called by load balancers as a health check.
  """
   return HealthCheck()

Handler (Lambdaに必須)

LambdaFastAPIを使用するためには、FastAPIappオブジェクトをMangumでラップする必要があります。

handler = Mangum(app)

注:アプリケーションをローカルまたはAWS Elastic Beanstalkにデプロイする場合、このハンドラは使用されません。

APIサーバーの実行 (ローカル環境)

最後に、コマンドラインからAPIを実行できるように、組み込みのuvicornサーバーを追加します。

if __name__ == '__main__':

   import uvicorn

   parser = argparse.ArgumentParser(description='Runs the API locally.')
   parser.add_argument('--port',
                       help='The port to listen for requests on.',
                       type=int,
                       default=8080)
   args = parser.parse_args()
   configure_logging()
   uvicorn.run(app, host='0.0.0.0', port=args.port)

以下のコマンドを実行することで、APIをローカルに実行することができます。

python main.py

Lambdaのデプロイメント

LambdaへのAPIのデプロイはいくつかのメリットがあります。

  • サーバーやインフラの管理が不要です。
  • 一時的な大量のトラフィックを対応するために、APIインスタンスの数を容易に拡張できます。

しかし、いくつかデメリットと制限もあり、特に以下の点が挙げられます。

  • しばらくLambdaが呼ばれないときに、コンテナが起動時間が発生し、リクエスト処理の遅延が発生します。
  • パフォーマンスを向上させるために調整できるのは、メモリ(および比例するCPU量)のみです。
  • API GatewayからLambdaを呼び出す場合、タイムアウトは29秒に制限されます。
  • Dockerイメージの容量は10GBに制限されています。
  • 使用料金は、リクエスト数と処理時間の両方に基づいて設定されるため、長時間の処理を大量に実行する場合には割高になる可能性があります。
  • ローカルストレージを必要とするアプリケーションには適していません。Lambdaは/tmpディレクトリに512MBの追加ストレージしか提供しません。

Dockerイメージのビルド

AWSでは、Lambdaがサポートするプログラミング言語のベースイメージが多数用意されています。

この記事では、Python 3.7のベースイメージを使用します。

注:ハンドラの名前は、ソースコードで定義されているMangumハンドラの名前と一致していることが必要です

FROM public.ecr.aws/lambda/python:3.7

# Copy function code
COPY main.py ${LAMBDA_TASK_ROOT}/app.py

# Install the function's dependencies using file requirements.txt

COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt --target "${LAMBDA_TASK_ROOT}"

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.handler" ]

次に、docker buildコマンドを使ってLambdaイメージをビルドし、タグ付けします。

docker build -t imagenet-lambda -f Dockerfile.lambda .

コマンドが完了すると、以下のような出力が表示されます:

Step 5/5 : CMD [ "app.handler" ]
---> Running in 2257d01b05b0
Removing intermediate container 2257d01b05b0
---> 14755a1c4440
Successfully built 14755a1c4440
Successfully tagged imagenet-lambda:latest

イメージをLambdaで使用する前に、AWS Elastic Container Registry (ECR)にアップロードする必要もあります。

まず、AWS ECRコンソールに移動し、新しいリポジトリを作成します。

次に、先ほど作成したプライベートECRリポジトリにログインし、<Region Name><Account ID>のプレースホルダーをECRリポジトリのリージョンとAWSアカウントのアカウント番号に書き換え、以下のコマンドを実行します。

aws ecr get-login-password --region <Region Name> | docker login --username AWS --password-stdin <Account ID>.dkr.ecr.<Region Name>.amazonaws.com

注:上記のコマンドを実行するには、awscliパッケージがインストールされている必要があります。インストール方法はこちらをご覧ください。

最後に、イメージにタグを付けて、ECRにプッシュ(アップロード)します。

docker tag imagenet-lambda:latest <AccountID>.dkr.ecr.<Region>.amazonaws.com/<RepositoryName>:latest
docker push <AccountID>.dkr.ecr.<Region>.amazonaws.com/<RepositoryName>:latest

CloudFormation

Dockerイメージの作成が完了したら、APIをデプロイするLambda関数を作成します。このLambda関数を簡単に作成するために、CloudFormationテンプレートを用意しました。

テンプレートを実行するには、以下の手順を行います。

  1. 1. CloudFormationのコンソールを開きます 。
  2. 2. 利用したいリージョンを選択します。
  3. 3. Create Stack → With new resources (standard) 「スタックの作成 (新しいリソース)」を選択します。
  4. 4. テンプレートファイルのアップロードを選択します。
  5. 5. deploy/lambda.yamlのパスを入力します。(Next)「次へ」をクリックします。
  6. 6. テンプレートに必要なパラメータを入力します。
    •  Stack Name. 今から作成するスタックの名前です。例:「ImageNetTest」。
    •  ImageUri<Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latestというフォーマットで、前のステップでアップロードしたDockerイメージのURI。
  7. 7. (Next) 「次へ」をクリックします。
  8. 8. 画面下部のチェックボックスをすべてチェックします。
  9. 9. (Create Stack)「スタック作成」をクリックします。

これでAPIがデプロイされ、すべてのAWSリソースが準備完了したら、API GatewayのURLを呼び出すことで、APIのLambdaを起動することができます。

Elastic Beanstalkのデプロイメント

APIは、Elastic Beanstalk上にもデプロイすることができ、Elastic Beanstalkの使用には以下いくつかメリットがあります。

  • ・より柔軟な設定が可能です。例えば、GPUインスタンスを含む様々なインスタンスタイプを選択できます。
  • ・しばらくAPIを呼び出さない場合、コンテナの起動時間は発生しません。
  • ・使用料金は、リクエストごとではなく、インスタンスが稼働している時間に応じて決まります。APIによってはこの方が安いかもしれません。

しかし、Elastic Beanstalkにはいくつかのデメリットもあります。

  • ・Lambdaに比べてインスタンスの起動とスケーリングが遅くなります。
  • ・インスタンスがアイドル状態でも料金が発生します。
  • ・Lambdaより設定に調整できる項目が増えますが、使い方も複雑になります。

Docker イメージのビルド

Lambdaと同様に、Dockerイメージを作成するためにDockerfileを作りますが、ファイルの内容は少し違います。

Mangumのハンドラを呼び出すのではなく、コンテナにあるuvicorngunicornサーバー上にAPIをデプロイします。

イメージの作成を楽にするために、uvicorn-gunicorn-docker templateを再利用します。

Elastic Beanstalk向けたDockerイメージを構築するために、以下のコマンドを実行します。

docker build -t imagenet-eb -f Dockerfile  .

ビルドが完了すると、以下のような出力が表示されます。

Removing intermediate container 91a51bb166d4
---> 0bb1a7031a5e
Successfully built 0bb1a7031a5e
Successfully tagged imagenet-eb:latest

イメージをElastic Beanstalkで使用する前に、AWS Elastic Container Registry (ECR)にアップロードする必要もあります。

まず、AWS ECRコンソールに移動し、新しいリポジトリを作成します。

次に、先ほど作成したプライベートECRリポジトリにログインし、<Region Name><Account ID>のプレースホルダーをECRリポジトリのリージョンとAWSアカウントのアカウント番号に書き換え、以下のコマンドを実行します。

docker tag imagenet-eb:latest <Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest
docker push <Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest

CloudFormation

Dockerイメージの作成が完了したら、APIをデプロイするElastic Beanstalkの環境を作成します。この環境を簡単に作成するために、CloudFormationテンプレートを用意しました。

テンプレートを実行するには、以下の手順を行います。

  1. 1. CloudFormationのコンソールを開きます 。
  2. 2. 利用したいリージョンを選択します。
  3. 3. Create Stack With new resources (standard) 「スタックの作成 (新しいリソース)」を選択します。
  4. 4. テンプレートファイルのアップロードを選択します。
  5. 5. deploy/elastic-beanstalk.yamlのパスを入力します。(Next)「次へ」をクリックします。
  6. 6. テンプレートに必要なパラメータを入力します。
    • Stack Name. 今から作成するスタックの名前です。例:「ImageNetTest」。
    • InstanceType。使用するインスタンスの種類です。
  7. 7. (Next) 「次へ」をクリックします。
  8. 8. 画面下部のチェックボックスをすべてチェックします。
  9. 9. (Create Stack)「スタック作成」をクリックします。

APIのデプロイメント

CloudFormationでElastic Beanstalkの環境の作成が完了したら、そこにAPIをデプロイします。

Elastic Beanstalkには、アプリケーションをデプロイするための2つの方法が用意されています。

  1. 1. Zipファイルをアップロードします。APIのファイルを含むZipファイルをアップロードします。デプロイに必要なDockerrun.aws.jsonというファイルにホストとDocker間のポートマッピングを定義している必要がありますが、DockerイメージのURIを指定する必要はありません。zipファイル内にDockerfileが存在する場合、APIコンテナはECRにアップロードする必要がなく、Elastic Beanstalkのインスタンスにビルドされます。
  2. 2. Dockerrun.aws.jsonのみをアップロードします。このファイルには、ホストとDocker間のDockerイメージのパスとポートのマッピングも記載されていますが、上と異なり、DockerイメージのURIを指定する必要があります。

今回は、アプローチ2番で進めます。

以下のようにDockerrun.aws.jsonという新しいファイルを作成します。

{
 "AWSEBDockerrunVersion": "1",
 "Image": {
   "Name": "<Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest"
},
 "Ports": [
  {
     "ContainerPort": "80"
  }
]
}

Image Nameの部分を、先にアップロードしたイメージのURIに書き換えます。

Elastic Beanstalkのコンソールに移動し、(Upload and deploy) 「アップロードとデプロイ」ボタンを使ってDockerrun.aws.jsonのファイルをアップロードします。

しばらく待つとデプロイは完了します。

最後に

この記事では、FastAPIによるTensorFlowモデルを活用するAPIを作成するアプローチを説明しました。

また、同じコードを使ってAPIを2つの異なるAWSサービスにデプロイしました。

機械学習のデプロイにどのAWSサービスを使用するかを選択するのは時に難しいことですが、まずAWS Lambdaを試してみることをお勧めします。他のサービスに比べて、Lambdaは使いやすくてスケーラビリティが高いです。

より高速な推論のためにGPUを必要とする場合や、その他の要件でAWS Lambdaが適さない場合は、代わりにAWS Elastic Beanstalkをお勧めします。

ソースファイル

ソースファイルを GitHub に公開しました。

・main.py – APIのソースコード
・Dockerfile – Elastic Beanstalkのデプロイに向けたDockerfile
・Dockerfile.lambda – Lambdaのデプロイに向けたDockerfile
・Dockerrun.aws.json – Elastic Beanstalkのデプロイに向けたコンテナ設定ファイル
・requirements.txt – APIの依存関係が書かれているファイル
・deploy/elastic-beanstalk.yaml – Elastic Beanstalkのデプロイに向けたCloudFormationのテンプレート
・deploy/lambda.yaml – Lambdaのデプロイに向けたCloudFormationのテンプレート

最後までお読みいただき、ありがとうございました。

AIエンジニア

AIエンジニア

沖縄本社では、一緒に働くAIエンジニアを募集しています

その他、システムエンジニア、iOS/Androidアプリエンジニア、多数募集中!

はじめに

はじめまして。プロトソリューション・オフショア開発の三亀です。
ベトナム・ハノイでIT開発チームの現地マネージャーとして奮闘しております。
今回は私のストーリーをご紹介いたします。

入社までの略歴

高校までは千葉にいました。その後、北海道大学に入学し、札幌で4年間を過ごしました。経済学部だったのですが、いわゆる「とりあえず文系で潰しがきく学部に入っとけ」精神だったので、卒業間際になって進路について迷走しました。

順当にいけば金融関係なんでしょうけど、「自分が何に向いてるかな」と考え直した結果、昔から物を作ったりするのが好きだったのと、当時盛り上がってきてたという理由でITを選びました。

実は大学3年から統計学のゼミにも入ってたので、そこでコンピューターに触れたというのも一つのきっかけだったと思います。

「手に職つけられて、将来性もある」と思って選んだつもりが、当時は周囲からの反対も多かったです。同期のメンバーは「東証一部の会社に総合職で入社」みたいなパターンが多かったので、完全に偏見だと思うのですが、なんでわざわざSE?みたいな雰囲気はありました。さらに、当時は「SEは3K」みたいな言われ方をしてたので仕方ないかと思いますが、この職業を選んだことに悔いはないですね。ちなみに、3Kとは「きつい、厳しい、帰れない」のことです。

その後、500名くらいの中規模SIerを2社ほど経験しました。この期間が10年くらいで、自分的には技術の下積み時代だと思ってます。そのうち自社プロダクトを開発している会社に憧れを抱くようになり、某インターネットメディア企業(以下A社)に転職しました。 A社には技術や開発に対する知見があるエンジニアが多かったので、日々刺激を受けながら仕事をすることができました。また、なにより、「ITをどうやってビジネスに結びつけるか」ということを、創業20年も続いているA社で見てきたことはキャリアの大きな糧になっています。

A社では主に開発チームのプレーイングマネージャーとして、約10年間、次のようなことをやっていました。「各種レガシーシステムの刷新」「マイクロサービス化」「不採算サービスの断捨離」「オフショア開発推進」

この中の「オフショア開発推進」が現在の仕事にもつながってきます。「IT需要に対して、年々エンジニア不足していく」という日本が抱える課題に対して取り組めば、仕事のチャンスも増えるだろうと考えています。

プロトソリューションに入社

プロトソリューション入社の経緯はちょっと変わってます。A社時代に出張で何度かハノイに来てたのですが、その際、プロトソリューションの現地駐在員の方々と仲良くなりました。その頃ちょうどその方が退職を考えていて、ハノイ拠点長の後任を探していたというのが経緯になります。

いろいろ会社の状況を聞いて、ビジネス面で伸びていて仕事量は豊富だし、やり方によってはオフショア開発を拡大して、事業に貢献する余地がまだまだあるなあ、と興味を持ちました。あと、最終的には、取締役がわざわざハノイにまで会いに来てくれて、その心意気にも決断を促されました。

入社してから約半年は東京支社に勤務していました。ハノイ駐在が入社の前提だったのですが、コロナ・パンデミックが始まりしばらく渡航できませんでした。でも、これによって、東京支社のメンバーと交流する時間も増えましたし、現場の課題を肌で感じることができたので、結果的に有意義な期間だったと思っています。

そして、昨年12月に2週間の隔離を経て、無事ハノイへ渡航しました。

今やっていること

僕はオフショア開発専任ですが、ベトナム側だけに目を向け改善していっても、それは部分最適にしかなりません。「仕事を出す日本側」と「仕事を受けるベトナム側」がいい感じに協調していかないと効果を最大化できないのは明白です。(最終的には「日本とベトナムは1チーム」という雰囲気を醸成したいのですが、それも段階的にやっていこうと思ってます)

・日本側

プロトソリューションに入ってまだ1年ちょっとですが、感想として「ビジネス、案件、仕事の量は多い」「現場のエンジニアが非常にまじめ」というのがまずありました。良い要素は揃ってるので、さらに開発フローなどの効率化を進めることでまだまだ伸び代があると考えています。例えば、Backlogなどのデファクトとなっているツールを最大限まで使い倒す、ということを現場に浸透させてきました。さらに、どの業務をオフショア開発に任せるべきか、というのを判断し、各拠点のメンバーと相談しながら徐々にベトナムへ移行しています。

・ベトナム側

前任者の時代にベトナムチームは35名に到達しましたが、品質問題が噴出し、一度そこから人数を減らしたという経緯があります。これを教訓に、規模の拡大に耐えられるよう、土台をしっかり作りながら進めています。具体的には、最終的な品質担保を行うPM(プロジェクト・マネージャー)、BSE(ブリッジSE)に優秀な人材を配置し、共通のガイドラインにそってプロジェクト運営を行ってもらっています。

その結果、徐々にプロジェクトのオフショア移管も進み、現在ベトナムチームも25名にまで回復しました。また、下記は一例ですが、扱ってるプロジェクトもユーザー影響の大きいものが増えてきて、やり甲斐を感じています。

「モバイル版 中古車・バイクのカタログサービス」「業販向けEC」「有名バイクメディア」

心がけていること

オフショア開発を行う上で主にこの三点を心がけています。

1.代理プロダクトオーナー

駐在というと、どうしても現地メンバーを「管理」するという発想になりがちです。以前、アジャイルとオフショア開発で発信力のあるエンジニアの方にアドバイスをもらったことがあって、「管理」ではなく「代理プロダクトマネージャー」として現地メンバーに接した方が良いと。

これは、日本にいるサービスの企画、運営を行っているプロダクトマネージャーの代わりに、現地でサービスの背景、狙い、収益構造などを説明することこそ大事という内容でした。ですので、何か改修を依頼するときでも、なぜその機能が必要なのか、必ず背景から説明するようにしています。この地道な積み重ねが、ベトナムエンジニアのコミットメントを引き出せると信じています。

2.ドキュメントが全て

多国籍チームになるに従い、コミュニケーションの齟齬は発生しがちです。文化や母国語が違うということを本当に慎重に扱わなくてはなりません。

対策としては、「ドキュメントが正」という文化を根付かせるしかないと考えています。チャットでも議事録でもGoogleDocsでもいいのですが、とにかく、書くことを面倒くさがらずに行うことが重要です。

例えば、開発ガイドラインに項目を常に足していって、開発の際に注意しないといけないことを言語化してみんなで守るようにしています。(英語、日本語、ベトナム語で記載) 日本人だけで仕事をすると、その場の空気感で物事が決まったり、暗黙知でお互いが仕事をしがちですが、それを排除していこうと考えています。

3.日越いいとこ取り

あと、「日本とベトナムの長所をミックスしていく」というのも意識しています。先日、あるリリースに立ち会ってた際、リリース中にそのやり方ではうまくいかないことが分かり、どうしようか?という話になりました。日本の感覚だと、一旦リリースを中止して、後日、代替案を検討&テストしてから再リリースしましょう、となりそうです。ところが、ベトナムのエンジニアは、その場で解決策を考えすぐ実装してしまうんですよね。ちょっと面食らいましたが、コードを見て問題なさそうだったのと、事業への影響度なども考慮した上で、その案を採用してリリースしました。この判断ができるかどうかが、日本とベトナムの間に立つ人間の役割だと感じています。結果的に、リリースを後日に回すことによる時間のロスを防げたので良かったです。

ベトナムエンジニアが持っているスピードを、日本のエンジニアが得意とする品質保証の仕組みでバックアップできれば、最強のチームが出来上がるはずです。

今後やりたいこと

今期50名体制を目指しています。さらに、2~3年後には最終的に100名体制まで拡大し、事業に貢献していきたいと考えています。当然、いたずらに規模拡大ではなく、品質やスピードを担保した上でのこの数字を追っていきます。

前述した通り、今はチームを盤石にするため、PM層に日本人を増やしていますが、最終的には、日本人を増やさなくてもベトナムのチームだけで拡大、自走できるというのが目標です。

さらに将来のことで、全然未計画ですが、アメリカなど日本以外の国からも開発案件を受けることができたら面白いんじゃないかと考えています。

最後に

今まで培ったIT技術やマネジメント経験を海外でも試してみたい、という方は是非プロトソリューションのオフショア開発推進に手を貸して頂ければ幸いです。

僕もそうでしたが、いきなりハノイ駐在は抵抗があるかもしれないので、まずは仙台、東京、沖縄のどこかに住みつつ、リモートでベトナムの開発チームと仕事をしてみよう、というのでも構いません。

最後までお読みいただき、ありがとうございました。

・現地の生活についてほぼ毎日ブログを書いてますので、良かったら覗いてみてください。

・いつもチーム運営をサポートして下さっているハイブリッドテクノロジーズ社にこの場を借りてお礼を申し上げます。

みなさん、はじめまして。
プロトソリューション東京支社の外間(ホカマ)です。

今回は、IT未経験で入社した私が東京拠点の責任者になるまでに見てきた景色をご紹介させていただければと思います。

プロトソリューションは「ヒト」が一番の強みであることが伝わるかと思いますので、
是非最後までご覧いただけましたら幸いでございます。

▶ 私のプロフィール

2010年  入社(SE)
株式会社プロトデータセンター(現・株式会社プロトソリューション)沖縄本社にIT未経験ながら
情報システム部に配属。主にクルマ情報メディア「グー」シリーズ誌面制作、社内システムSEを担当。

2013年4月 東京への転勤(プレイングマネージャー)
東京支社にて新規チーム立ち上げの為、転勤。
グーシリーズを中心とした大規模システムにおけるデータベース領域の開発を経験。
支社拡大の為、ITスキルだけでなく、チームビルディングも担う。

2016年 (マネージャー)
東京支社のIT部隊をWEB開発、クラウド、DBA(Database Administrator)を中心とした領域において
マネジメント。クライアントに近いロケーションで上流工程からシステム開発を支援。

2019年〜現在(マネージャー)
東京拠点におけるIT部隊の責任者となり、クライアントとの折衝をしつつ、WEB開発、クラウド、DBAといったプロトグループメディアを支えるチームを統括。
また最近では次期マネージャーの育成にも注力し、より強い組織づくりを目指している。

以下、私の経験も踏まえながらプロトソリューションの「ヒト」についてお話させていただきます。

▶ 入社まで

・社会人として生活基盤を整える
沖縄で社会人として生活するためには、移動手段として車が必要なので、
お金を貯めるため、故郷である沖縄を離れ工場に勤務しました。
貯めたお金で車を買ったのですが、その時利用したのが「グーネット」なので、何かご縁を感じました。

・IT業界へ転職するきっかけ
沖縄に帰ったら手に職をつけたいと漠然と考えていました。
工場内はシステムでライン管理がされていて、社内SEの社員が効率化を進めて改善していく姿に憧れて、
IT業界へ転職するきっかけとなりました。

▶ プロトデータセンター(現・プロトソリューション)入社

・入社時の状況
IT未経験ながら採用いただき、まだ創業期の雰囲気もわずかに残る状態で慌ただしい状況もありましたが、社員全員が1つの会社として成立をさせようと本気になり業務を推進している事を印象深く覚えています。

・ITエンジニア、SEとして大事な事を学ぶ
社内SEとしてキャリアをスタートさせましたがまずは改修の要件定義や設計を行うため、
システムを利用している部署へヒアリングし、開発部隊をコントロールする所からはじめました。
不慣れな事も多く、何度もヒアリングに時間を取らせてしまっていましたが
「また来てね」と声をかけてくれて、行くたびにお菓子をもらったり、
少し雑談を交えて会話してくれたりしてくれました。

不慣れな中でも、きっとシステムをより良くしてくれる一員として期待してくれていると感じ、
より一層システム開発に勤しみました。
このときの上司からは、

「システムを利用している人の生の声を聞きながら、背景を理解して
開発や改修を出来る事がエンジニアの成長にとって貴重な経験になる」

と私に教えてくれていました。
経験の浅かった私にとって最初の段階でこの事を教えていただいた事が
今でもお客様と寄り添う時のスタンスに現れていると思います。

・先輩からの教え
先輩方はいつも私の成長をベースに考えて面倒を見てくれていました。
始めは仕事の指示をいただいてそれ通りにこなす事を繰り返していましたが、
次第に指示ベースからどう考えているかといった意見を求めてくれる機会が多くなり、
頼られている気がして嬉しかったのを覚えています。

そういった経験から自然と物事を解決するために“考える”力をつけさせていただけたのだと思います。

・共に成長していく仲間として受け入れてくれる環境
大きな会社なので、中途の私が組織の中に入っていけるのかという自分の中の焦りもありましたが、
ある時「涼治」と下の名前で呼んでくれた事が、仲間として認めてくれたような感動を覚えました。

まだエンジニアとして至らない私の意見に、どんな時も時間をとって耳を傾けてくれたこともありましたし
プラベートでも仲良くなる方もいましたが、それに甘えず仕事上では良い緊張感をもった関係を築く事が出来ました。

沖縄:エンジニアとしての基礎を学ぶ

▶ 東京 新規チームの立ち上げ

・SEからDBAへジョブローテーション
IT経験が3年経ち、次のキャリアプランを考えていた頃、DB領域の事業を開始するので東京で挑戦しないかという話をいただきました。
自身を更に成長させるには良い環境だと思い挑戦してみようと転勤を決心しました。

・DBAならではの大型プロジェクト
大規模システムのDBを社外ベンダーから内製化をするというプロジェクトでしたが、
とにかくシステムの規模感が大きく、関係者も多かったのでやりとりが大変でした。
DBAチームのあるべき形のモデルになる情報が少ない中、手探りで進める事が多く
苦労もしましたが、そういった中で大手メーカーや開発ベンダーの方々と情報交換を行える
東京というロケーションには非常に助けられました。
そうして業務フローの整備を行い、安定した運用体制の構築を実現させていきました。

関わる「ヒト」「モノ」も多い中、一つの目的に向かう事の難易度を感じながら、どのように全体感が隅々に行き渡って完遂していくのかを学べたと思います。

システムも刷新され安定してきた頃、チーム体制を拡充するフェーズに入り、マネージャーの役割を
期待していただくようになりました。

・プレイングマネージャーとしてのキャリアをスタート
自身がプレイする場合と、リーダーとしてメンバーのパフォーマンスを最大限に引き出して物事を推進する違いにギャップを感じて苦戦をしました。

誰かに何かを伝える言葉、パフォーマンスを発揮してもらうための引き出しが全然無いという事に気づき、まずは自分自身がヒトとして成長していかなければならないと痛感しました。

そのうえでメンバーの考えや、成長して目指していきたいキャリアを知り、彼らが成長できる環境を提供する事に努めようと決心しました。

・2回目のDBリプレイスを経験
チームの形が出来て数年が経ち、次期DBシステムへのリプレイスを迎えました。
前回とは違い組織としてプロジェクトを推進し、成長したメンバーの力で無事に成功する事が出来ました。ここが私のエンジニアとしてのキャリアの節目となり、以後マネージャー業に振り切っていく事となります。

東京:リプレイス対策本部にて仙台、沖縄、名古屋とリモート中継

▶ 会社合併と組織の大幅な再編

・会社の合併
2016年に株式会社アイソリューションズと合併し、株式会社プロトソリューションへ商号変更するという大きなイベントを経て、社名もプロトソリューションとなり、文字通り心機一転の再スタートをして
最も良かった事はやはり多くの新しい仲間と仕事をさせていただいた事です。

培ってきた社風、文化、技術に対する向き合い方がこれまでとは違っていてるのが新鮮で、
IT経験が1社目だった私は、まるで2社目の会社を経験しているような気持ちで仕事に臨めました。
一人一人とのやりとりがまた私を成長させてくれていると感謝をしています。

・部署を立ち上げ組織を形にしていく
メンバーも増えた東京支社のIT部隊で独立した部署の立ち上げをすることができました。
そこで部署をとりまとめる責任者を拝命し、この部署を1つの形にする事を自身のミッションとしました。
これまで自身が経験したことのない領域も含めて組織をマネジメントしていくことになりました。

・トップダウンではなく、同じ目線で考え共に成長
トップダウンで指示をするとその瞬間の成果は大きいですが、
誰かが決めた中で物事を進めるという思考に留まってしまう可能性があります。
従って将来的に自律して自身の成長と会社の成長に貢献が出来る人材を増やしていく事にこだわってやっています。

ある程度、枠組みを用意する事は必要ですが、頭ごなしにしたり考えを無下にする事はせず、メンバーと
目線を合わせ、彼らがどのような考えをもって答えを出すかというやり取りを繰り返していきます。

もちろん方向のズレや失敗を招きそうな瞬間は発生しますが
そこで私のようなマネージャーがフォローやアドバイスをしていく形を意識しています。

これはまさに私が入社時に先輩や上司から教えていただいたやり方を踏襲しています。
メンバーがもっているポテンシャルももちろんあるかと思いますが
私の周りに信頼が出来る次世代を担うメンバーが揃っていると感じられるのは
それらがあるからだと自負しています。

昨今のIT・技術の進歩は目まぐるしいものとなっています。
エンジニアはそれらを新たに習得していく事になりますが
どの形になっても変わらない大事な事を、私と共に働く事で気づいてもらえたり
成長してもらえればと日々思いながら取り組んでいます。

東京:CODE BASE TOKYO

▶ 現在とこれから

エンジニアとして現場の経験を経て、今はマネージャーとして組織運営に携わっています。

入社前の自分がまさか東京に来てIT部隊の組織を作っていくとは想像していませんでしたがそういったことも含めて大きな変化や成長スピードの中で過ごすことが出来ています。

振り返ってみると私の周りにはいつも引き上げてくれている先輩や上司、私と一緒に働いてくれる後輩達がいました。自身もまだまだ発展途上であり、成長し続けたいと思います。

そういった姿を後進にも見せていきながら、より強い東京拠点を作り上げていければと考えています。

月並みな言葉に聞こえるかもしれませんが今の環境で働けている事に感謝し、感動し続けられています。特にメンバーが成長して評価をされる場面には目頭が熱くなります。

この充実した環境でメンバーと共にプロトソリューションという会社をこれからも
盛り上げていきたいと思います。

▶ 今後のキャリアプランを考えている方へ

楽しくやりがいをもって成長ができる仕事をしたいと多くの方が考えていると思います。

本気で働いている人の周りにはたくさんの人が集まり、
同じミッションを共有した仲間達は困った時に必ず助けてくれます。
信頼関係を築いた仲間達と共に成長する事が楽しくもあり、やりがいに繋がると考えています。

エンジニアとして技術を追求していきたい方、マネージャーとして管理職へ挑戦したい方、
今後のキャリアをどうしようかとお考えの方、ぜひお声がけください。

プロトソリューションで共に成長しながら働ける事を楽しみにしています。

今回、今までしたことの無い、自身のキャリアを振り返りながら執筆して、改めて自分の目指すところや
やりたいことが整理された気がします。

最後までお読みいただき、ありがとうございました。

ITエンジニア

ITエンジニア

東京支社では、一緒に働くITエンジニアを募集しています

Webディレクター、その他多数募集中!

はじめに

みなさん、はじめまして。
プロトソリューション仙台本社の進藤です。

今回は、私の仕事に対するマインド・スタンスを、当社人事の西野にインタビューしてもらいましたので、ほんの少しご紹介させていただきます。
最後までご覧いただけましたら幸いでございます。

私のプロフィール

2005年04月 – 2016年09月
株式会社アイソリューションズ入社
Webエンジニアとして、プログラマー、システムエンジニア、プロジェクトリーダー、プロジェクトマネージャーを順に経験。宮城県地場企業様から、首都圏大手企業様まで、大小多種多様な企業様のソリューション開発・ニアショア開発に従事。

2016年10月 – 現在
株式会社プロトデータセンターと合併し、株式会社プロトソリューションへ商号変更
仙台開発事業部の責任者として事業を統括、事業部戦略立案を中心に、ブランディング、リクルーティングなど、仙台本社に関わる取り組みを推進。現在は、AIテクノロジー推進室仙台を設立し、前述に加えて、システム開発(Web系)は勿論のこと、プロダクト開発(新規事業企画・SaaS製品開発)、R&D(AI研究開発・高度IT人材育成)、HRBP(人事戦略考案)、この4セクションの統括マネージャーに従事。

レビューは戦争だ!って、バッチバチしていた頃(笑

Q.今はマネージャーをされていますが、当時はどんなITエンジニアだったんですか?

特別なことはなくて普通だったと思うけど(笑)ただ、とにかくこだわってモノづくりをしていたのと、自分なりのポリシーは色々あったと思う。ITに興味がない、、、それだと語弊があるね(笑)ITに興味がないというよりは、IT以外のコトにも興味を持つようにしていたかな。そこは単純で多種多様なお客様(業界・業務)がいらっしゃるので、必然的にIT以外のコトも、お客様程とはいかないまでも知って、しがみついていかないといけないし、ITに没頭していれば、良いモノを作れる!っていうのはまかり通らないよね。だけどITは、世の中で最も夢のある、そして素晴らしい、最高の手段だとずっと思ってる。

Q.特にこだわっていたことを挙げるとしたら何ですか?

それは今も変わらなくてデータだね。お客様からオーダーをいただくシステム開発は、データをインプットして、アウトプットすること。一般的なWebサイトは、データを出し入れするためのいわばツールみたいなもの。データはお客様にとって貴重な資産で、データがあれば何かを創造できるかもしれないし、何かの方法が見つかるかもしれない、お客様の未来に繋がるはずだから、データだけは絶対に守らなきゃいけない!勝手にデータドリブンみたいな感じで必死だった(笑)だから、テーブル設計や、ER図のレビューなんかは、もう戦争(笑)これ!っていう答えがある訳じゃないから、エンジニア同士の意地と意地のぶつかり合い、バッチバチ(笑)

あとデータで言えば、後輩エンジニアにも、SQLから先に作ろう!って教えてた、逆に画面、Web、SQLの順で作ってしまうと、早く画面の動きが見たくて、SQLをおろそかにしちゃう、、、複雑になりがちで、カスタマイズ性を左右するのもSQL。それから、開発コストや、ランニングコストを下げたり、不具合解消のスピードと質を上げるのも、テーブル構造のデキが大きい。例えばデザインはお客様と密に詰めてアウトプットするけど、データはお客様が介入されない我々エンジニアが単独で完全に責任を追う唯一の領域だから、こだわりを持って当たり前。

当たり前と言えば、どこまでいっても、自分なりのポリシーの軸は「ABC(当たり前の事をバカになってちゃんとやる)」かな。デスクを綺麗にしてっ!・・・なんてこと、よく言ってるでしょ(笑)

明日もまた会社に来たい!って、心躍る、そんなチームがいい

Q.今、一番楽しい時って、どんな時ですか?

チームメンバーが何かを成し遂げてレベルアップをした時。初めて後輩が出来た頃から、自分よりも、後輩にベクトルが向いていたかな。それは、当時の先輩が仰っていた言葉がきっかけで「後輩は先輩を超えるもの、先輩の教えプラス自分があるから超えて当然」って言われたのを今でも覚えていて、それが大きな影響だね。

Q.楽しいとは反対に、不安になる時はありますか?

チームメンバーが笑っていない時は、すごく不安になる(笑)仕事でも何でも、ポジティブに楽しんで取り組んだ方がいい。その方がジブンゴトとして考えることもできるし、やり甲斐も、余裕も生まれる。なんなら失敗だって成長の糧なんだって思えるよね。当然、仕事上は、お客様がいらっしゃってローンチまでのプレッシャーもあるし、自分が成長できないストレスだってある、大変な事も多いかもしれないけど、朝起きた時、今日も頑張るぜ!って心躍る、そんなポジティブフルなチームがいい。

Q.チームメンバーに対して、普段から意識して取り組んでいることはありますか?

フロア散歩。普段、彼らから私に用事がある時って、決裁やら報告、もしくはネガティブな相談事・・・マネージャーって孤独なのよ(笑)だから、この時間って決めて散歩してる。

Q.散歩ですか?(笑)どんな会話をするんですか?

「ウィ!調子どう?」だけ(笑)特に自分が見させてもらってる部署は若手が多くて、何気ないコミュニケーションでも成長を感じられて、素直にすごいじゃん!って感心するし、同時にチームが上手く機能している安心感も得られる。特にスペシャリストの連中なんかは動きも考えも面白いよ。フロアにはポジティブなニュースがたくさん落ちてるから、それを拾い集めてる感じだね。

Q.他にも色々なコミュニケーション手段があると思いますが、なぜ散歩なんですか?

すごくシンプルで、課長、部長、役員みたいな現場からは少し離れていて、ブラックボックスな会議に参加するような人達に声を掛けられると、嬉しかったし、頑張ろう!ってモチベーションになったり、良い刺激をもらえていたから、そうしてる。

Q.印象に残っている散歩ってありますか?

・・・(笑)
当社のサービス < ラクネコ > の担当者に「ウィ!調子どう?」って言ったら「只今、リリース中です!」って即答されて「あ、ごめん」って言ったよね(笑)それから彼には「今、リリース中?」って声を掛けるようにしてるよ(笑)

Q.組織を運営している中で、大事にしていることはありますか?

組織を運営する中で意識しているのは、何よりもメンバーの成長が一番。ヒトがモノを創って、モノがコトを生むんだから。更に欲を言えば、テクノロジーとアイデアの中に自分達が居るような環境とか風土も創っていきたいね。あと、普段の振る舞い的なことでいうと3つあって、①自分という存在が常に適度なプレッシャーであること、②自分が一番のアイデアマンであること、③メンバーへの感謝を常に持ち続けること、この3つだね。

Q.組織の次世代を担うリーダー陣に、普段からメッセージングしていることはありますか?

特にない(笑)トップダウンで、あーして、こーして、っていうのは響かないから、自分らしく彼らは彼らなりのマネージメントをしていけばいいと思う。

強いて言えば「自分以外はお客様」精神かな。チームや、部署を率いるということは、カタチ上は自分が一番上に立っているようで、実は一番下。メンバーありきで自分がいて、メンバーに助けられていることを常に忘れてはいけないからね。

何にこだわり、何を夢見るか?って、本当に大事なコト

Q.夢はなんですか?

世界平和。すごくスケールの大きい話かもしれないけど、世界には困っている子供達がたくさんいるから、ちょっとでもチカラになれればいいと思っている。未来は子供達が創っていくんだから、子供達の夢が広がる各々の社会を創造する義務が現社会人にはあるよね。

世の中には数年後の将来を描き、それをカタチにして社会を変えている企業や、経営者の方々がいらっしゃって、生活を支える重要なインフラになっていたり、人々をアッと驚かせるアイデアで時代を牽引したりと、それだけで十分な社会貢献なのに、営利だけではなく、サステナブルな視点も含まれている、本当に凄いこと。このような大きな影響力を持つ企業や、経営者の方々が、世の中の10%だとしたら90%の人々は、小さなことでも何か一つ!後世に残していくことが重要だと思う。そこに、エンジニアとか、プロフェッショナルとしての社会貢献ということにこだわりはなくていい。

いつの日かくる社会人の終わりに、心の底から満足できていればいいんじゃないかな。

Q.そのための「Re:Jomonプロジェクト」ですか?

「Re:Jomonプロジェクト」は、東日本大震災から十年の節目を迎えて、地域の皆様に際して、何か貢献したいという想いで発足したプロジェクトだから、やるべきミッションは違うけど、ビジョンは同じだね。このプロジェクト通じて地域が活性化していって、東北から世界にちょっとずつでも波及できれば、もしかしたら届くかもしれないね。

このプロジェクトは、まだまだ道半ばだけど、本当にありがたい機会をもらえたと思ってる。ぼんやりとしていた夢がチャンスというカタチになって、目の前に来るとは思ってもなかったし、それほど、当社にはチャレンジしようとするマインドやカルチャーがあるってということだよね。

本当に器の広い、そして恵まれた会社で働けているって本気で思うよ。

さいごに

Q.最後にご覧いただいた方に、一言、お願いします

私達、プロトソリューションは、これからもバッチバチと成長して参りますので、もし、この記事を見て、ITへ挑戦してみたい!当社で働いてみたい!と感じていただけたら幸いでございます。

最後までご覧いただき、ありがとうございました。

ITエンジニア

ITエンジニア

仙台本社では、一緒に働くITエンジニアを募集しています

自社プロダクト(SaaS)開発エンジニア、社内インフラ、その他多数募集中!

自己紹介

ソリューション開発部仙台に所属している内藤と申します。現在はグループ会社の基幹システム開発を行っております。
もともとはECシステム関連を得意としておりましたが、ECシステムにかかわらず、システム構築全般をこなしてきました。

現在の業務

自己紹介でも書きましたが、グループ会社の基幹システム構築に携わっております。もともとはその会社で行っているEC販売に関連するシステム構築のお話を頂き、そこから拡大して会社全体を担う基幹システムを構築したいとのことで、毎年少しずつ機能を追加して現在は会社のほとんどの部署をまかなうシステムの構築をすることができました。

作成したもの

システムを構築する手順としては、相手先の担当者との要件定義(どんな物を作成するかを決める)から始まり、基本設計、詳細設計、実装、単体テスト、結合テスト、システムテストと各工程を経て最終的に完成に至ります。
そのような手順を踏まえて作成された基幹システムですが、基幹システムと一言でいってもどのような物か想像しづらいのかと思いますので、少しご紹介します。
会社内の各部署によりさまざまな機能が存在します。
社内だけではなく、外部のシステムとの連携も行い、業務にかかるコスト削減を目的としています。

・販売系部署
 - 受注データの作成
  - 各種外部ECサイトへ接続し受注データの連携(楽天、Yahoo!、Amazon、他ECサイト)
  - 手動での受注データ作成
 - 仕入担当部署への発注データの作成
 - レジシステムとの連携
 - タブレットを利用しお客様に記載頂く為の入力フォーム
 - お客様のシステムとのデータ連携
・管理系部署
 - 発注データの作成
 - 仕入データの作成
 - 商品データの管理
・物流系部署
 - 配送商品の物流会社との連携
 - ハンディターミナルを利用した商品のチェック処理
・経理系部署
 - 販売、仕入にかかる入金の管理


まだまだ他にも機能があり、また今後も拡張して行く予定となっています。

ハンディターミナル

利用言語と環境

システムのベースはJava言語を利用したWebシステムとなっていますが、外部との連携、実現したい内容、プラットフォームにより、利用言語を変更しています。

プラットフォーム 利用言語
Web Java
Android Java
ハンディターミナル VisualBasic.NET


また、これらのシステムを作ったとしても動かすためのサーバーが必要となります。
サーバーを動かすということは、セキュリティやネットワークなどのインフラ関連も重要になってきますので、システム構築には様々な知識が必要となります。

インフラにかかわる知識
OS Linux、Windows
Webサーバー Apache、nginx
FTPサーバー vsftpd、IIS
データベース Oracle、PostgreSQL、MySQL
ネットワーク ネットワークセグメントの設計、LB、IPS/IDS
クラウド AWS


このように、一つのシステムを作ることで新しい知識が増える喜び、成長を実感することができ、
またお客様によろこんで頂けると言葉では言い表せないほどの感動を得ることができます。

最後に

システムを構築する上で大事なことは、お客様の要件を聞き(要件定義)、実際には何を実現したいのかを把握し、無駄をそぎ落としつつシステムに落としこんで行くこと(設計)だと思っています。
言われたままシステム化を行うと、完成後に「こういうのではなかった。。」ということが起きてしまいます。(私も若いころにそういうことも経験しました。。)
技術を追い求める事も大事ですが、システムエンジニアとしては、ヒアリング力、提案力も大事な要素となります。
これらは、一人の力で解決できるものではなく、人それぞれ長所、短所があるように得意不得意のあるメンバーが集まって、チームで解決していくことでより良いシステムの構築ができるものだと思っています。

技術が好きな方、話すのが好きな方、考えるのが好きな方、それぞれで活躍の場がありますので、
一緒にシステム構築をやってみたいと思って頂ける方がいらっしゃいましたら、是非ご応募頂きたいです。

ITエンジニア

ITエンジニア

沖縄本社では、一緒に働くITエンジニアを募集しています

AIエンジニア、システムエンジニア、その他多数募集中!

ITエンジニア

ITエンジニア

仙台本社では、一緒に働くITエンジニアを募集しています

自社プロダクト(SaaS)開発エンジニア、社内インフラ、その他多数募集中!

ITエンジニア

ITエンジニア

東京支社では、一緒に働くITエンジニアを募集しています

データサイエンティスト、データベースエンジニア募集中!

ページトップへ戻る