MizushimaSotaの記事一覧

mini specが流行っている??うちもいつかやろう

こんにちは。
Raksul Platform Projectの水島です。

先日ふとProduct Manager(以下、PM)の平光さんから、「これって水島さんの昔の記事のことですよね?」と声をかけられました。

なになに??おお〜、私が前職のtechブログに書いたmini specに関する記事がカウルさんのブログで紹介されているではないですか!

スタートアップの現場で役立つ開発要件のまとめ方

涙ぐましい。魚拓から復元してくれたのかな。。。感謝。

実は、このときのブログの中で、「mini spec」でググると、外車のMINIのスペック情報が出てきちゃうし社内用語だよ、と書いていたのですが、今はちゃんとQiitaの記事がトップで引っかかるではないですか!

新機能をつくる前に整理しておきたい10のこと

しかもクラウドワークスさんも一部ご活用とのこと!そして、mid specなるものが。。。参考になります!
スタートアップ界隈でこういったノウハウがシェアされ、活用されていることに感激してしまい、ついついブログで書きたくなってしまっていました。

ラクスルでも当然mini specとかmid spec書いているんだよね?

。。。
いや、今は決まったフォーマットで書いていないです。。。

なんか書かなくても各スクラムのPMがストーリー分解できていて開発は一定回っていた状況なので今はいいかなと(本当はメンバー自身でストーリー分解するのが普通かもですが、ラクスルではPMが結構やる)。エンジニアからすると背景が見えないよ問題は時々起こりますが明確に導入するに至っていません。

あと私がメインでやっているRaksul Platform Projectは、相手にしているシステムと刷新の規模が大きくて、miniもmidも収まらない。。。 まさにlarge spec。決まったフォーマットはなくつらつらと方針とか計画とか意思決定したことなど、必要なドキュメントをチームで書いています。

プロジェクトの特徴的にも手を動かしたほうが見えてくる技術負債も多いような状況なので、ハイレベルなロードマップ、アーキテクチャーとデザインをエピック的に、Trelloにざっくりとcardを書いてとにかくガシガシ進めるスタイルをこのプロジェクトでは採用しています。後から漏れているタスクが多々出てくるので都度cardを追加していきsprint計画どころではないこともあります。。。泣。

このプロジェクトが落ち着いてきて中小規模な案件が増えてきたら、またmini specの運用をちょっとづつ考えてみたいと思っていますが、PMがmini specやmid specを書いてエンジニアに伝えて、というよりは、多少非効率でもエンジニア自身で大枠の仕様を決めたり、直接ステークホルダーに絡むともっと開発って楽しくなるのかなって最近思っています。

最近ベトナムでのオフショア開発も少しずつ開始していますので、言語の壁があったりリモートの開発部隊と協業するシーンで背景や仕様を伝える時には良さそうです。元々、mini specは、日本とサンフランシスコのエンジニア間で企画や仕様を共有するために生まれたものですから。

Raksul Platform Project の進捗

先日、会員登録、ログイン周りのUI刷新、内部的な認証認可のAPIの刷新をリリースしました。

見た目のデザインも変えていますし、今までメールの通達確認をしていなかったのでカスタマーサポートの観点でも問題があった部分を改善しました。
メールの通達確認を必須にすると会員登録CVRが落ちるんじゃないかという懸念がありましたが、計測してみるとむしろ良くなる兆しがあるくらいです。本当にやってよかった。

これで若干中途半端感があったraksul-authという内部APIのアプリをやっつけることができそうです。

また、平光さんリードでマイページ(ログイン後の注文などの確認機能)の刷新もリリースされました。

今までメニューが分かりにくかったり、ページング処理がない画面などが一部あり、エンジニアやカスタマーリレーション部のメンバーからも改善したいという声が大きかった機能です。
印刷ECは物販のECと比べて注文のステータスやお客様にしていただくアクションなどが複雑なので、マイページはとても重要な機能です。そのマイページの負を技術的にもユーザー体験的にも改善することができました。まだ、古いページも一部残っていますが。。。今後の機能拡張と併せて刷新していけそうです。

並行して、三瓶さんの活躍により決済のサービスが着々と仕上がってきており、より法人の方の決済ニーズを満たすことができる機能に刷新されていく予定です。

ガシガシ行きましょう。

新機能はrubyとgolangで開発する潮流

社内の潮流として、Raksul Platform ProjectでRuby on Railsのアプリケーション基盤が揃ってきたので、中規模以上の新機能については可能な限りRuby on Rails側のアプリで開発することを選択するようになりました。ここ半年で大きく変わってきた感触があります。

早いもので印刷サービスではそろそろ年賀状・喪中はがきの販売がスタートします。今年は新機能を乗せて販売開始をしようと準備をしていますが、新しいrailsアプリケーションの上で開発しています。

一部のタスクはとある事情でgolangで開発し、非同期の処理にはAWSのS3トリガーのSQSを組み合わせて実現したりと、なかなか楽しい感じのアーキテクチャーになってきました。
社内にもgolangの入門書が雑多に置かれています。ビジネス的にもエンジニアにとってもお客様にとっても今年のラクスルの年賀状は楽しみです。

詳細は追ってどなたかが書いてくれると信じて。。。

ラクスルではエンジニアを積極採用しています

赤裸々に書きましたが、こんな感じの私達と一緒に開発を楽しんでいただけるエンジニアをラクスルでは募集しています。是非一度オフィスに遊びにきてください!

そうだ、ラクスルを作り直そう!

10月からラクスルにジョインさせていただいた水島です。

新参者ですが、宜しくお願いいたします。

さて、入社して間もなくCTOの肝いりでスタートした 「Raksul Platform Project」 のプロマネを拝命したため、今日はその全体感の話をしたいと思います。

なにをするのか

「スタートアップあるある」だなんて言わないでください。

ラクスルをフルスクラッチで作り直そうとしています。

でもそれはあくまで手段です。

目的は、

  • 技術負債と思われている部分を根本的に解消して開発しやすい状態にする(エンジニアを幸せに)
  • システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする(経営を幸せに)

の大きく2つです。

特に前者の「エンジニアを幸せに」という目的に対する経営陣の温度感が不思議と高いのはポジティブに感じています。短期的な投資対効果とかではなく、「ものづくり」を大切にする会社になるんだという意思が強く感じられるので、長い道のりにはなりそうですが、エンジニアとデザイナーがさらに輝けるようにするために是非やりきりたいと思っています。

後者の「経営を幸せに」という目的は、プロマネである私のバランサーとしてのプライドみたいなものです。ただ作り直してキレイになりました、幸せです!だけでは虚しさがあるので、経営の潜在ニーズを今回のプロジェクトで一定先回りして、いつかドヤ顔したいと思っているのです。

つまりは、単純に他言語、他フレームワークで作り直すということではなく今後のアーキテクチャーから見直していくプロジェクトです。

 

今までのいろんなアンチパターンを思い返して方針を考える

ラクスルの現在のシステムの状態を見たり、私が今まで経験してきた様々なサービス、プラットフォーム、受託システムの開発を思い起こすと、やってはいけないアンチパターンの連続が強烈な反省と共に頭の中を駆け巡ります。

それらをベースに今回はどのようなアーキテクチャーで進めていこうとしているかをいくつかご紹介したいと思います。

アンチパターン1: サービスのコア機能が汎用化されていない

サービスはユーザーのニーズや市場環境を見ながら進化していくものなのですが、再利用可能なコア機能が主力サービスの中に閉じ込められていることがあります。

私の経験を思い返しても、

  • 会員体系の認証、認可機能
  • 決済、経理、資金決済法遵守のための仮想通貨管理などの機能
  • データ分析基盤機能
  • 校閲、投稿内容チェックなどの機能
  • 画像管理、変換機能
  • CMSと広告配信管理機能
  • ファイルシステムみたいな機能

などがありました。

つまりは社内外で今後再利用される可能性があるものを主力のサービスとは疎結合に作っておけばよかったと後悔し、後で掘り起こして、汎用サービス化することを繰り返してきました。

社外のクラウドサービスで置き換え可能な機能も増えているので、要件がほぼフィットするならそれらを活用すべきというのは言うまでもなく、実際にFirebaseなどに載せ替えた部分もありましたが、自社の強みや特殊要件が眠っている場合は、早めの段階で社内クラウドサービスのように汎用的な設計にして再利用可能な状態にしておくべきです。

現在のラクスルにおいて、主力サービスの中に閉じ込められている汎用的なコア機能としては、

  • ラクスル社の他事業(ハコベル事業等)で共通に使える汎用機能レイヤー
    • 個人向け、法人向け決済、経理処理などの機能
    • メール送信とテンプレ管理機能
  • 印刷関連事業で共通に使える汎用機能レイヤー
    • 印刷SCMと発注基盤機能
    • スピードチェック入稿を含むDTP機能
    • オンラインデザイン制作サービス機能
  • raksul.com で共通に使える汎用レイヤー
    • ラクスル会員の認証、認可機能
    • ECの基本機能

と分析しています。

ハコベル事業でも物流の輸配送管理システムなどは、物流全般で共通に使える汎用機能レイヤーと言えるかもしれません。

裏を返すとこれらの機能の汎用化ができていないために、既存事業とシナジーのある多角的な取り組みの開発スピードが落ちていたり、顧客体験の低下や、事業の機会損失が出始めているようにも見えます。

今回のプロジェクトでは、これらの機能を各レイヤーにおいて、社内外の他サービスと接続しやすく切り出して作り直し、そしてそのアーキテクチャーを継続していけるような開発体制を作っていくことが重要となります。

raksul.comの印刷サービスや集客支援サービスは、これらの汎用機能の上に成り立つ一つのサービスという位置づけになります。後付にはなりますが、これがRaksul Platform Projectと呼ばれている所以です。

 

アンチパターン2: データベースとアプリケーションの切り方を間違える

よくあるアンチパターンな構成としては、モノリシックなデータベースが中心にあり、ユーザー向け、管理画面やAPIなどの多数のWebアプリが読み書きしている状態です。

立ち上げ期はスモールな構成なのでいいのですが、そのまま多角的に機能追加を行ってしまった結果、データベースとメインのWebアプリ、管理画面などが肥大化していき、辛くなって対処療法的に小さなアプリだけを切り出し始めます。

 

こうなってしまうと、

  • 各アプリケーションで似て非なるモデルが冗長に開発され、コピペしはじめる(DRYでない)
  • 各アプリケーションがそれぞれの事由でスキーマを変更、書き込みをしていき、影響範囲が広くなる
  • 新しいエンジニアやオペレーターがシステムをキャッチアップするのに時間がかかる

といった弊害が出てきます。

開発の現場から悲鳴が上がり始め、内部にインターナルAPIを置き、データベースやビジネス・ルールを一定ラップして凌ぐことになります。ラクスルにも内部にAuth API, Order APIといった比較的新しくて小さな内部APIが存在していて、一時的な対処はしている状態ですが、抜本的な解決には至っていません。

本質的には適切な関心事であるドメイン毎に、データベースを分割して、各ドメインのアプリケーションが、

  • エンドユーザー向けWeb画面
  • 管理者向けWeb画面
  • 他アプリケーション向けAPI

の3つのプレゼンテーション機能を持ち、一つのデータベースと一つのストレージ(AWS S3 のバケット等)の保全に責任を持つ、という構成にすることで、機能の凝集度を高めるべきです。

早期にこういった発想でデータベースとアプリケーションの切り出しを意思決定したかったと後悔することがよくあります。

 

アンチパターン3: マイクロサービス化しすぎて逆に効率が落ちる

上記で説明した、データベースとアプリケーションの切り方についてですが、柔軟性を求めすぎて細かく切りすぎてしまい、ピタゴラスイッチ状態になるとまた問題が出てきます。

  • dockerなどを使っても環境セットアップするのが辛くなる
  • データを非正規化しすぎて不整合が起きやすくなる
  • 障害対応やチューニングの難易度が上がる

ラクスル内部でも、Auth APIがつらい、直接usersテーブル参照したい、joinしたいといった声が聞こえることがありますが、まさにといった弊害かと思います。それは近くにあるべきはずのものが遠くに切り出されてしまっている可能性があります。

一定仕方のない部分はありますが、なんでもかんでもAPIにして分割していくということではなく、逆に統合すべきドメインを見定め、的確にケーキカットしていくことが非常に重要だと思っています。

ラクスルの場合は、

  • 全社共通で使われるであろう機能レイヤーに2アプリケーション
  • ラクスルのコア技術で印刷事業共通に使われるであろう機能レイヤーに3アプリケーション
  • raksul.comのECサイトのレイヤーに2〜3アプリケーション

の合計7〜8アプリケーション構成程度になってくると思っています。
これでも少し多いですが、これ以上切り出すのは多すぎると思っています。

 

アンチパターン4: テストしにくい状態で身動きが取れなくなる

フレームワークや言語のバージョンアップをするというプロジェクトを今まで何度も経験していますが、ここで辛いのが、テストがないアプリケーションのマイグレーションです。

例えば、Rails5が出ている時期に、 テストが不十分なRails3の巨大なモノリシックなアプリがあってなかなかマイグレーションできませんでした。「Rails3 なんですねえ。。。」と採用面接で何度言われたことでしょう。

持続可能な事業を支えるアプリケーション、開発組織であればここは妥協すべきではありません。

ラクスルでも、PHP + テストがないアプリケーションなどが一部あります。かつ、それがとても事業上重要なアプリケーションだったりします。日々の開発では、End2Endテストと人力のQAで品質を担保していますが、もう少し細かいレベルでのテスティングに力を入れなければ長くアプリケーションの品質を保つのは難しいのは言うまでもありません。

思い切ってこれらのアプリケーションをRuby on Railsでテストフレームワークも含めて標準化し、テストを書きながら作り直していく必要があると考えています。

 

まとめ

さて、ご紹介してきたアンチパターンを踏まえた上で、今のところのRaksul Platform Projectの基本的な方針は以下のような形です。

  • レイヤーとドメインを定義し、コア機能を汎用的に切り出して社内外と接続可能な状態にする
  • 1アプリケーションに対して、1データベース、1ストレージ構成のアプリにする
  • アプリケーションを細かく切りすぎないように7〜8アプリケーションぐらいに再分割して切り出していく
  • Ruby on Railsでアプリケーションを標準化してreadable、testableな状態にする

ラクスルの開発現場はこれから大きく変わろうとしています。また、これによりシステム構成と事業・組織構成の間の歪を最小化することができる考えています。

印刷業界をリードできるコア機能の開発が段々できるようになってきた今、今度はそれらをモダンなアーキテクチャーに載せ替えていき、ワクワクするような経営・事業戦略と共にエンジニアもさらに高いレベルに成長できると思います。

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています♡