ID:84674さん

Web制作会社で、受託案件の進行そのものをマネジメントしていました。社内唯一のWebデザイナーとして常時3〜5件を並行し、要件整理、見積もり、スケジュール設計、デザイン、実装、公開後の運用までを一貫して担当。案件によっては他部署の開発チームや協力会社、インフラベンダーとの調整も行っていました。

担当案件を、クライアントの事業目的を満たす形で、品質を落とさず期日内に公開する状態にすることが責務でした。 受託は納品がゴールになりがちですが、公開して終わりではなく、公開後に運用できる状態か、更新の負荷が現実的かまで見て設計する必要がありました。また複数案件が同時に走るため、どの案件にどれだけ時間を割くかの配分も自分で判断していました。 クライアントは必ずしもWebに詳しいわけではないため、要望をそのまま実装するのではなく、その裏にある目的を引き出し、実現方法を提案して合意を取るところまでが役割でした。

要望ではなく業務から設計する 転職支援サービスの社内求人管理システムのリニューアルでは、当初「画面を見やすくしたい」という抽象的な要望でした。そのまま受けると表面的な改修に終わると考え、まず関係者へのヒアリングと既存業務フローの把握から入りました。 そこで分かったのが、入力に必要な情報が複数画面に分かれていて、担当者が別タブで参照しながら入力していたことです。これを、必要な情報を1画面で見ながら入力できる構成に再設計しました。あわせて、求職者のステータスを色分けして一覧で判別できるようにし、詳細画面を開かずに一覧から直接操作できるようにしました。 40ページ以上の管理画面の情報設計、UIデザイン、フロントエンド実装まで一人で担当し、日常的に利用する50〜80名の方から「以前より使いやすくなった」と評価をいただきました。 複数案件の並行と、品質の作り分け 常時3〜5件が並行する状況では、すべてに同じ工数をかけることはできません。そこで案件ごとに「何のために作るのか」を基準に、かけるべき品質の水準を判断するようにしました。 需要検証が目的のサービスサイトでは、機能を絞った最小構成で早く公開する判断をしました。逆に、毎日使われる業務システムでは、1操作の削減が業務効率に直結するため、情報設計に時間をかけました。 外部ベンダーを含む調整 クライアントのWordPressサイトで、MySQL 8.0から8.4へのRDSアップグレード(AWSのBlue/Greenデプロイ)が必要になった際は、インフラ会社との調整役を担いました。影響範囲の確認、作業内容の翻訳、スケジュールの合意、クライアントへの説明文書の作成までを行い、サービス停止を最小限に抑えて完了させました。 技術者同士でしか通じない話を、クライアントが判断できる言葉に置き換えることが、ここでの一番の仕事だったと考えています。

Next.js / React / TypeScript環境の校務管理Webアプリケーション開発において、フォーム機能全体の実装計画と、後輩メンバーとの作業分担をマネジメントしていました。対象は約30種のモーダルと約20種のフォームモジュールです。

タイトなスケジュールの中で、二人で分担しながら手戻りを出さず、期日内に実装を完了させることが責務でした。 このプロジェクトはFeature-Sliced Designを採用しているため、レイヤー構造を無視して着手すると、後から共通化が必要になった際に大きな作り直しが発生します。また経験の浅いメンバーに複雑度の高い箇所を割り当てると、レビューの往復が増えて全体が遅くなります。 単純に作業量を二等分するのではなく、どの順番で、誰が、どのレイヤーから着手するかまで設計した上で進める必要がありました。

2つの分担案を比較した 最初に検討したのは、モーダル単位で約30種を分け合う案です。分かりやすい反面、2つの問題がありました。モーダルごとに複雑度の差が大きく負荷が偏ること、そして複数のモーダルで同じフォームモジュールが使われるため、同じものを二人が別々に実装してしまうリスクがあることです。 もう一つが、FSDのレイヤー構造に沿って進める案でした。先にFeature層のフォームモジュールを固め、それが揃ってからWidget層のモーダルを組み立てる。この2フェーズ構成を立案・提案し、採用されました。 複雑度に応じて配分した フェーズ1では、バリデーションや状態管理が複雑なモジュールを自分が担当し、構造が定型的なものを後輩メンバーに割り当てました。先に自分が数本実装して型を固めてから渡すことで、実装方針を共有でき、レビューでの指摘も減らせました。 フェーズ2では、フェーズ1で作った部品を組み合わせる状態になっていたため、分担の自由度が上がり、負荷の偏りも解消されました。 並行して、重複の芽を潰した 同じ案件で、10ページ以上のフォーム系画面において全体レイアウトの実装が重複し、細かなスタイル差異が生じていました。数ページ実装してパターンが安定したことを確認した上で、共通レイアウトコンポーネントへの切り出しを提案・実装し、feature層に配置してStorybookに登録しました。結果としてレビューでのレイアウト指摘が解消され、コードも簡潔になりました。 結果 手戻りの少ない進行となり、当初のスケジュールを前倒しで完了しました。 意識していたのは、部品から固めて組み立てるという、デザインシステムと同じ発想です。共通化できる単位を先に見つけて型を作れば、後工程の速度と品質は自然に上がる。この感覚は、UIデザインの経験から来ているものだと考えています。

スマートフォンゲーム世界大会の10言語対応特設サイトについて、バックエンド以外の制作工程全体をマネジメントしていました。要件整理、掲載情報の整理、関係者調整、サイトマップ・ワイヤーフレーム制作、デザイン、フロントエンド実装、公開後の運用までを一貫して担当しています。

1言語あたり12ページ×10言語、実質約120ページ相当のサイトを、大会日程という動かせない期日に合わせて10言語同時に公開する状態にすることが責務でした。 制約が2つありました。一つは、翻訳データが日本語版の確定後に順次支給されるため、全言語を待ってから作り始めると絶対に間に合わないこと。もう一つは、賞品紹介やファイナリスト紹介など、大会進行やクライアント側の情報確定を待たなければ作れないページが含まれていたことです。 全部が揃うのを待つのではなく、確定した情報から順に出せる進行体制を設計する必要がありました。

待つのではなく、分けて出す 情報の確定タイミングが揃わない以上、一括公開を前提にすると全体が最も遅い情報に引きずられます。そこで、大会概要など確定済みの情報を第1フェーズ、賞品紹介・ファイナリスト紹介など確定待ちのものを第2フェーズとする2段階リリースを提案しました。 これにより、クライアント側の情報確定を待つ間も制作を止めずに進められ、確定済みの情報を先行して公開できる体制を作りました。 翻訳の支給順に合わせた進行設計 日本語版が確定してから翻訳が順次支給される制約があったため、日本語版で構造とレイアウトを固め切り、他言語は差分対応で流せる状態にしてから展開しました。 結果として、デザイン2週間・コーディング2週間の約1ヶ月で、10言語同時公開を納期内に実現しました。 多言語特有のレイアウト差分 言語ごとに文字量が大きく異なるため、日本語基準で組んだレイアウトはドイツ語やフランス語で崩れます。文字量の増減を許容する設計を前提にし、アラビア語では右から左へ読むRTL表示に対応しました。 ここは実装してから気づくと修正コストが高い箇所なので、デザイン段階で言語差を想定に入れておくことを意識しました。 公開後の運用まで含めて設計する 大会結果は試合当日から翌日にかけて10言語分を反映する必要がありました。公開して終わりではなく、更新のたびに10倍の作業が発生する前提で、運用しやすい構造にしておくことが重要でした。 2022年の新規受注から2023年も継続して対応しています。