「アジャイル開発の法務」を読んで改めて自分たちの開発チームをふりかえる
これは KWC Advent Calendar 2022 の最終日の記事です。
はじめに
こんにちは。KDDIウェブコミュニケーションズ（略してKWC）で技術部門のマネージャをしている青木です。
いつもはエンジニアイベントの登壇やテックブログなどで元気な若手の背中を押してベンチを温めてきたんですが、今回はアドベントカレンダーの満塁最終打席のバットをほいっと渡されて条件反射で受け取ってしまいました。
今回は最近読んだ本をもとにマネージャっぽい記事を書きつつ自分たちのチームを振り返ってみようかと思います。
アジャイル開発の法務を中心に扱った日本初の書籍ということで、「アジャイル開発の法務 スクラムでの進め方・外部委託・偽装請負防止・ＩＰＡモデル契約とカスタマイズ」（日本加除出版）が今年の年末に出版されています。副題にもあるとおりアジャイル開発の手法の内でスクラム開発をとりあげてまとめられた本です。
ソフトウェア開発の一部界隈では話題になっているようで、ネットニュースで流れてきた時に勢いでAmazonの予約購入ボタンをポチッとしました。
私たちは自社開発チームでサービス開発していますが、自社スタッフだけで事業ニーズに対応しきれない場合もあり、開発業務にかかわる契約周りの知識アップデートというつもりで読んでみました。
一読して思ったことは、開発プロセスやアウトプットについて会社間の揉め事にならないようにここは留意しようという点は、内製する場合でも共通する部分はあるよねということ。異なる立場のスタッフがいる中で期待される価値を生み出すために押さえなければ行けない点は似通ってきますね。法務的な観点でなくてすみません。
書籍の項目からいくつかあげてみます。
検査・検収
内製であってもテストは当然重要。
この項で、テスト駆動開発や継続的インテグレーションの採用を前提に、スプリントで開発されたインクリメントについて一定のテストに合格しているとしてプロダクトオーナーは完了確認とできると考えられると書かれてます。開発者としては「それはそうだよね」なんだけども、法務書籍でこうした記述がされていることに新鮮さを感じました。
テストについて杓子定規にいうつもりはありませんが、継続開発していくならやはりテストの自動化は重要ですね。ファーストリリース後の継続開発で手動テストは大変すぎる。いまのチームの開発メンバーはテスト書くのは当然でしょとなっており嬉しいです。
ドキュメント
アジャイル開発であっても必要に応じてドキュメントは作るよねということで、インセプションデッキ・ユーザストーリー・プロダクトバックログ・システム構成図やセキュリティ試験報告書などがあげられて、役割などについて簡単にまとめられてます。ここは内製でも必要に応じて、、、、、といいつつ気がつくと必要なドキュメントが不足している事も。
自戒をこめてドキュメント重要。
ちなみにKWCでは前年までドキュメントの形式や格納先が部署にやチームよってバラバラでした。今年、ドキュメントはConfluenceによせるように改善し見通しがとても良くなってきてます。ファイルサーバーの奥にあるメンテナンスされているかも分からないWordファイルよりも生きた情報が大事です。
アジャイル開発と偽装請負
偽装請負とは、形式上は請負や準委任など、労働者派遣契約以外の契約を締結しておきながら、実態としては発注者が受注者の雇用する労働者に対して直接具体的な指揮命令をして作業を行わせているような場合をいう
アジャイル開発の法務より
本来は派遣契約を利用しなければならないところを名目だけ他の契約形態をとっているため派遣法違反となります。
アジャイル開発ではプロダクトオーナー・スクラムマスター・開発者・ユーザが密なコミュニケーションをとりつつ開発を進めるため、外部委託先含めてチームを組む場合に連携が指揮命令とならないかという点で偽装請負が問題になります。
本書では厚労省の質疑応答集を引用しつつ、関係者が対等な関係の下で協働し、開発担当者が自律的に判断して開発業務を行っていると認められれば適正な業務委託となると示してます。対等な関係の下で協働とは、自律的に判断とは具体的にどういうことかが論点になる訳ですが、そこは本書をぜひ読んでください。
内製開発であってもプロダクトオーナー・スクラムマスター・開発者は対等な関係で議論し開発を進めるようチームを作る必要があります。またチームやメンバーが誰かに言われたからこうするではなくゴールに向かって合理的な判断を自律的に行うことは重要ですよね。
KWCでは居住地問わずエンジニア採用しているのでオンラインでのコミュニケーションが主体となり、slackではエンジニアのコミュニケーションが活発に行われてます。スクラムチームではないですが特にSREチームのチャネルはゆるいやり取りから業務上の議論まで常にチームメンバーが自律的に動きつつチャットでつながっているのが見てとれて感心してます。
まとめ
大分かいつまんで書きましたが、スクラム開発を前提にした法務本ということで身近な開発用語が要所で出てくることもあり、開発の各場面を思い浮かべつつ興味深く読み進めることができました。
今年は社内でバラバラだったツールが共通のJira・Confluence・GitHubに集約が進みSlackがよい感じで情報をつないでくれて、開発プロセス・アウトプットの見通しが本当によくなってきたことが実感できた年だったことを改めて思い返しました。
おわりに
KWC Advent Calendar 2022 をご覧頂きありがとうございました。来年も楽しみにしていてください。
私たちは、テスト書くのが好きな開発者・CI/CDの仕組みがないと落ち着かない開発者・スクラム開発に慣れた又は実践してみたい開発者を絶賛求人しております。関心がある方はぜひ手を挙げてくださいませ。
