ソフトウェア開発がビジネスに果たす役割は大きくなる一方だ。そして、ソフトウェア開発の進め方としてアジャイル開発は今や当たり前の方法となりつつある。日本のアジャイル開発の普及を牽引してきた達人たち、平鍋健児氏と西村直人氏による対談をお送りする。
10月に永和システムマネジメントの社長に就任した平鍋健児さん（左）と、平鍋さんの元部下で現在はリクルートジョブズでアジャイル開発を推進する西村直人さん（右）
アジャイル開発の普及活動を続けてきた平鍋健児氏は2015年10月に永和システムマネジメント代表取締役社長へ就任している。平鍋氏は、システムの可視化ツールを製品化するチェンジビジョン代表取締役社長でもある。
もう1人の西村直人氏は、リクルートジョブズのアジャイル開発を推進する立場にある。以前は永和システムマネジメント勤務、つまり平鍋氏の組織のメンバーだったという間柄だ。
2人の立場の違いは、主要なアジャイル開発手法の一つ「スクラム」の考え方で説明できる。スクラムでは、(1)プロダクトオーナー、(2)開発チーム、(3)スクラムマスター、の3種類の役割を定義している。平鍋氏は、製品や事業への責任を負うプロダクトオーナーの立場といえる。一方、西村氏は、開発現場を支援する役割であるスクラムマスターとして活動している。
アジャイル開発手法は今ではよく知られるようになったが、普及に伴う悩みも見えてきた。平鍋氏は、顧客とミッション、リスクを共有することにより、顧客の悩みを共に抱える立場を「つらい」と表現する。一方、西村氏は「スクラムマスターという役割を会社組織の中でどのように位置づけていけばよいのか」について、最近の関心事として取り組んでいる。
対談では、このようなアジャイル開発への思い、悩みを、率直にぶつけ合った。
──まずは簡単に自己紹介をお願いできますか。
平鍋：2000年にXP（エクストリーム・プログラミング、代表的なアジャイル開発手法のひとつ）に出会って衝撃を受けた。それまでソフトウェア開発はエンジニアリングだと思っていたが、XPの本（ケント・ベック『エクストリーム・プログラミング入門』 ）には「リリースのとき、お客さんと一緒にシャンパンを飲め」とか、そういうことが書いてある。それまではシステム開発で“うまく作ること”を中心に考えていて、“誰が嬉しいか”にまで考えが至らなかったが、そこは一緒になるべき。そう気がついた。
受託開発の現場ではお客さんがいて、厳しい仕様変更があって、現場は疲弊している部分がある。それを変える手段がアジャイル。そう思ってやってきた。
西村：2015年の春までは、平鍋さんのいる永和システムマネジメントにいました。永和時代の後半はアジャイル開発に関するコンサルタントをしていました。無事卒業して、リクルートジョブズで働いてます。
アジャイル開発の考え方は「オブジェクト倶楽部」（平鍋氏らが主催していたコミュニティ、現在はオブラブ）で出会って、それを広めていこうとやってきました。今はスクラムマスターをしています。現場の問題から会社の問題まで扱います。特に組織を強くすることに軸足をおいてます。
「スクラムって、つらくない？」「成長痛というか」
平鍋：スクラムってさ、つらくない？ スクラムを適用すると、良いところも悪いところも含めて、問題が明らかになるでしょ？
これは僕が思うことなんだけど、本に書いてある通りにやるじゃない。その瞬間にソフトウェア開発プロセスはうまく行ってる感じがしても、その周りにはもっと広い世界が、会社なり製品なり事業の成果なりがあって。コンサルタントって、そこにぶつからない？
西村：めちゃくちゃ、ぶつかりますね。
組織の外部からプロセス改善を支援するコンサルタントという役割では、限界があると感じたというか。最初は良くなっていくスピードが速く進むけど、それがどっかで止まってしまう。でも本当はその先が面白いはずだと。格好いい言い方でいうと、その先が見たくて、今の職場に来ました。「日本一のアジャイルの会社にします」ってみんながいる前で宣言したりしています（笑）。
さっきの「スクラムがつらい」話ですけど、（同じ永和システムマネジメントでアジャイル開発の普及活動をしていた）角谷（信太郎）がLT（ライトニングトーク）をやってたスライドとか、楽しいものだった。コミュニティをやっていたのは、楽しかったからです。「リリースできたからシャンパンを飲め」とか、楽しいじゃないですか。
そこが変わっちゃった。どこからか「つらいつらい」みたいな声が聞こえるようになって。アジャイル開発が広がったのは事実なんですけど。
平鍋：広がって、変わり始めているんだよね。
西村：成長痛というか。
平鍋：いいこと言うね！ アジャイル開発を普及させようとやっていた時期は、みんなの目が輝いていた。本気で変わるつもりだった。
西村：「価値を届けるんだ！」と。そこで気がついたら、価値自体が変わっている。そこも以前と違ってきた所じゃないですか。
平鍋：昔は自分の仕事がエンジニアリングだと思っていたから、いいものを作ろう、お客さんに届けよう、とやっていた。アジャイルの普及も中盤に入ってくると「それは儲かるのか？」と聞かれるようになった。システムを作ることによって、お客さんのもとで価値が上がるか下がるか。上がればお金が儲かるし、システムを作ることで世界のプラスになったことが実感できる。だけどときどきマイナスになることがあって。そこがつらい。
──アジャイル開発の考え方では顧客と目的を共有して開発する訳ですが、それが進むと顧客のビジネス上の悩みも共有することになる訳ですね？
平鍋：そうです。ミッションも共有するけど、リスクも共有するから。
西村：今、自分がいる場所は事業会社ですから。受託開発ではお客さんが相手だったけど、今は違うんだなと。そもそも届ける価値自体が変わってきてますね。
外部から「中の人」へ変わってどう？
──西村さんにお聞きしたいのですが、アジャイル開発に取り組む人の中には、外部からコンサルタントとして関わる立場の人が増えてきていると聞いています。一方、西村さんは外部のコンサルタントの立場から事業会社の「中の人」へと立場が変わった訳ですが、想定外のことはありましたか？
西村：コンサルタントをやっていたときにも、クライアントは今と同じく自社プロダクトを持っている会社が中心だったので、想定外ということはあまりありません。今は中の人間なので「今まで偉そうなことばかり言っていたな」という気持ちは、ちょっとあります（笑）。
中の人として見ると、アジャイルとは現場でうまくいくやり方に名前が付いたものと言えます。スクラムが登場して20年、XPも10年経ちます。今の現場ではもうちょっと、“よりアジャイルな”やり方があるなと感じています。
平鍋：僕はいわば第1世代なんですよ。発注側と受注側が分かれていて、ソフトウェアを作っている人はどこにいるかというと、受注側にいる。そういう世界を長く経験していて、その構造の中でなんとかしたいと思っていた。契約や商習慣の問題でうまくいかないことも分かっていて。それに伴う痛みもある。
一方、西村さんは第2世代。事業会社が直接アジャイルをやる構造ができてきた。事業のオーナーと開発部隊が同じ会社にいる。西村さんは事業会社に行って作る側に回っている。
──西村さんが永和にいた10年、どんな活動内容だったのですか？
平鍋：ちなみに、僕が今20年目ね。
西村：僕の場合は、チームでアジャイル開発をやりたくて、でもそんな現場はない、じゃみんなで始めてみようと。最初は商流の端っこで、常駐先から始まって。その後、プライム（元請け）で仕事を取れるようになって。みんなで情報を外部に発信していって。「教えて欲しい」と言われるようになって。アジャイル開発を企業が取り入れるようになって。いろいろやりましたね。
平鍋：その間に、日本で「認定スクラムマスター研修」も始まっているしね。
西村：アジャイル開発のコンサルタントとしての仕事はここ5年ぐらいでしょうか。新しくできた仕事です。
平鍋：2000年から2005年にかけてアジャイル開発を広めようとしたけどうまくいかず、「プロジェクトファシリテーション」という言葉で広げた。それで（2005年に）西村（直人氏）が入って、（2003年に）角谷（信太郎氏）が入って。その頃からアジャイルという言葉で売れるようになったのね。お客さんから「アジャイル」というお題で呼んでもらえるようになった。
西村：平鍋さんが普及活動を始めた頃は、「アジャイル」と言わない方が良かった時期もありましたね。僕のころはアジャイルという言葉を使った方が逆に良かった。アジャイルはもう知られているので。むしろ普通になって、わざわざ言わなくても良くなった。海外の会社から「（アジャイルで）やってないの？」と聞かれたり。
平鍋：それは、とある大メーカーでも聞きました。海外の関連会社と一緒に開発するとき「アジャイルじゃないとできません」と言われたと。
アジャイルに必要な職種をどう評価する？
西村：今、関心を持っていることがあって、聞いてもらえますか？ アジャイル開発をやるためのベースは人じゃないですか。そのベースとなる人の評価をどうするか。エンジニアの評価は昔に比べると変わってきている。あの会社ではエンジニアは高く評価されるみたいな、そういったエンジニアとしての評価の土台ができている。
ところが、エンジニアだけじゃアジャイルにならない。例えば、開発チームとビジネスを結びつける人が必要になる。そういったアジャイル開発手法に必要な役割がいろいろあるのですが、そういった人たちをどのように評価すればいいのか。そこの議論がまだまだ足りないと感じています。
平鍋：何を作るか決める人が、スクラムでいうプロダクトオーナー。モノを「作る側」のやり方や心得はスクラムや多くのプラクティスで記述されていて、分かりやすい。ところが、プロダクトオーナーがどうやって仕様を決めるのか、その「世界の向こう側（ビジネス側）」を僕らは知らない。
開発チーム（Dev）とビジネス（Biz）を結びつける人材の重要性を語る平鍋さん
──今は事業開発にも立ち入ると？
平鍋：そうです。
西村：一方、事業会社側は、逆に「こちら側（開発チーム側）」を知らない。
平鍋：リーンスタートアップなんかだと両方（開発とビジネス）でプロセスを回すんだけど。小さいときはいいんだけど、大きくなると壮大な円になってきて、プロセスを回すことが難しくなる。
西村：1週間に1回、小刻みにリリースするスクラムのやり方はビジネス側としては嬉しいことだけど、開発側が近くにいない場合はだいたい事故っちゃう。だから急成長しているサービスを持つと「内製しよう」ということになる。
なんでも、大きなものは難しいですね。（西村氏らが翻訳した）『アジャイルサムライ』の最初の方に、「大きな問題を分解しよう」とあるんですけど。
平鍋：それは設計に大きく関わる話でもあって。分割は設計活動なんです。
西村：大きなものを設計できるかどうかという、設計スキルの話になっちゃうんですね。
アジャイルなキャリアってどう作っていくんですか？
平鍋：作るからには、使う人や、そこに投資する人を幸せにしないといけない。ところが、そのための情報は自分の中からは出てこない。だから情報を持っている人と一緒にやる。新規事業を立ち上げる力と開発する力はぜんぜん別。職業上のキャリアとして、システム開発から新規事業開発に移っていけるかというと、そう簡単ではない。
西村：アジャイルなプログラマという存在は、本を見ていた頃だとなんでもできる万能のプログラマのように思えた。喋れなきゃ、設計できなきゃ。それが、実際にアジャイルなプログラマは登場してきて、ちゃんと評価されている。
一方で、エンジニア以外の職種は大丈夫なのかと。スクラムの場合でいうと、プロダクトオーナーとスクラムマスターは、いないと成り立たない。それなのに、評価がまだ定まっていない。例えばスクラムマスターは会社の中では評価しづらいですよね。
平鍋：人のパフォーマンスを上げる人は、その人自身の評価はどうなのという話だね。
西村：評価されないままでは、裾野は広がらないし、組織に残ってくれない。この先、さてどうなるんだろうって？
平鍋：日本では、人材流動性が低い会社では、他人のパフォーマンスを高める役割の人は最終的に評価されると思う。上司が見てくれているから。
ところが、短い時間で評価しようとすると、「上司が長い目で見てくれている」といったやり方は通用しない。アジャイルは短期で成果を出せることがポイントで、だとすると短期評価になる。長期的な人材評価が難しくなってくる。
西村：人がベースなので、どれだけそこに、即戦力というと言葉が悪いですけど、できる人が集まってくるのかが大切じゃないですか。せっかく来てくれた人には、なるべく長い間残ってもらいたい。また集めるのは大変だし、お金もかかるので。
平鍋：流動性という話でいうと、永和システムマネジメントも、アジャイル事業部は流動性が高くなっていて。アラムナイ（Alumni, 卒業生）のページが永和のWebサイトにあります。
評価って制度は別にして本来360度でしょ。「この人と仕事したい」という。会社を離れていても、この人を呼んで欲しいと。会社の定着率の話もあるけど、流動性が高くなったとしても、コミュニティの中で「あの人が何個スターを持っている」みたいな勲章の付け方がある。会社っていうバウンダリ（境界線）が実線で、コミュニティが点線だとすると、今は人の評価でも点線の部分、コミュニティが大事になってきていると感じる。
西村：最近嬉しいのが、エンジニアだけじゃなくて、プロダクトオーナーの人、ビジネスとエンジニアリングをつなげられる人が評価されるようになってきたこと。
コンサルタントをやっていたときにアジャイルの導入のステップの話をするんですが、最初はきっかけ作り。その次は現場での成果。その次は教育。アジャイルに動ける人を広げていかないといけない。その次が評価と採用。会社全体をアジャイルにしようと思ったら、人を採用しないといけない。採用しようと思ったら、その人を評価できないと。
欧米の例を見ると、個人で独立系コンサルタントとしてやるのが一つのキャリアパスですね。ずっとスクラムマスターやってます、という人はあまり見たことがない。例えば、国内で僕みたいにスクラムマスターをやっている人の今後とか、見えにくいですよね(笑)。
平鍋：エンジニアだとCTO（最高技術責任者）になるという“上がり方”があるね。
西村：プロダクトオーナーだと事業部長が“ゴール”とかですかね。ではスクラムマスターはどうかというと、総務課長が“ゴール”じゃないだろうと。
今の会社に転職して面白かったのは、最初の仕事が自分を評価するものさしを自分で作れ、ということになったんです。この前作って、適用されたものがあるんですけど（注：記事の末尾に補足あり）。もっと良いものにしていかないと。
──話は前後してしまいますが、スクラムが定義する3つの役割（プロダクトオーナー、開発チーム、スクラムマスター）のうちスクラムマスターとはどんな役割なのか、なるべく初心者にも分かるような説明をお願いできませんか。
西村：プロダクトオーナーは、誤解を恐れずにいうと、結果としてビジネスとして成功すればいい。開発チームのメンバーは、エンジニアとしてビジネスに寄り添えるソフトウェアをたえず作っていく。
スクラムマスターはどっちでもない。「儲かるかどうか」、「バグがないか」、ではなくて、チーム全体がいい仕事をしたら勝手に結果は付いてくる、そういうふうに現場の中で振る舞っていく仕事です。例え話をすると、サッカーチームの監督のような。ただしソフトウェア開発は勝ち負けじゃないので、そこが分かりにくい。この例えは失敗でしたね（笑）。
──それで評価が難しいという話になる訳ですね。
西村：ただ、定期的なイテレーション、スクラム用語でいうスプリント（小刻みに開発成果を出していく区切りの期間）ごとにしっかりしたものができているかどうか、そこは結果が分かりやすいかもしれない。そこを評価する方法はいくらでもあります。チームが苦しみながらやっているか、楽にやっているか、みたいな定性的な感じとか。
──チームを短期的に使い潰しちゃうようなやり方は評価が下がる訳ですか。
西村：長期的に貢献できているか、そこが評価軸になるかもしれません。短期的に、チームは疲弊するけどどうにかして成果を出すような戦略を取ると、長く持たない。ぼろが出る。そこを指摘する立場の人間（スクラムマスター）の重要性というものはある。
──それも他人の成果を出すことにフォーカスする職種ということで、面白いですね。
「できる人だからできるんでしょ」と言われてしまう件について
──ところで、アジャイル開発をしていると、なんだか特定の意識が高い人じゃないとできないんじゃない、という声がありませんか？
平鍋：アジャイルやっていると、「できる人ばかりだと、できますよね」とか「できない人をどうマネジメントするかが重要なんです」などと言われる。そういう時は「そんなにできない人がいるんですか？」と聞き返す。真顔で。
──平鍋さんの立場は、「できない人」のマネジメントを気にするよりチーム全体を良くしようと。ある種の性善説なんでしょうか。
平鍋：「もし本当にできない人ばかりなら、やらない方がいいですよ」と言います。どんなやり方でやってもうまくいかないから。
西村：「現状だとギャップがあります」といった話はめちゃくちゃ聞かされます。研修をすると、目の前でそう言われますからね。
コンサルタントをして良かったことは、いろいろな業種、いろいろな現場を見ることができたこと。何かを聞かれたときに「答えはないが、近いシチュエーションでこういうアクションを起こせました」という話はできる。お客さんをどう巻き込んでいくか。例えばさりげなく本を置いておくとか（笑）。野球をやるなら、まずルールを知るところから始めましょうか、そんな感じです。
──ふと思ったのですが、西村さんが永和システムマネジメントに来たのは、平鍋さんがいたから、という側面があったのでしょうか？
西村：それは当然あります。あと角谷（信太郎）さんの講演とか。
平鍋：あの頃、何か小さな事が起こったんだよ。
西村：僕は以前は地方にいたので、（平鍋氏らが東京で開催していた）「オブジェクト倶楽部」の集まりには行ったことがないんです。ただ、ああいうイベントをやっていてくれたおかげでインターネットで記事が読める。そこで講演スライドを見たりする。本だけだと分からない。じゃ、もっと知りたいと思って調べてみる。そういう事をやっていました。
平鍋：「オブジェクト倶楽部」は、当初はオブジェクト指向をやろうという集まりだったんだけど、途中からそういう感じじゃなくなって。壁の貼りモノ系とか、ワールドカフェ（少人数のグループで「お題」を語りあうラウンドを繰り返す）とか、LT（ライトニングトーク）といった発表とか。そっちのアナログなソーシャル系の取り組みが主になった。それでそこに集まった開発者間のコミュニケーションがうまく回るようになった。
西村：はたから見て面白そうでした。入ってみたら、実際に楽しかった。会社も、オブジェクト倶楽部も。
働き方の多様性と、アジャイル開発の関係は？
──最近のソフトウェア開発会社は、働き方の自由さ、多様さを認める事例がたくさん出ています。それはアジャイル開発との関連はありますか？
西村：分かりません。ただ、アジャイル開発でも働き方の多様性は大事です。あと、リクルートジョブズは、日本中の皆さんに多種多様な仕事や働き方を提供している会社なので。ビジネスも大事なんですけど、提供する価値ってなんだっけ、というのが少しあって。
平鍋：今のリクルートジョブズは、勤務地という点ではどうなの？
西村：日本全国に支社があります。
平鍋：永和も、沖縄事業所があったりする。たまたま「沖縄で仕事をしたい」という人がいたので。
最近、永和でも「WoW↑3」、ワウ・アップ・スリーと呼ぶのですが（WoWはWays of Working）、魅力ある働き方を3つ実現しようという取り組みを始めていて。フレックスタイムの始まり時間を本当にフレックスにした。当然プロジェクトごとにルールは作るけど。在宅勤務もいい。女性の働き方は特に議論になって、例えば子どもが生まれた後に自然に戻って仕事ができる勤務体系にしたいと思っている。
西村：『アジャイルサムライ』に、「本当に大事なことに集中しよう」とあります。環境もひっくるめて多様性があった方が、いろいろな働き方の人が一緒になって働ける環境の方が成果を生みだしやすい。
もうひとつ、ソフトウェアとして作るものがすごく難しくなってきていて、メンバーのパフォーマンスを発揮しにくい環境に閉じ込めて開発させたらうまくいくという訳にはいかなくなっている。
──アジャイル開発では、チームが一所に集まって行う考え方がありますが、在宅勤務やリモート勤務との相性はどうですか？ チケット管理ツールやGitHubのようにツールが進化してきたのでできるようになったということはありますか？
西村：実は僕はリモート（勤務）は苦手だったりするんですけど(笑)。リモートで作業をして成果を出すことは不可能じゃないけど、壁がある。「みんなでシャンパンを飲む」ことができない。
平鍋：チェンジビジョンでもリモート開発者がいる。デジタルのチケットは使っていて、それにアナログ付箋紙の“カンバン”も使っている。2重運用になっている。
──変な質問かもしれませんが、アジャイル開発手法はチームのコミュニケーションを重視しますが、コミュニケーションをあまりしたくないプログラマがいる場合にはどうなるんでしょうか。
西村：私見ですが、チームの中に、やりたいことが全然違う人がいたなら、それは外れてもらわないといけない。もちろん仕事に関して天才級の人なら話は違ってきますけど。けど、実際に話してみると、みんなコミュニケーション取れたりしますね。
平鍋：もし天才級の人だったら、その人に一点集中で仕事をしてもらえるようにする。僕なら、そうチームをデザインするね。例えば昔「外科医チーム」というチーム構成がありました。ぼくは大切なのはコミュニケーション・デザインだと思っていて、スクラムもその設計パターンの一つと捉えている。環境や目的によって解は変わる。一つじゃない。
──最後に、アジャイルな人が定義にこだわらないように見えるのはなぜなんでしょう。例えばオープンソース活動では言葉の定義が厳格で、「にせオープンソース」は批判されたけど、アジャイル開発では「これはアジャイルじゃない」といった話はあまり聞きません。
平鍋：難しいところです。これはアジャイルじゃない、という開発もありますしね（笑）。でも、アジャイルは「アジャイル宣言」以外の定義がない。これ以外で正しいと判断しては逆に多様性を損なうと思います。ぼくは、「今より開発をよくする活動」と捉えていて、「Better Software Development」を追い求めて行く旅としてのアジャイル開発がしっくりくる。今やっている作り方をより良くしたい、という思いでやっている。そう思うことが重要だから。
西村：『アジャイルサムライ』にも「たゆまぬ改善」を、と書いてある。アジャイル開発に入るきっかけは人それぞれでいい。「超楽しそうだ」とか、「あそこは儲かってるみたい」とか、そう思ってアジャイル開発を始めてもらえるなら、それでもいいと思っています。
対談中、西村氏が言及している「評価基準」について補足しておきたい。
アジャイル開発では、ソフトウェア開発に専念する役割、事業に責任を持つ役割だけでなく、アジャイル開発のチームを支援する役割（今回の対談では「スクラムマスター」）が必要となる。このような役割をどう評価するか、どう評価してもらうかは、西村氏のここ何年かの関心事だった。
これについて西村氏らリクルートジョブズが取り組んで作り上げた評価基準はどのようなものなのか、対談後に西村氏にコメントを寄せてもらった。
リクルートジョブズでは元々ミッショングレードという評価基準があり、おのおののキャリア(マネージャーなど)で期待されるミッションの難易度で評価されます。今回、スクラムでの開発を前提にして、スクラムで定義されている役割(ロール)についても、ミッションのグレードを設定して評価できるようにしました。
設定したのは、プロダクトオーナー、スクラムディベロッパー、スクラムマスターです。
例えば、プロダクトオーナーはよりビジネスとして重要なプロダクトにおいてもプロダクトオーナーシップを発揮すること、スクラムディベロッパーは単にソフトウェアを開発するだけでなくチーム活動・ビジネス観点での提案といった貢献や技術戦略、スクラムマスターは既存のチームが円滑に仕事できるようにするだけでなく、会社全体にノウハウを定型化して展開するといったことを、より評価するといった具合です。
また、それぞれグレードが高くなると後進の育成やより広い視野での活躍を求められるのが特徴です。こうした仕組みで少しづつかもしれないですが、会社だけでなく周辺の環境についても底上げできることを目指しています。
ビジネスで成果を上げることや、ソフトウェアをリリースすることに比べると、「ソフトウェア開発をより良くしていくこと」は目に見えにくい活動だ。そうした役割の重要性を分かってもらうこともまた、ソフトウェア開発をより良くしていくためには欠かせない努力といえるだろう。
