ID:68941さん

# プロジェクト概要 某鉄道事業者様の駅ホームに設置された案内表示器を更新するプロジェクトです。 # チーム情報 全体で約30名程度のプロジェクト。★が自己のロールです。 * ★プロジェクトマネージャー兼アーキテクト : 1名 * アソシエイトプロジェクトマネージャー兼アーキテクト : 1名 * PL : 5名 * デザイナー : 2名 * ソフトウェアエンジニア : 15名 * ハードウェア(機械・構造)エンジニア : 4名 * 電気系エンジニア : 2名 * QAエンジニア : 3名 # 役割 担当した役割の詳細は以下の通りです。 * プロジェクトマネージャ : プロジェクト計画策定、進捗管理、コスト管理、リスク管理 * アーキテクト : 要件定義、基本設計、機能設計 # プロジェクト面の課題 : 新規開発に伴うリスク ## 状況 案内表示に関する要件が複雑であり、実現難易度高い新規開発要素が多数存在していました。 ## 課題・問題点 開発途上での開発失敗に伴う工程遅延・予算超過のリスクがあり、対策が必要とされています。 ## 対策 有識者を巻き込んで開発リスクの洗い出しを実施。挙がった課題に対し、発生確度・影響金額を評価した上で、リスクヘッジ策を検討。リスクヘッジに必要な工数とリスク発生時の予算・工程への影響をあらかじめ計画に組み込むことで堅牢なプロジェクト推進ができるようにしました。 # 技術面の課題 : マルチディスプレイ用同期表示技術開発 ## 状況 複数の表示制御基盤を同期連動させ、複数のディスプレイで構成される大型の案内表示器全体で１つの案内を実現する必要がありました。 ## 課題・問題点 １つのディスプレイに対して１枚の表示制御基板が接続されている状態となっているが、上位装置から表示制御基板に対し、表示更新コマンドをブロードキャストしても、基板ごとの処理時間のばらつきによって微妙に表示タイミングがずれ、ディスプレイ間で表示している情報にずれが生じる。 複数枚のディスプレイ間で表示更新タイミングを同期させ、表示器全体で１つの案内が行えるようにする必要がある。 ## 対策方針 自社が保有する表示制御基板に対して、複数枚の表示制御基板間で表示タイミングを同期させるための機能を基板回路およびソフトウェアとして組み込み、表示情報の更新があった際に同期タイミングを合わせるための信号を相互にやり取りすることで、基板間のタイミングを映像フレーム単位で一致させる。（現在開発中）

# プロジェクト概要 スタジアムや駅などに設置される大型ビジョン・液晶モニタなどの表示デバイスに対し広告などの映像コンテンツを配信・表示するシステムの開発プロジェクトです。Azure（Microsoft社）上にWEBアプリケーションとしてサービスを実現しました。 # チーム情報 全体で約10名程度のプロジェクト。★が自己のロールです。 * プリセールス : 2名 * プロダクトオーナー : 1名 * ★スクラムマスター : 1名 * ソフトウェアエンジニア : 5名 * QAエンジニア : 1名 # 役割 担当した役割の詳細は以下の通りです。 * スクラムマスター : プロダクトバックログの作成・更新、デイリースクラムのファシリテート、スプリント管理、コスト管理、リスク管理 * アーキテクト : クラウド・フレームワーク選定、アーキテクチャ・インフラ設計 * ソフトウェアエンジニア：フロントエンドのコーディング・テスト # 開発課題1：初のクラウド型サービスへの挑戦 ## 状況 所属部門としては初のパブリッククラウド（Azure）を用いて行う開発であり、開発実績のあるエンジニアも非常に少ない状況でした。 ## 課題・問題点 パブリッククラウド上でのシステム実現方法に関して未知な部分が多く、どのようにシステムを構成すれば良いか不明な部分が多数存在していました。 ## 対策と成果 社内の開発規定はフェーズ（要件定義、設計、開発、テスト）移行にあたっての移行審査が求められますが、そこにフィットできる形でアジャイル型開発プロセス（スクラム）を採用。課題を早期発見・解決できる体制を構築することで、大きな手戻りなくプロジェクトを推進することができました。 # 開発課題2：メンバーの技術スタック ## 状況 開発するプロダクトは自社ビジネスの核となるため、今後も自分たちで開発を継続していくことが求められていました。 ## 課題・問題点 所属部門はオープン系・組み込み系の開発案件がほとんどを占めており、いわゆるモダンなWeb開発言語やフレームワーク（React、Vue、Angular等）に長けたエンジニアはほとんどいない状態でした。 ## 対策と成果 社内にはC#を得意とするエンジニアが多かったことから、C#でWebアプリケーションの開発ができるASP.NET Core Blazorを選定することで、アウトソースせず自分たちで開発できるようにしました。一方、市場の採用事例が他のWebフレームワークに比べて少なかったため、実装方法に不明な点が多い状況でしたが、スクラムを採用して早期検証とメンバー間の情報共有を促進することで、課題の早期発見・解決を図りました。