ジモティーのフロントエンド事情

初めまして。

2020年末からジモティーでフロントエンドエンジニアとして開発している山口です。

今回はジモティーのフロントエンド事情について紹介します。

ジモティーフロントエンドの現状

現在のジモティーのフロントエンドはRailsのAction Viewを用いて

  • jQuery で Javascript 周り(一部のページの一部の DOM に対して jQuery 代替として Vueも利用)
  • Rails の decorator でフォーマットして Haml でマークアップ
  • Sass でスタイル付け

といった構成になっています。

しかしサービスの規模が大きくなってきたこともあり、どのidやclassをどの jQuery コードが参照しているのか追いづらかったり、 似たスタイルを持つ似た名前のclassが乱立してしまいどれを利用すべきなのかの見通しがつかないなど、開発が辛くなってきているのが正直なところです。

Railsの開発チームはアプリ向けのAPIの作成やバックエンドの開発と並行してフロントエンド開発も行っているため、 辛さが出てきた現状が会社として求める開発スピードUPの足枷になってきています。

新規プロジェクトにてReact(NextJS)を利用

今月リリースした新規プロジェクト、自治体向けの電子申請・申請承認システム「LOCONET(ロコネット)」にて、弊社としては初めて React を利用した開発体制を敷きました。

バックエンドはジモティーに引き続きReilsを利用し、フロントエンドはバックエンドとは完全に分離してReact(NextJS)+Typescript で作成、さらにOpenAPIによる APIドキュメント整備とStorybook によるコンポーネントのドキュメント整備を行うことでバックエンド開発者やデザイナーとのコミュニケーションを取りやすい環境を構築しました。

技術負債との比較

前述した現在のジモティーの開発状況と比べると今回の開発体制では

  • styled-compomentsを利用でスタイルのスコープを制限してスタイルの見通しが付きやすくなる
  • contextの利用を避けてあえてpropによるバケツリレーを選択することでstateなど変数の変更が追いやすくやる
  • Typescript によりコードがよりドキュメントとして理解しやすい形で残るようになったため、第三者がコードを追いやすくなる
  • バックエンドと分離されることでアプリチームと似た分担で開発が可能になり、適材適所の分担で開発が行えるようになる
  • デザイナーとパーツ単位で実装しているスタイルを見ながら密なコミュニケーションが取れるようになる

などのメリットを得ることができました。

代わりに

  • Typescript 導入により、追加で工数が発生してしまう
  • 保守していかなかればならないものが増えた(OpenAPI,StoryBook)

といったデメリットは発生しています。

Typescript導入において型管理以外に特に時間を要したのは次に紹介する2項目です。

外部ライブラリ利用時の型調査の時間

外部ライブラリ使用した際にライブラリ内に定義されている型の内容、利用方法の確認に時間を要しました。

特に初めて利用するライブラリの場合、javascript時の倍は時間がかかる感覚です。

直で呼び出す場合より子コンポーネントへライブラリの一部を受け渡しする必要があった場合など子コンポーネントのpropの定義に悩むことが多かったです。(大抵公式のドキュメントにその場合の型の定義方法が書いてないので直接ライブラリを追ってみるしかなかったです)

例) React Hook Formの場合 https://react-hook-form.com/jp/get-started/

const { register, handleSubmit, watch, formState: { errors } } = useForm<Inputs>()

useFormで呼び出してきた各種メソッドregister, handleSubmit, watch, errors をコンポーネントへ受け渡したい時、どのような型で待ち受けるべきかがドキュメントからはわからず、なるべくanyなどを使わず実装しようとすると最適解を見つけるのに時間がかりました。

型推論のための追加記述

頻出するわけではないですが、遭遇した場合に解決の時間を用意したのがこちら。

適切な型推論が行われるようにするために javascriptだけならそのままで要件を満たして動作するコードに対して - typescriptが型推論に対応しているメソッドに書き直す - 自前で型推論させる処理を追加する(javascriptの動作上は必要のないコード) という対応をする必要が発生しました。

例) filterを利用してarrayを整理しても方が絞り込まれない例

const x = [123, null] // 型推論結果 const x: (number | null)[]
const y = x.filter(v => v !== null)
console.log(y) // [123]
// 型推論結果 const y: (number | null)[]
// number[] にならない

このままではビルドが通らないので型ガードを駆使したりして型を絞り込む必要が出てきますがチームへのTSの知見が溜まっていないと解決まで時間がかかってしまいます。

...

しかしながら、 Typescript導入やOpenAPI、Storybookはある程度のコード規模が大きくなり、チームの人数が増えてきたときに効力を発揮する要素なので投資として受け入れるべきコストだと考えています。

VueとReactの違い

実は私はジモティージョイン前までVueをフロントエンド開発に利用していたため今回のプロジェクトが React に触れる初の機会でした。

そのため Vue 開発と比べた時の違いについてもいくつか感じることができましたので紹介します。

自由度が高く、良くするも悪くするも開発者次第なReact vs 形式がしっかりしており、とっつきやすいVue

Vue はコンポーネント内で何をどこに定義すべきかはっきりしているのに比べて、React はとにかく自由度が高いため、開発者がやりたいように柔軟な書き方ができる反面、選択肢が多いため、知見がない状態ではベストプラクティスを見出すのが難しいと感じました。

コンポーネントファイル内でstateやeventなどを定義する場所(Vueはdataやwatch,methodなど書き場所が固定されていて開発者でバラつかない)や、スタイルの定義方法は他のオープンソースの事例をいくつか参照してみましたがどれもバラバラで自分たちに合ったやり方を見出す必要がありました。

スタイル付けに関してはスコープをコンポーネント内に留めたいのと、なるべくcssそのままの形で記載ができることをとってstyped-componentをチョイスしましたが正直Vueの方がシンプルにcssそのまま埋め込め、sassなども導入しやすかったので扱いやすかった印象です。

Typescriptとの親和が進んでいるReact、やれることが多いNextJS

自分がしっかりTypescriptに触れていなかった原因でもあるのですが、どうしてもVueの方がTypescript導入が遅れているので、きれいに導入できるReactの方が今のところは軍配が上がるという印象でした。

また、NextJSの方がISRなどへの対応が進んでおり、よりサービスに適した形でビルド方法を検討することができる点も好印象でした。

今後のフロントエンド開発

今後ジモティー自体でも Reils の MVC モデルに乗っかって jQuery を利用している現環境をやめて、今回 LOCONET で作ったようなフロントを分離した開発体制へ移行していく予定です。

かなり機能が多いサービスになっているため、大掛かりなプロジェクトにはなりますが、移行後はより良いユーザー体験と開発スピードを実現できると思います。

ジモティーは今回の私のように未経験技術へ挑戦する機会を積極的に与えてくださり 新規技術への興味関心度合いも高く、エンジニアとして働くのが非常に面白い組織です。

今後もこのサイトではジモティーのフロントエンド事情についての記事を投稿予定ですのでご期待ください。

ジモティーのUI/UXに関する取り組みについて🧸

f:id:jmty_tech:20210625183109p:plain:w250

ジモティーエンジニア紅一点のnaruです🧸
iOSチームで開発を行っています。

最近は自粛で気軽に外に行けないこともあり、自分の所有する車を擬人化したりなどしておうち時間を過ごしたりしてます🧸

f:id:jmty_tech:20210625172747j:plain:w200

前回は↓こんな記事を書いております。 jmty-tech.hatenablog.com

今回もデザイン関連についての話をしたく、UI/UXに関して自社で行っている取り組みの一部を紹介しようと思います。

まず、UI/UXに関するコミュニケーションは今年に入ってからより活性化するようになりました。

f:id:jmty_tech:20210625183029p:plain:w200

というのも、
会社全体のチーム編成や考え方の見直しや、
ジモティーの根幹のDesignSystemの見直しについてデザイナーエンジニア間でMTGする機会が増えたこと、
エンジニア側からもUI/UXの提案を行うようになったことで、
よりお互いが互いの分野に歩み寄って一緒に学んでいきたいという思いが強くなってきた部分があるのかなと思います🤗
(DesignSystemについては、絶賛検討が進んでおりますので、然るべきタイミングでまた話ができれば😌)


#design_infoというオープンチャンネルを作り、


他社の事例を紹介したり、 f:id:jmty_tech:20210625183422p:plain


デザイナーがプログラムについて調べてみたり、 f:id:jmty_tech:20210625183506p:plain


新しいOSの変更点などを共有したりしています🌟 f:id:jmty_tech:20210630135741p:plain

そして、今回メインで紹介したいのが、「UIパッション会」という取り組みです💪

UIパッション会

f:id:jmty_tech:20210625191255p:plain

「もっと色々話したいよ〜🥺」というところで
名前の通り、「UIにもっと目を向けていこうぜ!意見交換しようぜ!💥」という名目の共有会を月1で有志を集い開催しています。

f:id:jmty_tech:20210625182115p:plain:w250

もともと自分は月1で他社アプリのアップデートの内容を共有する、
ということをやっていたのですが

f:id:jmty_tech:20210630135803p:plain

もっと具体的に詳しく話し合ったり、

デザイナーから「こういうの実装したいんだけどどうかなあ」などをフランクに聞いてもらったり

f:id:jmty_tech:20210625194718p:plain:w250


ゴールは案件化ですが、あくまでもざっくばらんに話すを目的にしています:)


これまで実際話された内容としては、

「xxxみたいなUIって難しい?🤔」
「xxx画面の改善を考えているんだけど....🥺」 f:id:jmty_tech:20210630141144p:plain

「某アプリ考察した!😀」
f:id:jmty_tech:20210625201543p:plain:w280

「ios14からAppleが提供するようになったこんな機能があるんだ😏」 f:id:jmty_tech:20210625201744p:plain

あとは、
「〜〜〜っていう機能を作りたいからちょっとざっくり感想教えて欲しい🤗」

などなど....



実際ここから案件起案があがったりもあり、
新しい視点での発見や学びもあり良い取り組みだというところで今後も継続して実施できればと思います。

その他の取り組み

カスタマージャーニーワークショップ

有志で集まってはじめてのカスタマージャーニーマップワークショップという本を参考に、自社サービスについて分析。 各画面の優先度や既存機能の重要さ、改善ポイントをユーザー視点で考えるきっかけになりました💪

f:id:jmty_tech:20210625174342p:plain

UXきんにくん

ディレクターやUXチームを中心に、チームに分かれて他社アプリを洞察して発表し合う、なども行っています。

おわりに

ジモティーでは上記のような取り組み以外にも 色々な分野でユーザー視点での考えを推奨し、評価される制度となっています。
今回書いた内容に興味をもっていただけたり、共感いただけたら幸いです。

jmty.co.jp

AndroidのローカルDBをSQLiteからRoomに置き換えてみた

はじめに

はじめまして。ジモティーに2021年1月からAndroidアプリエンジニアとしてい働いている谷です。

今回はAndroidアプリエンジニアとしてローカルDBをSQLiteからRoomに置き換えた話をさせていただければと思います。

Roomとは

置き換えの話に入る前にさらっとRoomについて説明したいと思います。 RoomとはGoogleが推奨しているSQLiteのORMです。 SQLiteHelperの作成やCursorの操作などめんどくさい処理を一手に引き受けてくれます。

実装も非常にわかりやすく、3つのコンポーネントを作成するだけでローカルDBの構築が可能です。

  • Entity
  • Dao
  • Database

合わせて非同期処理としてRxやKotlin Coroutinesなどのサポートもされており、非常に使いやすいです。

さらにデバッグツールとしてAndroid Studio 4.1から追加されたDatabase Inspectorというものがあり、APIレベル26以上の端末でアプリを実行している時に使用できます。 作成したテーブルの中身をSQLを使って操作したり、Database Inspectorのウィンドウでそのまま書き換えたりといったことが可能です。 こちらにどんな感じのものか詳しく書かれている記事がありますので、是非見てください。

そして以下簡易的ではありますがRoomの実装例です。

まずはEntityを作ります。 これがテーブルの役割を果たします。

 @Entity(tableName = "tbl_todos")
 data class Todo(
     @PrimaryKey(autoGenerate = true)
     val id: Long,
     val title: String,
     val isActive: Boolean
 )

続いてDaoを作成します。 データを取得したい場合はこちらに定義したメソッドを呼び出すことになります。

 @Dao
 interface TodoDao {
     @Insert
     suspend fun insertTodo(todo: Todo)
 
     @Query("SELECT id, title, is_done FROM tbl_todos")
     suspend fun getAll(): List<Todo>
 
     @Query("SELECT id, title, is_done FROM tbl_todos WHERE is_done = :isDone")
     suspend fun getDoneTodo(isDone: Boolean): List<Todo>
 
     @Update
     suspend fun updateTodo(todo: Todo)
 
     @Delete
     suspend fun deleteTodo(todo: Todo)
 }

最後にDBを実装します。

 @Database(entities = [Todo::class], version = 1, exportSchema = false)
 abstract class TodoDatabase : RoomDatabase() {
     abstract fun getTodoDao(): TodoDao
 
     companion object {
         private const val DATABASE_NAME = "todo-db"
 
         fun createTodoDatabase(context: Context): TodoDatabase {
             return Room
                 .databaseBuilder(
                     context.applicationContext,
                     TodoDatabase::class.java,
                     DATABASE_NAME
                 ).build()
         }
     }
 }

おそらく基本的にはDaggerなどでインジェクションすると思いますが、以下のように呼び出すことが可能です。

 // Daoの取得
 val todoDao = TodoDatabase.createTodoDatabase(context).getTodoDao()
 
 // 取得したDaoから各種メソッドでローカルDBにアクセスする
 todoDao.insertTodo(Todo("保存したいTodoのタイトル"))

ここまでが基本的なRoomの使い方となります。

背景

元々ジモティーのAndroidアプリではローカルDBとしてSQLiteとRealmが採用されておりました。 ジモティー内での使い分けとしては以下のような感じです。

  • SQLite
    • サーバーから取得したマスターデータをキャッシュするために使用。
  • Realm
    • 検索結果の履歴保存などに使用。

上記の内、SQLite部分で

  • 実装されているコードが古い。
  • 可読性が低くマイグレーションなどが発生した際にメンテナンスしづらい。
  • ローカルDBへの接続処理がUIスレッド上で実装されている。

という負があり、その辺りが解消されるのではないかということで導入することにしました。

以下、置き換え実施時に参考にした情報です。

  • Migrate from SQLite to Room
    • SQLiteからRoomへのマイグレーション方法について基本的なことが書かれており非常に分かりやすかったです。
  • Incrementally migrate from SQLite to Room
    • 後述するのですが、今回は完全な置き換えができなかったので段階的に置き換えをするにはどうしたら良いかが書かれておりこちらも非常に有用でした。

結果

結果は完全な置き換えはできず、段階的な置き換えを実施する形になりました。 修正範囲が当初想定していたよりも広くなってしまったのと、アーキテクチャに則って作られていない部分の改修難易度が高く時間的にも厳しかったためこの判断になりました。

完全な置き換えはできなかったのですが、最終的には以下が実施できました。

  • 既存テーブルをRoomのEntityとして再定義
    • Stringの配列で設定されていた既存のテーブルがKotlinのdata classとなったことで可読性が上がりました。
  • SQLiteを呼び出していた箇所の一部RoomのDao化
    • Dao内に定義しているQueryアノテーションでSQLが書けるので何をしているのかすぐに把握できるようになった。
    • さらにRoomには決まった形で使われる挿入や更新、削除はコンビニエンスクエリとして事前に定義されたアノテーションが存在するためSQLを書く手間が省け、小さいですが実装時の工数削減になりました。
    • RoomのDaoに置き換えられた箇所では、ジモティーではRxをまだ使用しているのでSingleを返却するようにでき非同期実行できるようになりました。(アプリ全体としてKotlin Coroutinesへの移行を行っているのでどこかのタイミングでsuspend functionに変更する予定です。)
  • SQLiteからRoomへの置き換え時に発生するマイグレーション処理の追加
    • Migrationを使うことで各スキーマバージョン単位でマイグレーション処理を記述することができるため、処理が追いやすく、メンテナンスしやすい状態になりました。
  • SQLiteOpenHelperをSupportSQLiteOpenHelperに置き換え
    • これにより既存のSQLiteの実装を壊すことなく、Room側のSQLiteに移行することができ、今後他の箇所のDao移行も行えるようになりました。

まとめ

今回移行してみて、置き換えたことにより非常に可読性が高く、UIスレッドをブロックしないように作れるためパフォーマンスも良いアプリになっていくだろうと思っております。

今回置き換えを行っていて、途中で方針転換をしないといけなくなったり、リリース直後にマイグレーション周りで不具合を出してしまったりと進め方として改善すべき点も見えてきた経験でした。

今後はSQLiteの処理からRoomのDaoに置き換えることができていない部分がまだまだあるので、そちらも随時進めて行きたいです。

弊社iOSアプリにアーキテクチャを導入してみた ~計画編~

はじめに

サーバサイドチームに所属している丁(てい)です。

前回の記事弊社のiOSアプリにアーキテクチャを導入する前の状況とアーキテクチャを導入してどう変わったのか?をスーパーざっくりご紹介させていただき、その記事を皮切りにアーキテクチャ導入過程の紆余曲折記事を順番に書いていくことを予定していたのですが、その後全く気が向かず長いこと放置していました。

4月に入り気候も少し暖かくなってきたこともあり気が向いてきたので、本日はアーキテクチャ導入当初のお話をもう少し詳しくお話しできればと思いますので、気が向いた方は暫しの時間お付き合いいただけますと幸いです。

導入計画の策定

アーキテクチャを導入しよう!ということは決まりましたが、意気込みだけでは何も前に進みません。 そう、何をどうしていくのか?という計画が必要になります。 そこでまずはこんな項目を網羅した導入計画書を作成しました。

・目的
  ・アーキテクチャを導入することの素晴らしさについて嘘をつかない程度に誇張表現を交えつつ400字程度でまとめた。
・方針
  ・MVP+CleanArchitectureを採用するメリットなどをなるべくわかりやすく400字程度でまとめた。
・進め方
  ・担当者が誰でどの画面から着手してどの順番で進めていく。。。などをもっともらしい文章で800字程度でまとめた。
・ガント
  ・進め方をベースに週単位、月単位でスケジューリング。

実際のガントイメージ f:id:jmty_tech:20210427155317p:plain

この導入計画書はチーム内の意識共有のためという側面ももちろんありますが、主目的は他部署に対する説明です。

アーキテクチャ導入はリファクタリングの範疇なので長期的視点に立つと生産性の向上に大きく寄与するのですが、短期的には特に非エンジニアの方から見るとメリットをいまいち把握することが難しいです。

また画面単位で大きく手を入れることになるのでその期間は該当画面に対するエンハンス案件を回すことが難しくなり、仮にビジネスサイドの人が「この画面の改修案件進めたい!!!!」って思っても、「いやいや今リファクタリング中だから無理っす。。。」というなんとも気まずい空気を作り出す危険性を孕んでいます。

そう言った認識齟齬や納得材料として非エンジニアの方にもある程度納得いただけるように少し時間をかけて導入計画書を作成して他組織に展開して同意を獲得する作業を一番最初に行いました。

ここで一番効果があったのはやはりガントをある程度ちゃんと引き共有して、該当画面の作業期間中は事前にエンハンス案件検討から外してもらえるように調整できたことで、組織間コンフリクトを少なく抑えることができたことだと思います。

回帰テストケースの作成

計画書を作って全体共有もして、さあいよいよ待ちに待ったコーディングだ!!!。。。とは残念ながら行きません。

アーキテクチャが適用されていない画面にアーキテクチャを適用しようとするとかなり膨大な修正となり、(Objective-Cで作られてる画面など)場合によっては完全リプレースとなる大掛かりな修正となります。

アーキテクチャが適用されていない画面はほぼ全てのビジネスロジックがViewControllerに無秩序に記述されているのでその部分にガッツリ手を加えるとビジネスロジックが簡単に壊れることは想像に難くありません。

また画面の仕様を全て表す仕様書などがあればそれを拠り所とすることは可能かもしれませんが、日本全国津々浦々のどのシステム開発現場においても、現状の機能と寸分違わない仕様書の存在は都市伝説だと思っています。(偏見) ※ 日々刻々と変わっていく仕様を全てドキュメントに落としていくのは無駄という側面もありますしね。

したがってアーキテクチャ適用後もビジネスロジックの挙動に変化がないことを何かしらの手段で担保する必要があるのですが、我々は画面別に回帰テストケースを作ることで担保する方針としました。

回帰テストケースイメージ f:id:jmty_tech:20210427155011p:plain

ここで言う回帰テストケースとは「画面の全ての機能を網羅したぽちぽちテストケース」のことを指します。 ※ 「ぽちぽちテスト」とは自動テストじゃなく人間の手で行う動作確認テストのことを指しますが、この言葉を使ってるのは私だけかもしれません。

実装者はまず担当画面の仕様をくまなく洗い出すために以下の二つの切り口で画面の全機能を洗い出していきます。

  • FatViewControllerを頑張って読み解いて機能を洗い出す
  • 対象の画面をぽちぽち触りまくって見てソースリーディングで見落とした機能がないかを洗い出す

もしソースが綺麗に分割されていて洗練されていたら後者の作業は必要なかったかもしれませんが、残念ながらそうではなかったので非常に地味でつらい作業ですがこの過程を無視することはできませんでした。

この地味で孤独できつい作業を一通り終えて乗り越えたらいよいよ本番のアーキテクチャ適用作業に取り掛かることができるようになります。

今回のまとめ

iOSアプリへのアーキテクチャ適用に関する記事の2回目ですが、いまだにXcodeのXの字も出てきませんね。

ただし広範囲にわたるソースコードの改修は関係各所至るところに大きな影響を与えるので、前準備をしっかりすることがかなり重要なキモとなります。

今回ご紹介させていただいた内容の範疇だと以下の2点ですかね。

  • リファクタリングをスムーズに進めるためには計画をしっかりと立てて、他部署への共有をしっかりとしましょう。
  • 大規模改修の際はできるだけ緻密なテストケースを作りましょう。(回帰テストケースは仕様書と同様にその後の画面改修の仕様に追いつかせるのが大変(無理?)という課題はありますが。。。)

次回はいよいよ導入編に入る予定ですが、また気が向かない期間が長くなりそうな予感はしてます。

気が向いたら書こうと思いますので、その時にはまたお付き合いいただけますと幸いです。

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

自己紹介

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

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

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