アジャイル開発入門以前
今現在、派遣の立場で本格的なアジャイル開発の案件に携わって、比較的ストレスも少なく、自身の成長にもつながり楽しく開発を進めることができている。
一方、私が所属している自社の開発案件ではアジャイルとはほど遠い開発の進め方をしていて、控えめに見ても炎上していることが多く、同じオフィスで働きながら開発の進め方に対する考え方に大きなギャップを感じる。
自社の案件がもっとスムーズに進むようになれば良いなと思い、私が持っているアジャイル開発に関する知見を社内に広めようと勉強会を開くなどの取り組みを開始してみたのだが、上層部より反発を喰らって失敗に終わった。
取り組みそのもの対しても反発を喰らったし、アジャイル開発の話をしてみてもあまりしっくりきていない様子で、分かり合うことができなかった。上層部の人間ほどウォーターフォールの考え方に縛られているなと思った。
アジャイル開発を経験をすればするほど、ソフトウェア開発はアジャイルの方が向いていると思うようになったのだが、まだまだその考え方が一般的になっていないIT企業も多いのかもしれない。
日本ではなぜこれほどアジャイル開発が浸透しないのか、色々と考えても答えはまだわからないのだが、そもそも「ソフトウェア開発」や「仕事」に対する認識が根本的に間違っている人が多いのではないかと思うようになった。アジャイル開発を導入するために参考になる書籍などはたくさんあるけれど、ウォーターフォール型の開発の考え方に縛られている人がアジャイル開発について勉強しても真に理解することはできないのだろうと思う。
ソフトウェア開発の進め方を改善していく上では、アジャイル開発を導入する以前に、まずは「仕事」や「ソフトウェア開発」に対する正しい認識を持つことが大事であると思う。
仕事に対する認識
仕事とは、「自分以外の人に価値を提供すること」であると思う。
もちろんそんなことはわかっている、とみんな口では言のうだが、ウォーターフォール型の開発では価値を提供することを一番の目的とした行動ができていないと感じることが多いと感じる。私の感覚では、ウォーターフォール型の開発では「納期に間に合わせて納品すること」が目的になっていることが多い。
まずは仕事の目的を価値提供に変えることがアジャイル開発導入の第一歩であると思う。
仕事に対する価値観でもう一つ思うのは、経営層や営業の立場の人ほど顧客の要望を尊重し、開発者側の立場を軽く見ていることが多いように思う。
もちろん仕事である以上顧客の要望は大事であるのは間違いない。
しかし、価値あるものを提供するためには現場の人間がやりがいを持って仕事に取り組めていることはとても大事なことであると思う。
案件に対して権限を持っている人間は、顧客とチームメンバーがそれぞれWinWinの状態になるように調整していくことがとても大事である。
ソフトウェア開発に対する認識
IT業界で働いていても、ソフトウェア開発に対して正しい認識を持てていない人も意外と多いように思う。今振り返ると、私自身長い間ソフトウェア開発については間違った認識を持っていたなと思って反省している。
「ソフトウェア開発 = モノづくり」という認識
ソフトウェア開発の仕事は、プログラミングを経験したことがない人にとってはイメージがしにくい。IT業界以外の人にソフトウェア開発の仕事を説明する時は、「ソフトウェア開発＝モノづくり」と説明することが多い。その認識は半分は合っているが半分は間違っていると思う。
一言にモノづくりと言っても、にも色々なタイプのモノづくりがある。
ここではモノづくりを以下の2種類に分類する。
大量生産のモノづくり
職人が1つ1つ手作りするモノづくり
では、ソフトウェア開発の仕事はどちらのモノづくりに近いのかというと、職人が手作りするモノづくりの方が近い。
なぜなら、ソフトウェア開発の仕事はプログラミングをはじめとする様々な専門知識を必要とするからである。そのスキルの習得は短期間で簡単にできるものではないし、スキル差によって生産性や品質に大きな差が出る。
役割分担をしたり、下手にスキルの低い人を投入して人を増やすよりも、スキルの高い人が一貫して作った方が早いし品質も高くなる。
一方で大量生産のモノづくりは、高度なスキルは必要としない場合がほとんどである。生産過程を工程に分けて、役割分担をする。人を増やすことで並列で作業することが可能となり、人海戦術が使えるのが大量生産モノづくりの特徴である。
ソフトウェア開発の場合、アジャイル開発は職人のモノづくりのやり方に近く、ウォーターフォール型の開発は大量生産のモノづくりのやり方に非常に近い。しかし、ソフトウェア開発の仕事と大量生産のモノづくりは全く似ていないため、大量生産のモノづくりの成功体験を真似してもうまく進むことはほぼない。
建築業界との比較
ソフトウェア開発の仕事は建築の仕事に例えられることも多い。
建築の仕事は、「企画 ⇒ 設計 ⇒ 設計に基づいて建築する」という流れで進んでいく。
ウォーターフォール型の開発はまさにこのような進め方をするのだが、そもそもソフトウェア開発と建築業は根本的に色んなことが違う。
まず、最も大きな違いは、物理的なモノが存在するかどうかである。
建築の場合、物理的なモノを作っていくため、途中まで作った段階で後から大きな変更をすることは難しい。
例えば、3階建ての建物を作っていたとして、7割程度完成したところで、「やっぱり4階建てにしたい」とか「やっぱり2階建てで良い」と言われても物理的に困難となるだろう。そうなると「全部壊して最初から作り直した方が早い」となるかもしれない。
建築業は物理的なモノを作るという特徴から後で要件を変更するのが難しいため、最初に完成イメージを明確にし、綿密に設計し、設計に基づいて作っていく必要がある。
一方、ソフトウェアは物理的なモノは存在せず、目に見えない。
それだけで、完成イメージを関係者全員で共有するのは難しいし、使ったことによる効果は実際に使ってみないことには分からないケースも多い。
実際、ウォーターフォール型の開発では後になって「思ったものと違った」となるケースもよく見聞きする。
また、ソフトウェアという言葉は「ソフト（柔らかい）」という言葉が使われているが、この言葉にはハードウェア（物理的なもの）に比べて変更がしやすいという意味合いが含まれているらしい。
つまり、最初に要件を固めて、詳細を設計して、（変更を許容せず）設計通りに作る、という進め方はソフトウェアの本質を捉えていない。
ウォーターフォール型の進め方を説明するのに建築業界の仕事はとても説明がしやすいが、建築とソフトウェア開発自体は全く性質が異なることは認識しておいた方が良い。
研究との比較
ソフトウェア開発の仕事は意外と研究に近い部分がある。なぜなら、ソフトウェア開発の仕事は基本的に試行錯誤の連続だからである。
ソフトウェアの仕事というのは、まだ存在しないサービスやアプリを作ることになる。作ろうとしているソフトウェアでやりたいことを実現するにはどうすれば良いか、様々な言語、ライブラリ、フレームワークなどの技術を組み合わせていく必要があり、どの組み合わせによってやりたいことがより理想的に実現できるかを試行錯誤する。
様々な組み合わせを試して試行錯誤するその過程は、研究の仕事に近いと言える。
納期（期限、締切）に対する認識
ウォーターフォール型の開発では納期に間に合わせることが目的となっている場合が多いのだが、そもそも仕事に納期は必要なのだろうか？
日本では社会人になると「全ての仕事には期限がある」と教わるが、果たして本当にそうだろうか？
個人的に思っているのは、絶対の納期や期限が必要なのはイベントが絡む場合に限ると思う。
例えば、会社は毎月決まった給料日に従業員に給与を支払わなければいけない。給料日というのは会社にとっては1つの「イベント」と捉えることができる。給料を支払うためには、支払い日までに給与計算を終えている必要がある。給料日が決まっているため、それまでに給与計算を終えるために期限が設けられるのは自然に思う。
雑誌なども毎月発売日が決まっているため、期限を決めながら仕事をするのは納得がいく。
オリンピックやライブなどの参加型のイベントも、日程があらかじめ決まっているため、本番までに必要な準備が全て終えている状態でなければいけない。そのためには期限を決めて仕事をするのは大事であると思う。
では、ソフトウェア開発の仕事の場合はどうか。
例えば、オリンピックのようなイベントに関連するソフトウェアの開発であれば、絶対の納期があることも納得できる。
しかし、世の中の多くのソフトウェアは、そのようなイベントは絡んでいないように思う。「あると便利なサービス」を開発したり、「あると便利な機能」を追加するのに、絶対の納期がある必要はあるのだろうか？
「完成の目安」はもちろんあった方が良いと思う。
しかし、「完成の目安」が「絶対の納期」である必要はないよな、と思う。
ソフトウェア開発において絶対の納期があるとどんな現象が起きるか。
納期までの期間が短い場合、開発者が時間外労働をすることになる場合が多い。時間外労働が増えると、体力的にも精神的にも疲弊するし、モチベーションも下がってしまうことが多い。そうなると、成果物の品質も低下してバグが混入する可能性も高くなってしまうだろう。そうなると、サービスを利用するユーザーも満足できない品質になってしまう可能性がある。
結果、開発者もユーザーも含めて誰も幸せにならないし、誰に価値が届いたのかわからない状態になる。
どんな仕事にも「完成の目安」は必要だが、「絶対の納期」はイベントが関係している仕事以外ではむしろ設定しない方がみんなのためだと思う。どんな仕事にも納期が必要だ、と思っている人は考えを改めた方が良いと思う。
見積りと計画に対する認識
見積りと計画については「アジャイルな見積りと計画づくり」という書籍がとても参考になる。
この本の中では「見積りは確率で、コミットメント（確約）ではない」と言っている。また、「大事なのは計画づくり」と言っており、「計画」そのものや「計画通りに進める」ことは大事ではないと言っていない。
この考え方はとてもしっくりくるなと思う。
私の感覚ではウォーターフォール型の開発にこだわっている人は、最初に見積りを立てたらそれをゴールとして仕事を進めようとするし、計画を立てたら計画通りに進めようとする。見積りや計画を「絶対の納期」と認識して仕事を進めようとする。実際のところ、ソフトウェア開発は不確実性が高いため、プロジェクトの初期段階の見積りや計画はほとんど当てにならない。
にもかかわらず、最初に詳細な計画を立てて、その計画に沿って作業を進めていくことを仕事だと捉えている人が相当数いると感じている（特に役職を持つ上層部の人に多い印象）。
計画を立てることは大事だし、計画に沿って進めていくことで完結できる仕事ももちろんあるが、不確実性の高い仕事は見積りも計画づくりも難しく、計画通りに進むことはあまりない。ソフトウェア開発の仕事は不確実性の高い仕事であるため、正確な見積りは難しく、計画を立てても計画通りに進めることは困難である。
契約に対する認識
私の経験上、ウォーターフォール型の開発に固執している人は契約にとらわれている人が多いように思う。そのような人は、仕事はまず契約があり、その契約を守ることが何よりも大事だという価値観を持っている。
先にも述べた通り、仕事とは「誰かに価値を提供すること」なのだが、契約にとらわれている人は、価値提供よりもまず「契約を守っているかどうか」を気にしている。
ウォーターフォールの開発では納期を守ることが何よりも最優先されがちだが、結局のところ、契約の時点で納期が決まっているという理由で納期が最優先されているように思える。
契約を守ることはもちろん大事なことではある。
しかし、仕事をする上で契約を守ることが目的になるのは本末転倒である。
人間社会を形成する上で法律の存在はとても大事だが、法律を守ることを目的に生きている人はきっといない。生活していく中でトラブルを発生しにくくしたり、トラブルが発生してしまった場合にその問題解決を早めるための道具として法律が存在する。
契約も本来はそのようなものであるべきではないかと思う。
仕事をしていく上でトラブルが発生しないように、あるいはトラブルが発生した場合の解決手段の1つとして契約がある方が健全であると思う。
少なくとも、不確実性の高い仕事に対して契約で絶対の納期を決めるのはとても理不尽なパワハラに近いように思うし、そうでなくとも契約を守ることが最優先となるような仕事の取り組み方はやりがい搾取のようにも思える。
工数管理とタスク管理に対する認識
ウォーターフォール型の開発では、タスクをWBSという形で細分化し、開発者1人1人に対して割り振ることで開発を効率化しようとする。
しかし、実際には作業を細分化して1人1人に割り振っても効率化されないことが多い。
なぜかというと、開発者のスキルによって生産性や品質が大きく変わるからである。スキルの低い人に仕事を割り振ったとしても、品質が悪ければ後から修正が必要になったり、他の人が作ったプログラムを結合するときにうまくいかない場合が多くなる。
結果として、スキルの高い1人が一貫して作業した方が早かったり、あるいは役割分担をせずにペアプロ（2人1組でのプログラミング）やモブプロ（3人以上でのプログラミング）をした方が早かったりする。
なぜ作業を分割した方が作業が速いと認識してしまう人が多いのかというと、人月（1人が１ヶ月でできる作業量）や人日（1人が1日でできる作業量）という単位を使って工数管理をしようとするからである。
繰り返しになるが、ソフトウェア開発の生産性と品質は開発者のスキル差によって大きな差が出る。その差は大きいときには数十倍ほどの差になる場合もある。
つまり、人月という単位は誰を基準とするかによって天と地ほどの差が出てしまうので、工数管理をする際にはほとんど意味を持たない単位なのである。しかし、管理者の人の中にはこの人月という単位を使う人が未だに多い。
キャリアアップに対する認識
IT業界のキャリアアップの道としてよくあるのが「プログラマー ⇒ エンジニア ⇒ リーダー ⇒ マネージャー ⇒ 営業」という流れである。
私の個人的な考えでは、これらはキャリアアップではなく、キャリアチェンジである。
開発に必要なスキルと、マネジメントに必要なスキルと、営業に必要なスキルは全く関連性はなく、別物のスキルである。
開発のスキルの高い人がマネジメントできるわけではない、マネジメントできる人が営業ができるわけでもない。
開発もできてマネジメントもできる人の評価が高くなるのは納得できるが、開発スキルが高くてマネジメントスキルは低い人と、開発スキルは低くてマネジメントができる人でマネジメントができる人の方が高い評価になるのは評価の仕組みとしては不健全であると思う。
開発・マネジメント・営業はそれぞれ役割が違うだけで、それぞれ平等に評価されるべきであると思う。
管理職になるのがキャリアアップで給与を上げる近道という制度は時代遅れであると思う。
組織構造に対する認識
日本ではピラミッド構造の組織がとても多い。
ピラミッド構造の組織そのものが悪いとは思わないが、ソフトウェア開発の仕事に明確な上下関係がある組織構造が最適なのかというと、そうでもないような気がする。
例えば大量生産モノづくりのような仕事の場合、上下関係を作って上の立場の人が下の立場の人を管理することが効率化の面で最適なのかもしれない。
しかし、柔軟性が求められる不確実性が高い仕事においては上下関係があって現場の人間に権限がない場合はうまく対応できないことが多い。
私が関わっているアジャイルの現場では上下関係はなく、メンバー同士がフラットな形でチーム単位で仕事を任される形になっている。
ソフトウェア開発の仕事はそのようなフラットな関係性でチームを作り、チーム単位で仕事を進める方がスムーズだなと強く思う。
ウォーターフォール型開発に対する認識
ソフトウェア開発の手法は大きくウォーターフォール型開発とアジャイル開発の2つがあり、それぞれの向き・不向きがあると言われている。
私がよく耳にするのは、大規模な開発はウォーターフォールが多いという話だ。だが、正直なところピンと来ていない。
私自身、大規模な開発でウォーターフォール型で進めている案件をいくつか経験しているが、もれなく大炎上して大失敗していた。
アジャイルで進めていれば成功していたという保証はもちろんないが、経験上、大規模な開発ならウォーターフォール型の開発が向いているとは微塵も思っていない。
むしろ、ソフトウェア開発は規模が大きければ大きいほど不確定要素が増えるので、見積りや計画づくりは大変になる。ウォーターフォールで進めると失敗する確率の方が明らかに高そうと感じるのは私だけだろうか。
個人的に、ウォーターフォール型の開発が向いているのは、ハードウェアが絡む組み込み系の開発。
あとは要件が明確に決まっていて変更の可能性が極めて少なく、規模が大きくない開発の案件ぐらいじゃないかな思う。
アジャイル開発に対する認識
アジャイル開発についても正しい認識を持っていない人は割といそうである。アジャイル開発では、短い期間で小さなリリースを繰り返しながら開発を進めていく。
小さなリリースを繰り返すのは、ユーザーからフィードバックを貰える機会を増やし、よりプロダクトの価値を高めやすくするためである。
その小さなリリースに対して「絶対の納期」が決められているような開発の進め方をしていると聞くことがあるのだが、それはアジャイルもどきであり、本当のアジャイルではないように思う。
もちろんリリースのスピードが早ければ早いほどユーザーは喜ぶであろう。しかし、その納期の縛りによって開発者が疲弊してモチベーションを保てなければ最大限の価値提供をするのは難しく、本末転倒である。
アジャイル開発では、開発者もユーザーも、それぞれが最も良い形で
WinWinになるように協調することが重要である。
まとめ
ここまでの内容で正しい認識と誤った認識についてをまとめる。
正しい認識
仕事の目的は誰かに価値を提供するもの
仕事は関わる人々がWinWinになるように動く
ソフトウェア開発に似ている仕事
職人技が必要なモノづくり
研究
見積りは確率
計画づくりが大事、計画は大事でない
契約は大事だが仕事の目的は契約を守ることではない
作業を分割して割り振っても生産性は上がらない
開発の仕事は開発者のスキルで大きな差が出るので人月という単位に意味はない
開発者からマネージャーになるのはキャリアチェンジ
ソフトウェア開発はフラットな関係性でチーム単位で仕事をした方がうまく進む可能性が高い
ウォーターフォールは不確実性の高い開発には向かない
誤った認識
仕事の目的は納期を守ること
仕事は顧客が幸せなら良い
ソフトウェア開発に似ているとされている仕事
大量生産のモノづくり
建築業
見積りはコミットメント（確約）
計画通りに進めることが大事
契約を意識して守ることが何よりも大事
作業を分割して人を増やして適切に割り振ることで生産性が上がる
人月の単位を使って工数管理するのが良い
開発者からマネージャーになるのはキャリアアップ
明確に上下関係のあるピラミッド構造の方がうまくいく
大規模開発はウォーターフォールが向いている
ここに書いてある正しい認識と誤った認識はあくまで私個人の考えです。
この考えに概ね納得できる人もいるでしょう。一方で違和感を抱いたり、非現実的だと思う人もいることでしょう。
概ね納得できる人にとっては、アジャイル開発はきっと向いている開発手法であり、違和感を抱く人にとってはアジャイル開発は不向きであると思う。
アジャイル開発を進めるうえで最もハードルとなるのは、顧客やユーザーなどのステークホルダー全体でソフトウェア開発に対して認識をそろえることだと思う。
上で述べた正しい認識を、開発者、管理者、顧客、ユーザーが認知している必要がある。
顧客やユーザーにそのことをうまく伝えて理解を得ることが、マネジメントや営業をしている人間の大事な仕事であると思う。
「仕事」や「ソフトウェア開発」の特性を考えて合理的に仕事を進めようとすればするほどアジャイルな価値観の方が適していると思うが、実際には日本は未だウォーターフォール型の開発が多いのが事実。
なぜそのようになってしまっているのかは、日本の文化や社会学の視点を取り入れないと答えが見えてこないように思う。
ウォーターフォール型の思考が根付いている組織にアジャイルを取り入れようとするには、まずは社会学などの武器がいるのかもしれない。
参考にした書籍
いいなと思ったら応援しよう！
