エピソードの導入
aozora.fm第93回目。93回目なんですが、通算累計エピソードで言うと、これが100エピソード目だそうです。
SPとかっていうのを昔やってまして、その後すぐSPじゃなくて連番にすればよかったなってすごい後悔したんですが、
あれを含めると100本になるそうで、アップルポッドキャストとかで見ると、全てのエピソードがこれを配信すると100になるのかな。
配信する前は99になってました。というどうでもいい話を挟んで自己紹介をしていきたいと思います。
パーソナリティのFORTEと申します。ウェブエンジニアをやってますが、今インフラやってるんでいろいろやってるという感じです。
今回何をテーマに話そうかなと思っていたところ、今日ちょっとツイッターで、昨日かな。
ツイッターで組織を真からアジャイルにする人と歌っている、名乗っている人がスクラムマスターというふうに名乗っている、
そういう役割をやっているということが見たことないという話を見かけたので、
そういえばアジャイルとかアジャイル開発宣言について話をしようかなと思っていたのを思い出したので、今回はそういう話をしていこうかなと思います。
関連リンクに、アジャイルソフトウェア開発宣言へのリンクと、あとはIPAが出しているアジャイルソフトウェア開発宣言の読み解き方というPDFスライドがあったので、
それを合わせて貼っておき、主にアジャイルソフトウェア開発宣言を参照していくんですが、ちょっとこのIPAの資料も触れられたらなと思います。
あまりアジャイルソフトウェア開発宣言を朗々と読み上げたところで意味がないというか、読んだほうが早いかなと思うので、細かく読み上げはしないので、ぜひリンク先を見てほしいんですが、
リンク先に見てほしいのは、一応それぞれリンク貼っておきますが、アジャイルソフトウェア開発宣言というページと、あとアジャイル宣言の背後にある原則という2つのページですね。
ぜひともこの2つのページを見てほしくて、特に原則の方はリンクを一段深掘りというか、下りないと出てこないので、
ああこんな感じなので宣言を見ただけで終わらないで、書名というか、その宣言をした歴々な方々が並んでいるんですけど、ケントベックとか、
そのあたりの人たちの名前をスクロールして抜けていくと、宣言の原則というのが出てくるので、ぜひこの原則というのも見てほしいという感じです。
アジャイルソフトウェア開発宣言というのは文字通り宣言でして、よくアジャイル開発手法とかアジャイルな開発手法みたいな、その方法、開発方法、開発手法みたいな文脈で語られがちなんですが、
あくまで開発宣言には価値としか書かれていないんです。私個人としてはこの文章に書かれていることは思想だったり考え方、代理にしたいものですね。
いわゆる価値なんですけど、だと思っていまして、1から10までこういうやり方でやったらアジャイルだとか、このやり方が今までのやり方より良いとかそういう話ではなくて、
今までやってきた開発、ソフトウェア開発をやってきた中で、自分たちの経験から振り返るに、こういった観点を大事にするとよりうまくいくんじゃないかという話が書かれているという認識でおります。
原則と実践
これはいわゆる自宅開発だったりとか、ビジネスでって言い方はあまり好きではないんですけども、ソフトウェアを開発することでお客様のビジネスだったりサービスだったり、あるいは問題を解決するだったりみたいなことをやって売り上げを上げるといいますか、お金をもらっている人たち、会社だったり個人だったりがこういったものが大事だよね。
こういったことを大事にしていくとうまくいく、よりうまくいくでしょうということを言っていると思います。
ここで言っているうまくいくと言っているのは、自分たちのソフトウェア開発が、例えば納期通り開発が終わるとか、品質がいい、バグが少ないみたいな話というよりも、お客様のビジネスだったりとか、お客様の目指したいところに一緒に行けるみたいな、ビジョンの達成みたいな感じですかね、ミッションの達成みたいなところまで含めた価値だったり思想なのかなというふうに私は考えております。
表面的な話はこんな感じで原則の方に移っていくと、これも全部読み上げたところで読んだ方が早いという話なので、全部は読み上げないんですが、いくつかピックアップして、この辺りは今でもあまり大事にされていないというか、重きを置かれていない原則だったり価値かなと思うのが、持続可能な開発を促進しますという部分ですね。
一定のペースを継続的に維持できるようにしなければなりませんというところがありまして、これはいわゆるデスマーチみたいな、残業、残業、残業でのんきに間に合わせて作るものっていうのが、果たしていいのかみたいなところから来ているのかなと思っておりまして、やはりそこで無理して作ったものっていうのが、継続的にそれができますかっていうと、そんなことはない。
デスマーチずっと繰り返したら本当に死に至ってしまうという話ではあると思うので、一定のペースを継続的に維持できるようにしなければならないというのは、本当に今の開発現場、ソフトウェア開発現場に耳をたこにしてでも言っていきたい、聞いてほしい話なのかなと思ったりしています。
特にこれはあれですね、我々開発者、特にリーダーマネジメント層の考えもそうなんですが、仕事を依頼するお客様にも分かってほしいというか、本当はこういった価値を共有してお客様を巻き込んでやっていかなきゃいけないっていうのがソフトウェア開発者としてもあるとは思っているのですが、その上で分かってほしい、認識してほしい部分ではありますね。
やはり毎回毎回強従みたいなやり方をしていると、どこかで無理が来るので、本当に必要なものだけ本当に強従にやらないとビジネスインパクトだったりとか、あるいは影響がでかいものだけやって、1日2日後でも大丈夫というのは都度都度調整してやっていきたいというのが現場で開発している私個人としては思う部分ですね。
あとはそうですね、シンプルさが本質というのがありまして、無駄なく作れる量を最大限にすることというのがあるんですが、最大限という部分よりも個人的には無駄なくという部分が大きいのかなと思っておりまして、これも使い古されたというか、耳たこの話、手役がついた話ではあるんですが、開発された機能の6割だったかな、使われないみたいな話があるので、
やはり100作って60使われないよりは、その100全部使われるように無駄なく作っていって、ソフトウェア開発によって提供できる価値というのを最大限にしていきたい。
お客様のビジネスだったり問題解決に100%効果を及ぼすものでありたいとは思いますね。
正直使わない機能を作ると、ソフトウェア開発的にも技術的不採だったりとか、負の遺産だったりとか、あとは単純に使わない機能にお金を払っているというのがお客様的にも無駄ですよねという話があるので、そういった部分はなくしていきたいなとは思いますね。
これも2024年現在でも当てはまるというか、難しいからこそ考えていかないことではあるとは思うんですが、まだまだ解決していかなきゃいけない部分かなと思う。
あとは最後ですね、チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整しますという部分もありまして、あり定に言ってしまえば振り返りをしましょうという話だと思うんですが、
この辺りは結構、スクラムで言えばレトロスペクティブだったりとか、デリースクラムとか、正式名称忘れちゃいましたけど、いわゆる朝会議ですね、のような定期的に振り返りだったり会話する機会、自分たちが築ける部分、築ける機会、文字通り効率を高める、もっとより良いやり方を見つけられる、そんな仕組みを自分たちで考える。
あるいはそういった意識、認識、心構え、気がいい、みたいなところを意識してやっていくというのがアジャイルという考え方、価値なのかなと。このページで言うと原則ですね、なのかなと思っています。
意外と振り返りやってないって現場多い、実際私が今いる現場もやってないんですけど、と思いますし、やっててもなんとなくKPT、Keptやってて、なんかプログラムいっぱい出るんだけど放置して終わってたりとか、逆になんかプログラム出すとやることが増えるから、なんかキープだけで終わってたりとか、なんか辛い振り返りみたいなところもあったりして。
この辺りは振り返りエヴァンジェリストの黄色い人とかの話を見るといろいろあると思うんですが、そんな話があるかなという部分ですね。
ちょっとだけIPAの資料の方にも触れておくと、最初に結構ビジネス側の人、開発者みたいな図解があって、なんとなく今の私の認識で読むとあまりビジネス側の人と開発者で垣根というか区分を作るのはどうなのかなというのはちょっと思ったりはするんですけども、
これアジャイルソフトウェア開発宣言とか原則の方を見直してみると、ビジネス側の人という言葉を使っていたので、アジャイルソフトウェア開発宣言が出た当初はそういった考えが主流だった。
個人的には今はビジネス側、あるいはお客様というのは巻き込んでやっていくという方がよりアジリティが高いというか、ソフトウェア開発という文脈で言うと、ソフトウェア開発の成功ですかねという文脈でいくとより成功率が高いというか、お客様だったりとか市場のニーズに合った開発をしやすいのではないかなと思う部分ではあります。
このあたり最新の考え方というのが、アジャイルソフトウェア開発宣言って別に何伝版とかないので、スクラムガイドとかあるんですけどね、どういう考えになっているのかなというのはコミュニティだったりとかカンファレンスなんですかね、あたりでちょっと見てみたい聞いてみたいという部分ではあるかなと思います。
じゃあ、アジャイルについて具体的に学びたい、現場で実践していきたい、どうやって学んだらいいかみたいな方がいると思うので、私がどう学んでいたか、おすすめの本なんですけど、一つ紹介しておくと、アジャイル侍という本がありまして、何年前ですかね、14年、5年ぐらい前の本、もっと前かなになるんですけど、本当に今でも折に触れて読み返したいと思います。
アジャイルの入門書籍としては本当におすすめの本になっていまして、どういう内容かというと、アジャイルをより実践的な開発アプローチというか開発省に落とし込んでいくと、こうやっていくといいよねみたいな話ではあるんですが、この本を書いたジョナサン・ラスマセンという方の前書きだったかなとかに、
ソフトウェア開発、もっと楽しくやっていこうよ、楽しくできるやり方、より良いやり方を楽しみながら見つけていこうみたいなことが書かれていて、当時SIRでデスマーチの最中、あまり対比的に語るのは良くないんですけど、ウォーターホールが原因というよりは、マネジメントの失敗だったんですけど、
マネジメントに失敗した現場でデスマーチして、もう本当開発やだな、仕事やだなって思っていた私には本当に転系というか、晴天の霹靂というか、ソフトウェア開発って楽しんでやっていいんだなみたいな、ある種のカルチャーショック的な考えを与えてくれた本で、そういう意味で本当にアジャイルが好きですし、アジャイルに救われたとも思ってますし、
アジャイルとスクラムの関係
アジャイル侍という本との出会いがなかったら、今こうしたアジャイルについて、本当に表面的な話ではあるんですけど、しゃべってはいないと思うので、運命的な出会いだったと思うし、本当に領地をというか、あまり主語をでかくするとどうかなと思うんですけど、
ソフトウェア開発、ITエンジニアの出属、筆系の書、というとすげー数の本読まないといけないんじゃないかっていう話にはなる気がしないでもないんですけど、DWコードとかっていういろんな方の意見はあると思うので、アジャイルっていう文脈でいくとまずそこからなのかなっていうのは一つあるかなという話でした。
たぶんAmazonかなんかのリンク貼っておくんで、興味があったら見てください。ちなみにアフェリエイトはやってないんで、このリンクから飛んで買っていただいても、特に私にお金が入ったりとかそういったことはないです。
で最後に冒頭に話した組織を真からアジャイルにする人っていうのがスクラムマスターと名乗っているっていうのが見たことないっていう話の回答じゃないんですけど、なんでかなっていう話の結論を私なりに書いておくと、これツイッターにも書いたんですけど。
スクラムマスターの役割っていうのはスクラムを確立させることであって、組織をアジャイルにすることではないというのが答えになるんですが、これはどういうことかっていうと、スクラムをやっていく上でアジャイルである組織がアジャイルである必要はないという話ですね。別にアジャイルを否定していてもスクラムはできると思いますし、
なんならアジャイルより前にスクラムという考え方ができているので、スクラムガイドにおそらくアジャイルという言葉は一言も出てこないんじゃないかなと思います。少なくともスクラムマスターという役割の解説についてスクラムガイドを参照すると、そこにアジャイルなんて言葉は当然出てこないですし、組織をアジャイルにしようなんて言葉も出てこないわけです。
確かに組織に対する言及というのは書いてあって、それはスクラムを進めていく上で必要となる障害を取り除くにあたって、それはチームも組織も両方とも対象だよねっていう話ですね。このつぶやきをしていた人もその点はわかっていたみたいで、スクラムマスターは別にアジャイルにすることができる必要はあるかもしれないけれど、必要があればするが正確かな。
必要があればアジャイルにする、組織をアジャイルにするということもやるけれど、それが必要条件、必須条件ではないよねということをおっしゃっていたので、よくわかってらっしゃるというのは上から目線なんですけど、わかっている上でそういう人を見ないという話をただ単につぶやいただけだったんだなという話でした。
やはりツイッター、140字あるいは短い投稿リプでつなげていくと言いたかったことっていうのがなかなか整理されないというか、そこにたどり着くまで難しかったりとか、あるいは漏れてしまったりということがあるので、気軽につぶやけるのはいいんですけど、140字に全てを詰め込もうとするとなかなか難しいなと思ったりするという話でした。アジャイルの話だったはずなんだけどな。
ちょっとアジャイルについては深掘りするとしたらどういう話をすればいいのかっていうのはあるんですが、個人的に先ほどお勧めしたアジャイル侍という書籍のほかに、アジャイルとの本当の出会い、本当の出会いって何やねんって話なんですけど、実は書籍じゃなくてアジャイルについて書かれた発表資料がありまして、
その資料の最後にアジャイル入門にお勧め書籍として紹介されていたのがアジャイル侍だったという話ではあるので、その資料についていつか軽く触れられたらなと思っております。インターネットで公開されている資料ではあるので、全然誰でも見れるものではあります。
というわけで、エンディングということでアゾラFMの告知をやっていきます。このポッドキャストはアゾラFMではゲスト応募しております。話したい楽しいことがあれば誰でもOKです。今までポッドキャストに出たいけどハードルが高いなとか、そんなすごい話題なんてないよとしては大丈夫です。普段楽しんでいること、趣味の話、仕事の話、アジャイルの話、何でも大歓迎なのでお気軽にご連絡ください。
連絡方法はこの後紹介するツイッターのハッシュタグやDM、あるいは配信ページにあるお便りフォームからご連絡いただければ大丈夫です。よろしくお願いします。
また、アゾラFMではご感想やご意見をお待ちしております。ツイッターでハッシュタグ、シャープアゾラFM、シャープAOZORFMをつけてツイートしてください。配信ページのお便りボタンからもお便りを送ることができます。ぜひよろしくお願いします。
さらにさらにお願いですが、アゾラFMではご支援を募集しております。フィクシブアンボックスかオフセイというサービスで支援できます。支援してもいいよという方はこちらも配信ページのリンクから可能ですので、何卒よろしくお願いします。
では私ホルテからの告知というか宣伝をさせていただくと、配信ページに載っている内容ですね。技術同人誌、それから副業と書いているんですが、お仕事募集中です。業務委託でのお仕事募集中です。あとは芸術書店、17ですかね。いい加減新刊書かないと。ちょこちょこ書いているんですが、書かないとやばいなという話です。よろしくお願いします。
最後にアゾラFMのハッシュタグでつぶやかれた感想などを拾っていこうと思ったんですが、特にリスナーからの投稿つぶやき等々はないです。寂しいのでぜひよろしくお願いします。
つぶやいて欲しい反応が欲しくてやっているわけではないので、なくてもやるのはやるんですけど、やっぱり内容があった方がいいですというのはその通りです。あと自分で読んでいて気づいたんですが、シャープアオゾラFMって言っているんですけど、ハッシュタグの頭の文字って厳密にはシャープじゃなかったんですよね。
ハッシュタグっていう用語の文字。キーボード上はシャープなんですけど、だったのかなぁなんてどうでもいいことを思ったりしました。ちょっと今回アジャイルの話をしたんですけど、かなり表面的な話になってしまった部分はあるので、反省しつつ、あまり細かく深く掘り下げていくとめちゃくちゃ長くなるっていうのと、
なかなか一人でそこまでやろうとすると、どういう部分を話せばいいのかなっていうのがわかんなかったりする部分があるので、次回以降の反省点、課題としつつ、またちょいちょいアジャイルだったりとか、回転エンジニア、ソフトウェア開発みたいな話はできたかなと思います。
というわけで第93回は取り替え、アジャイルについて軽く触れるということでお話ししました。最後までご視聴していただきどうもありがとうございました。
