レジュメ

木村 寛

Hiroshi Kimura

iOSエンジニア

  • iOSエンジニアとしての経験やマインド
    • 0→1 もできますが、10 → 100の方が得意だと思います。
    • Objective-C → Swiftへの移行プロジェクトの発案・実行の経験もあります。
    • 技術選定
      • 中長期目線からトレンド技術の価値を検証し、実際のプロダクトへの適用
      • プロダクト(ユーザー)への価値、開発効率、学習効率の順番で検討する。全てを満たすことが理想であるためそのアイデアを常に考え、実行に移す。
      • ReactiveProgramming, MVVM, Fluxを導入した経験もあり、プロダクトの開発効率向上のため、VergeGroup/VergeというFluxベースのライブラリを開発
      • 価値が見つかれば、コストを恐れることなくコードの書き換えを実行します。チームにその価値を説明することにも時間を使います。
      • 大きなプロダクトでは簡単には置き換えられない場合もありますので、その場合は移行プランの検討から入ります。基本的にはいち早く部分的に利用可能にすることから考えます。開発者に実際に利用してもらうことで経験を溜めるができるからです。
    • アウトプット (OSSの開発・登壇・ブログ執筆)
      • エウレカは会社としてOSS開発も推奨しており、開発を通して得られたアイデアは自身のGitHubに多数公開。多くの公開ライブラリがプロダクトを支え、世界にもアイデアを共有することができている。
      • 私の開発するOSSは、現場で発生した問題から考えるため、実際に現場で活きるものになることが価値です。
      • こちらに技術記事をいくつか公開しています。
    • サーバー連携におけるAPI設計
      • 良いフロントエンドアプリを作るためにAPI設計の品質にもこだわりを持ちます。 OpenAPIなどを活用しながらサーバーサイドエンジニアとディスカッションしながら設計を固めていきます。
    • UIデザインから考えるアプリの品質への関心と貢献
      • デザインが好きなので、デザイナーとペアで実装を行う時には、アニメーションの提案などを行います。実装してから気づく問題も多くあります。エンジニアでさえ実装してみないと気づかない問題はあるので、これらを適切にデザイナーにフィードバックすることは大切です。 デザイナーがプロダクトを常に触っていれば問題にならないでしょうが、そうでなければ使い心地の悪いUIのままアプリがリリースされてしまいます。
    • 戦略戦術となる技術や設計手法のアイデアの多くは世界のトッププレイヤーを参考にする。
      • 長期を見据えるプロダクト開発では技術選定の精度や適用失敗に対するリカバリーのプランニングが大切です。 そのためには実際にビジネスとしてトップに立つプロダクトを参考にすることが非常に役に立ちます。 私たちの選ぶ技術が現場で本当に価値を発揮するかどうかはビジネス要件にどれだけ答えることができるかどうか。です。 ビジネス要件というのは、開発者を簡単に悩ませる本当に複雑なものです。技術はそれらを解決するものであり、解決できてこそ本当に良い技術と言えるでしょう。 トッププレイヤーは私たちに想像がつかないほど複雑なビジネス要件を実現し、実際にビジネスを伸ばしトップに立っています。そこから学ぶことは大いにあるはずです。
    • 技術を正しく扱えているか?にこだわりを持つ
      • 開発には欠かせないFrameworkやLibraryの利用ですが、これらをどれだけ正しく扱うことができているか?ということが自分にとってとても大切です。 なぜなら間違った使い方に気づくことができなければ、それはスキルとは言えないし、再現性が下がるからです。
      • iOSで必ず利用するUIKit.frameworkは本当に巨大で、全てを理解することは無理でしょう。なんとなくのコードでもそれなりに動いてしまうこともまた厄介なものです。 実装でうまくいかない部分があれば、妥協案を採用する前に正しい実装は何か?を探すことに全力で時間を投資します。そこで得られる知見は自分にとって、所属する会社にとって必ず価値につながるからです。
    • いわゆる、「リファクタリング」には注意が必要と考える。
      • エンジニアとしてリファクタリングは正しく行えるべきですが、無意味なリファクタリングも存在し得ます。 まず、
        • 新しいアイデアによる技術的進歩がない場合 - リファクタリングをしてビジネス的に何が解決しますか?
          • 新しいテクニックなどを活用しない可読性を上げるためだけであれば、コメントだけに留めておくほうがビジネス上のリスクがないです。
        • ビジネス的に改善予定のない機能のコードのリファクタリング
          • 今動いてるならいじらない方がよっぽどマシです。
      • どちらかが異なればそれはリファクタリングを行う価値があります。
      • 私はリファクタリングは機能改善と同じタイミングで行うべきと考えています。それが最もリファクタリングを行う、目的、考慮すべき事項、更新すべき技術、モチベーション、これらを揃えて行うことができるからです。
      • つまり正しいタイミングで正しくリファクタリングを実施するには、エンジニアはビジネスを理解している必要があります。
  • マネジメントレイヤー(ピープルマネジメント) としての経験
    • 2020年 エウレカのiOSチーム(10名)のマネージャーを担当
      • 1on1や面談 (フィードバックや給与の決定など)
    • 新卒・中途採用における面接・採用後のオンボーディング・メンタリング
  • エンジニア育成
    • 教えることは好きなので、コードレビューをコメントではなく、ペアプロ・ペアレビューのような形式を好んで行います。