アジャイル開発をサポートするための法務部門のマインドセット
こんにちは。
ここ数年、日常的にも、「DX」や、「SaaS」「MaaS」という言葉が聞かれるようになり、そうしたサービスが身近になったり、最近ではChatGPT等のツールも話題になっています。
私は、東京で弁護士をやっており、取り扱う案件のほとんどが、国内外の企業法務案件ですが、こうした話題にやや先行して、ソフトウェア開発等に関する相談もよく目につくようになりました。
私自身は、かつて担当した案件をきっかけに、情報処理学会のワーキンググループに参加し、開発手法毎の契約の在り方について法律家や開発の担い手の先輩方から学びながら、日々の業務に取り組んでいます。そのため、比較的そうした相談の際にもイメージが持ちやすかったのですが、いわゆるアジャイルと呼ばれる、今では主流ともいえる開発手法の在り方が、法務部門に必ずしも浸透しているとはいえないことから、法務部門が迅速かつ効率的な開発のボトルネックになってしまいかねない場面にいくつか遭遇することがありました。
一般に、企業法務におけるリーガルサービスの提供においては、当該事業をよく知ることが重要です。そこで、最近では、どうすればアジャイル開発のより正しい実践が適うのかという関心を持ち、法務部門へのアジャイル開発の浸透ということを私なりのテーマとして、ワーキンググループでの活動に取り組んでいます。
このような経緯の中で、情報処理推進機構（IPA）様におつなぎいただく機会を頂戴し、IPA発行の「アジャイルプロジェクト実践ガイドブック」において、私のこの取り組みをご紹介いただけることになりました。
そこで、今回は、「アジャイル開発をサポートするための、法務部門のマインドセット」として、なぜアジャイル開発に関してのマインドセットを法務部門において醸成する必要があるのかという点と、私がこれまでの活動を通じて必要だと考えている３つのポイントをまとめてみたいと思います。
また、今回、わかりやすく、手軽に、一人での多くの法務部門担当者にイメージを持っていただくことが、アジャイル開発に基づく社会そのものの発展にも資するのではないかとの思いから、本記事をストーリータッチの資料にもまとめましたので、アップロードします。適宜ご活用ください。
なぜ、アジャイル開発に関するマインドセットが必要なのか？
私が実際に経験したエピソードを公開できるよう一般化したストーリーをご紹介したいと思います。
とある後輩のアソシエイト弁護士（A弁護士とします）が、あるクライアント様から業務委託の契約書のレビューを依頼されました。
私は、彼のレビュワー兼スーパーバイザーとして、彼からレビュー結果を受け取り、確認する役割だったのですが、彼から受け取ったレビュー結果の内容を見てみると、管轄の部分であるとか、損害賠償責任の範囲だとか、必ずしも契約の主要な部分とは言えない部分についてのみを修正し、かつ、その修正は、あまりクライアントと先方の間のパワーバランスも考慮できていないものでした。そして、クライアント向けに「どのような業務を委託されているのか不明なので明確にしていただくようお願いいたします」等のコメントがいくつも入っている状態でした。
率直に言うと、非常に出来の悪いものだったのですが、A弁護士はもともと非常に優秀な後輩であったこともあり、A弁護士が、どのような実体がある契約書なのかがつかめていないことが原因であるとすぐにわかりました。
業務委託に限ったことではないのですが、我々弁護士を含む法務部門が行う契約書レビューでは、対象となる取引がどのような取引で、実際に当該取引に基づいてどのようなオペレーションが行われるのかを明確にイメージして、正確に契約書に落とし込むことが必要です。単なるひな形を利用しただけではなく、法務部門によって個々の案件ごとにアレンジが必要な理由はここにあるのです。
そこで、私は、A弁護士を呼んで、彼がどのような視点でレビューしたのかを聞いてみました。
すると、「作ろうとしているソフトウェアが完成すればどんな価値があるのかということは書いてあるのだけれど、肝心の、具体的にどんなソフトウェアを作成するのか、とか、ソフトウェアを作成するためにだれがいつまでに具体的に何を完成させればいいのかということがほとんど書いておらず、出来の悪い契約書で修正案をいきなり作るのは無理だなという印象を抱いた。そこで、まずは、クライアントに聞き取りをすることにしたいと考えた。」ということでした。
また、「会議への出席を発注者側にも課すなど不利な条項が多く、大幅な修正が必要に思われる。そのため、修正にはそれなりの時間がかかるということもクライアントに伝える必要があると考えている。クライアントが既に先方と大筋で合意してしまっているのであれば仕方ないのかもしれないが、このままビジネスサイドの決定だからと言って飲んでしまっていいのか不安がある。」といって、ずいぶん悩んでいる様子でした。
私は、A弁護士の説明を聞いて、「やっぱり」と思いました。つまり、A弁護士は、目の前の契約書の向こうで実際に行われようとしている開発の現場では、アジャイルが採用されており、トライアンドエラーを繰り返しながら、実現したい価値に向かってスクラムで開発に取り組んでいるという実態がイメージできていなかったのです。
そこで、私は、大まかなイメージを持ってもらえるようにと、以下のようなポイントをA弁護士に伝えました。
今日では、開発の手法にもバリエーションがあり、その中の一つがアジャイル開発であること。
従来の開発手法であるウォーターフォール開発と、比較的最近になって主流となってきたアジャイル開発では、開発プロセスが大きく異なるにもかかわらず、民法典が想定する請負契約や準委任契約の法的枠組みが、一見ウォーターフォール型と親和的に見えることから、契約書レビューを行う際に、法律家は、意識するしないに関わらずウォーターフォール型をイメージしてしまい易い傾向があること
開発の現場ではもはやアジャイル開発が主流と言ってもよいし、むしろ、ウォーターフォールで行うべき場面でもアジャイル開発を採用しようとしてしまうことの問題点が指摘されていたりもするほどでもあるので、システム開発の契約書をレビューする際に、自分がこれまでに勉強してきた感覚からするとよくわからない契約書だなと思った時は、アジャイル開発じゃないかと考えてみることがヒントになり得ること。
そうしてもう一度A弁護士に修正案を検討してもらったところ、すぐに非常に的を射た修正案を持ってきてくれました。
なんでも彼は、それまで、それまで、「アジャイル」という言葉も聞いたことがなかったそうです。私も、試しに、事務所内や所外の親しい弁護士に聞いてみてみましたが、特に若く経験が浅い弁護士は、知らないという人が大半でした。もちろん、正確な見識に基づいて業務にあたっている弁護士の先生も多くいると思いますが、おそらくは、経験を重ねるうちにアジャイル開発のための取引に関する依頼を受けてノウハウの一つとして属人的にため込まれている状態で、殊更に切り出して後輩にレクチャーするということはないのではないかという印象を持ちました。
また、企業の法務担当者の方も、特に発注者側ではシステム開発に殊更に明るくない場合もあり、アジャイル開発に関する理解の状況は、上記のような弁護士の状況と類似しているようでした。
こうしたやりとりから、私は、まず、①弁護士や法務担当者といったシステム開発の現場以外にも、アジャイル開発とはどんな手法なのかというイメージが浸透すること、そして、②そうした開発の取り組み方に関する抜本的な考え方の違いが、システム開発の業務委託契約という、私たち法務部門が普段よく目にする契約の書きぶりに大きな影響を与えているという認識が、経験が浅く勉強時間もあまりとれない若手の弁護士にも広く伝わっていく必要があるのではないかと感じました。
知識ではなく、イメージの共有が必要。
では、実際に、法務部門が、契約書レビュー等のリーガルサービスを提供するに際して、どのようなポイントを押さえておけばよいのか、という点についてなのですが、これは、ポイントを絞ってコンパクトにしておく必要があると考えています。
つまり、仮に、何らかの大きな開発のプロジェクトがあり、そのためにリーガルチェックにもそれなりの予算を取ってあるというようなというようなケースであれば、すでに法務担当者向けのアジャイルに関する専門書も出ていますので、弁護士や法務担当者も、そうした書籍等を参考に、勉強をすることができます。
しかし、そういったケースはほとんどレアと言っていいと思います。多くの場合は、開発のプロジェクトが決まり、内容も大筋固まって、契約書を作成し、双方リーガルチェックを受けるということになるわけで、その時に初めて契約書が我々法務部門の目に触れます。そのため、リーガルチェックの依頼の時点で、瞬時に、契約書の文言と担当者の大まかな説明から、「これはアジャイル開発なのではないか？」と頭に浮かばないと、アジャイル開発をウォーターフォールでの開発に直すような契約修正をしてしまい、法務部門がビジネスのボトルネックとなってしまうような状況を招きかねないのです。
そういった観点から、システム開発においては、アジャイルという開発手法があって、目の前の契約書に落とし込まれている取引としての開発が、そのアジャイル開発の手法をとっているのではないか？というアイデアがすぐに法務担当者の頭に浮かぶようになることを目的とした浸透が必要であると考えています。また、特にそのような契約書を最初にチェックするのは、比較的若手の担当者であることが多く、すぐにイメージを持てるようにして、明日からの業務に役立ててもらうことが、ビジネスのスピードを阻害しないという観点からは重要であると考えています。
そこで、アジャイル開発に関する詳細な法的分析を行うのではなく、必要に応じて、そうした専門的な書籍等にアプローチするきっかけとしてのイメージの想起ができるコンテンツを、発信できればと考えています。
したがって、今回は、私自身がこれまで経験したことを踏まえて、本記事の読者の方々には、以下の3つのポイントを押さえていただければと考えています。
従来の手法と比較すると、開発対象の解像度に違いがある。
アジャイル開発の性質上、開発開始の契約締結時点では、そのプログラムでどんなことを達成するのかを明らかにして合意していることこそが大切といえます。
そして、達成したいことに到達するまでの課題は具体的に何であり、その課題をどう解決するのか、つまり「どのように」その達成したいことを実現するのかということを、開発行為を進めながらトライアンドエラーを繰り返して整理していくプロセスを踏む点がアジャイル開発の特徴と言えます。
そのため、契約締結時点では、最終的に開発されるものがある程度解像度が低い状態で認識されるのは当たり前と言えます。むしろ、最初から決め切らないことで、最終的に、達成したい目標に対して、当初思い描いていたものよりもより直接的でより良い成果が出来上がる可能性を秘めているところが、アジャイル開発の効用ということもできるでしょう。
したがって、契約書のドラフトを作成するような段階では、開発プロセスにおいて受注者側と発注者側がビジネスゴールを共有し、円滑なコミュニケーションをとれるようにプロセスを設計することこそが重要になります。
そこで、法務担当者としては、最終的な成果物そのものの解像度ではなくて、ビジネスゴールが明確に表現されているか、受注者側と発注者側のコミュニケーションが円滑に図れるような手続きが見て取れるかというところに目を配ったレビューをする必要があるのです。
ところで、民法が、2020年に改正されました。この改正により、民法には、新たに、成果完成型準委任という類型ができました。法律家としては、あいまいな類型が増えたなあという印象を抱いた方も多かったかと思うのですが、近年もはや主流ともいえるアジャイル開発の手法をとるビジネスの側面から見ると、むしろビジネスの実体に親和的な類型が民法にも創設されたということもできるわけです。
円滑なコミュニケーションの重要性
先述のA弁護士が抱いた感想にもあったように、実際のアジャイル開発に関する契約書を見ていると、一見、発注者側にも、会議への出席や報告の義務が課されたりと、発注者側に無用な負荷が課されているように見えるときがあります。
しかし、上述のとおり、最終的に何ができるのかもわからないアジャイル開発においては、キックオフ時点では、受注者と発注者は、一方的に決まった業務を委託するという関係性ではなく、共創により開発を進めるという関係性にあります。そのため、両者が密にコミュニケーションを取ることが非常に重要であり、発注者側がこうした負担を避けようとすると、アジャイル開発自体が成功しなくなってしまいます。むしろ、積極的に会議にも参加し、意見を言える機会を確保することが発注者の利益であるという視点で、契約内容を確認していくことが重要なのです。
そこで、まずは、そうした対立型の当事者の捉え方から、受注者と発注者で一律に線引きできないチームを構成することのイメージ（ラグビーのスクラム）へと切り替えることが重要になります。
また、アジャイル開発は、細かい目標設定などをすることなくだらだらと行ってしまうと、いつまでたっても開発が終わらない可能性があります。そのため、細かいスパンで検証してチーム内でこまめにコミュニケーションを取って確認しながら進むことを可能な範囲で契約に盛り込んでおくことが必要と言えます。
アジャイル開発が全てではない。
アジャイル開発は、すでにシステム開発の主流といえることはすでに述べた通りです。
しかしながら、アジャイルがウォーターフォールより優れているという関係にあるわけではありません。開発手法は、個々の開発に対して適切に選択されるべきなのです。システム開発に限って考えも、例外ではありません。
例えば、システムの開発そのものだけではなく、ローンチ後の保守などの委託も発生することは多くあります。その時の事情を踏まえた改修が必要であり、再度共創による改良が必要な場合もあると思いますが、保守などの作業においては、あらかじめ決まった作業を粛々と行うといった性質の業務を委託されることも十分あり得ます。
そのため、システム開発の基本契約では、アジャイル開発を念頭に置いた書きぶりを取りつつ、保守等の個別の段階に入って締結する個別契約では、ウォーターフォールを採用し、法的には、請負または準委任と捉えて契約書を作成することが適切と言える場面も十分にあり得ます。
既に現場では、アジャイル開発が主流となっていることから、最近では、受注者側が用意している雛形がアジャイル開発を念頭に置いた契約書であり、これを全ての取引に流用してしまっているという事例も見受けられます。
したがって、法務担当者は、システム開発であるからと言って、一律にアジャイル開発だと決めてかからないように留意し、特に、保守などの委託の場合には、どのような目的で行われる保守作業なのかを聞き取った上、適切な形式を選択することが求められていると言えます。
最後に
以上は、特に、発注者側の法務部門を念頭にした説明になっていますが、受注者側の担当部門においても、利用していただけると考えています。具体的には、発注者側から返ってきた契約ドラフトに、法務部門の担当者と思しき人物の修正やコメントがあって、うまく契約交渉が進まない様な場合に、法務部門に上記のような視点が抜けていることから来る認識の齟齬があって、ピントのずれた修正案が返ってきている可能性があるかもしれないとお考えいただくと、契約交渉もしやすくなるのではないかと思っています。
開発担当者だけではなく、法務部門も含めた企業全体に、アジャイル開発の在り方が浸透することが、開発によるイノベーションを加速させ、社会全体の発展につながっていくのではないかと思っていますし、この記事は小さな小さな発信ですけれど、この記事がそうした動きにつながってくれればいいなと願っています。
この記事が気に入ったらサポートをしてみませんか？