こまぶろ

技術のこととか仕事のこととか。

なぜ僕は「アジャイルを!」と叫ぶのか〜「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加して

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」(@デンソー東京支社)に参加してきた。

connpass.com

イベントレポート的なものは、別にまとめている。本記事は、イベントに参加した感想として書き始めたが、感想の域を大幅に越えて、現時点での僕のアジャイルへの認識をまとめるものとなったため、イベントレポートからは独立させることとした。そちらに関心のある方は、下記に貼り付けた記事を参照していただければよいが、アジャイルに造詣の深い方々にはぜひ、本記事で書いた私見に対してのご指摘・ご批判をいただきたいと思っている。なにせ、僕はアジャイル非実践者であり、誤解や表面的な理解をしていると思うからだ。

ky-yk-d.hatenablog.com

(2018.08.27追記

良質なイベントレポートを公開してくださった方がいらっしゃったので、ご紹介します。

bayaaki.github.io

ビジネスとアジャイル

「ビジネスの成功が大事」なのか?

今回のイベントで、何度か発せられた発言に、「大事なのはビジネスの成功じゃないのか」「金を稼げなければ」というものがあった。それぞれ、成迫さんとryuzeeさんの発言だったと記憶している。お二人の発言の趣旨は、「アジャイル開発と言ってチームを良くすることばかり考えていてはいけない」ということだと理解している。文脈としても、きょんさんの「アジャイルの目的化」というインパクトの強い話があり、「チームビルディング大事!」一辺倒の流れになってしまいかねない*1ところにバランスを取りにいった印象を持った。

僕もこの指摘は、至極真っ当だと思う。この指摘は、「アジャイル開発者も霞を食らって生きるものではない」という意味で正しいだけではなく、「アジャイル宣言の背後にある原則」から読み取れるように、アジャイルという考え方自体にビジネスへの志向が(敢えて言えば、ウォーターフォールよりも)色濃く含まれているという意味でも説得力のあるものだ。

一方で、上に掲げたような発言を耳にしたときに、僕は少なからず違和感を覚えた。あるいは、「もにょる」という表現が伝わりやすいかもしれない。僕も、アジャイルが開発者だけに都合のいいものだったら、今日に至るまでのアジャイルの普及はなかっただろうし、アジャイルはビジネスの成功にも大きく貢献しうるものだと確信している。しかし、「大事なのはビジネスの成功」と言ってしまうことには危うさを感じている。この言葉がryuzeeさんなどのアジャイルを実践してきた方々の口から出てくる分にはよいのだが、「ビジネスの成功がアジャイルの目的だ」というような語りが蔓延することは危険だと思う。

なぜ「ビジネスの成功がアジャイルの目的だ」は危険なのか

ビジネスの成功の曖昧さ

なぜ僕は「ビジネスの成功がアジャイルの目的だ」という言説を危険視するのか。それは、「ビジネスの成功」という表現が曖昧すぎるからだ。ソフトウェア開発における「ビジネスの成功」とは何か。ある人は、「開発したプロダクトが売れること」と考えるだろうし、「いや、売れるだけじゃなくて利益が大事だ」という人もいるだろう。ではその売上や利益はどのような範囲で考えられているのか。単発のプロジェクトの収支か?ひとつのプロダクト/サービスの収支?それとも企業がその存続期間中に生み出す全てを含んでいるのか?

一定期間の数字に責任を持つ人間は、当然、その期間にフォーカスして物を考えることに傾斜しがちになる。皆が近視眼になっているというわけではなく、仕組み上そういう風になりがちだということだ。中長期的な視野をもって経営陣やマネージャーが現場を導くということもある(本来はそういうものだと思う)が、近視眼的になった上層部が現場に無理を強い、社会に対して無責任な行動に出た結果、長期的には企業の価値が大きく損じられたという事案も世間に多く見られる。

先に述べたような、近視眼的な行動による弊害に対する歯止めとして、CSR(Corporate Social Responsibility、企業の社会的責任)という考え方が登場し、マイケル・ポーターらはCSV(Creating Shared Value、共通価値の創造)を唱えるに至った。やっとむさんが赤福の例を挙げて指摘したのは*2、このようなことだったのではないかと理解している。

アジャイル人間性CSVから考える〜

やっとむさんが明示的に指摘していたのは変化することだったが、CSVという考え方を導入することでアジャイルには別の側面も見えてくる。これは僕がそういうものをアジャイルに付け加えようというのではない。この側面は、アジャイル宣言の起草者の一人であるケント・ベックも(CSVとは言わないが)意識しているものだ。それを見出すことができるのが、『エクストリームプログラミング』の第5章で第一の原則に掲げられている「人間性(Humanity)」の項目においてである。

人間がソフトウェアを開発する。このシンプルで逃れようのない事実によって、利用可能な方法論の多くがその効果を失っている。ほとんどの場合、ソフトウェア開発は人間の欲求を満たしていない。人間の弱さを認めていない。人間の強さを活用していない。ソフトウェアを人間が開発していないかのように振る舞えば、関係者にかかるコストが高くなり、人間の欲求を認めない非人道的な行為によって、人間性が失われてしまう。こうしたことは、高い離職率に伴うコストや組織の崩壊、クリエイティブな行動の機会損失など、ビジネスにとっても好ましいことではない。(『エクストリームプログラミング』22頁)

アジャイルは、人間性を帯びた考え方・やり方だ。「アジャイルソフトウェア開発宣言」・「アジャイル宣言の背後にある原則」には「対話」・「協調」・「意欲」・「信頼」、「スクラムガイド」には「スクラムの価値基準」として「勇気(courage)」や「敬意(respect)」などの人間にフォーカスした概念が登場している。その他にも、アジャイルを実践する現場ではメンバーのモチベーションに光をあてるプラクティスなどが採り入れられている場合も多いと思う。

開発プロセスとしてウォーターフォールを採用している現場でも人間的な実践が行われていることもあるが、「ウォーターフォール」には人間性への配慮はない。これは欠陥ではなく、そういった部分に関心を持つ考え方ではないというだけだ*3。しかしアジャイルはそこに関心を持つ。だからこそ僕は「アジャイルを!」と叫ぶのだ*4

アジャイルをそれ自体として擁護する

チームのアジャイルがビジネスのためにもなる

繰り返しにはなるが、「アジャイルができればビジネスなんてどうでもいい」と言うのではない。アジャイルを実践する現場の開発者は、「ビジネス大事だ」と100回唱えるくらいでいい。僕も唱えよう。しかし、「ビジネス大事だ」という圧力には警戒しなければならない。それは現場の開発者もそうだし、経営サイドもそうであるべきだと考えている。

アジャイルは、ビジネスに貢献しようとするものだ。フィードバックループを回すことによってプロダクトとプロセスを改善すれば、それはビジネスの成功可能性を高めてくれる。その基本方針は、「アジャイル宣言の背後にある原則」で高らかに謳われている。

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

ここで述べられていることを常に意識し、様々なプラクティスも活用しながらソフトウェア開発に臨めば、良いものができる方向に向かうはずだ。より良いやり方が一切存在し得ないと断定することはできないが、少なくとも、20年前に超一流のプログラマたちが実践の中から生み出したこの知恵を上回る有効性をもつものを、僕は知らない*5。 したがって、現場が「うまくアジャイルできていれば*6」、基本的にそれがビジネスの成功にも資するはずなのだ。

アジャイルを育むということ

そうはいっても、状況が芳しくないとき、外側から手を突っ込みたくなるのが管理者の情というものだ。しかしそれは我慢してもらわなければならない。そうでなければアジャイルなチームは死んでしまう。うまくいっていないならば、アジャイルの内部で、つまりチームによる改善に携わることによって対応していけばいいのであって、上意下達式の介入は避けなければならない。「環境と支援を与え仕事が無事終わるまで彼らを信頼」するのだ。与えるべきなのは支援であって指示ではない

「ビジネスの成功」という言葉に導かれたマネージャーが短期的な利益を志向した場合に、顧客/エンドユーザーにとって長期的には好ましくないプロダクトを世に送り出してしまったり、あるいは開発者を疲弊させてしまったりする危険性があるのではないか。そこで起きるのはアジャイル開発の崩壊だ。だからこそ、アジャイルは擁護されなければならない。

今回、きょんさんは、「目的論からのアジャイル〜手段を目的化すること〜」と題して、アジャイルが目的に対する手段として実践される場合であっても、それ自体を目的化してしまうくらいの方がよいというお話をされていた*7。きょんさんのポイントは、アジャイルの目的とされているもの*8の実現の困難さを考えると、仏教の修行のように本来は手段であるはずのものに「自らを一体化させる」ことが必要ではないかというところにある。

今回の記事は、このきょんさんの話に触発されて書かれた面がある。きょんさんの議論と僕の議論は、「アジャイルを、何かの目的のための手段として従属させること」に反対するという意味では共通する部分がある。しかし、その内容は異なる。非常に雑にまとめれば、きょんさんの論旨はアジャイル自体を目的にしたつもりで全力でやれ」であり、僕の論旨はアジャイルを特定の目的の手段としてのみ扱うと壊れてしまいかねないから、それ自体として擁護せよ」だ。

よいソフトウェア開発とは何か?

長々と論じてきた。僕は、アジャイルを実践できていない現場、会社にあって、これを(ほぼ一人で)推進しようとしている立場の人間だ。これまで自分なりに勉強をし、同僚や上司に伝えようとしてきたが、どうにも前に話を進めることができないでいる。だから、一度自分なりにアジャイルについての考えをまとめておきたいと思って、この記事を書いた。また、アジャイルというものについて、Twitter以外で文章をネット上に公開するのはもちろん、ここまでの文章を書いたことすら初めてだ。初めてだからこそ、一定の立場を据えて書こうと思った。それゆえ穏当でない部分もあると思う。

ここまで読んでくださった人の中には、社内での説得に失敗している理由が僕の考え方にあると感じる人もいるかもしれない。もし、「そういう考えだから人を納得させられないんだよ」という指摘があれば、ぜひ聴かせていただきたい。僕の考えていることに少しでも理があるなら、そういったフィードバックも欲しい。間違っていたら教えていただきたい。

この文章を書くにあたって、色々と考えたし、この記事に載せなかった文章もいくらか書いた。そうしているうちに、かえって「アジャイルどうでもいいかもしれない」という思いも自分の中に生まれてきた。会社ではアジャイルを推進する立場だし、現在の自分の会社にはアジャイルという考え方を導入することが意味のあることだと思っている。しかし、これからソフトウェアエンジニアとして仕事をしていく中で僕が向き合っていくべきは、「よいソフトウェア開発とは何か?」という問いであり、アジャイルはその問いに答えようとするためのヒントを与えてくれるものに過ぎないのだろうと思うようになった。これはまさに目的に関する問いであり、価値に関わる問いである。

エクストリームプログラミング

エクストリームプログラミング

よい教育とはなにか: 倫理・政治・民主主義

よい教育とはなにか: 倫理・政治・民主主義

*1:きょんさんが「ビジネスはどうでもいい」という立場を示したわけでも、そういう人だと僕が理解したわけでもない。

*2:赤福について、やっとむさんは肯定的に論じていたように記憶しているが、不祥事からカムバックできているのかは僕は評価する材料を持っていない。とはいえ、赤福が良い企業であるかどうかはここでの問題ではない。

*3:したがって、ウォーターフォールを採用する現場において人間性が重んじられるかどうかは、開発プロセス以外のところがどのように運営されるか次第であり、マネージャーの資質に大きく依存することになる。

*4:最近、「DX(Developer eXperience)」という言葉も目にする。参考、 DX: Developer Experience (開発体験)は重要だ - Islands in the byte stream

*5:どうやらウォーターフォールは限られた状況でしか機能しないらしいということを知識として知っているに過ぎない。

*6:"Don't do agile, Be agile"という言葉が飛んできそうだが、手法だけを取り入れる"doing agile"を意図したものではないとご理解いただきたい。

*7:「20年前の現実解をありがたがって理想を追求しないアジャイル老害だ!」というもう一つの軸は今回は措くとしたい。

*8:もっとも、これが何であるかをきょんさんは語っていなかったように思う。