学生プログラマと社会人エンジニアの違いについて

自己紹介

はじめまして。ジモティーで2020年4月からエンジニアをしている水上と申します。 前項を担当した阿部と同じく新卒での入社をいたしました。 学生時は情報システムを専攻しており、ジモティーには一月ほど実務インターンを経て入社いたしました。

いくつかインターンを経験したのですが、その中でも、人間関係が非常によく、意見の言いやすい環境が非常に魅力的でした。会社説明会時に現弊社取締役が述べた

「うちに嫌なやつはいない」

そんな言葉を体現している労働環境に惹かれ入社する運びとなりました。

まえがき

実際に入社してから1年が経とうとしていますが、いろいろなことを経験させていただきました。 私の担当記事では学生プログラマと社会人エンジニアの違いについて感じたことを書かせていただこうと思います。

これから先、弊社でも新卒採用も増えてくるのではないかと考えているため、こちらの記事が学生の目にとまり、そして就職活動に役立つことを願っています。(あわよくばジモティーで一緒に働けると嬉しいです)

学生時代

当時出身大学では地域をあげたハッカソンが開催されていました。

ハッカソンとは 出資企業を募り、各社エンジニアを派遣し、学生+αが2日間でプログラミングを用いた成果物を作成 それらを出資企業が評価し、表彰を行う催しです。

そのハッカソンに参加していた私は、実際のエンジニアさんと触れ合うことで非常に貴重な経験をできたと思っています。 そのときに感じた学生と社会人の違いを今回述べていきます。

学生プログラマと社会人エンジニアの違いについて、入社後1年経って思うこと

当時学生から見たエンジニアは非常に頼もしく、作りたいアプリケーションの説明をするとすぐにおすすめのツールや言語等を提示してくれました。さらに、開発時に難所があれば、颯爽と解決策を提示してくれる等、ありありと社会人エンジニアの凄さを見せてくれました。

それらの根幹にあるのは

  • 経験量

  • 知識量

  • 解決策の調べ方

そして、それらが身につく環境だと思っています。

社会人エンジニアは仕事(プログラミング)に対して報酬をもらっています。 対して学生プログラマは趣味や学術の延長線上です。(私の場合のお話です。もちろん学生さんでも責任感をもって報酬を対価にプログラムを作成している場合もあるかと思います。) 決定的に違うのは

  • 自身の成果物に対する責任感

だと思います。

当時、私はプログラミングを用いたソフトウェア開発をやっていましたが、そこまで期限に追われず、また自分しかコードを見ることが無いため、「動けばよかろう」の精神で作成していました。 入社後基礎知識の学習を終え、実務に入ったところ多量のコーディングルール違反によるシステムメッセージが発生してしまったことをよく覚えています。

社会人エンジニアは、自身の成果物の向こう側にその成果物の利用者、成果物の編集者など、関わる人数が学生に比べて非常に多いです。 加えて、学生時代と比べて自身の制作物が正当に厳しく評価されます。会社はそのソースコードを用いて売上を出しているため、中途半端なものを出すわけには行きません。 また、差配された案件によっては、要件通りに作成するばかりではなく、エンジニア観点からの作成方法の提示や、更に良い案のエスカレーション等の能力が必要になることもありました。

そのような経験を責任感を持ちながら積むことで、知識として定着する速度や量が学生と比べて多いと感じました。 解決策の調べ方に関しても、制限時間内に解決するための方法を模索し続けた結果として、早く正しい解決策の探し方が身についていくのだと思います。 実際に社会人エンジニアとなりましたが、日々の業務の中で成長を実感します。(半年前の自身のコードをみると非常に恥ずかしくなります)

おわりに

様々な業務を通して上記の学生と社会人の違いを身にしみてわかりました。最初は自分もハッカソン時に対応頂いたエンジニアのようになれるかと不安が大きかったのですが、やはり、実務に身を置くことで確実に成長し近づいていけていると感じます。まだまだ経験不足ではあるゆえ、上記の考え方は変わっていく可能性もありますが、この記事を読んでいただいた学生さん、もしくは業界未経験の方たちの参考に少しでもなれば幸いです。 もしジモティーにご興味ありましたら、以下にてエンジニアの方の募集を行っております! jmty.co.jp

新卒エンジニアでも貢献できることはある

ジモティーとの出会い

初めまして。iOSチームで開発を行っている阿部と申します。 本日は「新卒のエンジニアでも課題を克服することで、会社の成長に貢献できる」ということを体験談を元にお話しできればと思っています。

(連続して未経験者から・・・という記事が続いてることは目を瞑っていただきたいです🙇‍♂️)

自分は元々、北海道のとある工業大学で「情報技術を使って地元の観光を盛り上げよう」という研究を行っていました。この時点でお気づきの方もいるかもしれませんが、自分は地元が大好きです!

就職活動ではその地元に貢献できるようになるために、自分のスキルを高める会社を探していました。 そんな時に所属していた大学とご縁があったジモティーから内定をいただき1ヶ月のインターン期間を経て入社することを決めました。

・地元と連携し、地域活性のために働ける

・目の前に上場が控えており、成長スピードが高い

・仲間とパートナーを大切にするという文化

この3つの観点が何より魅力的に感じての決断でした。

その後、2020年の4月からジモティーでの新卒採用第一号のiOSエンジニアとして働くことになります。

研修期間から実業務に入るまで

入社してから1ヶ月は基礎的な部分を指定の書籍で学習する(いわゆる新人研修)期間でした。 ※この部分は前回の記事と同様ですね。

その後iOSのコードに触れ、導入しているアーキテクチャを学びながら実際に簡易画面を作ってみるアーキテクチャ研修に入ることになるのですが、この時の自分は「アーキテクチャとはなんぞや」という状態でした。

弊社iOSアーキテクチャはMVP(GUIアーキテクチャ)+CleanArchitecture(システムアーキテクチャ)という形を採っていることは先の記事を読んでくださった方ならご認識あるかもしれません。

f:id:jmty_tech:20201015120550p:plain

※ もし、未読の方がいましたらこちらの記事をご参照ください。

研修を進めていくと、「責務が明確に分かれているお陰で、どのレイヤーでどの挙動を担っているかが分かり易い!」と「なんぞや」状態だった自分でも実感知としてメリットを体感することができました。

その後、簡単な案件を行いながらその中で勉強していくという体勢に変わっていきます。

簡単な案件の中でも新たなテクニックが出現します。汎用性のあるcellを作成してそれを使い回すというものです。 この既存のcellを使うことで開発時間が短縮され、全くiOSを触ったことが無かった自分でもほぼ工数通りに開発を終えることができました。

※汎用性のあるcellのお話も過去のiOSエンジニアの記事に詳細が書かれているのでご参照ください。

このように弊社のiOSの開発では未経験者でも開発を効率的に行える環境が存在し、チームへのjoinがスムーズにできます。

※他にも開発効率化のために様々なツール導入など行っているのですが、それはまた別の記事をお楽しみください。

障害とモンキーテスト修行

さて、ここまで順調のように進んでいた様に見えると思いますがここから軽めの挫折が始まります。 それは自分が担当した機能でボロボロと障害が出てきてしまっていたことです。

弊社では障害のレベルを五段階に分類しており、そのうち4段階目,5段階目は重大障害として扱われています。 入社半年でこのレベルの障害を自分は出してしまい、QCDのQuality(品質)が課題となっていました。

同時期にアプリチームでも自動テストだけでは補えないケースに対応するためにモンキーテストの担当者を立てて、 結合テスト時にできるだけエッジケースのバグを洗い出そうという試みが計画されていました。

そんな個人と組織の課題感がマッチし、自分がiOS開発チーム側のモンキーテストの担当者となりAndroid開発を行っている先輩にモンキーテストをみてもらうことになります。

弊社のアプリチームでは、リリース日の前週木曜日に結合テストAndroid/iOSの両デバイスで同時に行うため、 先輩に結合テスト毎に30分時間をいただきモンキーテストの観点を教えていただきながら修行をつけていただきました。

教わった観点はkibelaにまとめ、アウトプットを出しさらにモンキーテストを実施する、これを3ヶ月続けていくことになります。

成果と成長

ざっと教えていただいた観点を書くと

- 並列と上下を考慮する
   - 構造的なデータ
       - 上下・並列の関係に位置するデータが選択される場合データの不整合が起きないか
   - UI観点
       - 表示が不必要に重なっていないか
       - アクションイベント時に不要な箇所が連動していないか
- ユーザが繰り返し使う機能は要注意
- 実際にはバシバシ負荷がかかる使い方をされるので思いっきり負荷をかけてみよう
- 見え方は問題ないが通信で余計な情報を送っていないか

などなどでした。(もちろんこの他にもまだまだありますが)

この様な観点を教わり、着々とモンキーテスト担当者としての役目を全うできる様になりました。 チームで行う結合テストの際に高負荷時にだけ起きそうな不具合の発見など、着実に成果としてチームへ貢献できていました。 もちろん、個人の課題でもあった障害の数も着実に減っていき「今月一回も障害出してない!」というところまで到達です。

さらに、この修行は別の箇所でも生かされることになります。

エッジケースやユーザの使い方をモンキーテストで考えるため、構造化された考えが身につき始めたのでしょう。 ディレクタから要件をヒアリングする際にも細かな仕様まで目が届く様になり、見落としがちな部分などをヒアリングできる様になっていました。 案件遂行のための成長にも繋がっていたのです。

この様に弊社では、個人と組織の課題を結びつけ個人の成長と組織の成長を結びつける習慣があります。

これは、

・自分の成長を実感できる

・組織への貢献も実感できる

とモチベーションが上がる2つの実感を同時に実現できる文化であると考えています。

この文化のお陰で「考え方」のスキルを身に着け、新卒エンジニアながら組織への貢献も行えたのでしょう。

まとめ

今回は新卒のエンジニアの失敗談を元に成長できる文化の一端を書かせていただきました。

今回の記事が新卒エンジニアの方や未経験の方の考え方の参考になれば嬉しいです。 また、これまでの記事で弊社の文化・技術に興味持たれた方がいらっしゃれば、この先ご縁が生まれると嬉しいです。

自分も次回執筆までにはtechのことをお伝えできる様にさらに勉強していきます!

最後になりましたが、ここまでお付き合いいただきましてありがとうございました。 もしジモティーにご興味ありましたら、こちらでエンジニアの方を募集しております!

営業職からエンジニアになり1年で年間表彰された話

ジモティーへの入社理由

初めまして!
webエンジニアをしている岩間です!
今日は「営業職から未経験でエンジニアになり、どんな過程を経て年間表彰することができたのか」についてお話しできればと思います。

さて、そもそもなんでエンジニアになったの?という話なんですけど、僕は新卒でベンチャー企業に入り、そこで営業をしていました。 営業として仕事を続けていたのですが、文系卒でエンジニアになっている人が意外と多いという事を知り、「自分でwebサービス作れるようになったら面白そうだし、チャレンジするなら若い方がいいだろう」という思いでエンジニア転職に踏み出すことに。

複数社から内定を頂いていたのですが、最終的にジモティーに入社することに決めました。 入社理由としては以下の3つが挙げられます。

  • 僕自身地方創生に興味があり、ジモティーはあらゆるアプローチで地方創生に貢献ができる

  • 利用者数も多いので、大規模開発の勉強ができる

  • 「何より人がいい、悪い人は1人もいない」と激推しされた

こうして無事に営業からエンジニアに転職できたのですが、入社後待ち受けていたのは勉強漬けの日々でした。

入社したら毎日がぶつかり稽古

入社した時点での僕のエンジニアとしての知識は入社前に3ヶ月ほど勉強した程度で、現場では圧倒的な知識不足でした。 入社後1ヶ月間は指定の本で基礎的な勉強をし、その後簡単な開発業務に取り組み始めました。

追うコードの量も多く、システム構成もいまいち理解していない状態だったので、最初は何から始めたら良いか分からず怒涛の質問攻め。 仕事から帰ったら本を読みまくり、ひたすらインプット。本の内容で分からないことがあれば次の日会社で先輩方へ質問。 さらに、成長速度を上げるために以下の取り組みを行いました。

  • 1つの開発業務が終了したら、「何ができなかったのか」「なぜできなかったのか」「何をすればできるようになるのか」「どんな知識が足りていないのか」を毎回考え、Evernoteにまとめる

  • 足りない知識を重点的にインプット

  • 次の開発タスクに取り組む前に前回できなかった事を見返し、できなかった事を意識して開発を行う

こんな日々を繰り返すことにより、少しずつ開発のQCDが上がってきました。

転機となった速度改善プロジェクト

5人日、10人日程度の開発タスクをなんとかこなせるようになってきたある日、工数1ヶ月ほどの速度改善のプロジェクトにアサインされました。 このプロジェクトが僕の成長速度を早めてくれました。

GoogleのMFI移行に伴い、全てのLCPを「良好」にしようというのがこのプロジェクトのゴールでした。ただ、このプロジェクトにアサインされるまでフロント関連の開発タスクにはあまり関わったことがなく、「ブラウザの動きは?」「速度はどんな要因で遅くなるの?」という初歩的な事からインプット始めました。(「超速!Webページ速度改善ガイド: 使いやすさは「速さ」から始まる」という本がすごい役立ちました。)

以下のような流れでプロジェクトを進め、Search Console上で遅いと見なされていたLCPを持つ約30万件のURLを0にすることができました。

1、ブラウザの動き、速度が遅くなる要因、速度検証ツールについてのインプット

2、現状のコードを見て仮説を立てる

3、仮説をもとにコードを修正し、Search Consoleで経過観察

4、改善されなければ再び2番に戻り、作業を繰り返す

ほぼ知識がない状態で、インプットから入り最終的に結果を出すことができたのは、弊社組織の中に「人を成長させる仕組み」が出来上がってきたからだと思います。
(速度改善に関する技術的な話は今度需要があれば、また書こうと思います。)

なぜジモティーで成長できたのか

弊社は「成長」したいという気持ちが強い方々にとっては、とても魅力的な環境だと思います。

入社をしたら1人1人が、どういうキャリアを描きたいか、1年後どういうことができるようになっていたいか、そのために今Qは何をできるようにするか、今月は何を達成するのかという風に細かく目標設定をします。自分が担当する開発タスクも基本的には自分の目標に沿った開発タスクがアサインされます。例えば、今月は設計に関する技術を高めたいから、設計から考える必要があるタスクがアサインされるなど。(ただし、その時にちょうどいい開発タスクがあるかどうか次第ではあります。)

このように弊社では、自分の理想のキャリアに寄り添って仕事をすることができます。努力をすればするほど、想定より早く理想のキャリアを実現することもできると思います。 まとめると、僕が「営業職からエンジニアになり1年で年間表彰された」秘訣は下記の2つだと思います。

  • どうしたら成長できるかを自分の頭で考え、工夫し、学習を継続する

  • 成長できる環境に飛び込み、目の前の目標を達成させていく

弊社では「成長できる環境」が整っていると思うので、ぜひ皆様の「飛び込み」をお待ちしております。

おわりに

この1年間で取り組んできたこと、意識してきたこと、成長についてさらっと書いてみました! 成長に伸び悩んでいる方、世の中の課題を解決するような仕事をしたい方、大規模開発を行いたい方など、ぜひ弊社で一緒に「キャリア」を作り上げて行きませんか??

最後まで読んでいただきましてありがとうございました。 もしジモティーにご興味ありましたら、こちらでエンジニアの方を募集しております!

※現在は経験者の方優先で採用活動を行っております。

ジモティーで未経験からエンジニアを始めた話

はじめに

こんにちは、ジモティーでAndroid開発をしている林と申します。 エンジニア未経験でジモティーに入社し、もうすぐ2年近くが経とうとしています。 ここでは未経験で入社した者がどのようにプログラミングの実務をこなして、他チームと案件に携わっていったかのプロセスをご紹介できたらと思います。

※未経験の記事を書いていて大変恐縮ですが、ジモティーでは現在経験者の方優先で採用活動を行っております。

入社前のスキル

まず前社では主にセールスフォースを使ったデータ管理や資料作成、エクセルのマクロ作成などで少々プログラミングを行った程度でした。 マクロ作成からプログラミングに興味を覚え、その時Pythonがこれから来るらしい!という情報からPyQを使って独学で勉強し、Djangoを使ってWEBブログのサイトを作成しました。 しかし当時求人を見てみたらPythonの求人が少なく、Rubyなら可能性が広がると考えて、UdemyでRuby + Railsを勉強し、写真も投稿できる簡易型掲示板を作成しました。 これらをポートフォリオとしてジモティーを受けて、アプリエンジニアとして採用させてもらいました。 そしてここからまたアプリを一から勉強し、RetrofitとRXを使ったアプリを作成して一応仕組みは理解しているつもりで入社することになります。 しかし、この時はまだエンジニアの入り口にも立てていなかったのです。。

入社後の挫折

まずGitを使ったチーム開発もしたことのない初心者だったので、プルリクの作成方法やGitの基本的な使い方などから勉強が始まりました。 そしてhttpをhttpsに変更する簡単な修正を行い、「なんとかこれならできる!」という感触を最初は持っておりました。が、、すぐに全く歯が立たなくなりました。 まず、独学でやっていた時はクラスを分ける意識もなく、必要なものをただ上から書いていただけだったので、プロダクトコードを深く追って行ってもどこに何があるのか分からず、「そもそもどこでnewしてるんだよ!」という有様でした。 インターフェースまでたどり着いても、実体が別にあり、これ呼ばれてるのに何もないじゃん?とますます混乱が増大していきました。 また膨大なコードと初めて対峙したので、引数が多くあった時点で思考が停止してしまう有様でした。

そしてここからアーキテクチャー研修を受けることになります。

やっとエンジニア開発の入り口に到達

ジモティーのAndroidではApp層、Domain層、Infra層と層を分けており、MVP+ クリーンアーキテクチャーをもとに実装がされています。 アーキテクチャーを理解しないとまず改修や画面作成などは手をつけるのが難しいです。 そして先ほどのどこでnewしているかわからない問題やインターフェースと実体の関係性も、DaggerというDIの仕組みがわからないと全体が見えてきません。 アーキテクチャー研修によりこれらの全体像を掴み、「何を聞いたらいいのかも分からない状況で、とにかく分からないです、、」といった感じから、やっと開発ができる入り口に到達することができました。

※弊社のAndroidアーキテクチャー詳細についてはこちら

そしてただプログラミングに慣れる日々

ここから簡単な案件に携わることになり、ディレクターから要件を確認し、サーバーチームやiOSチームのメンバーと連携して開発を行っていきました。 最初のうちは簡単な案件でもチーム開発を理解するために、マネージャーに振り返りを行ってもらい、この疑問はこのタイミングで聞いておくとよかったとか、次からは自分で提案してみてもいいですね、などコミュニケーションスキルの向上なども相談に乗ってもらいました。 またエンジニアチームでは技術点を設けており、1ヶ月にこの点数獲得したら評価はA、A+など分かりやすい目標も持って開発を進めていきました。 仕事場では全く聞いたことのない単語や専門的な話が飛び交っていて、何だかすぐに全てを理解しなければならない錯覚に陥ってしまい不安が高まっていたのですが、ジモティーでは週に一回1on1の面談を設けていて、そこでマネージャーに今やるべきことや、「そのうちできるといいくらいなので大丈夫ですよ。やっていけばできるようになりますよ。」とメンタル面でもケアをしてもらいました。

転機

半年ほど経った時に初めて新規画面を一人で実装することになりました。1ヶ月くらいかかるプロジェクトをジモティーでは大玉案件と呼んでいますが、初めてそのような案件に参加して上記のアーキテクチャー研修でやった内容をプロダクトコードに反映させて、リリースも行いました。 結果的に障害もなく無事にリリースできたので、「これやっていけるんじゃないか。。」とエンジニアとして自信につながる貴重な経験を得ることができました。

そして今に至る

現在はプログラミング能力が向上したのか、ただコードを見慣れたからなのか定かではないですが、エンジニア開発も問題なくこなしており、広告担当者として責任の大きい案件の実装も行っております。 またiOSの研修も行ない、ジモティーではAndroidiOSで同じアーキテクチャーを採用しているため、どこに何が実装されているのかおおよそ予想がつくようになっており、スムーズに研修をこなすことができました。 ゆくゆくはiOSも同じように開発できるようになることを目標に日々精進しております。

最後に

入社当初は毎日会社にいさえすれば成長できるはずだと考えて日々邁進しておりました。 環境面においても、プログラミング技術においても、「慣れる」ことがいかに大事かを学んだ期間でもあったかと思います。

最後まで読んでいただきましてありがとうございました。 もしジモティーにご興味ありましたら、こちらでエンジニアの方を募集しております!

※現在は経験者の方優先で採用活動を行っております。

iOSのデザイン周りの開発と改善について🧸

f:id:jmty_tech:20210107095931p:plain:w300

ジモティーエンジニア紅一点の@chanNaruです🧸

iOSチームで開発を行っています。

軽い自己紹介

絵や漫画を描いたり車でドライブすることが好き、 個人でアプリを作ったりなども f:id:jmty_tech:20210107094156j:plain:w110f:id:jmty_tech:20210107094420p:plain:w110f:id:jmty_tech:20210107094448j:plain:w110f:id:jmty_tech:20210107094451j:plain:w110f:id:jmty_tech:20210107094454j:plain:w110 f:id:jmty_tech:20210107095812p:plain:w200

-> wantedly:iOSDCにてデザイン関連の登壇などをしたり、個人アプリの紹介など書いてます

-> Qiita:イラストあれば理解しやすいよねをモットーにたまーに書いてます(最近書いてない..)

話すテーマ 🌼 iOSのデザイン周りの開発について

好きなことが講じてデザイン周りにも興味があるということで 今回はまだまだ課題のあるiOSチームのデザイン周りの開発について、 具体的には私が入社してからの約2年間でどのような改善があったのかについて書こうと思います🧸

入社当時

もっとデザイナーやディレクターと連携できるような環境に身をおきたいとジモティー に転職をしたのですが、

「前職でできなかったデザイン周りの開発改善やるんだ!🔥」

だったり、

「(転職当時)今アツいAtomicDesign取り入れたいな〜〜〜」

という野望を持っていました。

実際入社した時には丁さんの記事でも書かれてましたが CleanArchitectureを導入するなど設計面の見直しが進められているなか、

  • デザイナーとの意思疎通がとりづらい
  • 画面とパーツが完全に依存している

などといったデザイン面の課題があり、

この課題の結果として

  • (1) 類似パーツを量産するコスト
    • 各パーツが画面依存しているので同じようなパーツを量産してしまっている
  • (2) 変更による1つ1つの改修コスト
    • デザイン変更によって類似しているパーツを1つ1つ修正しなければならない
  • (3) 既存と同じでとなった際のコスト
    • 「xx画面と同じ表示で!」などとなった時にその既存の作りを確認し真似しなければならない
  • (4) どこでどのようなパーツが使われているのか探すコスト
    • どんなパーツがどこでどのように使われているのかコードを探すのが大変

などといった負が誘発されることで非常に効率の悪い開発が行われていました。

f:id:jmty_tech:20210107095931p:plain:w500

f:id:jmty_tech:20210107095953p:plain:w600

↑定期的に行われる微妙な色が違うよ指摘..😭や、 f:id:jmty_tech:20210107100045p:plain:w300

↑ここの実装どうなってたっけ..😭などなど。


これらの課題を解決するために、以下の3つの開発見直しを行いました。

①cellの分解

特に改善したポイント: f:id:jmty_tech:20210107100611j:plain:w500

1つの画面のxibにパーツが全部組み込まれているため、その画面からしか使用できず他画面に同じ表示を追加する場合もそれを流用できないような作りになっていました。 その結果、何度も同じパーツを画面ごとに作るコストが発生。

(※ xib(≒storyboard):画面やパーツを作るときに作成するGUIのファイル)

これについては、

1画面=1xib(必要なパーツを全て持っている)
↓
1画面=1xib+α xib(適宜必要なパーツを参照する)

f:id:jmty_tech:20210107100633p:plain:w500

に作りを変えることで「画面とパーツが完全に依存している」状態を改善し、 毎回作り直さなければならないコストを減らしました。

(この課題の副作用として2019年のiOSDCの登壇でもネタにしたのですが、 特に投稿画面はパーツが多すぎることでxibを開いても何も表示できなかったりフリーズしたりなどという問題もあったので この辺りも開発効率改善にすごく寄与しました😭)

f:id:jmty_tech:20210107100736p:plain:w600

②cellの共通化

特に改善したポイント:

f:id:jmty_tech:20210107100754j:plain:w500

「①cellの分解」を行ったことで、「画面とパーツが完全に依存している」状態は改善できましたが さらにもっと汎用性がでるようにコードの改修を行いました。

具体的には以下のように、共通パーツを呼び出すためのprotocolを定義し各画面のテーブル用のリストを作る際に用いることで、 どの画面でも好きなように呼び出して扱えるcellにしました。

private var tableViewData: HogeTableViewData?

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    guard let tableViewData = self.tableViewData else {
        return UITableViewCell()
    }
    let cell = tableView.dequeueReusableCell(withIdentifier: tableViewData.get(indexPath.row).cellId,
                                                 for: indexPath)
    switch viewData {
        case let data as CommonCellViewDataPtcl:
            (cell as? CommonCell)?.setUp(viewData: data)
        default:
            break
    }
    return cell
}

*********************

struct HogeTableViewData {
    private var list: [HogeViewData]
    init(list: [HogeViewData]) { self.list = list }
}

protocol HogeViewData {
    var cellId: String { get }
    /**/
}

struct HogeViewData: HogeViewData, CommonCellViewDataPtcl {
    let cellId: String = R.nib.hogeCell.name
    let title: String = "たいとる"
    /**/
}

protocol CommonCellViewDataPtcl {
    var title: String { get }
    var backgroundColor: UIColor { get }
}

extension CommonCellViewDataPtcl {
    var backgroundColor: UIColor { return .white }
}

class CommonCell: UITableViewCell {
    private var viewData: HogeViewData?

    func setUp(viewData: CommonCellViewDataPtcl) { /**/ }
}

このようにすることで既存と同じようなデザイン指示があった際に、 使いたいcellのprotocolを呼び出すだけでパーツを流用できるようになりました。

変更があった際にもその1つのcellクラスを修正するだけで完了できますし、 また、上記ではbackgroundColorをextension化することで、「配置とかは同じだけど背景色が違う」などといった 「同じだけど微妙に違うから共通化しにくい」にも対応する形で汎用性をもたせています。

({ return .white }と初期値を設定しておくことで、意図しない変更にも強い作りになっています)

共通パーツについては、 類似パーツの量産を防ぎ、どんな共通パーツがあるのかを探しやすくするための工夫として、Zeplinを使ってカタログ化しています🧸 f:id:jmty_tech:20210107100818p:plain:w600

(※ Zeplin:デザインリソースから指示書やスタイルガイドなどを自動で生成するソフトウェアで俗に言う「デザイン共有ツール」。 ジモティーではこちらのパーツの一覧管理用ににのみ使用しています。 カンプなどはFigmaを使っています。)

導入タイミング・キッカケとしては、大きなprjで7画面ほど新しい画面を作ることになった際に毎回作るコストを減らすために考えられました。

このコードの課題としては、cellForRowAt内でviewDataPtclの分岐を忘れてしまうと、setupが呼ばれずエラーにならず空セルとなって表示されてしまう点があり、 ジモティーでは結合テストでその問題が起きないように担保しています。

データと画面を依存させずにこの問題をテスト以外で担保できないかなど含め、コードの精査を今後も続けていく予定です✊

③ラベル/ボタン/カラーレベルのコンポーネント

特に改善したポイント: f:id:jmty_tech:20210107100941j:plain:w500

ボタンやラベルでもデザイナーの意図しない色やサイズになっていたり、 既存を参考にしようにもどこでどう定義されているのか探すのが大変という課題に対して、 一番小さい単位のパーツ類をコンポーネントとして定義して各所で使うようにしました。

f:id:jmty_tech:20210107101000p:plain:w600

デザイナーチームではAtomicDesignという概念を既に使用していたので倣う形で以下のような資料をもとにデザイナーと打ち合わせを行ない、 そこそこ前に書いた記事なので現在と一部異なりますが、

【swift】コンポーネントを実装してパーツのスタイルを使いまわそう!😊【デザイン】

f:id:jmty_tech:20210107101030p:plain:w200

ここに書いている実装をプロジェクトに導入しました。

// ボタン:XLarge
@IBDesignable class XLargeButton: UIButton {
    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)

        self.layer.cornerRadius = 2.0
        self.layer.borderWidth = 1.0
        self.titleLabel?.font = UIFont.largeButtonTitle()
    }

    // 背景塗りつぶしパターン
    func primaryFill(title: String = "") {
        if title.isPresent {
            self.setTitle(title, for: .normal)
        }
        self.layer.borderColor = R.color.jmtyColor()!.cgColor
        self.backgroundColor = R.color.jmtyColor()
        self.setTitleColor(R.color.invertedTextColor(), for: .normal)
    }
}

※Colorについては最近コードとパレットの二重管理からxcassetsの一元管理化に変えています

このような定義を行うことでスタイル名の「共通言語」が生まれ、 カンプ共有ツール上でスタイルの指示をしてもらうだけでコンポーネントを流用しデザインに反映するという効率アップだったり、 どこでどのようにスタイルが使われているのかをプロジェクトから探しやすくなり、 修正工数もグンと削減することができました👏

f:id:jmty_tech:20210107101102p:plain:w600

もともとデザイナーチームでもエンジニアとのこれらに関する意思疎通がうまくできていないという課題があったため一緒に検討を進められたのはとても良かったです👍

まずはエンジニア側で現状の実装を元に仮組みで導入し、ある程度うまく実装にのった段階で本格的にデザイナーとルールやパーツ選定を行うという進め方をしたことで、 デザイナーと計画してから導入までの期間を短く出来、軌道に上手くのせることができたのではと思っています。

結果

上記の見直しを行ったことで、

  • 大凡UI周りの開発について工数の半分ほどを削減🎉
  • パーツの大量発生を防ぐことでプロジェクト自体のサイズの増大を防げる
  • 既存実装を探す手間を防ぐ

などの改善がありました。

終わりに

上記で書いたこともまだまだ導入を進めているところで、Objective-Cのコードもまだ残っていたり課題は他にも色々あります。

少しでも興味を持っていただいたり、こういうアイデアもあるのではという方がおりましたらお話ししたいです。

+.🧸ジモティーではエンジニアを募集しています🧸+.

インフラ構成とデプロイ事情

はじめに

はじめまして、サーバーサイド/インフラあたりを見ているエンジニアの佐藤です。

ここまでインフラ関連の話があまりなかったようなので弊社のインフラ構成とデプロイ事情についてご紹介します。

インフラ構成

まずはデプロイ事情の前にざっくりとしたインフラ構成からです。
弊社では主にAWSを利用しています。
簡単な構成は下記図の通りとなっています。

他のマネージドサービスやGCPも利用している部分はありますが、今回は割愛させていただきます。

f:id:jmty_tech:20201214160729p:plain

  • Web
    • サービスが稼働しているサーバで、NginxやRuby on Railsが動作しています。
    • AZ2つにそれぞれ用意しており、AutoScalingを用いて柔軟に台数を調整しています。
  • Batch
    • 定期実行が必要な処理が動作しています。
    • cronが現役で動いており、ジョブ数も多くなってきているのでジョブスケジューラの導入を検討したいところです。
  • Worker
    • 主にリアルタイム性の必要のない非同期処理だったり、push通知など大量のジョブをこちらで実行させています。
    • 最近AutoScaling対応しました。
  • MongoDB
    • メインで利用しているDBです。
    • MongoDB4.0からtransactionが導入されているので、ぜひバージョンアップして使ってみたいです。
  • RDS(Aurora Mysql)
    • 現状利用しているMongoDBのバージョンにtransactionがないため、課金周りなどのtransactionが必須となる処理のために利用しています。
  • Elasticsearch
    • 投稿リスト表示や検索処理周りで利用しています。
    • EC2上で立てて運用していますが、所々課題があるのでマネージドサービスのElasticsearchServiceを導入したいと思っています。

と、ざっくりとした紹介ではありますが、今回はこの構成の中で頻繁にデプロイが必要となるWebサーバのデプロイフローについても紹介していきます。

デプロイフローについて

弊社ではBlue/Greenデプロイを採用しています。 大まかな流れは図の通りになります。 f:id:jmty_tech:20201214160659p:plain

  1. Jenkins上からデプロイジョブを実行
  2. releaseブランチに対してコードのマージ命令
  3. マージされたコードでWeb Serverの準備開始
  4. 準備完了後BlueからGreenへ参照を切り替える
  5. 待機時間(※)終了後、起動されているWeb Serverを終了させてジョブが完了
    ※ 切り戻しに備えて一定時間待機させている

事前に各開発者が機能の実装を完了させ、GitHub上でコードレビューを行います。
動作確認等の最終チェックが済むとデプロイ可能になり、図の①を実施します。
あとは自動で順序通りに進んでいきフローが完遂されるという流れです。

切り戻しの際はデプロイジョブを停止させ、同じくJenkins上にある切り戻し用のジョブを実行します。
経過時間が30分未満の場合は、Blueが残っているため速やかに切り戻しが完了します。
それ以降は対象コードをリバートして通常デプロイで切り戻しします。

※ Batch/Workerについては、そこまで複雑ではないので割愛します。

影響が大きそうなリリース時に採用している手法

各種ミドルウェアのバージョンアップなど規模の大きな変更の際はカナリアリリースを採用しています。
直近ではRubyのバージョンアップ時に採用しました。
バージョンアップ済みのWebサーバを1台用意してELBへ接続し、1週間ほど動作させます。
問題なければ全Webサーバをバージョンアップ済みのものに切り替えます。
この手法を採用することで、最小限のリスクで本番環境での動作確認が可能になり大きな障害を回避できます。

また、まだシステム的にカナリアリリースの実施が確立できていないので、より実施しやすい仕組みを検討していければと思います。

改めて思ったこと

メンテンス性について

そこそこシンプルな構成になっているように思いますが、図の中で記載しているデプロイジョブが中々厄介者です。
Rubyで一連の処理が書かれているのですが、若干見通しが悪くメンテナンス性が悪いように感じています。

また、稀にJenkinsサーバがハングアップしていて、Jenkinsサーバ自体のメンテナンスも必要になっています。
マネージドに依存するのが良いのか悪いのか悩むところではありますが、AWSにはCodeDeployといったサービスもあるので、導入を検討していきたいと思っています。

デプロイ時間について

図の③で新しいWebサーバを用意しているのですが、ELBからの疎通確認完了までの時間が長く、1デプロイに6〜7分程度掛かっています。
うーん、長いですよね。
上記で記載の通り切り戻しの際、30分程度であれば速やかな切り戻しが可能ですが、それ以降だと通常デプロイをする必要があり多少の待ち時間が発生します。
遅れて障害が発生することもあるので、一定時間経過後でも速やかに切り戻しできるような仕組みがほしいところです。

参考までに他社の事例ではデプロイ時間が数十秒〜1分程度で、弊社より何倍も早く完了するみたいです。
このあたりのデプロイ高速化を見習って対応していきたいなと思っています。

まとめ

以上、ここまで簡単に説明してきましたが、メンテナンス性についてやデプロイ時間の改善などが未対応なものがいくつかあります。
新しい技術を取り入れてうまいこと運用しているサービスもよく見かけます。
モダンな技術を取り入れてインフラ面でも技術的な負債をなくし、管理のしやすい環境作りを心がけていきたいです。

まだまだ課題はたくさんありますので、一緒にインフラ改善をしてくれるメンバーも募集中です!
よろしくお願いします!

サービス成長との付き合い方

はじめに

サーバサイドとAndroidネイティブアプリの開発を兼務している坂根です。

webアプリ開発を行うエンジニアと聞くと、 要求された機能を実装する つまりディスプレイと睨めっこしながら黒い画面に文字をタイプし続けるコーディングが中心のお仕事、と考えられている方もいらっしゃると思います。 しかし、私は なぜ開発をするのか 開発をする目的は何か 背景の理解を大事にして働いています。

皆さんの身近にいるエンジニア、想像するエンジニアは、どのような働き方をされているでしょうか? 最近、背景の理解を大事にしていないエンジニアが案外多いのではないかと感じています。 今日は背景の理解を大事にするとはどういうことか、私の仕事を通して紹介させていただきます。

要件の分解・分析

弊社では主にwebディレクターが開発案件のビジネス要件を考えています。 ユーザーが抱える潜在的な課題の解決、リーチ・認知の拡大、リピート率の向上など、webアプリエンジニアには考えが及びづらい箇所を基点に日々議論されています。

しかし、考えが及びづらいが故にwebエンジニアは全容の掌握を怠ってしまう場合があります。

全容の掌握

全体の掌握を怠ってしまうと何が起こるのでしょうか? webディレクターが事前に検討しているため、降りてくる要件を実現するだけで 近い将来の目標 に到達することは難しくないでしょう。 しかし 数年後の目標 に自然な形で到達するためには、課題から数年後の目標までの道筋を設定した上で、中間に近い将来の目標を置く必要があります。 つまり全体の掌握を怠ってしまうと、発射角を誤り望んだ未来や自然な未来に辿り着かないケースに発展し、無駄に難易度の高い仕様変更を重ねていくことになると考えています。

数年後の目標

以上のことから、課題やターゲットを明確にして、より良い解決方法を求めることを大事にしています。

解決策の模索

解決したい課題と数年後の目標を明確にできたからと言って、直ちに最善の解決策を出せるとは限りません。 議論に挙がる解決策がユーザーに驚きを与えるものだとしたら、どうでしょう? 「使い方が分からない」「意味や意図が理解できない、不安」など、ユーザーにとってもサービスにとっても多くの混乱を招きそうです。 問い合わせや不満に繋がり、やがてはサービスからの離脱も・・・と考えられ、この状態では誰も幸せにならないことも容易に想像できます。

では、驚きを軽減するためどのような方法があるでしょうか? 驚き = 予期しない事象を体験したときに起こる瞬間的な感情 ということで、予期できる事象を考えます。 予期できる事象とは、同一サービス内で類似の体験がある、他サービスで体験しており既に親しみがある、などが考えられます。 類似の体験があることで学習コストは低くなり、ストレスも溜まりづらいなど副作用が期待できます。

コストの掛かり過ぎる解決策の場合はスモールスタートさせることもありますが、可能な限りユーザー体験を考えることも大事にしています。

妥当性の担保

ここまで考えたので、もうこれ以上考えたくない!という方もいらっしゃるかもしれませんがもう少しです。最後までお付き合いください。

これまでは下記の流れで考えてきました。 数年後の目標に向かって道筋が通ることを確認できたはずです。 しかし、この結論について妥当性が担保されていません。

トップダウン

そこで、逆向きに考えてみます。なぜその結論に至ったのか、根拠を確認します。 納得できる理由付けになっていたでしょうか?納得できる理由付けではない場合、ここで妥協してはいけません。 将来的に不幸になる人が出てくる結果に繋がるため、解決策の模索からやり直します。

ボトムアップ

おわりに

さて、ここまでお読みいただいたみなさま、いかがでしたか?

時間の無駄では?webディレクターの仕事では?案件のスピード感落ちない? などなど、いろいろな感想があると思いますが、以上がコーディング前に考えごとをする私の仕事の一部です。

目的を達成するために・・・私はこれからも背景や全容の掌握を大事にします。 また、その他大勢のwebアプリエンジニアにも大事にして欲しいことだと考えています。

このような働き方に共感・理解いただけるwebアプリエンジニアの方と働けるようになること、日々楽しみにしています。 ご興味ありましたら是非ご応募ください。