ID:61498さん

# 概要 買取プラットフォーム（CtoBtoB）のサービス開発 アジャイル開発(スクラム)に最も力をいれながら、事業部や開発チームが一丸となり、「ビジネスとして当てることができる開発」や「MVPを意識した開発」に着手致しました。 基本的には、私一人で提案して何かを実行するというよりは、チーム一人一人から出てきたアプトプットを全員で議論し、改善するスタイルをとっております。そのため、私がチームにジョインした後のチームの変容や私の学びを記載します。 # メンバー 要員数： 約13名(オフショア開発者を除く) 内訳： PO：2名(事業部と開発部) PM：1名 SM(スクラムマスター )：1名 エンジニア：4〜7名 デザイナー：2名 ※海外のオフショア開発部隊は10〜20名在籍 # 担当業務 ・スクラムイベントへの議論参加、スクラムイベントの見直し、改善 ・バックエンドエンジニア、フロントエンドエンジニアとして、機能開発や改修。 # 担当したサービスの概要 買取のプラットフォームサービスを展開するWebサービスを担当致しました。 - 一般のエンドユーザーが当社サービスへ不用品の買取依頼を行い、当社はその依頼をもとに、加盟頂いている加盟店様に買取案件を提供し加盟店側の査定が確定した段階で当社にマッチング対価として収益が入る構造となっております。 - 当社も自社で買取サービスを提供しているため、買取依頼に対して自らが出張買取やユーザーの店頭持ち込みに対して査定を行い、自社の販売網で販売するというビジネスモデルをとっております。 ## 当社の課題 - 顧客によって良い買取体験が何か、ロールモデルがないためどのような機能の開発に着手すれば良いか試行錯誤する段階。 - 競合他社と差別化しながらいかに市場を占有するかが問われている。 - 本サービスはもともと他社で運営していたサービスとなるため大部分でレガシーな環境がある。 - 大規模なレガシー環境を修繕するほどのコストをかけられない。など # 当社の取り組み ※ 戦略に関わる部分もあるため割愛し、開発側で注力した部分を抜粋。 ## ◆アジャイル開発（スクラム） 上記の課題に対して、どのように開発を進めるべきか、検討する余地がありました。 そこで当社は、約1年半ほど前からアジャイル開発を導入し、スクラムの開発手法を取り入れ、チーム主体で開発を推し進めて参りました。 当社の開発は、スクラムを忠実に取り入れて開発を進めるスタイルが特徴的で、日頃の開発の中での気づきや課題などをスクラムイベントの中で議論し、次回のスプリントで改善に活かしています。 【スクラムの中で出てきた課題やレトロスペクティブでの議論の例】 ・スクラム開発であるはずなのに、社内の事業部側で要件定義されたものがおちてきていないか？（ウォーターフォールになってきていないか）それをスクラムに戻すにはどうすればよいか？ ・現在作ろうとしているものは車ではないのか？まずは自転車をつくるべきではないのか？そうするために何を変えるべきか？ ・本番のバグ改修において、改修が終わった時点ですぐに、臨時リリースすべきなのか？もしもそれがインパクトが低い、もしくはユーザーストーリーができあがらないならば、わざわざコストかけて臨時でリリースする必要はないのではないか？ ・チケット（バックログアイテム）は、粒度の荒いものになっていないか？サブチケット化して属人化を減らせないか？作業タスクを分解できないか？ ・チケットのポイントを振る際に、不確実性の高い状態に対して、どのようにポイントを見積もるべきか？などです。 上記のように、スプリント毎に出てくるこれらの課題を、チーム全員で議論や改善を繰り返しながら開発を進めることができているため、 開発のゴールがぶれることなく、ユーザーにとって価値のある機能やサービスを開発することができ、結果的にKPIで設定した指標を達成できるチームとなりました。 ### 当社のスクラムの成果 - 開発した機能がユーザーの満足度向上につながる確率が高い。 - 事業部の戦略をもとに、どのような機能開発や進め方が良いのかを開発チームが提案し、実行することができる - いつ誰がチームやプロジェクトに入っても同じ仕事をする（同じ成果を出す）ことができる - 開発者のほとんどが、フロントエンド とバックエンドを担当できる - 開発メンバーは全員、同じ情報を持っている（ブラックボックスが少なく情報が共有されている） - ビジネス環境の変化、当社組織の変化があっても、すぐに柔軟に対応できる。 ## ◆開発に関して 当社は、企業やサービスの買収、購入などによって母体が大きくなりました。その弊害として、複数の言語で、一昔前に開発されたサービスが複数あるため、いろんな言語で保守改修、もしくは機能追加する必要がありました。 当プロジェクトで経験した言語やサービス - バックエンド：Python, Django, Django Rest Framework, PHP, CakePHP - フロントエンド ：Vue.js, TypeScript, HTML(Smartyテンプレ), CSS, SCSS - インフラ：AWS(EC2, S3, RDS, DynamoDB, Lambda, Amplify, SES, GraphQLなど)、Docker, docker-compose, RUNDECKなど ・当社の開発における考え方として、以下のようなものがありました。 - レガシーな環境にできるだけテコ入れしない - 既存のシステムに機能追加する場合には、新しい技術を導入できないかを問う - MVPの思想を持った実装 これらを踏まえて、以下のような開発や対応をとっておりました。 ・バックエンド側はCakePHP3で作られており、フロントはSmartyのテンプレートが使われているというレガシーな状態に、新規で機能を追加したい要望が出てきた際に、既存のコードにそのまま機能を追加せずに、新たにVue.js+TypeScriptでのフロントエンドのリポジトリを生やし、RestAPIで連携するといったような形を取ったことで、レガシー技術を増やすことなく新たにモダンな技術を導入しております。 また、プラットフォーム型のビジネスモデルのため、そのディレクトリ構造においても考慮し、ユーザー、加盟店、自社の管理ページ、共通ページなどとうまくディレクトリをわけられるように対応しておりました。 ・既存のシステムからRDSにのみ保存されていた情報を、DynamoDBにも同時に保存されるようにしたことでDBの疎結合ができ、処理速度の向上やサーバレス化を目的にした再設計を行いました。 ・サーバレスで対応ができるようAWSのLambdaを利用しました。Lambdaを使ってユーザーがマイページの情報を変更した際に、それをトリガーにしてDynamoDB側も情報アップデートがかかる仕組みの構築や、一定の期間に加盟店から査定が入らなかった場合にその通知をユーザーに送信するなどといった形で積極的に開発に取り入れておりました。 ・レガシーな環境にできるだけテコ入れをしないよう考慮しました。常に考えていたことは、既存のレガシーなデザインやコードを改修した際にどのようなリターンが見込まれるのか？という投資対効果です。その効果が低ければ、やらないか、見送りという選択をとり、効果が見込まれるなら、ユーザーに及ぼす価値の大きな部分から順位付けして開発に着手しておりました。 ## 最終的な成果 - ビジネスと開発をうまくマッチングするために、アジャイルのスクラムが効果を発揮しており、ユーザーにとってもチームにとっても、良い結果をもたらしている - 他社から引き継いだレガシーな環境に対して最低限の改修に留めつつ、試行錯誤で技術をアップデートできており、疎結合化を意識した開発を取り入れ設計の改善が行われている。

# 概要 2、3ヶ月ごとに複数のプロジェクトをまたいで、機能追加や改修 プロジェクト - 自社の基幹システムの機能追加と改修 - デバイス関連の修理プラットフォームの改修 - 既存メディアの新規リニューアルなど # メンバー 要員数： 約4名 内訳： PO：1名(開発部) PM：1名 エンジニア：2〜3名 以下、プロジェクトごとに利用した言語や技術 ①自社の基幹システム Python, JavaScript, Vue.js, jQuery, Docker, DynamoDB, MongoDB, RDSなど ②修理プラットフォームの改修や既存メディアの新規リニューアル、新規LPコーディング など(プロジェクト単位) ・プロジェクト① Ruby on Rails, Vue.js, Docker：　アプリケーション側でエラーが出た際の改修にあたる。 ・プロジェクト② MODX, PHP, Nginx, Docker：　既存のレガシーなメディアがSEOで上位表示されていたため新規環境でのリニューアル。 ・プロジェクト③ Vue.js, Nuxt.js：　ECサイトの不具合が起きたときの改修。 ・プロジェクト④ HTML,CSS：　スマホアプリリリースに伴う、LPのコーディングと制作 本プロジェクトでは、当社のいろんなサービスの機能追加や改修業務に携わりコードや技術に触れることができました。 ここでは特に関わった、自社システムについて記載します。 # システムの概要 システム仕様や流れとしましては、 一般のユーザーが当社のフォームから買取査定依頼をした案件が、当社の基幹システムに全て反映され、大部分を自社の販路などで、自動出品するようなシステムとなります。また、それらの買取査定依頼の情報の他にも、商品情報や、個人情報、注文情報など、あらゆるデータが保存されたシステムです。私はこの自社システムにおける機能追加と改修業務に携わりました。 # 主に対応したタスクの一例 ・システムの新規項目追加などによるワーカー側（バッチ処理）の項目追加や変更などの改修 ・受注したデータをバッチ処理などで取得し、ヤフオク等の販売チャネルへの自動出品するAPIまわりの処理の構築や改修 ・銀行の為替情報をスクレイピングで取得しS3に保存後、為替レートから原価等算出し複数の自社システムに反映する機能の追加など ・自社の販売・管理アプリケーションと自社システムの動作齟齬によって発生する不具合の改修や紐付けなど # 難しかったこと 自社のWebアプリケーションから入ってくる受注データと自社システムにも入る受注データ（査定依頼）とで整合性をとりながら、いかに自動化できるのか？という点でした。 具体的によく起きていた問題として、 アプリケーション側で、当社のスタッフが販売ステータスの状態を「出品中」から「出品待ち」などに変更した際に、 本来、自社システムのワーカー（バッチ処理）がそれを数分ごとに検知して、自社システム側のステータスも変更される必要があるのですが、さまざまなパターンの条件分岐（商品自体による条件分岐やステータス変更時の条件分岐など）が相まって、相互のシステムで差異が発生してしまうということでした。 また、これがシステム上のバッチ処理だけうまく動けば良いのではなく、人間が操作する可能性すら鑑みて（オペレーションも考慮して）、どこかで問題が起きた際にそれをどう担保できるのか？を常に考えさせられました。 この問題は、一部まだ解決できていないものもありますが、そんな中でも次のことに意識して開発を進めました。 レガシーな技術には極力テコ入れせず、必要最低限の改修に留めて、新規開発の時点で新たな技術を導入する、といった思想です。 例えば、以下のようなシーンではこの課題を回避しながらも新規開発を行い成果を上げました。 ## 対応事例 上記のように、大規模な既存システムに手を加えればどこかしらに必ずひずみが発生してしまうような状態の中で、そのシステムに入ってくる大量の受注データに優先順位をつけたいという要望がありました。 そのため、なるべく疎結合化した上で機能を追加するにはどうすればよいか？を考えました。 実際に検討した中ででてきたのはのは、Google Chromeの拡張機能を使って開発し、要件を満たすというアイデアでした。 JavaScriptをベースに開発が進み、特定の受注が入った場合にCSSのスタイルを当て、なおかつその特定の受注を事業部側がスプレッドシートで更新、変更できるように、S3側でアップロードが簡単にできる仕組みを整えるなどで対応致しました。 これにより、既存の自社システムに変更は加わらず、Chromeのブラウザ上で要件通りに動く新規の機能開発ができたため、システムとの疎結合化もでき、かつMVPとして最短で機能開発ができました。

# プロジェクト概要 Web事業のスタートアップ に参画し、Webコーダーとデザイナー、マーケターを兼務。 実働開発メンバー2名〜4名（物流部門除く）でECサイト構築やメディアの構築を行った。 ## 担当内容 自社のECストアを構築しECにおけるほぼ全ての工程を兼務した。 - ECのフロントエンド のコーディング（HTML,CSS,JavaScript,jQuery） - LPモックアップ作成、LP作成（PhotoShopでのグラフィックデザイン） - 自社メディアサイトの構築（PHP、WordPress、FileZilaなど） - 購買データ算出(LTV、商品出荷数等、在庫管理、発注数算出)と一部データの分析 - 売上管理(日商売上、新規/既存の客単価、CPO、原価管理等) - タスク管理、施策の整理（カスタマージャーニーマップ） - 広告入稿(ヤフーショッピングや楽天市場など） - ECショップのバナーの新規作成やキャンペーン時などの張り替え、変更 - 商品パッケージ案の作成と海外デザイナーの選定 - 商品販売ページ作成、変更(コーディング) - メルマガ作成、コンテンツ配信、クーポンやキャンペーンの設定（販売促進） - 自社メディアの集客キーワード選定とブログコンテンツの作成 - SNSでのブランディング（SNS投稿） - 受注システム選定と導入、サードパーティの追加 - 出荷処理、出荷依頼 - その他社内の作業フロー構築、スキーム改善、薬事審査対応 - 自社コーポレートサイトでの商品ラインナップ追加やブログコンテンツの追加