アソビューAdvent Calendar 2023の4日目の記事です。
承前
こんにちは。今年の9月からバックエンドエンジニアとして「アソビュー！」にジョインした進藤です。今月は、「アソビューAdvent Calendar 2023」と題してアソビューを支える技術やエンジニアの開発Tipsに関する記事を毎日投稿していますが、今回は私の経歴などを交えながら実際にアソビューのなかで採用されているアジャイル開発（アジャイル開発はあくまで概念であり、具体的手法としてはスクラム）に慣れていくまでの間に感じたことをつらつらと書き連ねていこうと思います。まさにいまアソビューを転職先として検討中の方や、エンジニアとして更なるステップアップを考えている方への一助になれば幸いです。
私のこれまでの簡単な経歴
私は新卒から2社（アソビューが3社目）、システム開発会社を経験してきました。1社目はいわゆるSESと呼ばれる客先常駐型のシステム会社で約4年ほどテスターやプログラマーとして開発業務を経験し、2社目では主に非IT系の中小企業を得意先とした業務アプリケーション開発のシステムエンジニアとして10年ほど従事してきました。キャリア全般を通して共通しているのは、専門領域がWebオープン系であること、開発に使用している主要なプログラミング言語がJavaであること、そして開発手法がウォーターフォールモデルであることの3点です。
ウォーターフォール開発’のみ’経験者がアジャイル開発に相対してアジャストに苦労した3選
もちろん「アジャイル」という言葉はアソビューにジョインする前から認知はしていましたし、前職では規模が小さくスケジュールにも余裕があり、かつ少人数で比較的挑戦的な取り組みが可能な軽い案件でスクラムの真似事のようなスタイルを実践した経験もあります。しかし、アソビューにジョインし実際に本格的なアジャイルを乗りこなさねばとなった時、私は最初大きな壁にぶつかりました。入社から3ヶ月経ちようやく環境にも慣れつつある今振り返ってみると、その壁の正体はテクニカルタームや慣れ不慣れといった類のものではなく、どちらかいえばマインドセットや価値観といったレベルのそれだったような気がします。言語化は難しいですが敢えて具体化するならば次の3点に集約されると思います。
- 最初から完全完璧を目指さない
- コードにはコミュニケーションツールの側面がある
- 自分のスタイルや内在する過去の成功体験に固執しない
1. 最初から完全完璧を目指さない
完全完璧を目指さないといっても、当然プロダクトを不完全な状態のままリリースしてもいいという意味ではありません。リリースするプロダクトはそれを必要とするユーザーにとって必要十分な機能要件を満たしていなくてはいけません。この、「必要十分」をどう見極めていくべきかの初期段階で、私は当初ウォーターフォール的な思考を無意識で採用しており、アウトプットを出すまでにかなりの時間を要してしまいました。
ウォーターフォールの構造的な弱点のひとつにリリースまでの物理的なリードタイムの長さがあります。その一方でプロダクトが利用されるビジネスサイドでは状況は刻一刻と変化していくのが常というもの。あるある話としてよく引き合いに出される例だと思いますが、ウォーターフォールでシステムを開発すると、それが納品され日の目を浴びる頃には全く使われない機能があちこちに…なんてパターンは私も経験があります。加えて、ウォーターフォールではプロジェクト初期段階で比較的時間に猶予があると思えてしまうため（実際そんなことないのですが…）、片っ端から情報収集に走り結果的には開発に一切不要な情報まで細かく整頓して仕事した気になってしまう…お恥ずかしい限りですが、そんな時間の過ごし方をしていたこともありました。
スクラムはスプリントという通常1~4週間の小さなリリースサイクルがあり（自チームの場合は概ね2週間）、そのサイクルを継続的を反復していきます。この1サイクルのイベントで何をゴールに据えて活動していくかはとても重要なポイントで、スクラムにはそれを適切に定義するための様々なコミュニケーションイベントが別途存在します。完全完璧を目指さないとここで謳っていますが、発想の根本を見直す必要が私の場合にはありました。流動的なビジネスにプロダクトがしっかりレスポンスしていくため変化を柔軟に受け入れること。最初から大きな絵を描くのではなく手元の小さい’キチンと動く’完成品をスピード感をもってユーザーに提供していくこと。そういう土台の部分から、私の認識はズレていました。
具体的にはチケット管理システムの改修案件でのエピソードがあります。これはもともと先んじてリリースが完了していたとある機能に、営業サイドからの要望を受け追加機能を実装するというものでした。この頃の私は入社したばかりでバックエンドで稼働する各種管理システムの仕様を把握していなかった時期だったこともあり、社内で運用されているチケット制作の流れを一通りレクチャーいただいたあと、それをそのままなぞるようにコードの解析に着手し始めました。必要な機能要件を実現するためには、まずシステムの全体像を理解する必要があると思ったからです。
しかし、設定されたスプリント内で達成しなくてはいけないゴールのなかに「システム全体の仕様を理解する」というタスクは存在していません。求められているゴールは「どんな機能設計を具体化すればユーザーに'最短で'価値を提供することができるか」それが必要十分に表現されたアウトプットであって、いつ必要になるか分からない周辺機能の情報収集ではないのです。土台となる思想が異なるとたとえスタート地点が同じでも細かい認識のずれが作業として積み重なっていった結果、気が付いたらゴールからはるか遠い場所に着地してしまうという（これぞアンチパターンという意味で）いい典型的失敗を実践してしまったなと思います。
※念の為。私はウォーターフォールそのものを否定するつもりはありません。例えばバックオフィス系業務のシステム化などの場合、システム要件が横並びで一気に出揃わないと暫定的な手運用によるコストが嵩み、かえってビジネスの停滞に拍車をかけてしまう場合もありうるとは思います。
2. コードにはコミュニケーションツールの側面がある
これまでのウォータフォール型のシステム開発においては、開発フェーズで生産されるソースコードはあくまで成果物のひとつでした。要件定義から外部設計および内部設計で徐々にブレイクダウンした設計ドキュメントをプログラム言語で置き換えただけのもの、それがこれまでのソースコードだったのです。そのため、プログラムの開発工程というのは’下流’なんていうある種不名誉な呼び方になり、その段階で開発者があれやこれやとクリエイティビティを駆使する段階ではないと教え育てられてきました。
一方アジャイル開発では（特にアソビューにおけるスクラムでは）、プログラミングに対する見方・位置付けが大きく異なる印象を持ちます。現時点の私の認識ではコーディングの完了はあくまでもコミュニケーションの始まりというか、それが現在そして将来的な継続改善を伴うライフサイクルのなかで本当にあるべき実装なのかどうかをチームメンバーはじめとする関係者全員で討議検証し合う有機的なコミュニケーションの起点の役割を果たしているように思います。
もちろん、プログラムコードのレビュアーになったこともレビュイーになった経験も前職まで多く経験してきました。しかしこれまでの「あらかじめ定義され決まっている約束事（＝設計）に対して、どれだけ正確なコードに落とし込めているか」という観点がレビューだったと思っていた私にとって、「ここをこんな風に書き換えてみたらどうでしょう？」や「こここんなに細かく書かなくていいと思います...」といったタイプのコメントは、最初かなり戸惑ったものです（なぜなら今までは「いやなぜって言われても設計がそうなってるから…」と返して終わりの世界だったので）
3. 自分のスタイルや内在する過去の成功体験に固執しない
（このパートに関してはスクラムはあまり関係ないのですが、経験者が転職を考えるときに改めて自己を見つめ直す必要があるメタ観点だと思い記載しています） キャリア10年選手ともなると、業界標準のスキルスタックと比較して自分は何が得意で何が不得意かを高い精度で理解し、こだわりと志向性を兼ね備え、信念に基づいて行動することが徐々にできるようになっていきます。それ自体は良いことだと思います。しかし、組織やチームの一員として（あやうい表現かもしれませんが）意志をもった歯車のひとつとして会社員の道を選んだのであれば、’思い’をいったん傍において常に周りを客観的に見る視点を私は重要視しています。
企業には、それぞれ目指すビジョンとそれを達成するためのミッションを掲げています。弊社のようなベンチャー企業であればなおさら、それらを確実に実現しなくてはいけないという切迫感は高くなっていく。手元にある作業が持つ価値の抽象度のレイヤーをどんどん上げていくと、最後には企業のもつビジョン・ミッションに必ず連結していきます。その手触り感がベンチャー企業で働く醍醐味とさえ感じています。
そんな中で、籍を置いている企業が掲げる本来目指すべき到達点に対して「これが正しいやり方なんだ！」と外で積んできた経験論的な視点、あるいは成功体験ベースで考える比重が多くなりすぎるとどんなことが起きるでしょうか。特に弊社のように、スピード感と変化適応性を恒常的に求められるスクラムの’現場’のなかで日々刻々と変化する優先順位のなかで自分のスタイルや成功体験を信じて突き進んでしまったらどうなるか。優先順位が少しずつだがしかし確実にズレていってしまうのは自明だと思います。
転職して新しい環境に移ると最初は誰でも手探りです。「1. 最初から完全完璧を目指さない」の項でお話しした私の失敗の本質的な原因は、「経験者は基本的なことを聞いてはいけない（誰もそんなことは言っていないのになんとなくそんな気がする。そんなことも知らないの？と思われるのは恥ずかしいことだから）」という引け目でした。それに対し、これまでの経験として非IT系の顧客を相手にスクラッチで業務システムの導入提案をいくつも成功させた経験が私の中にはあります。仲間とはいえ周囲に安易に頼ってはいけない（と思い込んでいる）そんな時どうするか。
私の場合は徹底的な情報収集でした。いま必要かどうかではない、とにかく全部必要なんだという意気込みでした。当時もう少し周りを冷静に見る余裕があれば、誰もそんなことをしていないのは明白だったはずです。周りの動き方をよく観察して、日々のやりとりのなかでどうやって仲間は最短距離で成果を上げているのかとりあえず真似してみるところから始めればよかったのです。成功体験への固執から成功を再生産するのは難しいと思います。新たな発見がありませんし、そもそも昔と同じことを繰り返すために転職したのでは意味がない。なにより楽しくないからです。
まとめ
ここまでお読みいただけたのであればお分かりのことと思いますが、今回はアジャイル開発の詳細な説明や実際のスクラム手法に関する具体的な解説ではありません。その1歩手前、テクニカルタームを無理なく乗りこなしていくための姿勢や心構えといったその最初の1歩、いや0から1歩目について記載したものです。覚えることや身体で理解していかなくてはいけないことは山ほどあり苦労は多いと思います。しかしながら、遅まきながらようやく最初の1歩を踏み出した実感のあるいまアソビューで毎日楽しく働けている私の思いを伝えたいと思い、この記事を書かせていただいた次第です。
アソビューのエンジニアとして働くことに少しでも興味が湧いた方、エンジニアとしての今後のキャリアに不安を抱いている方、ぼんやり転職しようか考えている方、 是非カジュアル面談からお気軽にご応募ください！一度お話ししましょう！
アソビュー！の技術情報を発信する公式アカウントもありますのでぜひフォローお願いします！ https://twitter.com/Asoview_dev
