担当プロダクト・担当した開発範囲

• ガントチャートアプリケーション
  • 立ち上げ期…技術選定・設計（DB・クラス・画面）・実装
  • 拡大期…チームマネジメント・設計（DB・クラス・画面）・コードレビュー
• 工程管理アプリケーション・販売購買管理アプリケーション…設計（DB・クラス・画面）・実装・コードレビュー
• 倉庫管理アプリケーション…コードレビュー

特に力を入れて取り組んだこと

開発の仕組みづくり

• Prettier・ESLintの導入…「コード品質の向上」「コーディング規約の自動適用によりコードレビュー負担の軽減」「プロジェクト初期段階でlinterによる変更の影響が小さく比較的導入コストが小さい割に効果は大きいと見込んでいた」ことが導入理由
• git-flowにもとづいたブランチシステムの策定…ソース管理不備による不具合・開発スピード低下・パッチバージョンが当てられないなどビジネスへの影響が発生しており、それを防ぐために実施（こちらのような図にブランチ管理のルール・フローを全て書き出して、社内開発者へ認識共有することで対応）
• CI/CDパイプラインの構築（Jenkinsで実現、マージ時の自動テスト・社内環境への自動デプロイ・ビルド失敗時のチャット通知）…手動ビルドではビルド作業が属人的となり、またバグの検知に遅れが生じており開発スピードの低下・品質低下が発生していたが、それらを防ぐために実施（CI/CDに関する開発内容をこちらの図にまとめて社内開発者へ共有）
• コードレビュー・レビュアーの育成…自分がコードレビュー時によく見るポイントをコーディング時に大切にしているポイントとしてまとめて、社内開発者にも共有して実施
• 開発チームのスキルアップ（社内勉強会でのスピーカーとして知見の共有）
  • Jenkinsによる開発自動化
  • git-flowにもとづいたブランチ管理の方法
  • コミットやコード内のコメントを書くときのポイント（こちらを参照）
  • 技術的質問を行うときのポイント（質問時に大切にしているポイントを参照）
• 開発用データの自動生成…開発中に開発環境上で、開発者によって動作確認するデータが異ならないようにどの開発者も同じデータで動作確認できるようにするため、またコマンド一発でデータ作成することによる開発スピード向上のために実施（第2世代管理パッケージを使用した開発を行っていたため、こちらを参考に仕組みを構築）

自分自身の開発業務（設計・コーディング）

• 「大まかな処理の流れは似ているが、細かい個別機能の実装内容が異なる」機能が複数あり、それらの機能に対してストラテジーパターンを使用して開発…できるだけコードの可読性の向上や疎結合の実現ができるようにと考えて使用（実装例はこちらを参照）
• 大量データを扱う際にSalesforceの制限に抵触しないような設計・実装…SalesforceでApexの一括処理を使用して、トランザクション分割を実装
• 製造業というドメイン領域を把握した上での設計・実装…工場見学・書籍での学習・社内のbiz側のメンバーへのヒアリングなどをもとに自分自身でこちらのような図にまとめて、お客様業務を理解した上で俯瞰的に開発を実施

海外開発者もいる中でのコミュニケーション

• プログラムの状態や実装内容を、シーケンス図やクラス図を用いて視覚的に伝達…リモートワークということもあり、口頭・テキストのみのやり取りでは認識齟齬が起きることを懸念して、視覚的な情報を使用して意思疎通を実現

開発フェーズに応じた開発の進め方

• 立ち上げ期（0→1の開発）では、お客様にプロダクトをいち早く認知してもらい、作っているものの方向性が正しいことを意識しながら「小さく早く作って、改善する」を念頭に開発（4プロダクトの開発に関わっていたが、特に1プロダクトに関して立ち上げ期の開発者が自分1人の状態で、毎月バージョンアップして開発を遂行）
• 拡大期（1→10の開発）では、できるだけ技術的負債の解消を行うなどプログラム的な品質を高めつつ開発を行うことを意識、また開発人員が増えることに備えて開発の流れや現状の実装状態に関するドキュメント整備も意識

担当した開発範囲

詳細設計(クラス・画面)・コーディング

特に力を入れて取り組んだこと・学んだこと

チームの開発生産性向上

• コード自動生成ツールの作成…コードの書き方がどの機能も大まかに似通っている・同じような処理を開発者ごとに異なった書き方になっているという状況であったため、基本的なソースコードは自動生成できるようなツールを作成 （技術としてはRuby, C#, Mustache, スプレッドシートを使用し、実績としては開発時間が3分の1に短縮されたものあり）
• 生産性向上ツールは、自分だけでなく他メンバーでもメンバーでも保守できるように、できるだけコードを書かずにシンプルな作りのツールを作成 （初めはスプレッドシートなどで数式のみを使用するような簡易的なツールからスタート）

シニアメンバーから技術的に参考にできる部分の吸収

• フロントエンド・バックエンドの技術習得
• DIの使用
• 「良いコード=高可読性・高凝集度・疎結合なコード」であることの認識
• 技術的な質問の仕方の認識（大切だと思った点を質問時に大切にしているポイントとして個人的に記載）
• フロントエンドからバックエンドに対する通信回数は「原則、1トランザクションにつき1通信」の認識

大まかな流れ

• 研修内容（講義）の企画
• 講義資料・課題の作成
• 講義実施
• 課題のレビュー・フィードバック
• 振り返り

意識したポイント

• 開発用語の身近なものへのたとえ…プログラミング未経験者もいる中での研修となっており、技術的な言葉を身近なものに置き換えた方が理解しやすいと考えたため （例：変数=データを入れる箱、非同期処理=料理で肉を炒めつつ同時並行で野菜を切る、など）
• 各単元の学習によって「作れるもの」などゴールをあらかじめ伝達…「これからどのようなプログラムを作成するのか」よりも「これからの研修でどのような機能をつけることができるようになるのか（例：お天気アプリを作れるようになるなど）」を最初に伝達、また講師側であらかじめ作成したものの画面上でのデモを実施 （プログラミング未経験者の場合、プログラムの内容を最初に伝えられてもイメージがわきにくいと考えたため（自分がもともとそうだった））
• 資料には、文字よりも図など視覚的情報を多用…リモート環境下での研修となり、基本的に画面越しで研修を行なっていたため、認識合わせや技術的なイメージが湧きやすいように図や絵を多用

新人研修の最後に、自ら作るものを企画・設計・製造・テストを行う機会があり、以下の2つを作成

名刺読み取りアプリ

• 開発理由…社内の営業部がSalesforceを使用して商談管理を行っていたが、名刺管理は別のアプリケーションを使用していたため、名刺管理と商談管理を別々で行っていた。（名刺管理アプリで登録した顧客情報と同じ情報をSalesforceにも手入力で登録していた） データの2重管理の防止や手入力の手間を省き、Salesforce上での名刺管理も可能とするためにこのアプリケーションを作成。
• 使用技術…Salesforce (Aura Component, Apex), Google Cloud Vision API

送り状作成アプリ

• 開発理由…当時の社内の送り状作成は、営業担当者ごとにエクセルが用意されており、担当者自身のエクセル上で顧客名・顧客の会社名・送付物などを手入力で毎回書き換えて作成していた。しかし、商談管理として使用していたSalesforce上に顧客情報が存在していたため、Salesforce上の顧客情報からクリックのみで送付状を作成できれば業務効率が上がると考えてこのアプリケーションを作成。
• 使用技術…Salesforce (Aura Component, Apex), Google Spread Sheet API