BeeXではクラウドのインフラ構築のほかクラウドネイティブなアプリケーション開発も行っています。今回は開発部門のエンジニア3人が集まり、BeeXの開発環境や働き方、クリエイターとしての視点、今後のプログラマーのあり方を語ってもらいました。前・後編にわけてご紹介します。
参加者
- Iさん
- 40代 アプリケーション開発
- Hさん
- 30代 アプリケーション開発
- Oさん
- 30代 アプリケーション開発
モダンな開発環境で効率的に進められる
BeeXのアプリ開発は、どのような工程で行っていますか。
Hさん:代表的な手法にはウォーターフォール型とアジャイル型がありますが、BeeXではお客様のニーズに合わせて両方を組み合わせています。今僕が携わっている案件はアジャイル型です。一番重要なのは技術者とユーザーが直接話せること。一次請けの仕事だからできるといえます。
Iさん:最初は先方のプロジェクトマネージャーがタスクを作り、こちらでイテレーションに割ってタスクをメンバーに振り分け、2週間くらいのスプリントで仕上げています。タスクを担当しているメンバーが直接お客様と会話しながら進めるのは大きな特徴かもしれません。
Hさん:結構モダンな開発環境ですよね。
Oさん:僕の場合、前職の開発環境は仕様書をWordやExcelを作るようなところで、ここに来て初めてモダンな環境を体感しました。バイナリデータだとコミットしても誰がどのバージョンを扱ったのかわからないし、そもそもどれが最新ファイルかわからない。新しいツールを全然使わない会社だったのでやりにくかったです。
Hさん:開発するエンジニアにとって会社の環境はかなり重要じゃないですか。僕もそこが嫌で前の会社を辞めたんですけど。
Iさん:ですよね。今は、基本的にタスク作成はTrelloを使って設計書はDropbox Paperで書いています。プロジェクトオーナーがパッと概要だけ書いたら中身を僕たちがリアルタイムで埋めていく感じ。フローチャートを書くときはwebツールを使って連携させています。ネットにつないでブラウザさえ見られれば、どこからでも一応仕事はできる。
Hさん:僕の案件だと2週間に1回お客様と次のイテレーションについて話を決めて、その先はSlackやDropbox Paperを介してサクサク細かな仕様を決めています。無理な条件があったとしても「この方法はどうでしょう」とすぐ提案できるし、技術をわかっているお客様がリアルタイムで返事をくれるので仕事が早いです。
Oさん:ソース管理はGitHubで、リポジトリの中でやり取りできる。GitHubだとレビューしやすいからいいですよね。
Hさん:そうそう。こういう便利ツールからのデータはアジャイルのプラクティスに貯まっていくので、開発するほど一層使いやすくなるメリットがある。ただ、設計に関しては対面のほうがいいです。お互いの顔を見ながら細かく「ああではない、こうではない」とやり取りする時間は絶対に必要。
Iさん:わかります、正直設計に関してはお客様のところに行ったほうがいいとアドバイスすることが多いですよ。チャットをしていても埒が明かないので「今から行きます」みたいな。設計は無から有を作るプロセスなので、お互いの意識の齟齬があると悲惨なことになる。顔色を見て落としどころを探らなきゃいけない。
Hさん:やることが決まって後は組むだけとなったら、リモートツールを駆使すればいいと思います。
個々のメンバーが力を発揮できるよう、チームでカバー
やはりウォーターフォール型に比べると仕事はやりやすいですか。
Iさん:2週間でチームとして持っているタスクを全員でやる、という方向に気持ちが向いて自然と集中できます。みんなにフルスタックの能力があればいいんですが、やっぱり人によって得意不得意がある。そこはチームの強みで苦手な部分は誰かが手伝うとか、ある程度自由に組める雰囲気です。
Hさん:プログラムを書くのはすごく早いけれど設計ができない、という人ならこちらが先に設計してあげて、手を動かしてもらったあとに自分たちがレビューするとか、チームでうまく回していくための協力は惜しまない感じがあります。
Oさん:そういうとき相談しやすい職場ですね。みんな同じミッションに向かっているからお互いの様子がわかるというか。 定時内に終わるタスクだし、一人でずっと悩むようなことはないです。
Iさん:あとは誰に何を頼むか、タスクを割り振る側の腕にかかっている(笑)。テストにこだわりがある人、問題抽出がうまい人、プログラミングの手が早い人、それぞれの得意分野で力を発揮してくれたらリーダーとしては万々歳です。
アジャイル型開発のメリットは、柔軟性の高さ
短いスパンで仕事が組めるのは便利ですね。
Oさん:アジャイル型はリリースまでのゴールが細かく決まっているので、いつまでに何を作るか、ペース配分ができるんです。意外と重要なのは「やめやすい」点じゃないですか。
Hさん:たしかに、テスト環境にデプロイしてダメとなっても別の手を準備できるのは、アジャイル型ならではでしょうね。
Iさん:開発中はお客様の都合で機能が急に追加になったり、予算の都合で要らなくなったりする。運用した後も想定以上にユーザー数が増えたり、操作性の悪さが見つかったりする。でもすぐ「次のイテレーションでこうしましょう」と話して方向修正できる。
Hさん:最初から完璧な設計というのは基本的にあり得ないんですよね、開発というサービスの特性として。
Iさん:それを見越して作っていくのもエンジニアのスキルだと思います。その分、一人ひとりの力が求められるとも言えるんですが、でもみんな任せるとできるんですよ。任せないからできるようにならないんだと思うんですよ。
Oさん:それはたしかにそうですね。
Iさん:アジャイル型だとプログラミングをする人も頑張れる。自分の力で何を変えられるのか見えるし、ユーザーの反応もわかるからです。前後工程のメンバーとしか接触する機会がないウォーターフォール型だと難しいんですが、直接お客様の声を聞けるアジャイル型の仕事はエンジニアにとって非常に楽しいと思いますよ。