ディーカレットDCP

 

前編では皆さんの自己紹介や、チームの雰囲気などをお話しいただきました。後編では、入社後のキャッチアップ方法やどのように開発を進めているのかなど、皆さんの日々の業務について深堀りしてみました。

 

梶原 吉樹さん

プロダクト開発グループ / 開発チームヘッド

 

森 浩貴さん

プロダクト開発グループ / クラウドチームヘッド
サービス企画グループ / サービスデザインチームヘッド(兼務)

小林 敏幸さん

プロダクト開発グループ / 開発チーム

 

 

入社後はどのように業務やスキルのキャッチアップをされたのでしょうか

(森)私は入社してすぐにサンドボックス環境を作りました。正直当時はOJTというか習うよりも慣れろ、でした(笑)クラウドインフラの構築をして、その後ユニットテストを書いたり既存課題の解決をしたりなどをし、そしていま再びクラウドチームに戻ってきました。

(梶原)ブロックチェーンは複雑でキャッチアップが難しいので、私が入社したときは先輩社員が実際のシステムで手順を残してくれていて、キャッチアップする資料は整っていました。その手順に沿って、まずどういうものが動いているのか、どういうコンポーネントやサブシステムが存在するのかなどを学びました。

入社から2週間ほどして、プロジェクトに入り実際のシステムを触りはじめました。これまでの職場でもここまでオンボーディングの資料を用意している会社はなかったので、かなり整備されている印象はありましたね。

(小林)チュートリアルと呼んでいるシステムで動くキットが用意されていて、それを読み込んで試していました。あとはGitのソースを読みまくったんですよね。また、リポジトリにあるソースを片っ端から読んだおかげで、何がどういうものか、どうやって動いているのかは、机上でイメージできるようになりました。
あとAWSの全体構成図を見たら、ソースと対比させてなるほどと腹落ちできる情報でした。

(梶原)私には少し分かりづらい資料だったのでそっと閉じました…

(森)この間、私全部書き替えましたよ。どこに何がつながっているのかわかりやすくなりました。

(小林)個人的には、俯瞰してみたい時は構成図を見るのが一番速いかなと思っています。ちゃんとチュートリアルはやりましたが、それだけでは理解できない部分はソースを読んで理解を深めました。ブロックチェーンはこう動くんだというのがわかりました。

(梶原)たしか小林さんも、入社2週間くらいで実際に手を動かしてもらいましたよね。

(小林)すぐにjavaのバリデーションを直した記憶がありますね。でも私はまだ入社して一年も経っていないんです。

(森)そんなに短いですか?

(小林)いつも話題に上がる部分を担当しているので、存在感をアピールできたのかもしれないです。

キャッチアップも皆さんそれぞれ意欲的にされていたんですね
では当社のプロダクトは具体的にどのように開発を進めているのでしょうか

(小林)スクラム開発を取り入れていますが、スプリント(開発の一つの期間単位)の区切り方含めスタンダードなものだと思います。

(梶原)そうですね。スクラムマスター(タスクの振り分けなどを行う調整役)にも入ってもらうなど、最近は方法をアップデートしています。スプリントは開発のチームでは2週間で区切っています。スプリトが始まる前に、リファインメント(何を達成するべきかの合意)およびプランニング(作業の明確化と計画の作成)をします。私がプロダクトオーナー(プロダクトの責任者)の代わりにチームメンバーとプランニングをすることもあります。

エピック(担当範囲でグルーピングされたもの)からタスクを用意して、プランニングポーカー(ストーリーポイントを決める会議)でストーリーポイント(タスクの規模の見積もり)を立てます。あとはベロシティ(チームの過去の実績)を参考にして、リファインメントで決めた優先度をもとにスプリントで対応するチケットを決めていきます。

また、そのチケットひとつひとつで、チーム内でレビューをしながらテストを行い、最後にはスプリントレビュー(スプリントの成果のレビュー)をしてどこまで達成できたかの確認と振り返りをして、次のスプリントに活かしていきます。スプリントで課題があった時は、それに対して新しい取組みを取り入れたりもします。

 

(森)スプリントが3週間だったり2週間だったりチームによって違いますね。

当社ならではの特徴はありますか

(森)他よりかっちりしていますね。曖昧なままとりあえず着手することはよくありますが、当社ではゴールをしっかりと定めますね。

(梶原)通常だと、すでにあるシステムにある機能を追加するまでを一定期間で実行しますが、我々のサービスはまだ公開していません。しかも大規模システムを構築している途中なので、まず全体の構成を整理して、この機能の設計をここまで進めるとか、次のスプリントで設計や実装に着手できるための準備を終わらせるなど、現状のプロダクトでは少し変則的なやり方なのかなとも感じます。

(森)当社がつなぐのは金融機関のシステムなので、ちょっとお試しみたいなことはできないんですよね。だからこう、かちっと決めて固めて本番まで行こうというイメージです。

(小林)来年7月にリリースするプロダクトは規模が大きいので、細分化して工程もコンポーネントも細かく分けて、みんながそれぞれの単位の中で回している感じですかね。そこが通常のスクラムとは少し違う、当社なりのエッセンスでしょうか。

決して多くはない開発メンバーの能力を最大限に活かせるような考え方ですね
では最後に、仕事のやりがいを教えてください

 

(小林)私の担当は、ブロックチェーンネットワークが違うもの同士をつなぐっていうとこなので、考えることが多くて面白いんですよね。単純に暗号系のブロックチェーンだと、そういう目線はなかったかなと思います。今業務にあたっている領域だとやっていて発見もあって、それがやりがいです。

あとはデジタル通貨DCJPYがリリースしたとき、世の中にどのような変化が起きるんだろうっていう期待ですね。いま存在しないものなので、社会に対してインパクトがあるだろうと思っています!

当社のサービスで、様々な企業を含んだデジタル通貨の経済圏ができるといいですよね。まだイメージはしづらいかもしれませんが、ひょんなことで「デジタル通貨ってすごい」って感じてくれるはずなので、まずはそこを目指したいです。

(森)新しい技術系はやりがいがあります。そういうの好きなんで。他のクラウドだとマルチリージョン対応はしていなくて、24時間365日動かさなければならないという要件もないことが多いと思います。当社が提供するのは金融サービスなので、通常のWEBサービスでの障害対応よりもはるかに高い水準を求められていて、それをこなしていくのはやりがいですね。

(梶原)確かに動けばいいというサービスではなくて、動くのは当たり前だし、かつ当然障害や不正がなどは許されないものですね。要は設計において安易な考えではなく、ひとつひとつ思考を尖らせて、機能一つにおいてもこれがベストなのか、問題は起こらないか、万が一何かあった場合に被害は拡大しないのか、最小限に食い止められるのかなど様々なパターンを検討した上で進めています。
当社のシステムが止まることは絶対許されないわけで、シビアなものを求められていますが、そこに対して考えをめぐらすことが、やりがいにつながりますね。

 

ありがとうございました。世の中にないプロダクトを創り上げる難しさは、プロダクト開発グループの皆さんが一番感じているところですね。語りつくせないほど大変なことがあるかと思いますが、それをやりがいにつなげられるところに開発者の誇りを感じました。
<< 前編

 

※所属や業務内容はインタビュー当時のものです
※DCJPYは当社が開発するデジタル通貨の仮称です