kurauchi

# チーム構成と自身の役割 - プロダクトマネージャー（実装も兼任）：１名 - バックエンド／フロントエンド／インフラ：自分 # 概要 公共施設の予約システムを開発。初期リリースを終え、第二フェーズのタイミングで参画し、多くの機能を追加した。コードレビューを受けながら、すべての機能を自身で開発した。 # 実装した機能 - １年以上先の日時における抽選機能 - 複数一括予約機能 - 料金計算を自治体向けにカスタマイズ - cronを用いた自動抽選実行機能 - 帳票PDF作成　など - その他：顧客データ移行作業プログラム実装（CSV→RDB） # 身についたこと ## LAMP環境で必要な基礎力の醸成 実務をたくさんすることで、コードリーディングが早くなったり、ゼロから実装ではなく既存の関数を利用して素早く機能を実装する姿勢など、業務としてのプログラミングに必要な基礎力が大きく高まりました。また、リリース作業やバッチ実装など、LAMP環境で取り扱う全ての機能について一通り経験することができ、詳細設計以降の全分野に広く関わることができました。 ## 要件定義の経験 ヒューマンスキルを評価され、後半からMTGでの要件定義を任されるようになりました。要件を整理したのち、マネージャーと一緒に基本設計を行い、多数のレビュー指摘を受けながらも部分的に上流工程に関わることができました。優先順位づけや要件整理能力は、前職の経験が活き、始めから褒めていただけることが多かったです。 ## Gitによるコードレビューの作法 Gitをより有効に活用出来るようになりました。始めは単にPR作成をするだけでしたが、後半では、レビューがしやすいよう、Commitを分割したり、修正箇所が広範である場合はコメントで観点を記載するなど、チーム開発としての基本所作が身につきました。

# チーム構成と自身の役割 - プロダクトマネージャー：自分（先輩エンジニアの助言はあり） - バックエンド／フロントエンド／インフラ：自分 # 概要 公共施設の予約システムを開発。インフラ構築からリリースまで、全て自身で担当し、多くの機能を開発した。 # 実装した機能 - 複数デバイスでのログイン禁止 - 人気の高い施設は、一会員が短時間で複数の予約を取ろうとしてしまうことがあり、それを防止するための機能。（DBに一定時間保持されるtokenを保存し、Cookieと照合する簡易なもの） - ログイン失敗時のロック - 帳票PDFのデザイン - 自治体独自の料金計算ロジック　など # 身についたこと ## インフラ構築の経験 導入から全工程を担当し、ドメイン取得設定、本番環境、Webサーバー、DBの構築などを実施し、システム全体への理解が深まりました。 ### 要件定義・基本設計をメインで経験 パッケージ製品が母体として存在するため、ゼロからではないものの、上流工程から担当したことは大きな経験となりました。要件定義において、仕様の曖昧さを回避するためのヒアリングを入念に行いました。仕様整理や進捗管理・報告など、プロジェクトマネジメントのスキルが向上しました。

# チーム構成と自身の役割 - プロダクトマネージャー（実装も兼任）：１名 - バックエンド／フロントエンド：自分を含む２名 - インフラ：１名 # プロジェクト内容 ワクチン接種予約システムの開発。会員登録ではなく、整理券を配布し、来院時間のみ指定し、実際の受付はオフラインで行う形式。一部機能の追加を担当。 # 実装した機能 - 既往症の有無による予約可否機能 - 整理券配布機能 - 予約状況の表示機能 # 身についたこと ### モダンなフレームワークの経験 実務で初めてLaravel 5, Nuxt.js 2を使用しました。ポートフォリオとして使用したことはありましたが、これまで担当したシステムとは、設計が異なることもあり、苦労しましたが、モダンなフレームワークの使い方に精通することができました。 ### API開発の経験 このプロジェクトに参画する前はテンプレートエンジンを使用しており、バックエンド・フロントエンドを明確に区別していなかったのに対し、本プロジェクトでは区別し、実務レベルでのAPI開発ができるようになりました。 ### 実装の方法を自分で考える力の向上 実装したことのない内容の機能を多く開発したことにより、ロジックを考える力が高まりました。

# チーム構成と自身の役割 - プロダクトマネージャー 1名 - バックエンド／インフラ（兼任） 4名 - フロントエンド 自分を含む3名 - デザイン 1名 # プロジェクト内容 不動産保有者と入居希望者とのマッチングを行うモバイルアプリの新規開発。詳細設計以降を主に担当した。 # 実装した機能 - 内覧申込、入居申込、入居手続などに関わる詳細設計〜実装（APIを利用したフロントエンド実装） # 身についたこと ## モバイルアプリ開発の経験 Flutterを一度は実務で経験してみたいと考えていたので、自ら希望し、モバイルアプリの開発スキルを高めることができた。 ## 本格的なアジャイル開発の経験 JIRAを使用し、ストーリーやストーリーポイントを細かく設定する本格的なアジャイル開発を行い、全体の開発進捗を適切に保つための作法を身につけた。 ## レベルの高いチームの中で揉まれる経験 チームのレベルがとても高く、良質なコードレビューを受けることにより、命名やアーキテクチャ（クリーンアーキテクチャ）の考え方を深めることができた。

# チーム構成と自身の役割 - 技術選定／インフラ／バックエンド すべて１人で担当。 # 概要 大規模ECサイトのリニューアルに伴い、リダイレクト処理を行うためのサーバーを構築した。技術選定／インフラ／バックエンド すべて１人で担当した。AWSの可用性と費用のバランスを重視した設計の姿勢が身についた。 # 実装した機能 - 要件定義・技術選定 - 月間アクセス数に応じた、ベストなインスタンスを選定 - 採用を見送ることとなったが、サーバーレス構成についても提案した - サーバー構築(AppRunnerで構築後、事情からEC2に変更) - リダイレクト機能（FastAPI, Nginx, Route53など） - ログローテーション（Python） - システム監視（AWS CloudWatch, SNS, Cron） # 身についたこと ## AWSと監視業務への理解 - 開発内容自体はシンプルであるが、使用するリソースの選定や、可用性を意識した監視の仕組みを０から自身で考えたことが、基礎力の大幅な向上につながった。 - AWS自体は個人開発でも使用しているものの、「システムがダウンしないこと」「すぐに復旧できること」を突き詰めていくと、プロセスなどLinuxの細かい知識が必要となり、緊急時の対応力がついたと感じている。 # その他 AppRunnerからEC2への変更を余儀なくされた理由は、自社によるドメイン管理の許可が降りなかったため。Certificate Managerが使えないため、自動的にAppRunnerも利用不可となってしまった。個人開発で便利と感じていたマネージドサービスの意外なデメリットを知る機会にもなった。

# チーム構成と自身の役割 - マネジメント／基本設計／インフラ／フロントエンド 自分 - デザイン／フロントコーダー 1名 # 概要 フロントエンドエンジニア１名とコーダー１名で、Next.js 13（App Directory）を使用した自社HPフルリニューアルを開始。エンジニアが急な都合で休職したため、緊急の対応としてデザイン設計および、実装の60％が完了したタイミングで引き継ぐ形で参画し、AWS構築, microCMSとの連携およびフロントエンド実装を担当した。 # 実装した機能 - 画面の実装（難易度が高く、コーダーで実装できない箇所のみ） - SSG, SSRを明確に区別して実装することにより、ページの表示速度を改善 - Cookie同意機能実装 - GA4の導入 - microCMSの導入 - StoryBookを導入し、バラバラになっていたコンポーネントを統一 - 本番環境の構築（Amplify） # 身についたこと ## SSG, SSRを用いた高速化のスキル 参画した当時、静的なページを含む全項目がSSRであり、表示速度が遅くなっていたので、SSGとSSRを分割する実装に変更した。細かく実装したことにより、モダンなフロントエンド技術への理解を深めた。 ## Next.js13特有の仕様の理解 Pages Directoryと大きく変更されているApp Directoryの理解を深めた。また、Client ComponentとServer Componentの違いを実務レベルで理解した。 ## Google Analytics(GA4)の知見 導入始めは簡単だと考えていたが、GA4は組み込みイベントが特定のhtmlタグをトリガーとしているため、Next.jsを使用していると、一部使用できないものがあった。使用するコンポーネントを工夫しても解決できないものはカスタムイベントを作成するなど、実務レベルでの設定ができるようになった。 # その他 - 多言語対応に関する分析データ取得の法律的な知識がついた。 - 数は多くないが、難しいCSSの実装を数点担当したことで、特にSafari特有の、レスポンシブデザインの落とし穴をよく知るきっかけとなった。今後、自身が実装することは少ないと思われるが、実装にあたり、適切なアドバイスができるようになったと感じている。

# チーム構成と自身の役割 - マネジメント／インフラ〜フロントエンド実装 自分 - バックエンド／フロントエンド 1名 # 概要 ホテル開業に必要な設備や備品を調達するためのBtoBシステムを開発。新規開発案件の途中から参画し、２名チームのリーダーとして、バックエンド・フロントエンドともに追加機能開発をしている。都度クライアントとの要件定義も担当している。 # 実装した機能 - 様々なデータ登録・編集・削除（備品、ホテル部屋数、部屋タイプ、事業者、その他多数） - 請求書などの帳票機能 - データ一覧表出力機能　その他多数 # 身についたこと ## Django, Nuxt.jsの理解 PHP中心お業務から、Pythonの知識もつけることができている。 ## チームのマネジメント経験 １人で開発するという意味で上流工程から参画することはこれまでもあったが、本プロジェクトでは、小規模ながらもチーム開発で、顧客折衝を伴う形でリーダーを担当。GitHub Issueを使ったチケット管理も行い、小規模のチーム開発を、自身を中心として推し進める経験をすることができている。

# チーム構成と自身の役割 - 全て自分が担当 - 要件定義 - 技術選定 - 基本設計／詳細設計／実装 - インフラ - バックエンド - フロントエンド（※一部除く） # プロジェクト内容 新規開発。Excelで管理していたECサイト構築会社の業務管理をWebアプリ化した。 # 身についたこと ## 前書き このプロジェクトは、無事に納品し、運用までこぎつけているものの、現在も様々な課題を残しています。運用保守契約の範疇で、解消のために開発を続けています。失敗した内容も含めて書くことで、「次にどうしたらよいか？」について、考えられるようになった事項を記載いたします。 ## 技術選定での失敗・教訓 ### 失敗の内容 ゼロからの新規開発を自分が担当するのは、これが初めてでした。要件が８割程度定まったタイミングで、技術選定となりましたが、私は社内の先輩に要件を伝え、インフラとFWの選定をしてもらいました。具体的には、「AWS Lambda + FastAPI」の部分について決めていただきました。 当時は自分の経験の浅さ・認識の甘さから、そのままの採用としてしまいましたが、その後、さまざまな課題が発生しました。 具体的には、 - FastAPIが、流行ではあるが未成熟であり、ライブラリが少なかった - ドキュメントの大半が英文であり、調査に必要以上に時間がかかった。エラー対応もGitHub Issueのコメントを読むことが多かった - AWS Lambda はDynamoDB と組み合わせることが一般的であり、RDSと組み合わせるには追加の実装が多く必要であった - ログイン機能を実装後に、２段階認証が欲しいと言われ、自力で実装できる自信がなくライブラリを頼ろうとしたが、使いやすいものがなくCognitoに頼ることとなった（ランニングコストがかかってしまう） - 納品先企業のメイン言語であるPHPを使用していないため、自社でしか改修ができない（ある意味ではイニシアチブが取れてよいと考えることもできるが、選定基準の１つとして検討しなかったことは問題） このように多くの失敗をし、技術選定がいかに重要であるかを身を持って体験することとなりました。 ### 失敗から学んだこと - 新しい技術だからよいわけではない。要件と自分のスキルを総合的に考えた技術選定をするべき。枯れていることはメリットでもある。 - 非機能要件はよくヒアリングをし、その要件を満たすことのできる最短の手段を選択する。 - 「比較的厳しいセキュリティ」の意味で２段階認証 - どのサーバーやDBに対し、どこからアクセスできて、どこからはアクセスできないようにするのか - 最後に責任を持つのは自分であり、そこに経験値は関係ないこと - 何年も使うことを考え、引き継げる人が確保できる技術を選択すること ### 高まったスキル - 技術選定の判断基準をもてるようになった（わからない部分でも、「レビューを受ける力」が大きく上がった） - 英語ドキュメントへの抵抗感が一切なくなった - AWSの知識が大きく高まった ## 基本設計での失敗・教訓 ### 失敗の内容 テーブル設計において、様々な失敗をしました。 具体的には、 - どこまで正規化するか？の匙加減がうまくつかめず、過剰な正規化により実装を複雑にしてしまった - 論理削除の実装が回りくどかった - dateではなくboolを用いて、バッチ処理でフラグ管理をするべきだった - ログテーブルが後から追加となり、ログを追加しやすいテーブル構造になっていなかった ### 失敗から学んだこと - 正規化することが必ずしも正解ではなく、不要と判断できるならばあえてアンチパターンとしてもよい。要件に合っているものが正解であること - すぐに使うわけではなくても、入れておいた方がよいカラムもある（DBにも「可読性」の概念はある） - 顧客が明言していなくとも必要としている機能は必ずあり、予測して確認する姿勢

# プロダクト概要 - 商品購入ができるECサイト - 商品閲覧〜発送までの一連機能を備えた独自パッケージを基軸として、ファッション、文房具、家電など様々な商品の販売サイトを構築 - サイトによって多様なサードパーティAPI（決済、認証、流通、レコメンド、SNS等）を利用したり、販促のためのカスタマイズを施す - クライアントと技術理解が一致しない場面も多いなか、「何が本当に実現したいことなのか？」「ソースコード実装が最適か？運用による案がないか？」など正確にヒアリングできる資質が求められる - いわゆる「車輪の再開発」の起きやすい開発現場であり、別チームとの横のコミュニケーションが重宝されている # チームを"創る" ## はじめに：参画を決めた理由 これまでに経験してきたプロダクトと異なり、技術スタックの古い現場ですが、大きな魅力を感じて参画を決めました。 具体的には、 - 事業規模が、これまで自分が関わってきたプロダクトと比較して明らかに大きく、「売上をあげるための開発」を学べると感じた - これまでよりも裁量の広いリーダーポジションを任せてもらえること（現場リーダー＋リソース管理、採用） - チーム規模拡大が、ほとんど青天井であること 上記のような理由から、自分が世の中に提供できる価値のキャパシティを大きく高められると感じています。 ## 現在までの状況 - チーム規模を徐々に大きくしてきています。 - １月：まずは１人で参画し、要件定義〜実装まで担当。マネージャーに信頼していただく - ４月：２名を加え、３名のチームに。実装の担当部分を減らし、上流工程業務を中心に稼働 - ８月：４名のチームに。また、今後も増員予定 - 人間面での高評価をいただくことが多く、「どんな会議にも安心して参加し、発言させられる」「メンバーをプロジェクトに馴染ませるのが上手い」「教えていて気持ちがよい」と言っていただけている ## いま、苦労していること - 自分よりも業界経験の長い方をメンバーに迎えいれ、コミュニケーションスキルを鑑みて、自分がリーダーを継続している。リモートワークでありがちなコミュニケーションの難しさを感じており、自分に合わせることを強制するのではなく、成果に着目する姿勢で接するためにどうしたら良いか、などを模索している。 - 「自分がやった方が早い」病になりがち。任せたくとも、大規模プロダクトの中で、失敗のダメージが小さい場所がなかなか見つけられずにいる。結論としては、スケジュール調整を意識し、意図的にそのような場面を作り出さなければならない。そのスキルはまだまだ足りていない。 # その他 - 最近、Composerのパッケージ開発を行った。（インストールで使う人は多いが、開発するという貴重な経験をした） - → 横展開可能な機能を揃えておき、必要なサイトにのみ適用するサイクルを効率よく行うために導入 - 最近、言語のバージョンアップデート業務を担当したので、リプレイス業務の作法（計画立案、実装、結合テスト、リリース等）について、基本的な知識を備えている