プラン変更開発秘話

 

こんにちは、ペラログ編集部です。

 

今週のブログも、ペライチのプラン変更についての話題が続きます。

新しいプランに変更した理由、その使い方、とユーザー様の目に触れる部分に続き、今回お送りするのは舞台裏のお話です。(新しいプランの変更内容についてご存知になりたい方は、前回のブログをご参照ください。)

今回は、いつもと趣向を変えて、対談集となっています。コードの書き換えや、データの改修、デザインの刷新など、実際にプラン変更の開発に当たったチームのみなさんにお集まりいただき、お話を伺いました。

写真の左から、佐藤さん(開発部長)、東さん(エンジニア)、関さん(デザイナー兼フロントエンドエンジニア)、尾崎さん(エンジニア)になります。

 

f:id:peraichi:20190212124532j:plain

 

編集部

まずは、お集まりいただいてありがとうございます。プラン変更のプロダクトリリースから、1ヶ月が経ちますね。開発に当たって、皆さんのそれぞれの役割はどのようなものだったのでしょうか?

 

佐藤 

役割としては、僕がディレクター兼プロジェクトマネージャー、東さんと、尾崎さんが開発、サーバー処理、そして関さんがユーザーが見えるところ全部、という持ち回りでした。


編集部 

今回の開発期間は企画が出てきてから、1ヶ月ぐらいでリリースする、という今までの開発と比べると結構な短期間での開発、リリースだったと伺っています。その中で特こんなことがキツかった、というエピソードはありますか?

 

佐藤

そういう話なら、東さんが一番きつかったんじゃない?

 

f:id:peraichi:20190212124519j:plain

 

いや、僕の作業は地味なだけだったので…

 

編集部

地味、と言いますと、具体的にはどんなことですか?

 

そうですね、例えば、月額プランを1個潰したり、増やしたりという作業です。あとは、機能の単品販売が始まったので、それに伴って料金の上での矛盾を正すために、新しいルールを設計する必要が出てきました。あるオプションを購入した場合は、特定のプランには契約できませんよ、というようなものです。

従って、テストケースをひとつひとつ、検証しようとすると、625通りのケースが出てきてしまったんですよね。それを1個1個潰していく、という途方も無い作業でした。

 

佐藤

東さんは、プランの組み合わせが多岐に渡るようになってしまったところ、全部網羅してくれました。まさかそこまで丁寧にやってくれるとは思っていませんでしたね。でも彼はやってくれました。本当に、流石です。

 

東 

そこは、力技というやつです。(笑)

 

編集部 

なるほど(笑)。開発というと、新しい機能を開発しつつ、過去のコードを綺麗にして、メンテナンスをあげるための「リファクタ」みたいな作業もあると思うのですが、今回はリファクタも、東さんがなさったのですか?

 

東 

そうですね。でも、そこはここにいる全員で、って感じですかね。内部の作りとしては、新しいプランを追加しにくい作りだったので、今回のリリースに合わせて、内部の作りに手を加えました。今後、新しいプランを追加修正したい時もサクッと、対応しやすいように修正しています。

編集部 

東さんと、尾崎さんはどんな風に役割分担されていたのでしょうか

 

尾崎 

手分けして作業する、という感じでしたね。サーバーサイドは二人とも見ています。

 

※サーバーサイドとは
ユーザ側ではなくサーバ側で動くプログラムのこと。

 

佐藤

でも、結局は、プランの新設と、機能の単品販売で役割を分けていましたね。主に、東さんがプランの新設で、尾崎さんがオプションの単品販売を対応。

 

編集部

尾崎さん、機能の単品販売実装の方はいかがでしたか?

 

f:id:peraichi:20190212124749j:plain



尾崎 

最初、開発の要件を見たときは…1ヶ月での実装は無理だろうと思いましたよ。

 

東 

ビジネス側のマネージャーがいない時に、こっそり、聞こえないくらいの声で「これ絶対、無理無理!」って言ったりしていましたもんね(笑)

 

佐藤 

それでも、実際1ヶ月でできたわけとしては、1年くらい前に、プランの大幅なリファクタを施したことが大きいですね。それより前はコードがベタ打ちだったので、プランを新設することが難しかった。

 

それを、基本的にデータを新しく追加したらプランを新設できるようにプラン周りの改修を行なっていて、今回のプラン変更みたいなことがあっても、データを追加すれば気軽に対応できる仕組みを僕がメインで作っていたんです。この対応をしていたので、僕はできると踏んでいました。

 

でも、なかなか現場のメンバーたちに信じてもらえないので、(笑)

試しに僕が代表的なプランをピックアップして、動作確認を行い、修正少なく今回の対応ができることを示せたので、多少メンバーに安心してもらえたかなと何度も「大丈夫だよ!」って言って信じさせたんです。

編集部

なるほど。それがあったから、今回の運びがスムーズになったのですね。

 

尾崎 

確かに、実際蓋を開けてみたらサーバーサイドで大変なことは、構えたほどではありませんでした。

 

佐藤 

それでいうと、ユーザーさんの目に見えやすい形で、1番ガラッと変わったのはデザインじゃないでしょうか、関さんの力ですね。

 

編集部 

関さんの中では、今回のことで一番の障壁となったのはどんなことだったのですか?

 

f:id:peraichi:20190212124730j:plain



関 

体調不良、ですかね。

 

佐藤 

パーソナルなことで言えば、彼、年末胃腸炎で入院していましたからね。 

 

関 

あ、過労じゃないですよ、(笑)スケジュールがタイトだったとはいえ、いつもより長く働いた感じもしなかったので…。単に、食べ過ぎです。

 

体調が優れないと安定したパフォーマンスが出せず、進み具合が読めなくなってしまうので、そういった意味でも健康維持が一番の課題でしたね。

 

 

編集部 

では、一旦ここで話の切り口を変えて、今回のプラン見直しの開発期間中、オフィスの中で頻繁に短いミーティングを開かれていて、白熱した会話が飛び交う様子がよく見受けられましたが、どうしてそのようなミーティングを行なっていたのですか?

 

f:id:peraichi:20190212124709j:plain

佐藤 

ミーティングの主な目的としては各々のできること、やろうとしてることの確認でした。最近、チームの体制も変わった中で、コミュニケーションをしっかりとって、プロジェクトを目的に沿って確実に進行させる必要が出てきたんです。幾度ものショートミーティングは、自然発生的なものでしたね。過去のプロジェクトでも、必要であれば朝礼の後に、朝会やミーティングなどは行なっていました。


編集部

意識合わせみたいなものですね。

 

佐藤

今回に関しては決まりってほどじゃないけれど、直感としてやったほうがいいなと。

 

実は、個人的には頻繁なショートミーティングは意図的に行うよう心がけていました。というのも今回は自分が開発を多少リードする流れになっていたのですが、今までお二人と同じプロジェクトに参加したことがあまりなく。それぞれどのようなスキルセットを持っているのか、お互いに把握するところからの手探りという状態からのスタートだったためです。

 

特に最初はコミュニケーションをしっかり取っていかないとマズそう。必要のない無理を自分を含め誰かがしてしまうのでは、と考えていました。みんな責任感の強い人たちなので。



編集部

意識齟齬の例と言えば、先ほど尾崎さんが「無理だ」って思った部分とかもそうですよね。それを短いミーティングを通して、佐藤さんが「大丈夫だよ!」と説得された。(笑)チーム内での不安や曖昧な部分などが取り払われていくことになって、チームの体制変更にも柔軟な対応ができたわけですね。

 

では、最後に、今回のプロジェクトを踏まえて、もしくは開発チームのこれからのチームについて、こんなことを今後やっていけたら楽しいな、なんてことでも良いので、最後に皆様から一言ずつ、いただけますか?

 

今回の役割に関しては、佐藤さんがディレクターかつPM、関さんが開発全体をリードしながら、フロント全般、尾崎さんがサーバーサイド全般を見てくれました。僕は尾崎さんについていきながらサーバーサイドとテスト全般を担当しました。個々の役割が明確になっていて、綺麗なパスが通っていました。個々の資質がよく組み合わさってうまくできたことなので、いいチームとして機能したのではないかと思います。

 

f:id:peraichi:20190212125505j:plain

 

みんな、本当に頑張ったと思います。想像以上のアウトプットができました。最初は自分のリソースも限られているので、他メンバーのフォローにどのくらい時間を割いた方が良さそうか、バランスを優先的に考えていました。

ですが気づけばどんどん開発スピードは上がっていき、単にスケジュールに間に合わせられたというだけでなく、クオリティも高められたと感じています。とても勉強になりましたし、開発チームとしても良い自信になったと思います。

 

尾崎

お二人とは、違った切り口でいけば、ペライチはスタートアップの特性上、ビジネス的に効果が出やすい開発を優先し、スピード重視の開発を進めて来ていました。

その弊害として、システムの拡張性が乏しい部分が出て来ています。

その部分がボトルネックとなり、今は逆にビジネスのスピードに開発のスピードが追いつけないという課題が出てきていて。

そうしてみると、1年前のプランのリファクタはやっておいて本当に助かりました。

また、今回の開発でも変化が大きそうなビジネスロジックが含まれる部分は拡張性を考えた実装に切り替えることができました。

今後も、優先度をつけながら先手先手の動きが出来ればと思います。



佐藤

言われてみれば、今回は、関さんがテックリードとしての動きをよくしていただいたので、ビジネス側との調整に専念することが出来ました。

 

このチームは、本当にいいチームだったと思います。

今後の開発でも、今のいいチームをキープしていくのはもちろんですが、

マネージャーの視点としては、あえてチームのメンバーや立場を変えて見るのも大切かなと思います。

そうすることで、個人個人が成長して、その結果としてチームも成長できると思うので。

そういった、変化がどんな成長に繋がるんだろう、どんなストーリーが生まれるんだろう、と前向きに、楽しみに考えています。

 

(おしまい)

 

■最後に

 

今週も、最後までご覧いただいてありがとうございました。

 

実際に開発を担当したエンジニア素顔が垣間見れた今回の対談記事でしたが、お楽しみいただけましたでしょうか?

今週は、めくるめくITスタートアップの進化を支え、日々新たな価値を生み出す開発チームの方々にスポットを当てさせていただきました。

 

プロダクトそのものが「やさしいIT」として、ユーザー様の課題を解決し、また、幸せに導くことが出来るになることを目指す、と少し前のブログで株式会社ペライチ共同創業者・CTOの香月さんは綴っています。 

 

香月さんの記事はこちら

 

わかりやすくなったプランやオプションで、ペライチは「やさしいIT」へと一歩前進できたのではないでしょうか。現場のドラマから、作り手の情熱を感じ取っていただければ幸いです。

 

ペライチのブログでは、今後も、こんな対談記事をお届けしたいと考えています。

ぜひ、お楽しみに。