面川泰明

## 概要 EUの船舶排出量規制規約に対応すべく、EU圏を航行する船舶の温室効果ガス排出量を監視するためのWebサービスを開発。 ## 規模 サービス対象顧客24社、総対象船舶は2000隻。 船舶データトラフィックは１分あたり平均2KBのJSONファイルが60通届く計算。 ## 担当領域 EUの規約は大まかに以下の３つのフェーズに分かれている。 1. 航行計画登録フェーズ 2. 航行情報監視フェーズ 3. 航行情報承認フェーズ このうち、自分は2の「航行情報監視フェーズ」を担当した。 ## 具体的な作業 時系列順にまとめると、以下のようになる。 1. 規制データチェック仕様の設計～結合テスト 2. Webサービスの顧客受け入れテスト支援PMO 3. 規制データチェック仕様再定義支援 4. アプリケーションリファクタリング ## プロジェクトが抱えていた課題と、それに対する対応 ### 顧客がイニシアチブを取れるようにしよう まず顧客は、**プロパー社員でサービスを立ち上げるだけのマンパワーが不足**していた。さらに、**キッチリした工程で集団開発するノウハウがなかった**。よって、業務システム開発に必要なキッチリした工程で開発した経験がある会社へ業務をアウトソースした。自分はそのアウトソースされた会社の１人としてチームに参画した。 顧客のサービスが**Webサービスであることを考えると、顧客が運用を主導できる状態にするのが望ましい**。受諾会社にロックインさせるのはサービス提供のスピード感を向上させる意味で好ましくない。 よって、プロパー社員の残したデータチェック仕様を受け継ぎ、仕様を把握して設計に落とし込み、**ドキュメントを整備して顧客が主導権を取れるようにした**。具体的には、以下のように実施した。 - システムの全容を見えやすくした - **仕様からシステム全体のフローチャートを起こしてシステムの全容が見えるようにした**。フローチャートの起点ボックスにハイパーリンクを貼って概要設計に飛ばせるようにし、**設計されている機能が、チェック機能のどの部分にあるのかを判断しやすくした**。さらに概要設計から詳細設計にリンクを貼って、**設計書をフォルダから探す手間を省いた**。 - 設計への落とし込みについて - 船舶データの専門用語について知識がないといけないと思い、**データチェック仕様に書かれている単語を中心に毎日1時間専門知識についての学習をした**。顧客から用語集をもらったり、質問シートを作って聞いたり、ネットや図書館で調べたりした。調べた結果はデータで纏め、自分がチームリーダになったときにメンバーに展開して学習効率を向上させた。**今後同じような案件をやるときは、設計書に書いてある文言から専門用語集へ飛ばせるような、Wikipediaのような仕組みがあれば良いと思っている**。 ### 専門知識の共有をしよう データチェックには多変量解析を用いている箇所があったので、以前学習した統計の知識を使って対応できると思った。しかし顧客の開発リーダは多変量解析の知識が無かった。そこで、**プロジェクトをスムーズに進めるために顧客側の担当者と開発リーダ、自分とで認識合わせのための会議を開いた**。 会議では、担当者間で認識合わせを行い、開発リーダには議事録を取ってもらい、「必要なデータ、データ量、計算ロジック、計算ロジックの検収チェック方法、担当者と期日、タスク完了基準」を作成。開発リーダには、作成したタスクの進捗管理を行ってもらうようにした。 ドキュメントを整備し、テストまで終え、これで自分の役割は完了したと思った。**しかし、顧客はアプリの検収テストを実施できるだけの体制が整っていなかったことが分かった**。 ### 顧客の体制を立て直そう 顧客から検収テストの仕様をもらったところ、開発仕様と随分異なっていた。おかしいなと思って開発リーダとテスト仕様作成者に確認を取った。すると、**自分が作ったアプリの仕様と、検収テスト仕様を作った人が参考にした資料にズレがあった**ことが分かった。一番最初に仕様を作った顧客担当者は既に担当から外れており、しかも顧客担当は主担当が2人おり、統制を取る人物がいなかった。そのため**仕様に食い違いが起きていた**。 開発のやり直しをやるべき状況だが、アプリの基本機能は出来ているので、**テストは進めるが自分が担当したチェック機能だけ仕様から作り直しという方向に話がまとまった**。 自分はアプリ開発責任者として、顧客の作成したテスト仕様とアプリの実装を比較して、差異が出たら設計に反映して単体テストまで実施する役割になった。初期の仕様作成者は開発リーダにお願いして2人とも呼び戻してもらった。EUの規約も呼び戻した人と一緒に確認して自身のリテラシーを上げ、仕様作成担当とダブルチェックできるようにした。 そのほか、テスト進捗の作成、課題管理の主導も行った。 課題管理の方法は、スプレッドシートで管理し、「課題内容、完了基準、優先度、担当者、チェック担当者、開始日と終了日、ステータス」を確認するようにした。課題が発生したら発見者に記入してもらい、朝と夕方にチーム会議を開いて課題の状況をチェックした。担当者が埋まっていない課題は詳しい人を聞いてアサインし、課題の優先度を高、中、低で識別して高のものを優先して取り組むように促した。テスト進捗はバーンダウンチャートを作って予実管理した。 スケジュール状況としては、当初のリリースまでに3か月を予定していたが、遅れた。3か月で予定機能の30%をリリースし、その6か月後に100%をリリースした。**当初の予定の3倍の期間が掛かってしまった**。 ただ、良かったこともあった。アプリ仕様を作るところから顧客担当者と一緒に作業し直せたので、**チェック仕様にムダのあった機能を削ることができた。当初の機能数のままであればリリースまで1年以上かかっただろうと上級マネージャから言われたので、「4か月以上短縮できたのは良いことだね、ありがとう」と言ってもらえたのは嬉しかった**。 ### 情報へのアクセシビリティを考えよう 最終的には、アプリの内部実装をリファクタリングして簡略化させ、ドキュメントも再整備した。**どこに何が書かれているのか、どうやったらアクセスしやすい資料になるかまで含めて整理した**。 例えば、システムフロー図を作って全体の流れを理解させるようにし、機能を意味するブロックに設計図のハイパーリンクを貼ってアクセス効率を上げ、設計書には処理の流れを書くだけではなく、処理の目的や「なぜこの設計を選んだか」を書くようにして、当時の意思決定をどのように行ったかが分かるようにした。 ## まとめ マンパワーが足りないということは、転じると、主担当者が変わりやすいプロジェクトということでもある。そのようなプロジェクトにおいて、**アプリケーションの全体を見て取れる形にして属人化を防ぎ、顧客のリテラシーを高めて受諾会社にロックインされないような自立した体制を作ることに貢献した**。

## 概要 GoogleアナリティクスAPIを使い、コンバージョンに寄与する指標データを特定。 **データをどれくらい変動させると、どのくらいコンバージョンが向上するかを統計解析して表示する。Webマーケターのための意思決定支援サービス**。 コンバージョンの寄与率と、コンバージョンの変動率の2軸で優先度を定義し、**施策の効果が高い順にランク付けできる**ようにした。 さらに、外部のDBデータと連携して、Web以外のデータ（たとえば業務システムのDBデータ）を指標データとして取り込めるようにした。これにより、**オンラインデータとオフラインデータの連携ができる**。 ## 経緯 知り合いのWebマーケターに誘われ、起業したときに開発したもの。 **マーケターが企画とデザインを担当し、自分はそれ以外のすべてを1人で担当**した。 ## 担当領域 要件定義～運用保守。営業。 ※　結局サービスインまで出来なかったので、運用設計まで。 ## サービス開発の流れ 時系列順にまとめると、以下のようになる。 - バージョン１。時系列式データ分析 - バージョン２。２軸で優先度をランク付けし、ローカルデータ取り込み機能を実装 - バージョン３。統計解析の精度を向上。 **バージョン３の開発中、Googleアナリティクスにコンバージョンに寄与する指標データをレコメンドする機能が実装されたため、開発を断念**した。 ## プロジェクトが抱えていた課題と、それに対する対応 ### 開発のスピード感 人が足りないので増やそうと思ったが、人を増やして解決できるほどサービスが固まっていなかったため断念。代わりに、**インフラの面倒を見る手間を削減するためにHerokuを導入**した。 サービス開発当時は業務インフラ構築を専業にしていたため、**アプリ開発の知識が無かった。そこで、学習障壁が低いと当時言われていたRubyOnRailsを学習し、Railsチュートリアルと呼ばれるチュートリアルサイトを一通り学習して基礎中の基礎を学習したところでサービス開発に入った**。 日中はSESで情報通信サービスの統合テスト設計案件をしていた。そのため、時間を確保するために早朝や夜、休日を使って開発に充てた。 ### 問題共有 密にやりとりをすべく、QA表を使って事前に問題を絞りこみ、図を描いて可視化し、**マーケター観点とエンジニア観点の齟齬を無くすように努めた**。 また、当時は経費削減のためにオフィスを構えておらず、予約制の会議室を主に使って会議をしていた。相場は1時間500円や1000円が多く、プロジェクタやホワイトボードがセットで付いていると有難かった。今なら、SlackやTeams、Googleハングアウトを使って直接画面を見ながらやりとりできただろう。 ### 応答性能の向上 データ解析のためにAPIリクエストを沢山する必要があった。一つのリクエストでまとまったデータを取得してくるよりも、**クエリが複雑になることを恐れた**のでリクエスト回数を増やすことで対応した。そうしたらデータ表示までに3分も掛かってしまった。これは良くない。せめて1分くらいまで時間を絞りたい。 ということで**APIリクエストはparallel gemを使って並列化した。ただしそのままだと並列化したリクエストの完了をUI側でキャッチできないので、jQueryのタイマーでリクエスト結果のJSONをチェックし、想定したデータ構造になったら表示させることでデータの整合性を担保した**。 また、いったん表示した内容を画面遷移後にもう一回観るときに、APIリクエストをもう一回すると応答性能が悪いので、**同じリクエストがあった場合はmemcachedにキャッシュした結果を返却するようにした**。 ### 営業 興味を持ってもらえるマーケターの知り合いをピックアップして営業メールを送ったところ、反応をもらえた。企画の人と一緒に客先に赴いてにデモをした。しかしデモに使う自社のGoogleアナリティクスデータが非常にアクセスが少なかったため、大した結果にならなかった。APIアクセス箇所のみデモデータを用意すればよかったなと反省。しかし営業のあと、デモを見せた先から、「ぜひ開発に協力させてほしい」ということで、業務サイトのGoogleアナリティクスアカウントを提供してもらった。これで、**業務データを使った細かいケースのテストが出来るようになった**。 ### 分析精度の向上 ある程度サービスが形になったところで、分析精度の向上について問題が上がった。コンバージョンの寄与率と指標の変動率の2軸で施策効果を決定していたが、分析精度が弱い。というよりも、**分析にもっと説得力が欲しい**ということになった。 これまでの分析ロジックでは、結果は出せても、「結果のもっともらしさ」まで出すことは出来なかった。そこで、この「**結果のもっともらしさ」を加えた3軸で分析精度を上げてゆこう**という流れになった。 しかし、そのためには統計学の知識が要る。最低でも、主要な分析ツールを使う知識とそれをWebサービスに応用する形にできるくらいのプログラミングスキルが必要になった。そこで、**R言語と統計学の基礎を同時並行で学習した**。 R言語は、金明哲の『Rによるデータサイエンス』を中心にタイピングしながら学習した。統計学の基礎については、永田靖の『多変量解析入門』で基礎を学んだ。 その後、Useful Rや、Rで学ぶデータサイエンスを読み漁り、KDD(Knowledge Discovery in Databases)というデータ分析プロセスの手法をベースとして、分析手法を確立していった。分析の設計プロセスは以下の通りに実施した。 1. まずは分析方法・分析結果の見方を学ぶ。 2. 分析結果の見方を学んだ後は、分析精度の向上方法を学んでいく。 3. 学習結果によって知見が大きく変動する可能性が高いため、設計は毎日見直す。 4. 「その分野の広く知られている方法」を一通り学習、手順化し、手順化までの流れを掴む。その後、発展的な方法を学習、手順化してゆくことで、知見を深めてゆく。 学習計画はWBSを作り、詳細化して逐一結果をスプレッドシートにまとめて管理していった。 最終的にリリースまで至れなかったことは残念だ。 ## まとめ **Web解析の知識、アプリ開発の知識、統計学の知識、営業活動、など、すべてほぼゼロベースから知識を吸収して形にした**。外部委託という選択肢もあったが、新規サービス開発ということでコミュニケーションコストが掛かってしまうことを考えると、たとえ１人でもコミュニケーションロスは少なかったように思う。 しかし、外部委託という選択肢や、知り合いに頼むといった方法もあった。自分にはそれが出来なかった。かろうじて出来たのは、コワーキングスペースに行ってアプリ開発の有識者に話を聞いたりすることや、勉強会に参加して知識を得るだとか、それしかできなかった。 しかし、自分はこの経験で、**アプリ開発における孤独のつらさ、仲間の大切さ、ディスカッションをすることで頭がどれだけクリアになるかを学んだ。エンジニア領域でない人とコミュニケーションの仕方を工夫することがサービス開発においては柱となることも身に染みて分かった**。というわけで**組織としてバリューを出すことに強い憧れを抱くようになった**のである。