ID:75669さん

＃プロジェクト概要 プレイステーションプラットホームの新ハードに関わるOS、SDK開発やドキュメントの執筆、サンプルコードのコーディング ＃チーム情報 日本の開発者はエンベデッド20名、ソフトウェア(SDK開発)40名 海外の各拠点（アメリカ、イギリス、ドイツ、イタリア、インド）などの開発者も参加 開発には海外のエンジニアと英語をベースにメールでディスカッションを行いながら進めた。 ＃開発・実装内容 【概要】 SDK API 開発 【課題・問題点】 参画当初、SDK の機能ツリーを見ると機能毎には分かれているものの、似たような API が存在しており、 何をどう使えばやりたい事が実現できるかイメージしずらかった。 どうすればシンプルかつ依存性のないモジュールにできるか？ 【工夫】 1つのAPIで複数の事を実現するのではなく、機能を1つに絞り極力他のモジュールと依存しないように実装。 【成果】 API の数は増えたものの、どの API を使えば実現したい機能であるかが明確になった。 【打ち手・使用した技術】 私自身も元ゲームソフトウェアの開発者なので、開発者の立場に立って考え、想定される使用方法を確立した上でモジュール化していった。 また過去に SDK のセキュリティホールを利用したハッキングが横行した経緯があるため、セキュリティも考慮した仕組みにする必要があった。 結果として OS のレイヤーを分断しある条件を満たさないとネイティブ API にアクセス出来ない仕組みを作った。 APIはC++、ラッパーとして C# を使用 結果として強固なセキュリティを持ったコンソールハードを開発することができ、 SDK も全世界に公開され、プラットフォームに携わる全ての人達にコードやドキュメントを見て貰う機会ができた。

＃プロジェクト情報 ECサイト (サービス名:グリーンビーンズ) のシステム構築、運営。 ＃チーム情報 参画当初5名、現在50名 (IT部) ＃業務概要 グリーンビーンズではイギリスの OCADO 社が開発した OSP というパッケージを日本仕様に改造してサービスを提供している。 ＃開発・実装内容・1 【概要】 Azure 上に作成された SQL Server に DataFeed 呼ばれる json 形式のデータをデータベースに格納するシステムの開発 【課題】 OSP は DataFeed と呼ばれる json 形式のデータを gz で圧縮されたデータが数百あり、生成される時間、フォーマットもまちまちでこれらのデータをどう効率よくデータベースに落とし込むか？ 【工夫】 DataFeed が生成された数分後に REST API を実行し Azure上の Blob に配置した。 Blob 上に配置されたイベントをトリガーに gz ファイルを解凍、json データをパース、SQL 文を自動生成して DB に格納まで自動で行えるようにした。 【成果】 上記のフローをベースに DataFeed のパース部分の基本的な部分を基底クラスとして定義し、それぞれの DataFeed のフォーマットに合わせた部分を派生クラスとして実装した結果、全ての工程を自動でデータベースにデータをストアすることが出来る仕組みを作ることができた。 【問題点】 DataFeed はバージョンが変わる際、フォーマットが変わってしまうことがあり、既存のプログラムでは対応しきれない事が多々あった。 【打ち手・使用した技術】 既存のプログラムを改修する形では古いバージョンのものに対応できなくなってしまうため、DataFeed のバージョン毎に専用のパースクラスを実装し対応した。 この仕組みにより、グリーンビーンズのローンチ直後から直近のデータまで満遍なくデータをストアできる仕組みができ、後述する DWH へのデータ格納がスムーズに行えた。 ＃開発・実装内容・２ 【概要】 Azure 上に作成された SQL Server から GoogleCloud の BigQuery にデータ移行後、BI ツールを用いデータの分析作業 【課題】 DataFeed はデータが膨大過ぎて SQL Server で全てをまかなう事が困難になったため、業務用途は SQL Server、分析用途で使うデータは BigQuery に移行を行った。 【問題点】 各部署が独自に Redash で SQL クエリを書き、不定期に実行していたため SQL Server への負荷が非常に高くなり、データの抽出に時間が掛かるようになり、データベースを維持するコストも非常に高くなってしまった。 【工夫】 Redash 上に書かれた SQL が適切かつパフォーマンスの良いものかを判断するため GitHub に一旦全ての SQL を保存を行い、 プルリクエストで承認されたものは SuperSet への移行を現在行っている（私はレビュアー）。 また PowerBI のデータモデルの構築も業務要件に沿った形で作られているかを再検証し、前述した業務用途で使っているモデルは SQL Server、分析用途で使っているモデルは BigQuery からデータを取得するようにしている（BigQuery 用の SQL も私が担当） 【成果】 上記作業を現在も行っているが、結果として SQL Server の DTU を半分まで下げることができ、BigQuery も適切なスロット数をユーザーの使用傾向を見ながら分析し、部の予算を超過していたコストを抑えることができた。 ＃開発・実装内容・３ 【概要】 BI ツールを用いたデータ分析、可視化 【どのような機能の開発・実装か】 個人情報や経営判断に使うようなデータは PowerBI、その他のデータは SuperSet を用いデータの可視化を行っている 【課題】 一部のレポートは外部の会社に委託して作られていたものがあり、納品時には問題がなかったものがデータの増大に伴い時限爆弾のような不具合を引き起こし正確なデータとして使えなくなった。 【工夫】 各部門から数値を算出する計算式などについて徹底的にヒアリングを行い、SQL の修正、場合によってはデータモデルそのものの再構築を行った。 【成果】 幸いレポート自体ガワは出来ているため、データモデルを構築する SQL や Power Query を業務要件に沿った形で修正することによって不具合解消、新規レポートの着手に取り組めるようになった。 新たなレポート、ダッシュボード作成のリクエストがバックログに溜まっているため、現状の人数では捌ききる事は困難と判断し、外部ベンダーに依頼し、私自身も手を動かしながら外部ベンダーのコントロールを行っている。