アジャイル手法
今日は10月8日、つまり8日連続投稿となります。
連続投稿にチャンレンジするのは久々ですが、いやいや大変ですね。
以前、99日連続投稿したことがあるなんて想像できません。
何故、当然連続投稿に挑戦しようかと思ったのは #note CREATOR FESTIVAL 2022 のスペシャルバッジをもらおうということに興味を持ったからです。
皆さんにもお知らせは来ていると思いますが、以下の通りです。
昨日はかなり危機的でした。午後から公共交通機関で移動が続いて投稿できる時間がありませんでした。そしてその後、お酒を伴う会食、
気づいたら22時を過ぎています。
どうしよう！
もはやこれまでか！
と思いましたが、電車の中で軽いほろ酔い状態の中で、キーボードを走らせます。そのうち気づけば電車の中で寝落ちしてしまって、ハッと目が覚めたら
「あっ！降りる駅」
と思ったらかなり手前でした・・・
しかし立った時にはもう遅い。
その拍子に立ち上がったはずみにPCを落としてしまいました。これでかなり目がさめて気を取り直して、下車する駅まで再びキーボードを走らせます。
以前、連続投稿の時に感じた内容の薄い浅い文章になってしまいましたが、100歩譲れば一応、投稿にギリギリ耐えられそうな文章になりました。
そして、とにかく
連続投稿第一
で投稿しました。そして後から編集で修正をしたりサムネイル写真を追加しました。
本当はこういうことは良くないだよな～
と思いましたが、実はこういう許容範囲無いで市場投入して、トライアンドエラーで商品を完成さえていく手法をアジャイルだなと思ってしまいました。
アジャイル手法とは？
もともとはソフトウェア開発会社が2001年により柔軟で迅速な市場投入を可能にするソフトウェア開発アプローチでした。
ソフトウェアの開発は自律的に編成された機能横断型のチームが、各々の状況合わせた実現するたための取り組みを行います。ここで重要視されているのは以下の四点です。
手順や手法より個人との対話
包括的な書類よりとにかくソフトが動く
契約交渉よりも顧客との強調
計画に従うことよりも変化への対応
日々の計画のチェックポイントを達成するために、ラグビーのスクラムのような機能横断システムを作って調整する。
という感じです。
一旦チームを組んで役割分担を明確にしたら、やる事をリストを作業します。作業しながら、新たなやる事が必要だったら情報を更新しながら、都度ミーティングを行いながら、情報を更新していきます。
今一つ分からない
と言う方もいるかもしれません。私が以前いた製造メーカーの例（もうひと昔前ぐらいですが）にすると以前はこんあ手法でした。（今はもっと違う手法が導入されているかもしれませんが。）
ソフトウェアを開発する時は（特に日本中心でしょうか・・・）、プロジェクトの範囲、費用、開発日程、開発時の不安要素、開発後の動作や表示する画面等を細かく指定する「仕様書というのを書きます。
具体的には
要求定義: プロジェクトの範囲、コスト、スケジュール、リスク等全情報を収集し文書化
設計: 全情報が収集できたら、顧客のニーズと仕様に基づいて設計を進める。
開発: 設計が定まったら、プランがスタートして製造が開始される。
テスト: 製品が完成したら、顧客に届けられる前に検証と点検を行う必要がある。
運用: 製品が顧客に届けられる。
保守:
です。要求定義はかなりの作業ボリュームです。
これを半年とか1年、1年半といった期間で進めていきます。
事前考察や準備の分量は多く、一方、顧客のニーズや設計日程が確定したら、市場がどうなろうとその計画が完遂するまで続きます。
そしてその仕様書の動きに合わせてソフトウエアを開発していきます。
しかしながら、例えば、想定していた動作がその通りにならなかったり、他社が開発したソフトウエアを自分のソフトウエア上で動かそうとすると動かなかったり・・・ということで時間を要します。
更に、バグ（英語でいう「虫」でプログラムの誤りや欠陥等）を「ゼロ」にしようとしている間に時間はかなりかかってしまいます。
そして仕様書を書き直したり時間を要します。
そうしている間に商戦に間に合わなかったり、他社が先に商品を投入してしまったりして先行者利益を享受されてしまいます。（いわゆる機会損失ですね）
アジャイルでは違います。とにかく、ソフトウエアのコードを書いて動かしていきます。横断的な組織で、相談しながら、ある決められた時期にある一定のレベルまで開発を進めていきます。
市場に商品を出す時も考え方が違います。
深刻なバグでなければ市場にバグが残ったままでも市場投入してしまいます。市場に投入しながら、「バグ収束曲線」といってバグの個数を減少させるスケジュールを作ってそれに沿って減らしています。
よくスマートフォンやＰＣなどで「ファームウエアの更新をします」というのもこのようなバグ収束曲線に基づいて修正されたソフトウエアですね。
日本では以前はハードウエアが中心でしたので「仕様書」重視でした。そういう方が会社で管理者や上層部にいたため、ソフトウエアのアジャイル手法が理解できずソフトウエア開発者で悩んでいた方もいたのではないでしょうか？
今日の内容は私がメーカーに居た時の体験記と以下のサイトからです。
ちょっと話が飛躍し過ぎてしまいましたが、
昨日の内容が薄い私のnoteも取り敢えず、出しても、ギリギリ許容される内容でとにかく「連続投稿第一」で公開してあとで修正や内容を加える。
そして再度推敲するというのは
スクラムみたいなチームじゃないけど
一人アジャイル手法かな!?
なんて思った次第です。
いやいやそんなカッコいいものではなかったですね。
すみません。
本日も最後までお付き合いいただきありがとうございました。
本日のサムネイルはAdobeStockの「ソフトウエア開発」から検索し使用しました。
いつもありがとうございます！
それでは、また次回の記事で会いましょう！
この記事が気に入ったらサポートをしてみませんか？