この記事は、Money Forward Kansai Advent Calendar 2024 12月13日の投稿です 🎄
こんにちは、マネーフォワード関西開発拠点のAPIチームでインターンをしている進捗ゼミです。 私たちのチームでは、マネーフォワードのプロダクトがサードパーティーアプリケーションとAPIを通じて連携するための仕組みを作成しています。
私は週2でチーム開発に参加して、プロダクトの改善を行っています。 APIチームでは、アジャイルな開発プロセスを採用しており、開発者が自発的により良いプロダクトを目指しています。
そのようなチームで働くエンジニアには、単に作業ができる以上の能力が要求されます。 チームの一員として有機的にコミュニケーションを取りながら、自分でより良い意思決定を行う経験ができています。 その一方で、アジャイル開発のフレームワークは、開発者の役割が大きいため、週2しか参加していない学生にとっては実践が難しいことも多いです。
本記事では、インターン生の目線からやれる範囲でアジャイルな開発をするために考えていることを書きました。
やれる範囲で頑張るアジャイルとは
私の現状
私は、次のような内容は問題なく理解できています。
- 技術的な内容のキャッチアップ
- 担当している部分のプロダクトの動作概要
しかし、次のような課題を持っています。
- 1週間に開催されるミーティングのうち、半分以上参加できないこと
- チーム全体の進捗共有で把握できない業務が多々発生していること
- プロダクトのビジョンを考える機会がないため、あるべき姿が想像しにくいこと
- 全社的な取り組みを知る機会が少ないこと
このような現状は、技術系アルバイトをしている学生であれば、共感できる点が多いのではないでしょうか。 特に、大学生は103万円の壁の内で働こうとしている人が多いため、自分の手元の範囲外が見えにくくなってしまいます。
おことわり
マネーフォワードのインターンでは決して踏み込んだ経験ができないわけではなく、むしろ積極的に関わることが可能です。 やりたいと発言すれば、様々なプロダクト・技術に関わる機会があります。 私は研究活動、趣味の技術活動も重要視しているため、リソースの100％を開発に費やすのではなく週2回という制限を設けています。
せっかくだしアジャイルしよう！
仕事の理解が不十分な点があると書きましたが、実際のところ、それが原因でただちに困るようなことはありません。 むしろ、作業者としてそこそこ上手くやるという守りに入った考えをすれば、指示の範囲さえ理解していれば大きく失敗することなく開発できます。
とはいえ、せっかくインターン生として実運用されているプロダクトと実稼働している開発プロセスに関わっているのだから、作業者を超えたエンジニアとして働きたいと考えています。
やれる範囲で頑張る戦略
普通の開発者向けの行動ガイドや普通の技術書に書かれているやり方だと上手くいきません。 なぜなら、フルタイムの開発メンバー向けに書かれているため、作業量や前提知識が多すぎるからです。 そこで、私はやれる範囲のプラクティスを見つけ出すために、次のような戦略をとりました。
- アジャイルのコア部分を理解する
- 各種プラクティスがどうして有益かを理解する
- 本質を損なわない範囲でプラクティスを修正する
step1. アジャイルのコア部分を探る
アジャイルのコア部分を理解するため、古典的名著であるエクストリームプログラミングを読みました。そのなかから、私が重要だと感じた部分を紹介します。
シンタックスとセマンティクス
次の文章は、第二章の一節です。
ソフトウェア開発が車の運転に似ているのはそのためだ。道路をまっすぐに走らせればいいわけではない。チームの中にいる顧客は、チームが目指したい地平線を心にとどめておく必要がある。
車の運転では、道路交通法があり、そのルールに従えば一応失敗することはありません。しかし、それだけでは目的地に到達できないのです。 よく考えてみると、世の中にはこのような構造があふれています。一段階抽象化して捉え直してみましょう。
シンタックス
シンタックスとは、形式的に正しさを検証できるルールのことです。 シンタックスが正しいとは、少なくとも守られるべき形式的ルールを満たしている状態です。
プログラミングをしていると「Syntax Error」という文言を見つけることがあるかと思います。プログラミング言語として最低限形式的に満たすべき記法が満たされていない場合にSyntax Errorとなるのです。
セマンティクス
セマンティクスとは、物事の意味内容のことです。 セマンティクスが正しいとは、内容が意味を含めて正しく、価値観に一致する状態です。
フロントエンドエンジニアの方であれば、セマンティックWebや、セマンティック要素などの用語を聞いたことがあるかもしれません。
価値・原則・プラクティス
三段階の構造
エクストリームプログラミングでは、開発者が実践するべき内容を、価値・原則・プラクティスの三段階で説明しています。
- 価値：最も根源的、直感的な実現するべき哲学
- 原則：価値を達成するための活動指針
- プラクティス：具体的な行動、やり方
ただ行動するのではなく、基本的な価値から出発して、それを実現するための手段であることを明確にして行動をとるべきなのです。
ソフトウェアの構造
エクストリームプログラミングは「プロジェクトの成功」を導くために価値・原則・プラクティスというピラミッド上の構造を提案しています。 この構造は、ソフトウェア開発でも同じです。「ソフトウェアの目的」を導くために、要求分析・設計・実装が行われています。 開発者も、ただコードを変更するのではなく、基本的な要求から出発して、それを実現するコードであることを理解するべきなのです。
私の考えるコア
私が考えるアジャイル開発のコアは価値・原則・プラクティスのすべてのレイヤーにおいて、セマンティクスが正しいソフトウェアを作り出すことです。
step2. プラクティスがなぜ有益かを理解する
アジャイル開発では、さまざまなプラクティスが提案されています。しかし、労働時間などの制約から、私がそれをそのまま実施することは難しいです。そのため、プラクティスを分類して、パターンごとにプラクティスの背後にある原則を理解します。
実験する
ソフトウェア開発中、論理的に正しい推論をするだけでは、セマンティクスが正しいとは限りません。自分の知らない制約や文脈が隠れていることが多いからです。そのため、アジャイル開発では、セマンティクスが確実に正しくなるよう、実験を推奨しています。 このパターンのプラクティスには、次のようなものがあります。
- 小さく頻繁なリリース
- KISS原則
- なるべく早期に失敗する
エクストリームプログラミングには、「勇気」「フィードバック」という価値があります。
エキスパートと相談する
ソフトウェア開発でセマンティクスを正すための最短の方法は、知っている人に教えてもらうことです。もちろん、すべての分野のエキスパートは存在しないので、対象領域ごとに相談することになります。特に、ソフトウェアを利用する顧客は、価値のレイヤーのエキスパートと考えられます。 このパターンのプラクティスには、次のようなものがあります。
- ペアプログラミング
- 全員が物理的に近い場所で働く
- 顧客と身近になる
- 完成の定義を行い、顧客が価値を感じる最小単位で進捗を共有する
エクストリームプログラミングには「コミュニケーション」「フィードバック」「リスペクト」という価値があります。
ドメイン知識を学ぶ
必要な知識が得られない場合に都度試したり、聞いたりすることは常に重要です。しかし、開発者が事前に広い知識を持っていて、直感的にセマンティクスを正しくする方法を理解していると、非常に効率よく開発することができます。 このパターンのプラクティスには、次のようなものがあります。
- ドメインモデル
- ユビキタス言語
- ユーザーストーリーマッピング
現代のソフトウェア開発ではドメイン駆動設計が非常にメジャーなものになってきました。
step3. 本質を損なわない範囲でプラクティスを修正する
最後に、私が今後実践していきたいと思っている簡易版のアジャイルプラクティスを紹介します。
問題の種別を区別する
エンジニアとして開発する以上、誤りは避けられません。そして、誤った場合には原因を探って改善することになります。 この振り返りをするときに、シンタックスとセマンティクスを意識して対策を考えるとよいです。大まかには、次のような方針を取ります。
- 誤りがシンタックス由来であれば、記憶や技術的成長によって減らしていく方法を考える
- 誤りがセマンティクス由来であれば、早期に間違いに気づくための方法を考える
セマンティクス由来の誤りを減らすにはドメイン知識を学ぶぐらいしか対策が取りにくいです。 しかし、参加の度合いが低いと、知らない場所でどんどんドメイン知識がたまっていくので、事実上セマンティクス由来の誤りは無くなりません。 そのため、自分が文脈を理解せずにピントのズレたことをしているという前提で行動したほうが良い結果を生むことが多いです。
チームの仕事のセマンティクスを聞く
普通にアルバイトとして働いていると、チームで働いている同僚のタスクにまで目が向きません。 そこで、ランチや休憩時間で、素直に「この仕事をするとどんなことが嬉しいんですか？」と聞いてみましょう。 一番簡単な話題にもなりますし、チームの価値や原則について理解できることが多いです。
直接会話するまでしなくても、事前に同僚のチケット、タスクを眺めておくのも有効です。 現時点の雰囲気をわかっていたほうが、チームへの帰属感も高まります。
価値と原則を知る
アジャイル開発では、プロダクトの実現する内容の価値、原則を少しずつ修正していきます。 このような価値・原則レベルの修正は、PdM（プロダクトマネージャー）やチームのリーダーがステークホルダーと相談しながら行っています。 逆に言えば、インターンレベルでどうにかできるものではありません。 そのため、簡易的なアジャイル開発として、現時点でのプロダクトの価値と原則を簡単に書き出すことをおすすめします。
自分のやっているコード修正は、コードさえわかっていればどうとでもなりますが、それがどうして価値につながるかを理解しておくと、少し仕事が楽しくなるはずです。
原則のレイヤーで考えて、チームのメンバーと相談する
前節で、インターンレベルだと価値・原則に立ち入ることはできないと書きました。しかし、何もできないわけではありません。 自分のタスクに取り掛かるときに、何を重視するべきか、原則を意識して設計すると良いです。
例えば、開発中に次のような選択をすることがあったとします。
- 後方互換性 vs 機能のシンプルさ
- 厳密な整合性 vs レイテンシ
このときに、原則を意識していないと「プランAだとこうで、プランBだとこうです。どちらがいいですか？」と質問したり、勘で設計したりすることになります。 原則を意識すると、「チームで・プロダクトで・この機能で重要な観点はこれだから、この品質特性を重視するべきなので、プランAかと思うのですが、どうでしょう」という提案ができるようになります。
大抵の場合、知識不足や技術不足でセマンティクスがズレた提案をしてしまいます。 しかし、それは本質的な問題ではありません。メンバーからアドバイスをもらって、提案を修正していきましょう。 仮にピントが合っていない提案だとしても、なんとか仮説を立てて、必要な要求を整理して設計する習慣が成長を促します。
たくさん感謝する
簡易的なアジャイルを頑張ると、セマンティクスの理解不足をいろいろな人に教えてもらう機会が増えます。 すると必然的に、感謝する機会が増えていくはずです。リスペクトがエクストリームプログラミングの価値であることが実感できると思います。 逆に、感謝する機会が少ないと感じるならば、自分の担当範囲だけで仕事を終わらせていることが原因の可能性が高いです。
「分からないことを頑張って見つけて聞く」というマインドを持つべきだと考えています。 「分からないことがあったら聞く」というスタンスだと、自分の範囲が分かれば何も質問しなくなってしまいます。 しかし、アジャイル開発をするなら分からない範囲は無限大のはずです。
おわりに
今回は、インターン生の体験から、アジャイルな働き方をどう達成していくのかについて書きました。 他の学生インターンの方の記事を見ていると「バリバリ働いて技術学んでます！」「2ヶ月でここまでやりました！」みたいなものが多いですが、その働き方について言及されている記事は見つけられませんでした。 この記事を書くことによって、新しい観点を提供できたのであれば幸いです。 短期集中で一気に成長するというのも大切ですが、持続性のある活動をするのも重要です。 今後もやれる範囲で頑張って、チームに貢献していきたいです。
