00:15
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネルです。この番組では、ウェブ業界に関することや、エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
えー、今日はですけども、やりたいと思います、アジャイル開発の落とし穴のお話をしようかなと思ってます。
まあ、今朝ですね、面白そうな記事を見つけてバーッと読んでて、すごくですね、これは参考になるな、とてもためになるなっていうお言葉がたくさんあったので、
その記事の言葉をお借りして、なんか思うところをダラダラとしゃべっていきたいと思います。
ミクシーの中で、いろんなことをされている方が、インタビュー記事ですね、あって、それを読んでいたって感じですね。
はい。そもそもアジャイルとはなんぞやみたいな話を定義して出すと、もう全然時間が収まらないので、
なんとなくみなさんが感じているとか、理解しているアジャイルでいいと思います。一旦それでスタートしようかなと思ってます。
私も、株式会社イメミというところに僕は今いるんですけど、
何年だっけ?20年?19年かな?
アジャイル組織宣言っていうのをして、イメミはプロジェクトもそうですし、社内の運営とかもアジャイルに物事を進めていくっていうことを宣言したんですね。
これは代表が宣言して、組織構造とかをガラッと変えていったみたいなところはあるんですけど。
で、そのままやっていったんですけど、まあいろいろ、個人的に思うところはたくさんあって、
まあ良い面、悪い面ももちろんあるんですけど、
まあやっぱアジャイルって難しいなっていう、好き並みな言葉を使うんですけど、そんな感覚があります。
で、先ほど読んでいたその記事の中でおっしゃっていた、
組織にアジャイル開発を導入して根付かせるのに必要なものっていうのは、知識とマインドセットの両方が必要だというふうにおっしゃっています。
というところですね。
特に今回読んだ中で僕が感じたのは、知識の方が結構大事なのかなっていう気はしましたね。
マインドセットももちろんあるかもしれないですけど、どちらか程度知識の印象が強かったと。
はい。
必要なこととしてはまずは、知識なんですけど、それ以前にもっと大事なことがあって、
それを育むための組織構造ですね。
アジャイルカルチャーを育む組織構造が大事だみたいなことをおっしゃっていて、
なるほど、組織なんだっていうところですね。
で、その方が読んでいた書籍、タイトル忘れました、ごめんなさい。
まあ後で記事もシェアします、するのでちょっと見てくださいと。
その書籍の中でおっしゃっていた一言にその方も感銘を受けていたんですけど、
文化は組織構造に依存するっていうお言葉をおっしゃっていたんですよね。
これは僕も共感するところがすごくあって、
こんな組織だと多分アジャイルカルチャーを育むことは厳しいんじゃないの?
っていうふうにおっしゃっていたのが、
一つは縦割りの組織構造ですね。パキッと縦に分けられた組織構造だったりとか、
横の連携がなかったりとか、コラボレーションが少ない組織っていうのが多分一つだと思いますね。
あったり、あとは強いヒエラルキーですね。
縦の線がしっかりしていて上司、部下みたいな関係がはっきりしていて、
03:02
それを超えることが難しかったり、そこでのうまいこと連携っていうのが
単なる報告と意識系統みたいなだけになっている。
そういうヒエラルキーの組織も多分アジャイルカルチャーを育むのは厳しいんじゃないかな?
っていうふうにおっしゃってましたね。
その言葉2つを感銘すると、うちの会社っていうのは確かにヒエラルキーは一気になくしましたね。
上司という概念がなくなったんで。
一応取締役会とか、いわゆる経営層と執行部っていうところの組織構造があります。
そういう意味での上下関係は確かにあるんですけど、
そこを除くと、あとはもう皆さん役職とか役割の違いだけであって、
お互いがリスペクトをし合ってお互いの職位ってところを相互に協力し合ってやっていくっていうのはすごくアジャイル感はありますが、
そうではなくて、いわゆるフラットな組織構造ですね。
最近フラットっていう言葉自体がご回を招いたり抽象度も高いので、
ちょっと使うの難しいなと思って、
僕も使わないようにはしてるんですけど、
まあでも適切なことも今見つからないので、
広く、抗議の意味でフラットなような組織構造とか、
あとは自立性に富んだメンバーとかですね。
それはもちろんそうだと思います。
要はそんなメンバーが集まって、
一つワンチームでお客様とか顧客に価値を提供できるケイパビリティを
そのチームが持っているっていうような組織構造にはアジャイルっていうのは全然いけるんじゃないかっていうのをおっしゃってましたと。
これはすごくそのまんまだなと思います。
で、一方でガートナージャパン株式会社っていうところがいろんな市場調査をされているらしくてですね。
ちょっと時代が古いというか、結果が古いんですけど、
2019年の結果として、いわゆるアジャイル型の開発とか組織を対応している日本企業っていうのは
大体15%未満、15%ぐらいですね、にとどまっているという数字が出てます。
これ多いと思うか少ないと思うかなかなか難しいですけど、
世界各国と比較すると日本はかなり少ない数値が出ているというのは事実としてあるというので、
その意味ではまだまだアジャイルっていうのが導入されているわけではないなというのを思っていらっしゃいますね。
これの理由として、いわゆる産業構造ですね。
日本におけるIT産業の構造というのの大部分がですね、
住宅開発とかはやっぱりSIAが占めているっていうのが進んでいない背景にあるんじゃないかなとおっしゃってました。
これもまあ確かにと思いますね。
いわゆる日本の住宅開発とか住宅企業っていうのは、SIAもそうですけど、
言われたものを作ってくださいと、命令通り動いてくれみたいなところですね。
いうようなプロジェクトというか現場っていうのがまだまだたくさんあるからっていうのは思ってますし、
これ根深いなと思いましたね。
一方でいわゆる事業会社で自社プロダクトに携わるエンジニアっていうのを焦点を当ててみると、
日本で自社プロダクトに関わっているエンジニアっていうのは大体30%ぐらいらしいですね。
アメリカに行くと65%なので全然違うと。
それはなかなか自立性を育むことは難しい土壌にいるなっていう感じはやっぱりありますね。
70%がいわゆる住宅系かSIAにいるっていうことになってしまいますので。
で、そういう自立性に富んだメンバーとかどういう人なのかっていうのもちょっと言及されていて、
06:00
そういう人たちはいわゆるコラボレーションを好んだりとか守備範囲にこだわらない、
本当に不確実な未来とか不透明な未来に対して自分たちの能力とかチームで物事を解決していくっていうところが好きな人たち、
もしくはそういうところに壁を感じない人たちっていうのが集まっていくといけるんじゃないかなっていうようなお話をされていましたね。
はい。で、そんないろんな背景とかの話をした上で、じゃあどうやってやっていくかってことなんですけど、
アジャイル開発って言われると一番有名なものとしてはやっぱスクラムというフレームワークがあったりします。
他にもエクストリームプログラミングとかリーンというものもありますけど、
あれはちょっとアジャイルとはちょっと違った分野などいろんな手法があるんですね。
そんなたくさんの手法があって、どれを採用するかはその企業とか組織、チームに応じて好きに選んでください。
ただ大事なのはそのアジャイル開発の様々な手法を皆さんいきなりスクラムやりましょうとかエクストリームプログラミングで開発を進めていきましょうって、
いざ言ってもそんないきなりドーンと導入してガラッと運営を変えることはできないんですよね。
できないというか難しすぎるんですよ。障壁が高いし、そうするとスクラム自体をやることが目的になってしまうという落とし穴ですね。
よくある落とし穴に結構はまりがちなので、スクラムの要素とかを少しずつ取り入れたりするのはよくやるんですけど、
それを自社の、自分たちのチームに少しアレンジしたりとか、僕たちの今までのやり方にうまいこと咀嚼をして、
こういうやり方で僕らやりましょうみたいなことをやっていくチームとか組織がかなり多いと思うんですけど、
それがアジャイル開発をうまくいけなかったり、アジャイルという文化が根付かない大きな理由だというふうにおっしゃっていて、
まずはちゃんとアジャイル開発のいろんな手法の基本とか基礎に忠実にやってくださいと。
いろんなことを加味して、いろんなことを分析したりして、こういうフレームワークに落とし込んだっていうのがそのアジャイル開発のいろんな手法でありますので、
とにかくその特性とかを正しく理解して、忠実にまずやっていきましょう。
チーム全体としてもしっかりインストールできましたとかなんだけど、その上でやっぱり僕らのチームごとにやり方とか色を変えていきたいっていう、
その試行錯誤の上でアレンジしていくんだったらそれは全然いい話なのでやってください。
ただそういうことは分からないで、まず形から入って型を使っていく。
でもそれのやり方のやり方をいきなりガランと書いていくと、結局それぞれのフレームワークの中にも手法とかプロセスに応じてやり方とかいろんなものがあるんですけど、
一つ一つの趣旨とかが分かっていないと一個一個のアクション自体が空回りしてしまう。
というので、結果アジャイルうちには難しかったなっていう結論になってしまいがちだと。
とにかくまずは基本とか基礎に忠実に従って動いてくださいっていうのをおっしゃってました。
これはすごく僕も共感があるし、自分もそういう反省しなきゃいけないなっていう動きを今までしてきたので、
ちょっと耳が痛い言葉だったんですけど、
エンジニアでもそうですけど、フレームワークとかライブラリー使うにしても、
いきなりなんか自分たちのプロダクトごとに書き方を変えるとかではなくて、
まずはゲットスタディとか公式が出している基本的な使い方とか、
09:00
忠実に従ってこうやってやっていくんだっていうのをまず自分の中にインストールすると。
そんな感じですかね。学問でも一緒かなと思ったりしますね。
学問の世界もまずはやっぱり基本的に先人たちが残した理論とかっていうのに従っていろんなものをまず学んでいって、
そこから先未来のための理論だったりとか、現実のケースに落とし込んで、
こうやったらどうだ、ああやったらどうだっていうのをどんどん発展させていくっていうことですね。
日本には手張りっていう言葉がありますけど、まさにこういうことだなと思いました。
アジャイルをインストールするのは無理で、
アジャイルをインストールするには結局手張りの原則に従うっていうのが僕の今の結論で、
いや本当この記事を読んでて改めて手張りってすげー言葉だなって思ったりはしましたね。
まずはでも文化情勢のためにそういう組織構造から作るとか、
メンバーそのものの意識改革から入らなきゃいけないっていうのは強く感じましたし、
それは結構体力というよりもペインを伴うものだと思います。
それを組織全体からやっていくってなると本当に腕力が必要なので、
うちの代表はそれをやりきったのでやっぱすごいなって改めて思ったし、
いい意味で頭おかしいと思いました。
さておきでもそういうところからやっていかなきゃ文化の情勢ってのはできないし、
昔からの日本のIT産業がやってきた構造っていうのを変えるのはかなり大変なんだなってことはあります。
まあでもいまだに結局住宅開発が7割っていうのは多分まだ数字変わってないはずなので、
まあ長い戦いがずっと続くんだろうけども、
まあちょっとずつちょっとずつ変わってくると思いますし、
まあいろんなものが淘汰されてきたりすると思いますので、
こっからは変わっていきたいなと思います。
その中でアジャイルっていうのがもっと浸透していくというのかなと思っています。
IT業界とアジャイルっていうのはもうほぼ僕は不可分というか、
必ずセットになってくると思っていて、
さすがにウォーターホールが破綻していることは皆さん分かりきっているとは思うんですけど、
いまだにやっている現場っていうのはたくさんあるので、
もう少しここが変わっていけるようになればいいなと思っています。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
