開発プロセスのことが,あまりにも大切になりすぎている昨今
開発プロセスって,もはやソフトウェア開発現場に任せておくには,あまりにも重要過ぎる領域になっている気がする。
旧態依然とした,ウォーターフォール開発(※いちおう断っておくと,ウォーターフォール開発のことをディスっているわけではない。ウォーターフォール開発が適したケースも依然としてあると思う)でやっている組織でも,世間全体的にアジャイル開発へ向かっていることは無視できないだろうし,そうなると,現在の古い組織の仕組みをどのように作り替えていくか?ということは,もはや,ソフトウェア開発現場へ任せておくには,大きすぎる課題じゃないだろうか?ということ。
アジャイル開発的なことも,語りたいことが随分と増えているから,これから少しずつ書いていこう。
日本に学んだアメリカ,アメリカに学ばなかった日本
最近,PMBOK の第七班でもアジャイル開発の色が濃厚になっているということを知って驚いたけれど,よくよく考えると,当然なのかもね。
ソフトウェア開発現場は,そもそも,知識生産をするのであって,工場生産ではないから。
(どちらかと言うと)工場生産的に,大量生産・大量消費を前提とした思想であるウォーターフォール開発で,厳密にコントロールしようとすれば,ソフトウェア開発現場が,人間不在テイストになってしまうんだよね。
その面,アジャイル開発は,状況に応じて柔軟に仕事を区切りながらやっていくという,より人間中心の考え方だから,ソフトウェア開発現場でも,優れたプロジェクト結果が出るのは,容易に想像がつく。
そしてアジャイル開発って,ルーツをたどると,少なからず,80年代の日本製造業からの影響も受けている。
それを思うと,アメリカのソフトウェア開発現場に,アジャイル開発で負けたくないという気になっちゃう。
皮肉なことにも,ソフトウェア開発現場においては,今度は,日本がアメリカから学び返すという構図になっているのだと思っている。
アジャイル開発って,仕事の区切り方だけのハナシではない
アジャイル開発のことを勉強していて,少しずつ分かって来たんだけれど,「アジャイル」って言葉は,意思疎通上の混乱にもつながりやすい。
「細かく区切って開発する」というイメージを指している場合。
XP / スクラム / カンバンなどの,個別のお作法を指している場合。
あるいは,アジャイルソフトウェア開発宣言を指している場合。
話者によって,解釈に差が出てしまうから,いっそのこと,エンジニア同士の会話では「アジャイル」を禁句にしてしまったほうがよくないか?みたいにも思っている。
ちょうどここらへん,DX と似ているよね。
アジャイルをキチンと勉強するならば,どうしても,80年代の日本製造業の部分(トヨタ生産方式など)から入門して,リーン,アジャイルという順番でアプローチするのがいいと感じているけれど,下の図が,一番分かりやすいと思う。
思想の系譜をたどるような学習が大切だと思うんだけれど,エンジニアって忙しいから,なかなかそこまで勉強する時間が確保できないのは,実際問題としてあるだろう。
起源から一つずつ紐解いていく勉強は,時間はかかるけれど,一度きちんとやったら,自分の血肉となって,エンジニアとしての職業人生を支えてくれる気がする。
そこら辺の話題についても,少しずつ投稿していきたい。
今日は,ここまで。