アーキテクトとして、横浜駅のようにシステムづくりに励む今
2021年3月現在は、社内でも数少ないアーキテクトとして、ウェブサービスを担当しています。その前は2年ほどファストフード店のアプリの保守を行ったり、家電量販店のサーバーサイドを担当したりと、アプリを中心に活動してきました。
アーキテクトとしては、クライアントのご要望を実現するシステムの設計、構築を担当しています。その際に、意識していることはふたつ。
ひとつは、最終的にシステムが目指す完成形、もうひとつはクライアントにとってメリットのあるシステムを提供し、実際に使ってもらえるようにすることです。そのふたつを踏まえて、全体の枠組みから見た機能を提案し、将来を見据えたシステムを構築しています。
また、機能だけでなくインフラも受け持っています。AWSなどのサービスを使ってどのようにシステムを安定させていくのか考え、サーバーで動くプログラムを設定するのがメインの仕事になりますね。
システムづくりは改修し続けるものなんです。昔インターネットで、「システムづくりは横浜駅みたいなものだ」という記事を読んだことがあります。横浜駅はいつ行ってもどこかが工事されていて、駅として運用しつつも機能が拡張され続けています。システムづくりも同じなんですね。私も改修しやすくてバグが少ないシステムを心がけています。
エンジニアとして働く！理想の働き方を求めてたどり着いた、ゆめみ
学校は情報系で、進学のきっかけはファミコンでした。自分でゲームをつくれるのが、当時はとても新鮮で興味が湧いたんです。雑誌やパソコンを買ってもらい、自分でプログラミングを打ち込んで覚えていきました。進学後はより本格的に学べ、最新技術に触れることもできて、一層プログラミングに楽しさを感じましたね。
新卒で入った会社も情報関連でしたが、プログラミングよりもデータの作成が主要な業務でした。今でも通用するSQLやUnix、ネットワークを学べたものの、「もっとプログラミングを書きたい、他のことがやりたい」という想いが募り、転職を決めます。
2社目はSESの会社で、社外に出てクライアント先で開発するのが当たり前でした。そのため、私自身やりにくさと不安を覚えたんです。また、30代40代と年齢を重ねて、自分がSESをしているイメージが持てませんでした。そこで再び転職し、3社目へ。そこには10年ほど勤務していました。
ゆめみに転職した理由のひとつは、ライフワークバランスを整えたいと思ったからです。また、SESは営業やPMの影響力が強く、エンジニアは裁量が少ないと感じることがありました。エンジニアが尊重されて、かつ新しいものに触れられる会社で働きたいと思ったため、ゆめみを選びました。
そして、昔から親や友だちに仕事を聞かれたときに、言われてパッとわかる仕事がしたいと思っていたんです。まさに今、それが実現されていますね。
ゆめみに転職する前まではウェブサービス系を担当することが多かったのですが、ゆめみではサーバーを担当し、アプリのAPIやAWSの構築をメインで手掛けるようになりました。
これまでのキャリアで、印象に残っている出来事がふたつあります。
ひとつは、最初の会社で経験したデータ投入です。数をこなすために、アルバイトや派遣の方と一緒に2～3年ほど仕事しました。会社の業務内容を知らず、これまでの経験や得られた能力が異なるメンバーが集まった中で、同じ作業をして同じ成果を出すためにはどうすれば良いのか、自分なりに考えて工夫していました。
そこで学んだ経験が今に活きていると思います。とくに、チームをまとめる上で役に立っていると感じますね。
もうひとつは、2社目でシステム方式設計に携わったことです。
ここで、業務共通のチームではシステム全体を俯瞰し、決めごとをしっかり設計しないと、システムとして運用できないことを学びました。
個別の機能をそれぞれつくっていくと、どこかにひずみが生じて合わなくなってしまうんです。そうした事態を回避するために、設計手法として土台を整えるのが重要だと学びました。さらに、決まりごとを守ったうえで個別の機能を設計するので、全体の整合性がとれて保守もしやすくなると気付きました。
「グッドソリューション」と「やってみなはれ」で、さらなる進化を遂げる
仕事をする上で大切にしている言葉として「グッドソリューション」があります。これは以前受けたセキュリティ講習のワークショップで知った言葉です。
講習中に行われた課題の発表会で、講師の方が「よくできました」の意を込め「グッドソリューション」と言っていたんです。それ以降、クライアントの課題を解決できたら「グッドソリューション」だと思うようになりました。
グッドソリューションを実現させるために、注意していることはふたつあります。まず、購入したシステムが何に使われるのか。さらに、社会にどのような貢献ができるのかを常に意識していました。受託開発では求められたものをつくるので受け身になりがちですか、本番運用が始まった後にシステムが生む価値を常に意識しています。
もうひとつはシステムの外側も含めて全体最適化を図るため、クライアントの求めるものをしっかり探ることです。クライアントの目指す先や考えを得るために、ドキュメントをしっかり読み込み、行間を読むように努めています。
また、クライアントに提案するときには、複数案提示するようにしています。物事を決める過程を知ることで、クライアントにも納得感を得てもらうためです。さらには、クライアントと一緒に作っているという一体感にもつながります。
クライアントから指示を頂いているだけでは、できる・できないといった問題が発生してしまいますし、こちらばかりが働きかけても、クライアントの求めるものはできあがりません。案を出すことは、クライアントのご要望を探るコミュニケーションでもあるのです。
一方社内では、打ち合わせでのコミュニケーションやドキュメントから、メンバーの得意・不得意を見て、得意な部分を生かすことを意識しています。今できないことがあるとき、その理由は不得意だからか、たまたまこれまでに経験がないからかのふたつかな、と。何度か経験してもできない場合は不得意だと思えば良いし、経験が少ない場合は伸びる可能性があるんじゃないかと思います。
ただPMとしては、口出ししたくなってしまうんです。任せられないことで自分の仕事量は増えるし、メンバーの経験を奪っているように感じる一方で放置はしたくないといった具合で、さじ加減に苦労しました。
ゆめみには「やってみなはれ」という言葉があります。当社代表の片岡 俊行も「一回失敗してもいいから、チャレンジしてみよう」と、よく言いますね。今では私も、一回は失敗して良いと思っているので、自分がカバーできる範囲でメンバーに仕事を割り振るようにしています。
困ったときこそ学ぶタイミング──クライアントと利用者と自分のために
ゆめみで印象的だった案件は、ファストフード店のアプリです。規模が大きく、やりがいがありました。アクセス数やデータ量が他の案件の10倍、100倍もあり、きちんと構築しないと処理スピードが落ちてしまいます。
とくにアクセス数の増えるキャンペーンやシーズンでも、クライアントがいつも通り利用できるようにするのは苦労しましたが、大変勉強になりました。自分にとっても新たな挑戦でしたね。
今後は、機械学習やAIをやってみたいですね。とくにチャットボットなんて楽しそうだなと思っています。チャットサービスはよく見かけますし、ユーザーインターフェースとしてチャットでクライアントとコミュニケーションを取るという手法は、より身近になっていくと感じているんです。
私は変化には敏感ですね。周りに置いていかれないよう、対応することにはこだわっています。これまでの経験で、変化の重要性を感じてきたからだと思います。また、困ったときこそ学ぶタイミングだと思うんです。クライアントのご要望に対応するため、手作業を自動化するため、あるいは周囲に遅れを取らないようにするために、新たな技術を学んでいます。
SESでいくつかの案件を経験していくなかで、プロジェクトの繁忙期になると増員が行われ、閑散期になると配置転換をしてコストの最適化が行われていくのを見てきました。配置転換でプロジェクトを離れる人にはそれぞれ理由があると思っています。
一緒に仕事をしていた期間の成果を見ていると、新しい技術や手法に対応できている人とそうではない人との差は短期的には決して大きくありません。時間が経つにつれて大きくなるものなんです。ただ、周囲からの評価はその変化よりもあからさまなものであると感じました。そういう分かれ目をみて、変化の重要性を感じてきたのだと思います。
なので、これからも新しい技術を取り入れながら、できるだけ利用者が使いやすいものをつくっていきたいです。そして、なるべくクライアントと近い部分で、より良いシステムをつくり続けていきたいですね。