ID:77863さん

【プロジェクト概要】 データサイエンティストが事前に PoC をして精度の良かったアルゴリズムモデルを使って、顧客でも試行錯誤できる学習環境の構築。 【担当フェーズ】 提案～システム構築まで。 【業務内容】 ・プロジェクトのまとめ ・全体アーキテクチャを設計 ・パイプラインの構築 ・データサイエンティストを開発に巻き込み、インタフェース設計の折衝 【実績・取り組み等】 ・顧客の要望もあり、アジャイル開発風で進めた(スパイラル開発)。経験者がいないため進め方を先導した。 ・データサイエンティスとエンジニアの連携が、この会社では常に課題となっていた。問題点を整理して、データサイエンティストと役割分担を折衝し、完走できた。 ・Vertex AI Pipelines をこの会社で初めて案件で実用利用した。 ・設計書ドキュメント作成に工数をかけず、代わりにマニュアルをしっかり作りこむことで、内外の関係者への情報統一ができた。 ・会社としてのレビュー制度や品質制度がなかったため、自発的に社内お披露目会を設け、社内関係者と意思統一を図ったうえで、逐次顧客に提供をした。 ・要件定義を細かく決めすぎない代わりに、逐次顧客からあがる要望に対応した。 ・Google サポートを積極的に利用して、解決を図った。 【課題・問題】 ・メンバーがシステム開発未経験 →情報の透明性(全体図)、役割の明確化、タスクの明確化、密な会話(朝会)を計画 とにかく 1 回目の MVP 作成に注力 →MVP 提出後は、開発サイクルのリズムが出来て安定した ・新人が途中で離脱 →社会人意識が欠けていたため、内省を促した(問いと回答の繰り返し) →結局、案件中には改善しなかったが、上司には感謝された 新人教育にはなっていたため ・想定外にマニュアル作りの工数が膨らんだ 顧客がそのまま現場に渡せるレベルのマニュアルを期待し出したため しかし本来はそういうものじゃなく対面メンバー向けという話だった →幸いにも開発後半は余裕があったので、可能な限り要望に応えた。 ・9 月に長期休暇(夏季休暇)取得予定だった →全メンバの休暇予定+予想を加味してスケジュールを立てた。 →休暇中特に何事もなかった。 →随時リリースしていたため、顧客も進行度に心配を持っていなかったと推測。 ・開発に集中するため週定例をやらず、代わりに Backlog による週報を出した。 →そもそも顧客にはその時点で動くものをリリースしているため、問題なく進められた。週定例はないが必要に応じた打ち合わせのみ行った。 ・当時の Vertex AI Pipelines では、GPU を起動パラメータ指定で変えられないことが途中で発覚した。 →Google サポートに問い合わせるも「出来ない」という回答 →代案として全 GPU 分の分岐を作って対応 結果、フローが見づらくなってしまった →顧客には承諾いただき、将来課題となった(Google 対応待ち) 【貢献】 ・社内案件で初の Vertex AI Pipelines 採用実績(のはず ・データサイエンティストと協業しての開発をスムーズに完遂した(いつもトラブル要因だった) 進め方の事例を築けた ・最終的にできたプロダクト(マニュアル含む)は顧客に好評で、顧客からの信用度を上げられたと推測。 【得た知見】 ・完全なアジャイル開発ではないが、スパイラル開発でも様々なリスク回避が行えた。 ・MVP で作業 1 巡することで、その後がスムーズに進む(1 巡目が大変だが、問題があっても対応する時間がいっぱいある) ・何度も全体結合するため、問題がプロジェクト期間の前半までに洗い出しやすい。その為顧客との交渉時間が持てる。 ・大事な作業から着手できるので、大事な作業を落としにくい。優先度が低い作業(デプロイの完全自動化等)が出来なかったりしたが、言い換えれば、そのおかげで大事な作業は完遂できた。 ・要件定義書のほかは、マニュアルしかドキュメント作成をしていない(プロダクト提供物として) →マニュアルは外部仕様書、外部テスト仕様書になることを実証できた(トムデマルコ著「デッドライン」の内容を実践) 【開発環境】 GCP Vertex AI Pipelines Docker Python Cloud Build ほか 【役割／担当／規模】 【役割】プロジ ェク トマネージャー 【プロジェクト規模】4 人

【プロジェクト概要】 Azure から GCP への移行 【担当フェーズ】 アドホック分析環境部分の要件定義と構築。 【業務内容】 ・顧客調整（説得、事前調査、会議資料作成、会議） ・Google と調整。 ・手順書作成。 【実績・取り組み等】 ・顧客が事前に想定していた方法が出来ないとわかり、代案の新相だしとその実現性の検討。様々な選択肢がある中でどうしてそれが推薦となるかの説得材料作成。 ・解決のために、社内社外に助けを求めながら形にしていった。 【課題・問題】 ・12 月から参加予定だったが、急に前倒しで参加することになった しかもなぜか予定より遅れていると言われている状態で始まった →ひとまず、先が見えない中で、キックオフ資料（会議予定）を作ったプロジェクトのキャッチアップは後回しになったため（結局最後までその時間はなかった）、既存メンバーに協力を取り付けた → 最 初 の 会 議 で 、 顧 客 が 利 用 を 想 定 し て い た Vertex AI Workbench が、想定通りに使えないことに、顧客から激しい指摘を受け、予定が全て崩れた。 ・顧客が利用を想定していた Vertex AI Workbench が、想定通りに使えないとわかった。当時 Vertex AI Workbench は VPC Service Controls はサポートしていたが、Access Context Manager 未サポートだったため。そのため特定外部 IP からアクセスすることがサポート外だった。 →急遽代替案を洗い出し、その中でも有力そうな GKE Autopilot でJupyter（または JupyterHub）を動かす案の検証作業を行った。 →年内に比較検証結果を提示し GKE Autopilot 案で進みそうだったが、年が明けたら、ひっくり返され、再度比較検証することとなった →上司にも相談し、「本来はこういう分析環境はマスクデータを使うものだ」というそもそも論も出すことにした。 →そもそも論が顧客の特別顧問に認められ、当初通り、Vertex AI Workbench を使う方向となった。 ・1 月末に長期特別休暇（慶弔休暇）を取得予定だった（ずっと前から決まっていた） →色々揉めて冷や冷やした状況だったが、常に文書を残して、引継ぎできる状態で進めた。 →運よく何も起きなかった ・Google Cloud 側の不具合で、環境が使えなくなった →プロジェクトについていた Google サポーターと、Google サポート窓口を両方フル活用して、解決を図った。 →結局、Google 側の不具合修正がリリースされるまで解決しなかった。（回避策もなし） 【貢献】 ・Google Cloud（特に Vertex AI 関係）の有識者として立ち回れた。 【得た知見】 ・VPC Service Controls サポート、Access Context Manager 未サポートというケースがありうることを知った。 （ウォーターフォールではなく、MVP から始めていれば大ごとにならなかったのにという思いはある） 【開発環境】 GCP Vertex AI Workbench VPC Service Controls Access Context Manager ほか 【役割／担当／規模】 【役割】メンバー 【プロジェクト規模】10 名以上

【プロジェクト概要】 公共機関（ガス会社等）の請求書などの帳票出力に使用する大型システムプリンタの開発。クライアントマシンから受け取った印刷データを、プリンタに渡すプロセスの開発を行った。 データのやり取りに様々な方法を使用した。プリンタドライバとの ioctl アクセス、スレッド間通信、プロセス間通信、ソケット通信。 エクストリーム・プログラミングを導入した。UML、デザインパターン、cppUnit を使ったユニットテストなどの改善活動も同時に行った。エクストリーム・プログラミングで適用したプラクティスは、反復、共通の言語、開けた作業空間、回顧、テスト駆動開発、ペアプログラミング、リファクタリング、継続した結合、YAGNI、最適なペースの仕事、ストーリーの作成、リリース計画、短期リリース。 Linus ディストリビューションは Redhat.ビルドツールは gcc、libtool、makle を使用。ビルド支援ツールにシェルスクリプトと Ruby を使用。情報共有に Pukiwiki を使用した。リリースコード上で boost が使用出来なかったため、shard_ptr など、boost にあって、STL にないものは、仕組みやインタフェースを参考に簡易版を自作した。 アーキテクチャとして、Service Locator パターンを使用。これにより、モジュールの部品化（祖結合）が大幅に進んだ。部品化が進んだために、ユニットテストの質が向上、ユニットテストの質向上により、リリースコードの品質向上に繋がった。 ユニットテストでは、Mock オブジェクトや Recorder パターンを使用して、網羅率の向上とユニットテスト自信の祖結合を進めた。これにより変更によってユニットテストが壊れる可能性を下げた。改善活動結果として、結合検査以降の障害発生が殆ど無かった。仕様変更を含めた修正発生時も、素早く対応することが出来た。これは、障害状況を単体環境で再現しやすく、問題箇所の特定、修正やリリースも容易に行える環境になっていたため。また常時結合を実践していたため、急なリリース依頼（現時点の最新が今欲しいという要求等）も 1 時間以内に対応するなど、素早く行えた。 結合フェイズ時には、直接関係のない部分についても率先して解析作業を行って情報展開した。 それらが認められ、その後は進め方について相談されたり、進め方の質問をされるようになった。またシステム全体の改善活動としてユニットテストが採用された。 その後も改善活動を続けつつ、チームの新メンバへ上記改善活動の教育を実施した。 【担当フェーズ】 調査分析、基本設計、詳細設計、製造、テスト 【業務内容】 システム開発 【実績・取り組み等】 システム開発 【課題・問題】 ・エクストリームプログラミング（XP、アジャイル）の本格的な実践が初めて →キャッチアップをとにかくした →テストファーストを心掛けた →その結果、テストしやすい設計になり、デザインパターンを適用しやすくなった また新しく覚えたコーディング手法をテストコードで気軽に試すことが出来、プロダクトを作りながら学習も進んだ。そして動作確認できた手法を本番コードにすぐ使えるようになり、ますます品質向上につながった。 【貢献】 ・テストコードで単体テストをがっつりやった結果、ほぼ自責不具合なしという結果をだせた（他は 200 件以上、かつ半年以上遅れ） 【得た知見】 ・エクストリームプログラミング（XP、アジャイル）の実践知見を大いに得た。ただ実質一人開発だった。 【開発環境】 【OS】Windows2000、Linux 【言語】C++ 【フレームワーク】STL boost pthreds 【DB】 【その他 ミ ドル ウェア、サーバー等】cppUnit gcc、libtool、makle Pukiwiki シ ェ ル ス ク リ プ ト 、Ruby 【役割／担当／規模】 【役割】 【プロジェクト規模】要員 2 名（全体 20 名以上）

【プロジェクト概要】 衛星の撮影計画立案受付、衛星データの提供・保存システムの構築。 上位システムである立案システムの試験用シミュレータ及び異なる SOAP通信を中継するプロセスの開発を行った。通信には SOAP を使用。 SOAP の実装は Java の JAXM、JAX-WS を使用し、JAXM とJAX-WS 間のデータを繋ぐために JAXB を使用した。 OSS として、Apache HTTP Server、Apache Tomcat、Apache Axis2、Trac Lightning、Jenkins、Nexus、Apache Maven、Google Web Toolkit、Seasar2 を使用。社内環境を構築した。ユニットテストには JUnit を使用した。そのほか、REST(OSS は Jersey を使用）を使った通信部分を作成した。 また社外での試験環境構築支援を行った。その際には追加 してOpenAM、OpenDS、squid、zabbix、monit といった OSS を扱った。 【担当フェーズ】 その他（シミュレータ開発）、製造、インフラ整備 【業務内容】 ・シミュレータ開発。 ・REST 通信部分の開発。 ・結合試験環境、運用環境の構築支援。 【実績・取り組み等】 ・技術的に実現方法が不明（社内にも経験者無し）な部分を担当し、実現方法の調査と、裏付けを取るためのプロトタイプ作りをしつつ開発を進めた。 【課題・問題】 ・新しいことだらけでキャッチアップが大変 →Wiki を使って、プロジェクトナレッジをためた。 ・CI を実践し、エラーがあれば即修正を依頼した（アウトソーシング分も含む） →かなり抵抗があったが、このおかげでリスク洗い出しを前倒しできた。 【貢献】 ・バージョン管理、Seaser2 や、CI 環境の提案を行い、自ら構築して、運用した。 【得た知見】 ・新しい技術スタックの知見を得た。 【開発環境】 【OS】Windows Linux 【言語】Java、XML 【フレームワーク】Seasar2 、Google Web Toolkit、JAXM 、JAX-WS 、JAXB、JAXP 【DB】PosgreSQL 【その他 ミ ドル ウェア、サーバー等】Subversion、Apache HTTP Serve、Apache Tomcat 、Apache Axis2、Trac Lightning、Jenkins 、Nexus 、Apache Maven 、OpenAM 、OpenDS 、squid 、zabbix 、monit 【役割／担当／規模】 【役割】メンバー 【プロジェクト規模】要員 4 名（全体 20 名以上）

【プロジェクト概要】 所属本部の取り組み。部門間での交流機会の創出と、最新テクノロジーへのキャッチアップを目的に活動。 【担当フェーズ】 なし 【業務内容】 ・隔週でミーティング。 【実績・取り組み等】 ・２年目と３年目でリーダーをやった。（Snowflake 好きを見込まれて） ・自分がリーダーの時はメンバーに無理強いせず、モチベーションドリブンで進めた。また、本部内に閉じずに全社向けにオープンに開催し、他本部からも気軽に参加できるようにした。 ・３年目に切り替わるとき、SnowflakeG だけ、全員継続参加希望だった。 ・活動中に、Snowflake 案件も立ち上がり、案件からの経験 FB もいただいた。 ・Snowflake との企業間パートナーを締結でき、Snowflake の再販が可能になった。 【課題・問題】 ・誰も Snowflake を知らない →会の目的は、Snowflake を知る事、認知を広めることにした →参加の敷居が下がり、継続しやすくなった →自社のテックブログに記事を掲載できた 【貢献】 ・参加メンバーが、Snowflake の実案件（JR 九州）を担えた。 ・参加メンバーの協力で Snowflake パートナー（再販可能）になれた。 【得た知見】 ・Snowflake は自分好み。 ・Snowflake はおそらく DWH のトップランナー。 【開発環境】 Snowflake 【役割／担当／規模】 【役割】メンバー→リーダー 【プロジェクト規模】10 名超

【プロジェクト概要】 データ基盤の構築。 【担当フェーズ】 基本設計～実装 【業務内容】 ・キャッチアップ。（ほぼ初めてのことだらけだったため） ・ジョブフローの設計と実装。 ・メンバーフォロー 【実績・取り組み等】 ・タスク管理ソフトに Rundeck を推奨し採用された。 【課題・問題】 ・Talend の有識者がいない →可能な限り事前にキャッチアップした。 →結局、プロジェクトの開始が遅れて、十分にキャッチアップできた。 ・メンバーがシステム開発初経験 →隣の席に座って、OJT のように接した。 →飲み込みが早く、社会人経験はあったため、特に面倒なことはなく、まじめにやってくれ、特定箇所を専任できるほどの戦力になった。 ・顧客からデータが送られてこず、スタートできない しかも一括請負だったため「まずい」状態になった →自分から PM にまずいと伝えても相手にされなかったため、知り合いの営業を通して話を通してもらった。 →PM もことの大事さを理解し、顧客とスケジュール調整をして事なきを得た。 【貢献】 ・タスクツールを PM が迷っていたため（Windows タスクを使おうとしていた）、自分で調べて Rundeck を提案、採用された。 ・Talend や SendGrid、Pardot など、やってみるといろいろ問題があり、自分がベンダーサポートに問い合わせするなどして解決した。 【得た知見】 ・GCP は、メールサーバーが使えない。GCP にメールサービスもないため、SendGrid を使うことが推奨されている。 ・気が付いたら、案件が終わる事には、社内で一番 Talend に詳しい人になっていた。 【開発環境】 GCP GCE CloudSQL PostgreSQL Talend Rundeck Java Sendgrid Tableau Pardot Salesforce 【役割／担当／規模】 【役割】リーダー 【プロジェクト規模】3 名

【プロジェクト概要】 システム監視。定常保守対応、非定常保守対応。 【担当フェーズ】 システム運用保守 【業務内容】 ・キャッチアップ ・日々の監視。（朝昼の定時バッチ監視） ・月次レポート作成。 ・AWS 由来のメンテ作業。（リタイア通知対応等） ・トラブル対応。 【実績・取り組み等】 ・キャッチアップがとにかく大変。前任者がほぼ不在、頼りになるドキュメントもなく、ソースコード管理もされていないため。 ・基本的に日々監視のみ。（何もトラブル無ければ） ・必要に応じて顧客とのメール連絡。（ほぼ定型文） ・パフォーマンス改善の提案と実施。 【課題・問題】 ・作った人がほぼ残っておらず（少なくとも全体像を知る人がいない）、信頼できるドキュメントも少ない →ソースコード解析 →CRUD を作った 後日の調査業で重宝した ・特定タスクが重く、時々長時間化してバッチ時間を突き抜ける →ひたすら調べて、とある方法をみつけ、タスク時間の短縮と安定化を同時に実現した。 ・RDS のメジャーバージョンアップする際、バージョンアップの前後結果の比較が必要だった（テストコードもテスト仕様書もないので） DB ダンプをしてひたすら比較するがとても遅い →Athena で比較することを提案 →手間と作業時間を大幅に減らした（丸 2 か月以上→2 週間程度） 【貢献】 ・かなり不安定で、毎日手間のかかるバッチ処理が、非常に安定して手間がかからなくなった。ほぼメールチェックのみでいけるようになった。 ・少なくとも自分がかかわった範囲のものは、ドキュメントを残した。 【得た知見】 ・AWS の利用実績を得た。 ・PostgreSQL の利用実績を大量に得た。 【開発環境】 AWS Linux Windows PostgreSQL Bash Hinemos JIRA Python C# R Athena ほか 【役割／担当／規模】 【役割】リー ダー 、メ ンバー 【プロジェクト規模】1～5 人

【プロジェクト概要】 社内のナレッジ蓄積と活用の環境整備と啓もう活動。 【担当フェーズ】 なし 【業務内容】 ・記事の充実と、記事掲載や査読への誘導。 ・ケーススタディ会の開催など。 【実績・取り組み等】 ・社内コンフルに PV カウンターを設置。 【課題・問題】 ・どうやって盛り上げていくか →イベント開催（ケースメソッド勉強会など）をして、巻きこみをしていった →開催のたびに PV が伸びた 【貢献】 ・この活動が終わっても、たまったナレッジは引き継がれ、本部で運用されている模様。 【得た知見】 ・ナレッジはトップダウンと、ボトムアップの熱量の両方がないと難しい。事実、この活動は全社活動ではなく 1 本部での活動にとどまった。また知見はちゃんとしたデータ化されておらず、利活用が難しいものだった。（DX とはいいがたい） 【開発環境】 Confluence Google Analytics Google Data Portal 【役割／担当／規模】 【役割】メンバー 【プロジェクト規模】10 名超

【プロジェクト概要】 LP ガス配送ルートを最適化するシステムの構築。他ベンダーからの引継ぎ案件。 【担当フェーズ】 実地検証のための仮実装中 【業務内容】 ・バラバラになっている実装コードを Azure ML Pipelines 上で動作できるよう構築しなおし。 【実績・取り組み等】 ・Azure ML Pipelines の基本から調査。挙動不審な箇所をマイクロソフトサポートとやり取りして調査。 ・パイプラインとしてつながるようソースコードの追加修正と、ひたすら動作確認。 【課題・問題】 ・Azure 案件初めて →ひたすらキャッチアップした 周囲の協力も仰いだ ・通知漏れが発生することがあった →マイクロソフトサポートとやり取りして調査。 →結局時間経過（2 か月ほど）で再現しなくなり、自然解消となった。 【貢献】 ・予定より早く終わり、後半はほぼ待機状態。細かい質問への回答とアドバイスをしていた。 【得た知見】 ・この時点では「Azure ML Pipelines」も意外に使いやすいとわかった。特にインスタンスの起動は「Google Vertex AI Pipelines」より確実に早い。 【開発環境】 Azure ML Pipelines Python Kubernetes ほか 【役割／担当／規模】 【役割】ヘルプメンバー 【プロジェクト規模】10 人超

【プロジェクト概要】 LP ガス配送ルートを最適化するシステムの構築。他ベンダーからの引継ぎ案件。 【担当フェーズ】 実装中 【業務内容】 ・障害原因調査 【実績・取り組み等】 ・キャッチアップ。 ・再現環境がないため、状況資料とソースコード解析から論理展開して、原因と思われるものを提示。関係者に納得いただいた。 【課題・問題】 ・障害状況を再現できない →ひたすらログとソースコード解析で推測を立てていった →どこまで行っても推測だが、納得してもらうための論理展開を考え、顧客に納得してもらった。 【貢献】 ・予定より早く終わり、後半はほぼ待機状態。細かい質問への回答とアドバイスをしていた。 【得た知見】 ・TypeScript も Go も全く知見がなかったが、意外に読めた。 【開発環境】 Python TypeScript Go ほか 【役割／担当／規模】 【役割】ヘルプメンバー 【プロジェクト規模】10 人超

【プロジェクト概要】 Dataprep と AutoML Tables の使い勝手を検証。 【担当フェーズ】 検証 PoC 【業務内容】 ・Dataprep、AutoML Tables をつかって、用意されたお題を実際に操作し、レポートを作成。 ・ツールを取り入れる前提での概算見積もり作成。 【実績・取り組み等】 ・同上 【課題・問題】 ・なし 【貢献】 ・顧客のレポートへの納得感には貢献できたと思う 【得た知見】 ・Dataprep は日本ではほぼ無名だが、ポテンシャルはあると感じた。 【開発環境】 GoogleDataprep AutoML Tables Bigquery ML ほか 【役割／担当／規模】 【役割】メンバー 【プロジェクト規模】3 人