面川泰明

2021年4月回 指名 (未返答 : 0/0件)年収を見るには?


まだ何もありません

自己推薦一覧

自己推薦はありません

あなたを気にしている企業

  • フォトラクションが面川泰明のレジュメを見ています。

    2021.04.20 22:41
  • noteが面川泰明のレジュメを見ています。

    2021.04.20 21:11
  • Seibiiが面川泰明のレジュメを見ています。

    2021.04.20 20:05
  • Lectoが面川泰明のレジュメを見ています。

    2021.04.20 17:09
  • ラクスルが面川泰明を見てメモをしました。

    2021.04.20 14:57
  • ラクスル面川泰明のアウトプットのURLを見ました!

    2021.04.20 14:51
  • ラクスルが面川泰明のレジュメを見ています。

    2021.04.20 14:47
  • AppBrewが面川泰明のレジュメを見ています。

    2021.04.20 13:57
  • ユーザベース面川泰明のSpeakerDeckを見ました!

    2021.04.20 09:51
  • ユーザベースが面川泰明のレジュメを見ています。

    2021.04.20 09:51

3年後の目標や野望


組織の力を最大化したい

## そう思う理由 勉強会の出会いで、仕事の課題を解決できた経験が沢山あります。 ずっと客先常駐の仕事をしてきたので、人と協力して仕事を進めることの大切さを知っています。 ## 具体的にやりたいこと 具体的には、デザイナーや営業などの第三者との意見交換を積極的に行い、良い問題解決のできる組織を作りたいです。 例えば、私がキャリアマッチングサービスを作っていて、付加価値を高めたいと思ったとします。 エンジニア目線だと、精度の高いレコメンドエンジンを作りたくなります。 しかし、それはユーザにとって価値のあることなのでしょうか? マッチングサービスを使う方は、既存の仕組みに納得できず、自分で考えて行動する方が多いと思います。 ならば、精度の高いレコメンドエンジンを作るより、キャリアカウンセリングサービスを提供した方良いのではないでしょうか? なぜなら、「自分で考えて行動し、前に進んでいる実感」を得られることが本当のニーズだと思うからです。 ただし、あくまでこれは私の仮想にすぎません。 真のニーズを把握するには、立場の違う人の意見が必要です。 私は、意見交換を積極的に行える組織づくりをしていきたいです。

年収評価シート

2017年/2年以内

船舶排出量データ監視サービス開発プロジェクト

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

2014年/2年以上

Webアクセスデータ分析サービス開発

## 概要 GoogleアナリティクスAPIを使い、コンバージョンに寄与する指標データを特定。 **データをどれくらい変動させると、どのくらいコンバージョンが向上するかを統計解析して表示する。Webマーケターのための意思決定支援サービス**。 コンバージョンの寄与率と、コンバージョンの変動率の2軸で優先度を定義し、**施策の効果が高い順にランク付けできる**ようにした。 さらに、外部のDBデータと連携して、Web以外のデータ(たとえば業務システムのDBデータ)を指標データとして取り込めるようにした。これにより、**オンラインデータとオフラインデータの連携ができる**。 ## 経緯 知り合いのWebマーケターに誘われ、起業したときに開発したもの。 **マーケターが企画とデザインを担当し、自分はそれ以外のすべてを1人で担当**した。 ## 担当領域 要件定義~運用保守。営業。 ※ 結局サービスインまで出来なかったので、運用設計まで。 ## サービス開発の流れ 時系列順にまとめると、以下のようになる。 - バージョン1。時系列式データ分析 - バージョン2。2軸で優先度をランク付けし、ローカルデータ取り込み機能を実装 - バージョン3。統計解析の精度を向上。 **バージョン3の開発中、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解析の知識、アプリ開発の知識、統計学の知識、営業活動、など、すべてほぼゼロベースから知識を吸収して形にした**。外部委託という選択肢もあったが、新規サービス開発ということでコミュニケーションコストが掛かってしまうことを考えると、たとえ1人でもコミュニケーションロスは少なかったように思う。 しかし、外部委託という選択肢や、知り合いに頼むといった方法もあった。自分にはそれが出来なかった。かろうじて出来たのは、コワーキングスペースに行ってアプリ開発の有識者に話を聞いたりすることや、勉強会に参加して知識を得るだとか、それしかできなかった。 しかし、自分はこの経験で、**アプリ開発における孤独のつらさ、仲間の大切さ、ディスカッションをすることで頭がどれだけクリアになるかを学んだ。エンジニア領域でない人とコミュニケーションの仕方を工夫することがサービス開発においては柱となることも身に染みて分かった**。というわけで**組織としてバリューを出すことに強い憧れを抱くようになった**のである。

マネージメント能力

アプリ開発チーム テスト推進チーム
アプリ:  スケジュール通りに成果物を作成すること。 テスト:  テスト計画に対して実績がどうであったか可視化すること。  欠陥が見つかった場合は担当者の割り振り、一覧化、状態管理をすること。  対処する欠陥の優先順位を関係者と調整して決定。
可視化をするためには、状態を誰でも見て取れる形にして、マネージャーだけが全体を確認できる状態であってはならないと考えた。 しかし、組織を観察するためにはそれなりに時間がかかる。 自分は口下手である。表情が豊かなわけでもない。初対面の人には、ぶっきらぼうな印象を与える。 要するに**とっつきにくい**のだ。 そんな中でどう立ち回ったか? まず、オフィスには誰よりも先に来るようにした。そしてなるべく長い時間を過ごすようにして、業務をこなしつつ周りの人間関係を観察することに徹した。さらに、一日一回は絶対に誰かと一緒にご飯を食べるようにした。可能なら飲み会の席も設けた。 要するに、組織で誰かと一緒に居る時間を単純に増やした。 相手の警戒心を解くにはそれしか出来ることがなかった。 そんなことをしているうちに、実際の作業をどうしたら良いのか、問題解決の方法が見えてきた。 作業をやるときは、「なるべく作業を単純作業にまで分解」することを意識した。自分のタスクを、なるべく他人に割り当てられるようにするために、有識者を無理やりにでも詳しい領域から引きはがしてもらい、担当者以外の人とツーマンセルで作業にあたってもらうようにした。そのさい、互いの専門領域を交換して作業にあたってもらうようにした(当初はかなり嫌な顔をされたが、それでも頼み込んだ)。

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Speaker Deck アカウント
あり
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

- バックエンドのチューニング技術(効率的なSQL、アルゴリズムとデータ構造、OS機能とプログラムの連携箇所の理解) - ビジネスとエンジニアリングをつなぐための技術 - カウンセリング技術 - 自己認識の技術 - メンタル強化の技術 - 相手の前提と状況を分析して、何を欲しているか察する技術

エンジニアとして影響を受けた本を教えてください

- ピープルウェア - コードコンプリート - スーパーエンジニアへの道 - 熊とワルツを - アドレナリンジャンキー - ワインバーグ「ソフトウェア文化を創る」シリーズ全4巻 - リーダブルコード - SQLアンチパターン - 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

- 特に役割がキッチリ決まってない環境。 - 静かな時と騒がしい時がキッチリ分かれている環境。 - 昼寝ができるスペースのある環境。 - 他者の意見を面白がり、自分の意見との違いを楽しめる環境。

キャラクター

直近で一番やりたいこと
組織を作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 分析力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
金融 / 広告 / ゲーム / アダルト
その他の特徴
使用言語にはこだわらない / 起業/創業期のベンチャーにいた / 多職種のバックグラウンドがある / OSSのコミッターである
その他のやりたいこと・やりたくないこと

違法多重派遣をやりたくない。
ワンオペをやりたくない。
尊敬できない人と一緒に働きたくない。
仕事仲間の幸せに繋がらないことをやりたくない。

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
Visual Studio Code
希望勤務地
東京都 / 福岡県
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

面川泰明
今年で30代中盤
Visual Studio Code
参加ステータス
参加中
参加回数
7回
累計平均提示年収
528 万円
SIGN UPSIGN IN


このサービスを友人に薦めたいですか?