週刊READING LIFE vol.124

銀の弾丸なんて無いんだ《週刊READING LIFE vol.124「〇〇と〇〇の違い」》

thumbnail


2021/04/19/公開
記事:田中真美子(READING LIFE編集部ライターズ倶楽部)
 
 
「アジャイル開発を導入すれば、開発スピードがもっと早くなるんじゃないの? 」
 
社内のシステム部門の動きが遅い、なんてあなたはお嘆きになった経験はあるだろうか?
または、あなた自身が社内のシステム部門で働いていて、上司に言われたことがある、なんてこともあるかもしれない。
 
アジャイル開発とは、ソフトウェア開発手法の一つだ。
日本では今から15年〜10年くらい前あたりから注目されている手法である。
 
ドキュメントより実際に動くソフトウェアを重視し、少人数で同じ拠点に集まって毎日意思疎通を図りながら小さな単位に区切ってソフトウェア開発を進める手法で、一般的に迅速にソフトウェア開発を進めることができる手法として広く認知されている。
 
それまではソフトウェア開発はウォーターフォール型開発が主流だった。
ウォーターフォール型開発とは、要件定義→設計→製造→テストと、ソフトウェア開発の一連のプロセスを工程に区切り、順番に実施していくやり方だ。
水が上流から下流に流れていくかのように、一度下流に流れてしまうと上流には戻ることはできない。
工程ごとにしっかり完了条件を決めて次の工程に進める。
 
住宅を建てるときをイメージしていただくとわかりやすいだろう。
まずは施工主にどんな住宅を建てたいのか希望を聞き(これが要件定義)、そしてそれを図面に起こし(設計)、さらに材料と大工を調達して実際に住宅を建てる(製造)、最後に出来上がった住宅を施工主が内覧しチェック(テスト)して完成だ。
 
住宅を建てた後にやっぱりトイレは2つ欲しかった、となっても遅い。
そうなると追加で改築が必要になる。
 
同じようなことがウォーターフォール型開発でも当てはまる。
テスト工程まで進んでしまった後に設計を見直す必要が生じた場合、設計→製造はやり直しの箇所ができ、大きな手戻りとなる。
そうなると、完成するまでの期間やソフトウェア開発のための要員を維持するためのコストにも影響が出る。
最悪、当初の予算を大幅にオーバーする可能性だってあるのだ。
 
一方、アジャイル開発では、そのような問題を解決できる! と注目され始めたのだ。
 
アジャイルとは英語だとagile、「機敏な」という意味があるらしい。
その意味の通り、アジャイル開発という手法は、大きな単位で開発を進めるのではなく、少人数で小さい単位に区切って製造とテストを繰り返しながらソフト開発を進めるやり方だ。
 
さっきの住宅建築の例えだと、最初から住宅を完成させることをゴールとして計画立てて工事を行うが、アジャイル開発は車のタイヤを作る、エンジンを作る、ドアを作る、など小さい単位に区切って必要なものを必要なだけ少数のチームで作っていく、というやり方だ。
なので、あるパーツに対して何らかの変更が生じた場合も、影響は最小限に留めることができる。
 
ファッションやメイクのトレンドのように、ソフトウェアやシステムの開発にも流行がある。
アジャイル開発が日本で流行り出す前は、オフショア開発がブームだった。
オフショア開発とは、主に開発コストの低減を目的にシステム開発業務の一部を海外企業に委託することを指す。
海外に仕事を委託するのだから、作って欲しいものを明確に伝えるために重厚長大な設計書を事前に用意する必要があり、開発手法もウォーターフォール型で一部の工程を海外に出すやり方だ。
 
そこから一転してアジャイル開発が注目されたのだから、まるで真逆の手法がブームになったということだ。
ヤマンバギャルファッションが流行っていたのに、急に清楚なお嬢様ファッションが流行っちゃった、みたいな。

 

 

 

さて、私はIT企業に約20年勤める、しがないサラリーマンだ。
冒頭に出てきたような企業の社内システム部門からシステム開発を受託し、開発して納めるのが主な仕事である。
 
実際に業務の中でこういった一連のブームを目の当たりにしてきた。
 
冒頭のような問いかけも何度もされてきた。
 
そして実際にウォーターフォール型開発とアジャイル開発、両方を仕事で経験してきたからこそ、言えることがある。
 
理想と現実は違う。
 
銀の弾丸なんて無いんだ。

 

 

 

あれは今から3、4年ほど前だったと思う。
とあるサービスを提供するプロダクト開発のプロジェクトが社内で立ち上がった。
 
競合他社も水面下で着々と類似サービスの開発を進めていることがわかっていて、私の勤める会社でもその競合他社に負けないスピードでプロダクト開発し、速やかにローンチすることが必達であった。
 
与えられた期間は半年ほど。
 
規模にもよるが、ある程度広く顧客に提供するソフトウェアの開発期間としては非常に短い。
 
従来型の開発手法では間に合わない、ということで開発手法はアジャイル開発を取り入れ、技術も新しいソフトウェア開発技術を導入して進めることになった。
 
開発の難易度は高く、実際開発期間中には作業が遅れたり、想定外の仕様が途中で分かったりとトラブルもあったが着々と進んでいった。
 
3ヶ月くらい経った頃にはニュースリリースもされてしまった。
もう、後戻りはできない。
なんとか完成させるしか無いのだ。
 
そして開発スタートから半年後、ニュースリリース通り、無事にサービス開始にこぎつけたのだった。
 
今まで社内で取り組んできたプロダクト開発と比較し、少人数の体制で期間もコストも抑えて開発することができ、大きな成果となった。
実際社内で他の部署に対してもこのプロジェクトは成功事例として広く展開された。
 
……という成功事例を、当時同じ部署にいて別のプロダクトの開発を担当していた私は横目で見ながら、「担当者は大変だったろうな、よく間に合わせたなぁ」という凡庸な感想しか持ち合わせていなかった。
 
ところがサービス開始してからしばらくしたある日。
担当が異動になり、そのプロダクトの開発マネージャーに任命されたのだ。
 
フタを開けてみれば、「あちゃー」という感想しか出なかった。
 
開発メンバーは、急造りで完成させるために投入した超優秀な技術者と他数名。
 
作りたくないものは作らない、というスタンスで、アジャイル開発の進め方に乗っ取り、次に開発したい要求仕様を提示しても納得しなければ作らない。
お前は気難しい芸術家か! と叫びたくなったが、マネージャーといえど配属されたばかりで立場の弱い私はグッと堪えてなんとか説得しながら開発を進めてもらう。
 
そんな胃の痛い日々が2、3ヶ月ほど続いた。
 
また別の新しいプロジェクトがスタートしたことにより、開発メンバーの配置換えがあり、気難しい芸術家たちが去ったあと、ようやく普通に言うことを聞いてくれるメンバーばかりになってほっとしたのも束の間、今度は開発スピードが低下して思うように進まないのだ。
 
そして「ドキュメントより動くもの」を重視していたためドキュメントが少ない。
メンバーが変わったので、ソフトウェアの仕様を理解しながら進める必要があったのだが手がかりがソフトウェアのコードしか無いのだ。
 
一方でビジネス部門からはどんどんプロダクトの機能追加の依頼が舞い込んでくる。
アジャイルだから早く作れるでしょ? と言わんばかりだ。
 
別の理由でまた胃が痛い日々が続いていたある日、ついに事件が起きてしまう。
 
私たちのサービスを利用しているお客様が、店舗で大々的なキャンペーンを行うことになった。
事前にキャンペーンを行うことは私たちにも知らされ、万が一何かあったときのためにキャンペーン当日は体制も組んでいたが、私たちのプロダクトに不具合があり、大トラブルとなったのだ。
 
当然キャンペーンにも大きな影響が出て、お客様の店舗は大混乱となった。
当日私はお客様店舗の様子を見にいったのだが、私たちが提供するサービスがうまく動かないせいで、店舗のスタッフさんは皆汗をかきながらお客様に対して一生懸命お詫びをしていた。
 
解析の結果、プロダクトの一部の設定にミスがあり、キャンペーンでデータ量が増えたことによってそれが顕在化したことが分かった。
 
設定はほんの1箇所で、その1箇所のミスでお客様も、私たちの会社も大きな損失を出すことになったのだ。

 

 

 

これに懲りた私は、一旦プロダクトの機能を追加する開発のスピードを落とすことを宣言した。
他にも問題のある箇所がないか見直し、リリース前には慎重に誤りがないかを確認するためにテストプロセスを見直した。
 
そして何より、一番はメンバーのマインドの改革だった。
開発スピードを何よりも重視するようになっていたところを改め、私たちの顧客にとって、安定したプロダクト品質が何よりの価値であるということを徹底して浸透させた。
 
その後はミスが減り、安定してプロダクトが稼働するようになった。
トラブルが完全に無くなることは無かったが、それでもあの時のようにお客様に大損害を与えるような大トラブルは起こらなくなった。
 
私の胃痛も少し和らぐことができた。

 

 

 

「アジャイル開発を導入すれば、開発スピードがもっと早くなるんじゃないの? 」
 
さて、冒頭のような問いかけを誰かにしたことがあるあなた。
 
答えはイエスでも、ノーでもある。
 
厄介な対象を一撃必殺で仕留めることができるものを例えて、「銀の弾丸」と呼ぶことがあるが、銀の弾丸なんてないのだ。
これはフレデリックス・ブルックスというIBMのオペレーションシステムを開発した技術者が過去に発表したソフトウェア工学の論文でも述べられていることだ。
 
銀の弾丸はない。
あるのは、人の情熱と創意工夫なのだ。
 
最後に。
アジャイル開発に取り組んだことで得られた大きな成果もあった。
小さな開発を繰り返し繰り返し進めることで改善が繰り返されてきたし、その中で若手中心のメンバーは大きく成長した。
 
私にとっては、若手の大きな成長が何より一番大きな成果だった。
 
なんらかの立場でアジャイル開発へこれから携わる人へ。
立ち上げ直後は、思ったより開発スピードが出ないこともあるが、辛抱強く、暖かく見守って欲しい。
 
 
 
 

□ライターズプロフィール
田中真美子(READING LIFE編集部ライターズ倶楽部)

神奈川県藤沢市在住。IT企業に勤める40代中間管理職。
仕事の疲れをカレーで癒す日々を送る。
ライティングは2020年から勉強中。読んだ人の心を明るくする、そんな文章を書けるようになりたい。

この記事は、人生を変える天狼院「ライティング・ゼミ」の上級コース「ライターズ倶楽部」をご受講の方が書きました。 ライティング・ゼミにご参加いただくと記事を投稿いただき、編集部のフィードバックが得られます。チェックをし、Web天狼院書店に掲載レベルを満たしている場合は、Web天狼院書店にアップされます。

人生を変えるライティング教室「天狼院ライティング・ゼミ」〜なぜ受講生が書いた記事が次々にバズを起こせるのか?賞を取れるのか?プロも通うのか?〜

お問い合わせ


■メールでのお問い合わせ:お問い合せフォーム

■各店舗へのお問い合わせ
*天狼院公式Facebookページでは様々な情報を配信しております。下のボックス内で「いいね!」をしていただくだけでイベント情報や記事更新の情報、Facebookページオリジナルコンテンツがご覧いただけるようになります。


■天狼院書店「東京天狼院」

〒171-0022 東京都豊島区南池袋3-24-16 2F
TEL:03-6914-3618/FAX:03-6914-0168
営業時間:
平日 12:00〜22:00/土日祝 10:00〜22:00
*定休日:木曜日(イベント時臨時営業)


■天狼院書店「福岡天狼院」

〒810-0021 福岡県福岡市中央区今泉1-9-12 ハイツ三笠2階
TEL:092-518-7435/FAX:092-518-4149
営業時間:
平日 12:00〜22:00/土日祝 10:00〜22:00


■天狼院書店「京都天狼院」

〒605-0805 京都府京都市東山区博多町112-5
TEL:075-708-3930/FAX:075-708-3931
営業時間:10:00〜22:00


■天狼院書店「Esola池袋店 STYLE for Biz」

〒171-0021 東京都豊島区西池袋1-12-1 Esola池袋2F
営業時間:10:30〜21:30
TEL:03-6914-0167/FAX:03-6914-0168


■天狼院書店「プレイアトレ土浦店」

〒300-0035 茨城県土浦市有明町1-30 プレイアトレ土浦2F
営業時間:9:00~22:00
TEL:029-897-3325


■天狼院書店「シアターカフェ天狼院」

〒170-0013 東京都豊島区東池袋1丁目8-1 WACCA池袋 4F
営業時間:
平日 11:00〜22:00/土日祝 10:00〜22:00
電話:03−6812−1984


2021-04-19 | Posted in 週刊READING LIFE vol.124

関連記事