ただし、顧客とエンジニアが共に不断の努力ができるのであればな！！！！！
この記事で言いたいこと
アジャイル開発をやると楽になるどころかメチャクチャ大変になる。
・・・でもそれで社会が良くなると信じたい。
はじめに
受託開発界隈で「アジャイル開発は無理だ」という嘆きをときどき聞く。
本当にそうか？と疑問に思っていざ「アジャイル 受託」とかで調べると、各ベンダーの公式サイトにあるブログ記事がヒットし、ポジショントークというか、ビジネス上の下心が透けて見えるものが多く、エンジニアからするととても 醜い 見にくいものが多い。
そんな中、私は受託としてアジャイル開発をやった一実践者（エンジニア）として、自戒を込めて、もやもやっと思ったことを書いてみたくなった。
アジャイル開発の話をするので、『アジャイルソフトウェア開発宣言』を一読した上でこの記事を読むと良い。
ただ正直アジャイル開発の実践的で技術的な、ためになる話をするわけではない。どちらかというとアジャイル開発に対する変な期待をぶち壊す話をしたい。なのでタイトル詐欺かもしれない。
軽量であるということ
アジャイル開発の実践的なフレームワークとして、スクラム開発やら XP (エクストリームプログラミング) とかカンバンとかがある。弊社ではスクラムやれるほど人数いないので XP を実践的にやってみたりもしている。[1]
いずれのフレームワークにせよ、「軽量フレームワーク」として説明される。
それも当然で、agile という単語の意味の通り、局面に応じて素早く対応することが求められる。だから フレームワーク = 価値提供までのプロセス が短い、"軽量"なものがアジャイル開発のフレームワークとして紹介される。
ただ、これの意味をちゃんと考えてみてほしい。
特にスクラム開発。数あるたとえの中でわざわざラグビーのあの「スクラム」を名付けているのである。「屈強な男たちががっちり組んで全員が全力で押し込み、少しでも誰かが力を抜けばすぐに崩れる」あのスクラムである。これが大変じゃないわけない。
もしラグビーの試合を一度も見たことない人はぜひ見てほしい。スクラムがどういうものかを。
つまり「軽量フレームワーク」という言葉とは裏腹に、というか、フレームワークが薄いからこそ、それ以外の要素 = 人 に多大な負担と能力が求められるわけである。[2]
"軽量"という言葉のイメージに騙されてはならない。
顧客と対話するということ
エンジニアだと、アジャイルソフトウェア開発宣言の以下の文面に目がいきやすい。
包括的なドキュメントよりも動くソフトウェアを、
(中略)
計画に従うことよりも変化への対応を、
この部分はエンジニアの実働に強く関わる部分であり、関心が高くなるのはわかる。
しかし、エンジニアにとって本当に大事なのは以下の文言である。
プロセスやツールよりも個人と対話を、
(中略)
契約交渉よりも顧客との協調を、
「個人と対話」と聞いて、ちゃんと顧客もその個人の一人としてカウントしただろうか。
そして「顧客との協調」と聞いて、具体的にどうすることが協調することだと理解しているだろうか。
この記事では特に受託開発で必要な、この「顧客との対話」の部分を強調して分厚く書きたい。
そもそもその顧客は対話を望んでいるのか
アジャイル開発に不慣れな顧客が多いことをまずは最初に指摘しておきたい。その上で、アジャイル開発を導入することでうまくいく顧客とそうでない顧客がいると私は考えている。
これは、アジャイル開発に理解がないだけでは足りない。強い言葉を使うと、そもそもアジャイル開発を導入する資格がない顧客がいる、ということだ。
誤解のないよう補足するが、「受託開発だから要件を最初に投げれば、あとは放っておいても納品される」と顧客が考えているかどうかという話ではない。それはアジャイル開発について十分な理解を得られていないことに起因している可能性がある。また「業務を十分説明できるほどの言語化能力」が顧客にあるかどうかでもない。それは開発側に業務内容を引き出させる能力が欠けている可能性もある。
そうではなく、たとえば、「余裕がない顧客」ではアジャイル開発の参加者足りえない。
要求を（取捨選択せず）際限なく詰め込んでこようとしたり、横柄な態度をとってきたり、対話を拒否するような振る舞いを見せることもある。
その余裕のなさは、会社の予算が少ないのに上司からの機能実現要求は高く内部交渉にリソースが取られる、人手不足で他の業務が忙しい、会社とは関係のない私生活の問題を抱えている等から生まれている。そのような状況下では自身のことに手いっぱいで開発の面倒を見ること自体ができなくなっている。理不尽だがそういった余裕のなさはアジャイル開発の成立を妨げる。
それ以外にも開発対象の業務に詳しい人と対話させてもらえないことや、（補助金等の惰性で）そもそも業務改善にあまり意欲がない等、アジャイル開発に不向きな案件がある。
そういった場合はむしろウォーターフォール開発の方が納品に至りやすいかもしれない。（ただし、価値のある製品になっているかは言及しない。）
アジャイル開発は顧客側も開発に前のめりになってもらわなければ、改善サイクルが回らない。それを見極めることは、お互い損をしないためにもとても大切である。
顧客と協調するということ
自分たちの文脈を押し付けるのではなく、相手の文脈を理解することがとても大事である。
特にエンジニアは自分の合理性を押し付けてしまう可能性がある。相手の業務の話を聞いたり見たりすると、なんと不合理なことかと思うことがあるだろう。また、UI/UX においても自分が使いやすいものにデザインすることがある。
しかし、果たして本当に相手の業務は不合理なのか。それはエンジニアの一面的な合理性にすぎないのではないか。まだ聞き出せていない他の業務との関連性によって一見不合理に見えているだけなのかもしれない。つまり情報が足りてない可能性がある。
UI/UX においても同様だ。 Web などの文化として自然でも、その顧客にとっての自然ではない。そこに配慮してデザインをする、もしくは顧客側に十分な説明が必要である。
ただ業務フローを理解すればいいのではない。顧客の業務がなぜそうなっているのか、どういう価値観で動いているのか。これらを理解しようとしなければ、協調など不可能である。
同時に顧客のビジネスに貢献することもちゃんと考えることも大事である。特に顧客ではどうしても把握できない技術的な面への配慮だ。
たとえばクラウド開発[3]で運用費や運用面を考慮するといったことだ。油断すると開発側の惰性で顧客に無駄に高い運用費を強いてしまうことがある。もちろん完璧な知識と技術力を持って運用費を最小化できるわけではない。だがそこに関心を払わない/新たな学習をしないで技術選定することは、顧客との協調とは程遠い。
また、協調において地味に効いてくるのは以下の点である。
包括的なドキュメントよりも動くソフトウェアを、
ちゃんと開発透明性を上げた上で、開発成果物を見せながら顧客とコミュニケーションをすると、顧客も安心する。それだけで利得がある。
エンジニア側が納期に間に合うか不安なのは、顧客にとっても同じである。エンジニアが安心するためだけであってはならない。顧客も安心させなければならない。
協調において、顧客のことを理解するだけでなく、顧客もまた開発側のことを理解してもらわないといけない。その上で動くソフトウェアはとても有効に働く。
開発側が考える「絶対これこうした方がいいと思うけどなぁ」が顧客に伝わらないことがあるが、ソフトウェアを見て触ってもらうと納得してもらえることは多い。
最後に、開発に参加する顧客に対する敬意を忘れてはならない。そもそも案件として発注してもらうには、顧客側の担当者が稟議を通して予算を確保してもらう必要があり、顧客側で奔走してくれている。また、そもそも担当者は開発に専念しているわけではなく、通常業務の合間を縫って参加してくれている。そのありがたさは忘れてはならない。
対話するために必要なスキルや面倒を引き受けられるか
上にあげたこと以外にも、対話しながら予算範囲内でできることを意識する、正確性を多少失うが噛み砕いた説明をする、顧客のことを不快にさせずに反論し交渉する等、さまざまな対話スキルがいる。[4]
理屈でわかる面もあるが、顧客との対話スキルは実践での経験を積まなければ身につかない部分も多分にある。身体感覚として身につけなければならない。[5]
それは時間のかかることであり、短期的にできるようになることではない。
エンジニアも対話スキルを身につける努力がアジャイル開発には必要である。
とはいえ、全員が全員、スキルが必要というわけでもない。
しかし、チーム内で営業能力とエンジニア能力がグラデーションでなければならない。ある人は営業能力がやや乏しいけどエンジニア能力が高い。また逆も然り。そういった人たちの集合でチームが成り立っている必要がある。
そうでなければ、どうやってエンジニアリングの観点を適切に顧客に伝え、逆に契約等の営業寄りな視点をどうエンジニアに伝えられるのか。どのように橋渡しされるのか。どちらかの能力が 0 か 1 かの人だけで構成されていたとしたら、それは今までと大して変わらないかもしれない。
そしてなにより、対話は面倒である。
もし対話が面倒でないのであれば、世界中のあらゆる紛争は存在しない。対話が面倒だから力で制圧しようとしたり、不満を抱いたまま黙ってしまうのである。
対話をしないほうが短期的には楽だと思えてしまう。それほどに甘美なインセンティブがある。
それはエンジニアもだが、顧客にとってもそうである。
対話を諦めない、甘美なインセンティブに抗い続ける、その不断の努力をエンジニアと顧客双方に求められるのがアジャイル開発である。
付録：対面で打ち合わせることの意義
顧客との対話では対面での打ち合わせが必要な場面は多い。特に弊社はバス専門であり、顧客であるバス会社はどうしてもパソコンやインターネットにまだ不慣れなことがある。そんなところで自分たちの都合で「楽だから」といってオンラインミーティングにすると、かえってコミュニケーションロスが加速する。
また、実際に顧客の会社に赴いて打ち合わせることは、思っている以上に得られるものが多い。
- 特に遠方から赴くと「遠くからわざわざきてくれた」と感じてもらい、信頼につながることがある[6]
- ジェスチャーや表情などが自然に近くなり、より相手の意図が読み取りやすい
- 実際に事務所等がどうなっていて、どういうところで社員は働いていて、どういう人がいるのかを見れる
- 顧客の資産状況やセキュリティ意識等も環境を通して見えてくることもある
- どういうデスク環境なのかを見ておくと、それを考慮した上で提案できるようになる
- デスクが狭くて「大きなディスプレイを置くのが難しい」「マウスの移動に制約がある」などあるかもしれない
- それを知らないままでは、なぜ相手が変な注文をつけてくるのかわからない、ということが起こる
信頼関係がそれなりに確保されてきたか、顧客側がオンラインに慣れているかなどを総合的に見た上でようやくオンラインミーティングでやっていくことが考慮される。
特に、どっちがいいかわからない、初めての顧客の一番最初の打ち合わせに関しては正直対面の方が安全なのではないかと思われる。
また対面においての注意点は、身だしなみや所作、言い回し等である。
エンジニアであることは（名刺交換等で）開示されるので大目に見られる部分もあるが、とはいえ最低限度はある。
やはり顧客は顧客であり、良い印象を与えることに気を遣わなければならない。打ち合わせは、単に意見交換だけの場ではない。我々が顧客の状況を把握するように、顧客もまたスーツや身につけているものでどれくらいの企業なのかを品定めする。資金繰りは問題ない（社員にちゃんと報酬を与えている）か、信頼に足るのか。
そのように考えると、営業職が良いスーツ・良い所持品をつけるのは、顧客を安心させる側面もあるだろう。見習っても良い。
それでもアジャイル開発をやるということ
ではなぜそんなに大変で、面倒くさくて、しんどい、このアジャイル開発をやるのか。
それも受託開発でわざわざやるのはなぜか。
それは儲かり続けたいからである
アジャイル開発の大変さは短期的には負担が大きいことは明らかである。実践した肌感覚としても、ウォーターフォール的なそれまでの開発と比べると大変だった。
一方で、以前よりも顧客にとって価値のある形で製品を提供できている実感がある。ここにアジャイル開発の導入理由がある。価値あるものをちゃんと提供すること。そしてそれによって以下のことを期待している。
- 良い製品の導入によって顧客側で業務負担が減る
- より顧客側が自身のビジネスに集中できる
- 顧客側が提供しているサービスが良くなる
- それによって顧客が儲かりやすくなる
- 儲かった分で新たに業務改善をしようとする
- 良い製品だと顧客側で評判になれば、弊社に新たな案件を発注してくれる
つまり開発努力によって、新規顧客獲得に投じるはずのコストを削減しうるということである。これはとても気の長い話だが、長期的には確実に意味のあることだと思っている。
新規顧客獲得にコストを投じ、案件の数を捌いた方が短期的にはそちらの方が利益が出るかもしれない。しかし、それで使いづらい製品を納品していてはパイが増えないのでゼロサムになって新規顧客競争が加熱しコストが上がるばかりである。
逆に他のベンダーも全員が同じように価値ある製品を納品していれば、社会全体としてとても良いことだ。
その結果、たとえ弊社に案件の発注してもらいづらくなるとしても。
なぜなら良い製品を納品し、顧客が本業で儲けてもらってパイ自体が増えれば、ゼロサムではなくなり、どの開発ベンダーも儲け続けられるかもしれない。そちらの方が良い生態系ではないか。
顧客というのは究極的には全ての会社であり、ひいては社会全体の成長に貢献するということでもある。
・・・まあ、正直ここまで考えた上で受託開発をやっていたとして、これで儲からないのはおかしいから、ちゃんと儲かるような世の中であってほしい。[7]
そして何よりアジャイル開発は楽しい！！！！！
あーだこーだ言ったが、結局私はアジャイル開発をそれなりに楽しんでいる。
顧客が何を望んでいるかを推理するゲームをやっているような感覚だ。動くソフトウェアを通して顧客の要望を探り、対話でも引き出せない「本当に必要だったもの」を当てることができたら最高である。
逆にアジャイル開発を楽しいと思えないのであれば、素直にやめた方が良い。
さいごに
アジャイル開発について書きたいことは書いた。なんなら勢い余って詰め込み過ぎたかもしれない。それでも、もう少しだけ、アジャイル開発からズレるかもしれないが、書いておきたいことがまだあるのでそれに触れる。
「良い製品」「良い開発」は誰にとっての「良い」？
開発生産性の議論で「良い製品」「良い開発」に注目する機会は多いだろう。しかしそれがエンジニアリングの中で閉じた議論であるならば、あまり実際のビジネスに紐づいているものではなく、結局机上の空論になりかねない。
「良い製品」「良い開発」というものを、営業や経営まで全てを包括し、顧客との長期的な信頼関係の構築という文脈において論じられなければならない。
エンジニアが頭の中で考えたものではなく、ちゃんとビジネスというものをやって、身体感覚として身につけた、地に足つけた「良い」について議論されなければならない。
これは、当然アジャイル開発を論じる上でも大事な視点である。
アジャイル開発を導入したいと思っているとき、それに関わるステークホルダーすべてを包括して考えられているか、改めて自問してほしい。
そして、他の立場、他の価値観、他の合理性を把握すること、理解しようとすることを怠らないでほしい。相手や制度を否定する前に、まずは「対話」と「協調」をしてほしい。
営業・経営・開発の間で苦しみながら、その中での妥協点を探りながら、その時点でのベストを尽くすことを諦めない。その悩みの中にきっと解はある。
アジャイル開発と心理的安全性は隣接している
本記事のアジャイル開発に近い話は、「心理的安全性」の議論にも通ずるところがある。というより、アジャイル開発に心理的安全性が求められるから大事な議論だ。
ただ、「心理的安全性」に関しての優れた記事はすでにあるので、以下に少し紹介するだけにとどめたい。
本記事を最後まで読んでくれた方であれば、より良い示唆が得られるだろう。ぜひ読んでほしい。
この記事では、心理的安全性の高い組織はぬるい環境どころか個々人の覚悟がないと成立しないことを指摘している。
- 残酷なほど率直な意見を受け入れる覚悟がありますか？
- そういった状況を楽しむことができますか？
心理的安全性が高い、というのはそういった覚悟や心構えをもった上での話ではないのかなと思います。
心理的安全性には個々人の「受け止め方」も大事であり、相手に求めるのではなく、まず自分の認識を変えることの重要性を指摘している。
世界史データベース事業部のコミュニケーションガイドラインには「ポジティブな意図を想定する」と明文化されたものがあります。
言い換えると「邪推しない」「相手の善意を前提に受け取る」という姿勢で、個人的に僕が大切にしていることでもあったので、初めて見た時嬉しくなったのを覚えています。
（COTEN RADIO 見てます！こんな記事読んでいる人には刺さるコンテンツだと思うから見てみて！）
-
どう進めているかの話は別の記事ですでに書いているので参照してほしい: https://zenn.dev/bussystem_take/articles/2026-01-26-how-to-dev-on-ddd ↩︎
-
AWS などのクラウドサービス上で動くアプリケーションを開発し、顧客環境に納品することをここでは指している。 ↩︎
-
同じ会社の社員同士での対話だけでなく、顧客とのビジネス上の損得も踏まえた駆け引きとしてのスキル全般を指したい。顧客との協調というのは、開発側の都合を理解させることも含んでいる。 ↩︎
-
あなたはどうやって自転車を乗れるようになったのだろう。理屈でジャイロ効果がどうだの自転車がなぜ走れるのかを分かっても、実際に乗って何度も失敗しながら身体で覚えなければ乗れるようにならない。それと同じことである。 ↩︎
-
もしかすると読者の中にはそう思わない人がいるかもしれない。しかし、これは覚えておいてほしい。「みんなは私ではない。」自身の考えや感じ方は決して他の人もそうというわけではない。 ↩︎
-
これは公平世界仮説（誤謬）かもしれない。 ↩︎
バス業界専門で業務システムを構築する小さな受託開発会社です。業界を絞っているからこそできる「かゆいところに手が届くモノづくり」をモットーに、顧客とエンジニアが直接打ち合わせをしながら、より良い製品と開発体験になることを日々模索しています。 採用活動をしたいのですが、バックオフィスが弱すぎてそれもできません。誰か助けて。
Discussion