読者です 読者をやめる 読者になる 読者になる

2017年に利用していく技術領域

2016年6月16日にレクミーキャリアをリリースして約半年、会員登録したユーザーさんへのマイページの提供や、裏側のキャリアアドバイザーさんが業務を回すための予約管理やユーザー情報把握の仕組みなど、必要最低限の機能は提供することができたと思います。 recme-career.jp

現在レクミーキャリアの開発メンバーは2名ですが、まだまだユーザーさんへの価値提供のために必要なものは多く、今後利用者も増え開発エンジニアが増えていく前に構築しておくべき技術領域を整理しておこうと思います。 ここ半年間、大きな負債を残すことなく開発を続けてこれた反面(負債を少なく保つために心がけたことは別途記事にします)、以下のような箇所はまだまだ改善ができると考えてます。

  • データ分析
  • インフラ
  • フロントエンド開発
  • スクラム開発

データ分析

新卒側のレクミーのマネージャーをしていた頃、データ分析の必要性を感じTableauの導入を行いましたが、その後社内にTableauを利用する文化を育てることができず頓挫してしまったという経験があります。 Tableauがやや重量級で、使いこなせなかったという理由はなくは無いが、それより日々の業務に直結するユースケースを提供して、データを分析することによってユーザーさんへの価値が向上する・そのためBIツールをこう使っていこうというストーリーを提供しきれなかったのがメインの理由だとは考えてます。 Tableauを再トライするのか、もっと簡単なデータ可視化ツールなどを提供していくのかはまだ決めてませんが、社内でデータ分析を行いユーザー理解を深める機運は一つ作っていきたいと考えてます。

また、ユーザー行動/基本情報から特徴を把握して、より適切な求人情報を提供するための仕組みを提供することも1つのミッションに掲げていこうと考えており、手段が目的にならないように気をつける必要はありますが、SparkでPython使って高速に特徴抽出を行ったり、機械学習を利用してユーザーによりマッチする情報を抽出する必要があると思います。 とはいえ最初のアプローチのためにはJupyter使ってPandasの内容を視覚化してくことからなのかなと思ってます。今までその辺りが苦手て、Slackで事前に組んだKPI数値をチームメンバーに流すにとどまっているので改善できるはずです。

インフラ

現在、インフラの専任の担当者という方はいません。 新規サービスを立ち上げるときにはサーバーサイドのエンジニアが自身でインフラを構築して、その際のナレッジを構築手順書という形でまとめて、その手順を元に開発環境を構築することで成り立っています。 AWSずっぷりで構築しているためスケールアウトさせる際にはEC2をコピーしてELBに追加することで対応可能ですし、nginxやsupervisordやuwsgiなどの設定ファイルはGitHub管理されているためある程度は安全ですが、オペレーションミスの低減や構築&破棄が簡単にできる仕組みの構築のためにインフラのコード化は早めにやっておきたいなと考えてます。 また、開発環境/テスト環境用がメインの目的になると思いますが、さくっと立ち上げて捨てやすいという意味でDockerは本格導入しておくと幸せなことは多いと考えてます。

フロントエンド開発

2016年、食わず嫌いだったフロントエンドのFWを利用してみてかなり感動をしたことを覚えています。 今までjQueryでフロントエンドを構築していたため1画面での機能が増えてきた際に複雑になりがちで、他人が書いた表面のコードを修正するのがつらかったのですが、かなり薄めのFWでしたがVueを利用することでかなりさくっとそれなりの規模(jQueryで書いていたら2週間程度と想定していた)の予定管理画面をほんの数日で構築することができました。 Vueを利用することで(これは巷のフロントエンドFWの多くに言えることだとは思いますしjQueryでできないことではないと思いますが)きれいにサーバーサイドとフロントエンドを分離することができ、実際数百行程度のコードを書いてみた感想として、動作の流れも分かりやすくHTMLとロジックの分離度合いがとても適切で、Vueの分かるエンジニアなら後から保守に入っても修正しやすいコードになっていると思います。 そんな経験もあり、レクミーキャリアの裏側をAPIとVueでのフロントエンドにきれいに分離するための土台構築&実施をしていこうと考えています。競争力のある使いやすい裏側にするためには、今はこのアプローチがいいのかなと思っています。 ※デザイナーさんとの協業をどう進めていくかというのは今後課題になりそうですが

スクラム開発

チームがスクラムな状態にあるという状況の定義がまだ自分の中で得心できていませんが、2016年はスクラム的なプロジェクト運営にトライした年ではありました。 レクミーキャリア開発チームでは、イテレーション単位を1週間にして、

  1. イテレーション初日にプロダクトオーナーとともにキックオフ(スプリント計画)をしてその単位での作業量をメンバーに割り振る
  2. 毎朝、朝会(デイリースクラム)をして前日の進捗と本日の予定、困っていることをチームで共有する
  3. 単位としては長いが、約1ヶ月に1回の単位で振り返り(スプリント振り返り)を行い、チームのアウトプットをレビューする
  4. 仕様はGitHubのIssueにまとめて、PR単位でレビューを行い適宜リリースする
  5. 別途、毎週1回KPTとして開発チーム全体の改善案をまとめる

※全てがスクラムの儀式というわけではないが、開発の大きな流れとしては上記のように進めている

という進め方は一定まわるようになってはきているがまだまだ改善の余地があり、

  • イテレーション毎にざっくりと見積もって入るが過不足が毎回あり、ベロシティが安定しているという状況ではない
  • デザインスケジュール・仕様詳細FIXのために、スプリント計画参加者だけでじゃそのタイミングで要件が固まりきらないことがある

と、平たく言うと計画の部分に課題を感じているので、私以外のメンバーもスプリント計画の中で開発スケジュールが明確になるまで要件を詰められるように事前準備をしておき、計画終了後には全員が同じレベルの情報を得ており開発に集中できる状況を作っていきたいと考えております。

おわりに

新年2記事目にして2500文字オーバーの記事を書いてみましたが、まだまだ長文を書いた際の文章力が無いなぁと反省。。 もっとまとまっていて読みやすく、読んだ方にとっても価値ある文章となるよう精進していきます。 とはいえ、最初に頑張りすぎてガス欠にならないようにも注意しないと。