iimon TECH BLOG

iimonエンジニアが得られた経験や知識を共有して世の中をイイモンにしていくためのブログです

弊社、アジャイル開発だったの!?〜アジャイル再入門〜

こんにちは! 株式会社iimonでEMをやっている松田です。

最近、なんとなく弊社の求人内容を見る機会がありました。(強引な導入やな)

下記がその求人内容です。

仕事内容 プロジェクトマネージャーとして、「速いもんシリーズ」の新規プロダクト開発 や、既存プロダクトの開発スケジュールの調整から開発要件とりまとめ、テ ストなど幅広く携わっていただきながら、テクノロジーで不動産業界の日常 を変化させるサービスを開発していただきます。 手法としては、アジャイル開発を利用し、市場やニーズに柔軟に対応して います。

ん??? 「アジャイル開発を利用し」・・・だって???ほんとにそんなこと言い切って大丈夫かなぁ。私個人としては、まだ「なんちゃってアジャイル」だと思っていて、エンジニアのカジュアル面談等でもそのように説明してるんだけどなぁ・・・。

そもそも、なんで「なんちゃって」だと思ってるんだっけ???

うまく言語化できないことに気がついたので、今回はアジャイルに再入門しながら、弊社がほんとうにアジャイルを実践できているか、できていないなら何ができていないのか、を確認していきたいと思います!

そもそもアジャイルとは

アジャイルとは何か。私なりの理解でもあり、一般的によく言われることとしては、「常に変化しつづける顧客にとって価値のあるもの」を「無駄なく素早く柔軟に」つくり、「顧客に(ビジネスゴールの観点で)満足を提供する」ための取り組みや考え方、です。

その解釈があっているか裏付けるには、原典である「アジャイルソフトウェア開発宣言」を読む必要があります。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を価値とする。

この4行はあまりにも有名で、たとえ「なんちゃって」しか体験したことがない方でも、見たことがあるかもしれません。

ただ、これが有名すぎるがあまり、次の1文が抜けてしまって誤解されているケースもよく見られます。その1文とは

すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

です。

「◯◯よりも◯◯を」のうちの、前者も無価値ではないし、「ドキュメントはつくらない」、「計画をつくらない」という意味ではないことに注意が必要です。

そのあたりは、IPAが提供してくださっている「アジャイルソフトウェア開発宣言の読み解き方」という資料にも詳しく載っていますので読んでみてください。

かくいう私も、お恥ずかしながらアジャイル=「ドキュメントは作らず、とにかくプログラムを書いてみて時間を浮かし、浮いた時間で次の機能を素早く作っていく」「ウォーターフォールよりめんどくさくないやつ」、みたいに捉えていた時代がありました(本当にお恥ずかしい・・・汗)

今のiimonは「なんちゃって」なのか?

この問いへの答えとして、「YES」と書くか「NO」と書くか、記事を書いている今でさえまだ迷っています。

iimonのメンバーはみんなが少なからず「顧客にとって価値があるものはなにか」を考え、「どうやったら素早く柔軟につくれるか」を考え、「顧客に満足してほしい」と思ってプロダクトを作っているはずだし、そう信じたいからです。

ただ今回、改めて「アジャイルソフトウェア開発宣言」や「アジャイルソフトウェア開発宣言の読み解き方」を読み返してみると、まだまだやれることが残っていそうだったので、ここではあえて、まだ「なんちゃって」である、と言ってしまいたいと思います。(そうじゃないと記事の続きが書けませんしね笑)

顧客の満足とは何かを定義することからはじめよう

繰り返しますが、アジャイルとは「顧客に(ビジネスゴールの観点で)満足を提供する」ための取り組みです。

ということはつまり、顧客のビジネスゴールが何であるか、どのような価値を提供すれば満足してもらえるのか、を最初に定義することが必要です。

iimonでも、もちろんビジネス側のメンバーが新規のプロダクトを企画したときにそれは考えられているはずですが、それを開発メンバー1人1人まで理解できているかというと疑問が残ります。

アジャイルソフトウェア開発宣言の読み解き方」から引用すると

ビジネス側の人と開発者は、ビジネスゴールについて初期の時点で徹底的に話し合いましょう。

ビジネス側の人と開発者は、ビジネスゴールに向かっているかどうかを常に確認し、方向がずれていたら素早く修正しましょう。

ビジネス側の人と開発者は、ソフトウェアで実現すべき要件を顧客の立場で一緒に考えましょう。顧客が必ずしも正解を持っているわけではありません。

このあたりにはまだ、課題が残っているように思います。

その課題への取り組みとして、直近ではPM等に働きかけ、プロダクトが作られた背景や顧客が求めるものについての説明会を開いてもらうようにお願いしています。

要求の本質を見抜く

アジャイルソフトウェア開発宣言には、「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます」という記述もあります。

顧客にとって価値のあるものは時間が経つにつれ変化していくので、要求の変更があるのは当然であり、それに柔軟に対応することが求められます。

ただ、顧客からの要求が常に正しいとは限らないことには注意が必要です。

アジャイルソフトウェア開発宣言の読み解き方」の行動規範にはこうあります。

ビジネス側の人と開発者は、価値があるのであれば、積極的に変更を受け 入れましょう。

- ただし顧客に言われるがままに変更を受け入れることはやめましょう。

顧客からの要望をそのまま鵜呑みにするのではなく、その裏に隠された本質・洞察(インサイトとも言ったりします)を分析して、真に価値ある要求に落とし込むことが重要です。

また、アジャイルには「ムダ=価値を生まない」を探してやめる、という考え方もあります。

ムダをなくすためにも、要求の本質に迫って極力シンプルな解決策を考えましょう。

ビジネス側の人と開発者は、顧客の要求を鵜呑みにせず、「その要求は本 当に必要ですか?」と聞きましょう。

- 顧客にとって本当に必要か分からない機能を、先に作るのは「つくりす ぎのムダ」です。

iimonでは基本的にセールスの方々が顧客の声をPMに伝え、PMがやるやらないの判断をしていますが、基本的にはその場ですぐに判断することが多く、また、そこには当然開発者は不在(私は無理を言って参加させていただいていますが)なので、もう少し顧客の声を深堀りする時間や開発者視点の提案があってもいいのではと思っています。

市場からのフィードバックの共有

アジャイルで素早く価値を届けるのは、変化し続ける顧客にとっての価値をきちんと提供できているかの仮説検証ループを細かく回すためでもあります。

いくらビジネス側や開発者側が「これがお客さんが求めている価値だ」と思っても、それが間違っている場合もあるし、変化し続けるのでズレを修正する必要があります。

アジャイルソフトウェア開発宣言の読み解き方」の行動規範では、

ビジネス側の人と開発者は、市場からのフィードバックを共有しましょう。

とあります。

開発者側に「今、あなたが担当しているプロダクトは顧客が求めている価値を提供できていますか?」という問いを投げかけたとして、”根拠を持って”胸を張って「はい」と答えられるエンジニアは(私も含めて)いないかもしれません。

この点でもまだ、iimonでは改善できることがありそうです。

開発者も顧客の価値創造について考える

iimonでは、PMがタスクを管理しており、開発者に何をやってもらうかその都度振っていく流れで開発が進みます。

このやり方では、開発者はそのタスクの裏にある背景(顧客が何を求めていて、どんな価値を提供するのか)を知るのは困難でした。

今すぐできることとして、PMにお願いして、タスクのチケットに極力背景を書いてもらうことにしていますが、アジャイルでは前述したように、ビジネス側と開発者が顧客にどんな価値を提供するのかは徹底的に話し合うことが推奨されており、もっと取り組みを前に推し進める必要がありそうです。

ビジネス側の人と開発者は、顧客の価値創造のために、自らが考え、自ら の行動と判断に責任を持ちましょう。

ビジネス側の人と開発者は、自分の作業だけでなく、顧客の価値創造のた めに何ができるかを考えましょう。

ビジネス側の人と開発者は、必要な人たちが集まり、双方向の議論をする ことを心がけましょう。

- 決まった仕様を伝えるだけのような一方通行はやめましょう。

開発手法はどうか

ここまでは「アジャイルソフトウェア開発宣言」、「アジャイルソフトウェア開発宣言の読み解き方」を参考に、iimonでアジャイルの考え方がどれくらい浸透しているかや、これからの課題を見てきました。

では、「スクラム」や「XP(エクストリームプログラミング)」、「カンバン」などに代表される、いわゆる”アジャイル開発手法”についてはどうでしょうか。

これについては、スクラムでいう「デイリースクラム”っぽいもの”=朝会」は昔から存在し、昨年後半に「レトロスペクティブ”っぽいもの”=週1のふりかえり」が始められた程度で、まだまだこれから整備していく必要があります。

スクラムについて詳しく説明すると、とても30分では足りない(この記事を使って、社内で行われる30分の勉強会をしています)ので、詳細はスクラムガイドYahoo!Japanさんのわかりやすい記事に譲るとして、今後段階的にスクラムの要素を取り入れていければいいなぁと考えています。(私が考えているだけで、社内のコンセンサスはこれからです汗)

朝会や週1のふりかえりについても、実施こそしているものの、その背景やねらいについてはスクラムで定義されているような意味合いでは伝わっていないので、再整理&再周知がいりますね。

いいわけ?

このままだと、冒頭で触れた弊社の求人内容が嘘みたいになってしまうので、できていることにも触れておきます!

IPAの「アジャイルプロジェクト実践ガイドブック」には「アジャイル開発における技術と難所」というものが挙げられています。

1.CI/CD

バッチリ整備されています!実際にデプロイの頻度は週3〜4回をキープできており、できあがったものを素早く届ける準備ができています。

2.テスト駆動開発

ちょ、ちょっとだけ・・・ほんのちょっとだけですが、啓蒙を始めています!

私自身は以前の職場でTDDを体験しており、メンタルの安定という最強の武器を手に入れた経験があるので、ぜひiimonのエンジニアメンバーにも体験してほしいです。

弊社の開発はフロントエンドの割合が非常に高く、啓蒙している私自身がバックエンドでのTDDしか経験がないので、フロントエンドのTDDをどうやっていくかの知見が不足しているという事情もあったりなかったり?します。

3.ドメイン駆動設計

絶賛啓蒙中&一部トライ中です!近々、外部の専門家をお招きしての勉強会の予定もあるとかないとか・・・??

4.ペアプログラミング&モブプログラミング

ペアプログラミングを一部トライ中です!

特にシニアエンジニアとジュニアエンジニアが一緒に作業したときのジュニアの成長には期待しています!

5.クラウド技術

AWS、Firebaseをはじめ、多数のクラウド技術を使っています!

・・・そんなわけで、最後はいいわけじみてしまいましたが、”技術の難所”と言われるものにも積極的に取り組んでおり、「なんちゃってじゃないアジャイル開発」を行える素地はしっかりできています!

この記事を読んで興味を持ってくださった方、一緒に「なんちゃってじゃないアジャイル開発」を目指していただける方、ぜひカジュアル面談でお話ししましょう!
iimon採用サイト / Wantedly / Green

参考文献

agilemanifesto.org

アジャイルソフトウェア開発宣言の読み解き方

アジャイルプロジェクト実践ガイドブック