shimpeee_

＜担当業務＞ 【業務内容】 - EVeM社のマネジメントプログラムをベースとした組織マネジメント - 構造化組織でのサブリーダーを介した間接的マネジメントによる複数チーム運営 - 目標管理制度の導入 - ピープルマネジメント - 期初の目標設定 - 1on1や日々の業務を通じた能力向上支援 - 期末の査定・フィードバック - 採用 - 自チームメンバーのイグジットマネジメント - 生産性改善活動 - 「フロー効率を高める」ことをテーマに、スクラムの導入・フィーチャーフラグの導入・レビュー基準明確化・コーディング規約の整備・AIコードレビューの導入 - 採用 - JD作成 - 書類選考 - スカウト - 正社員カジュアル面談 - フリーランスのワンショットのエージェント面談（スキル面含めて） - 候補者との連絡や日程調整含めた採用事務 - Railsエンジニアとしての開発 - スクラムマスター - 技術広報（テックブログ運営） 【成果・学び】 - マネジメント - 入社時はCTOが唯一の管理職であったが、2つのうち片方の事業を自分が管理することで、会社として組織スケールを実現できた。 - チーム・個人の目標設定を開始したことで、チームに戦略マネジメントが生まれた。ピープルマネジメントというと、1on1やティーチング・コーチング・フィードバックなどの手法に議論が集中しがちだが、より抽象的な「人材育成」の観点でみると、期初：目標設定→期中：1on1や日々の業務での支援→期末：査定と評価フィードバック　というサイクルを回すことが大切だと分かった。 - 目標設定は3ヶ月ごとに行うが、メンバーの高い成長意欲と、適切な育成サイクル（目標設定〜期末の評価FB）があれば、3ヶ月という短い期間でも明確に成長が見られるという成功体験を得た。 - 自チームメンバーのイグジットマネジメントを経験。最終的には、会社の評価・目標制度運営方針でお互いに合意できず、自己都合退職する形となった。採用時のミスマッチは入社後に挽回するのが難しいことを痛感した。 - 生産性改善 - 1年間でFour keysの変更リードタイムは1/3ほどに短縮。自身にとっても未経験の取り組みばかりであったが、書籍やセミナー等で正しく形式知を取り入れ、アンチパターンを避けることで最小のコストで成果創出に繋げられた。 ＜開発環境＞ ◦ 言語/ FW等 Ruby / Ruby on Rails

副業として業務委託として参画しているプロジェクト # 【業務内容】 - Rails のモノリシックなアプリケーションでの新規機能開発 - 要件定義・基本設計・詳細設計・実装（rspec を用いたテストコード含む）・QA まで一気通貫で担当 ## 担当機能 - サイトトップ LP（ https://foovest.com/ ）（コーディング） - 新規製造リクエスト機能（一般的な CRUD 機能） - オペレータ用管理画面（一般的な CRUD 機能） ## 使用技術 - バックエンド - Ruby(v3.0.0) / Rails(v6.0.\*) - フロントエンド - jQuery (v3.5.1) - DB - PostgreSQL - インフラ - Heroku ## チーム構成 - PdM兼PjM（IT未経験）: ​1 - デザイナー: 1 - バックエンド: 1 - フロントエンド: 1 ### 自分の担当 最初は、フロントエンド担当としての参画だった。担当領域は、マークアップのコーディングと、バックエンドとのつなぎこみ（アクションから渡されたデータの表示・decorator実装など）である。エンジニアは自分ともう1人の2人体制で、当初より相互レビューによりバックエンド機能もレビュワーとして関わった。β版リリース後の追加機能実装からはバックエンド機能開発にも携わるようになり、現在ではプロダクト開発の全ての領域を任されている。 # 【成果・学び】 自身の出身である食品業界の購買担当者向けプロダクト。ドメイン知識を生かして仕様策定段階から深く関わることができ、プロダクト開発におけるドメイン知識の必要性を強く感じた。ドメイン知識があることで、仕様やデザインに対して「ユーザー目線」での改善提案ができている。さらに、ユーザー目線でそれぞれの機能の必要性・重要性が分かるので、工数かけてフル実装するべきか・一部機能を絞って開発するべきか・今は開発しないべきか、という選択を適切に行うことができている。エンジニア 2 人でのチーム開発であったので、要件定義〜リリースまでの全工程を担当し、開発者としてのスキルも大きく飛躍できた。 本業のフォトラクションでは、エンジニアリングマネージャーとして働いており、業務内でコードを書く機会はかなり減ってしまった。エンジニア歴 2 年ほどで、まだまだスキルも伸ばしていきたいフェーズであったので、本業以外の時間で副業や個人開発を通じてキャッチアップをしている。 もう一人のエンジニア（バックエンド歴 15 年）との相互レビュー体制によって、本プロジェクト参画前までは未経験だった Rails を用いた開発も、経験 1 年ほどで小規模システムなら一通り rspec でのテストも含めて一人で実装できるようになった。適切なレビューを受けると飛躍的にスキルが伸びると実感できた。 また、ドメイン知識がプロダクト開発においてどれだけ重要かということを本業のフォトラクション（建設業界向けプロダクト）との比較でより感じる。FOOVEST は自身が食品業界にいた当時、まさにユーザーになり得たサービス。業界・ユーザーのことに精通しているので、適切に要件やデザインに対して指摘ができ、建設的な議論が行えている。「いかにドメイン知識が大切か」を身をもって体感できたことは、本業へもいい影響を与えている。 # 工夫したこと ## フロントエンドのリンター（ESLint, StyleLint, Prettier）をCIに組み込み、レビューコスト削減 当初フロントエンドのリンターはPJ内に存在せず、手動でインデント修正やレビューでの指摘を行なっていた（バックエンドはrubocopが入っていた）。実装者・レビュー者ともにムダが大きいので、ESLint, StyleLint, Prettier をプロジェクト内およびGithubActionsのCIに組み込み、フロントエンドの実装およびレビューコストを下げつつ、実装者による差異をなくすことに成功した。 ## 実装前に設計を行い、手戻りによるムダ削減 本PJに参画するまで、バックエンド開発のチーム開発は未経験であった（個人での受託開発経験はあり）。その経験値の無さゆえ、最初は「PRレビュー時に設計レベルの指摘を受け、大幅に作り直しが必要になる手戻りが発生する」という失敗をしてしまった。 恥ずかしながら、この時は「実装前に設計を行う」という発想がなく、いきなり実装に入っていた。 それ以降は、実装前に設計方針のすりあわせを行ったのち、設計のレビュー（ルーティング・アクション・サービスクラスなど各階層でどんな処理を行うかのざっくりとした流れ）をしてもらってから実装に入るよう進め方を変更。 設計→実装というあるべき進め方をとることで、「PRレビュー時に設計レベルの指摘を受ける」ということがなくなり、手戻りによるムダが削減できた。 ## ScssでBootstrap風のオリジナルクラスを作成し、コーディング時間削減 スピーディーな開発を行うため、CSSフレームワークにBootstrapを採用している。デザインをBootstrapのコンポーネントスタイルに寄せてはいるが、Bootstrapではカバーしきれない部分があり、一部オリジナルのスタイリングをせざるを得ないものもある。 その中でも、使用頻度の高いfont-sizeやborder-radiusについてはBootstrapのソースコードを参考にBootstrap風のクラスを作成することで、コーディング時間を削減することができた（例：font-size-sm-18 で、568px以上のときfont-size:18px など）。 独自のコーディング規約は今後人が増えたときの参入障壁になるので、ドキュメント化も行っている。

# 【業務内容】 ## 業務内容① 品質課題解決のための開発チームマネジメント 喫緊の最重要課題である品質課題（不具合が多い）解決のため、不具合解消を担う CRE チーム（4 名）および不具合発生抑制を担う新規開発チーム（7 名）のマネジメントを行う。一部オフショアへ開発委託しており、オフショアのマネジメントも行う。 ### 代表的な取り組み #### 取り組み概要（What） 「Backlog の不具合チケット残数を減らす」こと #### 取り組みの背景（Why） これまでの開発は、「どんどん作ろう！」というスタンスで新機能開発にエンジニアリソースのほとんどを投下し、不具合の改修は必要最低限に止めていた。 しかし、顧客からのクレームがだんだんと増えてきて、それが原因で大口顧客がチャーンの危機に陥ることもあった。 そのような背景から私が入社したタイミングで CRE チームが発足し、新機能開発と不具合改修のリソース分離し、不具合解消は専門チームでチームで行うことにした。 それでもなお、私の入社当時の残不具合チケット数は 200 ほどあり、「ユーザーに自信を持ってお届けできる」サービスではない状態であったので、予算をかけて短期決戦で不具合チケットを減らすことになった。 #### 具体的な取り組み内容 社長含めた関係者と「年度内に不具合チケットをゼロにする」という計画を立案し、依頼実績のあるベトナムのオフショアを増員（ブリッジ SE2 名、エンジニア 9 名、テスター 2 名）。日本人を業務委託や SES で雇うではなくオフショアにした理由は、コストが安いからである。（日本人: 約 120 万円/人月、オフショア: 約 45 万円/人月） 私の役割は、ブリッジ SE とのコミュニケーション窓口、その他不具合チケットを減らすための各種ボトルネック解消など。 #### 取り組み結果 結論からいうと、「解消数は目標を下回った。オフショア開発をやめて日本人の採用を行う計画を練り直しているところ」である。 増員したオフショアによる改修はどんどん進んだが、納品後の日本側でのコードレビューで停滞が始まった。ヒヤリングの結果、停滞原因は主に「オフショアの納品するコード品質が低い」ことが理由だと分かった。 具体的には、PR レビューでの指摘に対しても適切な修正が行われない・なぜその修正を行なったのか？が分からず Approve できない・そこで発生するやりとりのコミュニケーションコストが大きいことがなど挙げられた。 そこで、品質面の課題解決のため、週次で WEB・iOS・Android の各テックリードとブリッジ SE を招集してフィードバック MT を開催することにした。コード品質向上のため、現地でのレビューを導入し Github で Appeove したものを納品するように依頼。コミュニケーションコストを下げるため、コミットコメントの書き方を指導・納品時に「バグの原因・修正方針・影響範囲・エビデンスの画像/動画」を併せて提出するよう依頼。3 ヶ月ほどかけて前述の依頼内容について細かくフィードバックを行ってきた。 しかし、依頼内容を実施し少しずつ状況が改善されてはきたがやはりコミュニケーションコストが大きく、レビュー停滞が解消できるほどの改善効果は得られなかった。オフショアへの委託は、人月単価自体は安いが、コミュニケーションコストを考慮したトータルのコストパフォーマンスでいうとマイナスが大きいと判断。 さらに今後長期で見たときに、「今の不具合発生数ありきで解消するための人数を確保するのではなく、本気で発生数を抑えにいくべき」と提言し、別で進めているアジャイル開発への移行とともに不具合解消もアジャイルチーム内で行なっていくよう意思決定をした。チーム内で不具合発生数を測定し、観測することで長期的に発生を抑えにいく。 オフショアへの委託は結果として「安物買いの銭失い」となってしまったことは勉強代としては大きすぎるが、この失敗を今後の組織運営に生かしていきたい。 ## 業務内容② 不具合調査 CS からの技術的な問い合わせには、自ら手を動かし調査を行う。バックエンドは Laravel(v5.2)、フロントエンドは backbone.js・Vue.js・Nuxt.js・TypeScript、インフラには AWS を使用している。書類出力・描画周りでは一部外部サービスの API を利用している。外部サービス連携を含むインフラ〜フロントエンドまで横断的に調査を行う。 AWS は、以下のような構成 - ElasticBeanstalk を用いたブルーグリーンデプロイ - Lambda・CloudWatch を用いた外部サービス連携のバッチ処理 - Worker 環境を用いたアップサーバーとの処理の分離 ### 不具合対応の内容 - Vue.jsで実装されたフロントエンド不具合の改修 - Laravelで実装されたバックエンド不具合の改修 - PHPDebugを用いたデバッグ - 開発環境から本番DBへつなぎ、環境起因原因の特定 - CloudWatchでのLaravelログ・Lambdaログの確認 - AthenaでのALBアクセスログ確認 - RDSのスナップショット復元 - ALB, ECS, Elasticbeanstalk など各サービスのステータス確認 - 実装者が退職済み・現メンバーが誰も分からない APIGateway x SQS で実装されたサーバレス環境の不具合 - クラスメソッドサポートへ問い合わせながら、原因究明 - 外部サービス連携部分は、原因切り分け後、先方担当者と共に解決策を模索 ### 不具合改修において工夫したこと #### ALBのアクセスログをAthenaで分析できるようにし、不具合調査効率向上 モバイルアプリ側の不具合調査の際、サーバー側との同期関連の不具合だと「同期が走ったのか否か」が一次切り分けとして非常に大事であるが、DBでの操作ログだけだとそれが分からず調査がしづらいという課題があった。そこで、ALBで取得しているアクセスログ（日時・クエリパラメータ付きURL・ステータスコード）をAthenaで分析できる環境を用意し、「同期が走ったか」の確認ができるように。モバイル側の調査効率が悪いという課題を解決できた。 ## 業務内容③ 不具合改修のPM CREチーム4名、およびオフショア9名が行う全不具合改修案件のプロジェクトマネージャーを担当。常にチケットが10〜20動いているような状態で、日々これらの確認に多くの時間を割いている。 ### 不具合改修のPMとして工夫したこと #### BacklogAPIを使った課題集計システムを開発し、業務工数削減 週次・月次で解消状況をまとめて報告する際、毎度Backlog上で課題検索で絞り込みを行い、集計を行なっていた。週に2度 **1**時間、月に1度 **2**時間かかっていた作業をTypeScriptで自動化し、計**4**時間/月 の工数削減に成功。 # 【成果・得られたスキル】 ## コミュニケーションが活発な生産性の高いチームビルディングを行うことができる チーム生産性を高めるため、コミュニケーションが活発なチームビルディングを重視している。「生産性の高いチーム」 = 「行き交う情報量の多いチーム」であると考えている。 コロナ以降働き方がフルリモートになった現職では、『[Gather](gather.town)』を用いて、オフィス出社時代の「ちょっとイイですか？」ができる空間を作ったり、定例内で議論が活発になるアジェンダを用意するなどし、リーダー対各メンバーの「1 対 n」ではなく、メンバー同士の「n 対 n」のコミュニケーションがとれる環境作りを行っている。 また「褒めるフィードバック」を行うことで、メンバーの自己肯定感・向上心が高まり、そのエネルギーがチームに還元され、他のメンバーへも良い影響を与えるというサイクルを生み出すことができている。 コミュニケーションが活発な、「生産性高いチーム」を作ることが得意。 ## リーダーシップ 食品メーカーで約 3 年のリーダー経験があり、現職でも入社 1 ヶ月で CRE チームリーダーを、6 ヶ月目には兼任で新規開発の WEB チームリーダーも任されている。プライベートでも 10 人ほどのプログラミング学習コミュニティを立ち上げ日々活動を行うなど、チームで仕事をするのが好きであり、得意領域でもある。 チームとしての成果が最大になる為の施策を考え、粘り強く実行していくことが得意。現職でも、入社直後から開発組織最大の課題であった「不具合件数を減らすこと」に対して綿密な計画立案・オフショアのマネジメント含めたプロジェクト進捗管理を徹底的に行い、2021 年度上期の「全社（社員 60 名弱）で最も業績貢献した人」として MVP 賞を受賞。 # 【学び】 ## ベテランエンジニアのマネジメントの難しさ EM としてエンジニア組織のマネジメントを行うのは初めてですが、「チーム内外の関係各所に協力を仰ながら、目の前の課題にチームとして取り組む」という点は後述の食品工場時代のマネジメントと同じであり、その経験が生きています。 しかし、自身のエンジニア経験が 2 年程度であり、自分よりはるかに知識豊富なエンジニアの方々の中心に立つという難しさに直面しました。会社・チームとしてやりたいことをリーダーとして推進していくために、まずは信頼してもらう必要があります。 その中で特に意識したことは、「『自分にできること』と『自分ができないこと』を明確にする」です。具体的には、以下のような棲み分けです。 - できないこと - 技術的なサポート - できること - 即レス - 関係各署との調整 - 誰でもできるが、時間がかかるもの（不具合再現など） - 誰よりも熱量を持って、真摯に取り組む - 技術のキャッチアップ 技術・プロダクト・組織作りといった多くの職務領域を完全にカバーすることはできません。できない部分は人に任せ、できる部分にフォーカスして動く方が、結果として全体のパフォーマンスは上がり、信頼も得られるだろうと考えました。前職での大手企業での経験から、関係者を巻き込み調整しながら業務を進めることは割と得意領域だったりするので、まずはそこで自分のバリューを発揮しようと心に決めました。 あとは、「熱意」の部分も非常に重要で、リーダーの熱量がそのままチームの熱量になると思っています。即レスするだけでも相手へ熱量を伝えることができます。 また、今はできないこととしている技術面についても、「キャッチアップしている姿」も見せることが非常に大切だと思い、メンバー同志のモブプロに参加したり、積極的に Slack で技術的な質問を投下するなどしています。 これを意識してやった結果、最初は私に相談することなど皆無だったメンバーからも半年経った頃には毎日相談を受けすぎて手が回らないくらいには信頼してもらえるようになりました。前述の MVP 受賞理由も、こういった姿勢が評価していただけたようです。 ## 「リソース効率」より「フロー効率」 前述のオフショアを使った不具合解消の取り組みで、「リソース効率」よりも「フロー効率」を重視した方がアウトプット量は多くなる、ということを、失敗を通じて学ぶことができました。 『【業務内容】> 代表的な取り組み』で述べたように、レビュー工程で停滞してしまったのはオフショアの品質が低いことが主な原因でした。実は失敗はそれだけでなくもう一つありました。 オフショアへは、「レビューは日本側でさばくので、どんどん新規チケットを対応してガンガン納品してほしい」と伝えており、追う KPI も納品数を設定していました。 しかし、「チケットがレビュー工程で停滞する → 監視対象のチケットが増える → ハンドリングが煩雑になり、質問や指摘コメントへのレスポンスが遅くなる → さらに停滞する」ということを経験しました。その頃ちょうど[ネットで見た記事](https://www.slideshare.net/i2key/xpjug)で「リソース効率」と「フロー効率」という言葉を知り、自分がやっていたのは完全に「リソース効率」重視のハンドリングであったことを認識しました。 そこからフロー効率重視のハンドリングへ切り替え、KPI も「納品数」ではなく「レビュー通過数」へ設定し直し、現在取り組み中です。 ## 変数が多い場合は、究極にシンプルに考える 前述のオフショアによる不具合解消の取り組みで、オフショアエンジニアが何人必要かを算出するために「一人あたり月何件解消できるか」という能率を設定する必要がありました。 最初は、過去の Backlog チケットのデータから「解消した件数」「修正規模」「修正難易度」など、「考慮できうる全ての要素」を反映させた完全な数値を出そうとスタートしました。 しかし、変数が多すぎるとどんな計算式を使っても納得感が出ず、どうすれば良いか分からず堂々巡りになってしまいました。 そこで、代表に相談したところ「シンプルに実績の平均で出せば良いじゃん？月によって大きくバラツきがあるのも、それが実態ということだから慣らしちゃえばそれっぽい数字になるよ」と言われました。 最終的に、一人あたり解消数 5 件/月で計算してオフショアの人数を決めましたが、半年ほど運用して非常に精度の高い（頑張ればぎりぎり到達できそうな）数値になっていました。 「変数が多すぎる場合は究極ににシンプルに考えるとよい」という教訓を得ました。 ## チームの雰囲気は一人一人の総和だが、変えるキッカケは一人でも生み出せる 私のチームは、6 人のメンバーで構成されています。メンバーの中で 1 名、あまり積極的に発言することはなく、笑った姿を見せることも少ないおとなしい女性のメンバーがいました。 それがある日を境に、チームミーティングでもがんがん発言するようになり、これまでのポーカーフェイスが嘘のように豊かな表情を見せるようになりました（後から本人に聞いて分かったことですが、プライベートで大きなプラスの心境の変化があり、それが仕事へも良い影響を与えていたようです）。 彼女の大きな変化が、チームに大きな変化をもたらしました。フルリモートでなかなか分かりづらいにもかかわらず、明らかにチームの雰囲気が明るくなり、チーム内の会話量が増えました。 この一連の出来事は完全に偶然でしたが、リーダーとしてチーム運営する上で非常に学びとなる出来事でした。

## 【業務内容】 - ABテストのデモ実装 資料請求画面のエンハンスABテストを行うチームにて、マークアップとJavaScript/jQueryを用いたデモ開発を行い、バックエンドへ連携。「スマホ画面」に特化したチーム - 要件定義 企画・デザイナー・フロントエンド・バックエンドの総勢10名程度の少人数チームなので、全員で要件定義から行う。自らもフロントエンドエンジニアとして積極的に仕様やデザインの調整に加わる。 ## チーム構成 - PO: ​2 - デザイナー: 2 - バックエンド: 3 - フロントエンド: 2 ### 自分の担当 フロントエンド ## 【成果・学び】 - 技術面では、「既存の縦スクロールを横スクロールに変更する」や、「バリデーションを丸ごと書き換える」といったJavaScriptのロジックに大きな修正の入る実装を多くこなしている。具体的には、「スクラッチで画像スライダーを実装する」、「ajaxを使って非同期で読み込む複数のモジュールの表出タイミングをMutationObserverで制御する」のような実装をこなしている。 　また、スマホ画面に特化したチームで開発を行なっているので、AndroidとiOSというOSの違いによる差異・iOSのバージョンごとの差異などに精通している。 　案件はユーザビリティ観点でのエンハンスが多く、徹底したユーザー目線を会得できている。直近で大きくCVR向上できた施策として、「フォームのSP画面での入力項目の分離」がある。PCとSPが同じ画面体裁だと、SPの場合に「入力項目が多くてユーザーの心理的負担が大きく、途中で離脱してしまっているのでは？」という課題感があり、入力を分割してあげることでユーザーの入力心理負担を軽減することで、CVR105%の改善に成功。 　また、20年の歴史ある大規模サービスにおける開発手法を身につけることができた。 - 実装力だけでなく、要件定義を含めた「開発メンバーの一人としての自走力」を非常に求められ、その能力が身についた。配属以来数十件の案件にて実装の実現可能性の判断や工数の見積りを自分の判断で行ってきた。 　工数の見積もりや実現可能性を測る上で大切にしているのは、エンジニアとして企画側の要求を全力で実現したい思いがあるのは大前提として、いい意味で「全てを疑ってかかる」という姿勢。具体的には、「その機能は、今本当に必要か？」と疑うことである。 　ABテストは期間限定の実装になるので、「実装にかけるコスト」と、「早くリリースすることにより得られるメリット」とのバランスが重要となる。企画側の提案がコストの割に効果のインパクトの弱いと思われる場合は、「ABテストでは要件を削ってリリースを早めて市場の反応をみて、ABテストが勝利して本反映する際に全要件を実装しましょう」といった提案を行う。 ## 【PR】 ### ◻️ 開発全体を任せられる力 　このプロジェクトでは、フロントエンドエンジニアとしてディレクターやデザイナー、バックエンドエンジニアと共に要件定義のフェーズから携わります。上流である「ディレクター・デザイナー」と、下流である「サーバーサイド」に挟まれる形でフロントエンドである自分が存在しているので、自分が中心となって前後の工程の進捗を見つつ、開発全体のスケジュールハンドリングを行なっている。このように様々なアクターと調整を繰り返した経験が多く、関係者を巻き込んでの仕様調整・要件定義を行うことができます。 　また、個人で受けた副業のシステム開発案件では、サービス名の考案・ワイヤーフレーム作成・デザイン外注とそのディレクション・実装、そしてサーバーアップまで行いました。このように、1人で案件を完結させる能力があります。 　さらに前職では30人ほどのチームのリーダー経験もあり、チームおよびプロジェクト全体を見通す視野の広さを持ち合わせています。 　単なる実装者の範囲に留まることなく、開発プロジェクト全体を円滑に進めることができます。

個人で受けた副業のシステム開発案件です。 ## 【業務内容】 - サービス名考案 - サービス内容を端的に表していて、親しみやすく、ロゴにしたときの見た目がよく、検索優位性が高くドメインの取得できるサービス名『ぷっとれ』を考案。 - ワイヤーフレーム作成 - Adobe XDを使ってワイヤーフレームを作成。 - デザイン外注とそのディレクション - ココナラを使ってデザイナーを外注。実装と平行してデザイナーとのやりとりをディレクション。 - 実装 - Laravel × jQueryを使って、管理画面を含めた全20画面をレスポンシブで実装。 - サーバーへデプロイ - すでに稼働しているサービスのあるサーバーへ自分のプロジェクトをデプロイ。 ## チーム構成 - PO: ​1 - エンジニア: 1 ### 自分の担当 エンジニアとして、開発全工程を担当 ## 【成果・学び】 　サービス名の考案からワイヤーフレームの作成、デザインの外注とディレクション、設計〜実装およびデプロイまで、webサービス開発の一通りの流れを仕事として経験することができた。「決められた納期の中で、要件を満たしつつどこまでユーザビリティを追求できるか」というバランスを考えて実装を行うことは、実際の業務においてもそのまま応用できる。 　デザインの外注では、1人目に依頼した相手でこちらの希望するデザインを作成してもらうことができず結局2人目にお願いすることになり費用が2倍かかってしまった。1人目の発注の際に相手のポートフォリオを確認することなく選定してしまったことが失敗原因だったが、こちらの求める品質をクリアすることができるか事前に入念に確認することの大切さを教訓として得た。 　また、初めて自分が外注の業務委託の方とやりとりをしたことで、「クライアント（自分）を安心させるにはどうすればよいか？」ということを客観的に見ることができた具体的には、連絡には即レスをすること（即レスできない場合は「〇〇までに確認してご連絡します」などと具体的な日時を伝える）、依頼された仕事が「いつまでに完了できるか」を伝えることなどである。 ## 【PR】 　受託の開発案件を1人でやりきったことで、webサービス開発の一通りの流れを経験することができました。ひとりで案件を完結させる力があります。 　また、実装に留まらずサービス名の考案なども行いマーケティング観点の知見も得られましたので、サービス・事業拡大に貢献することができます。