読者です 読者をやめる 読者になる 読者になる

Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

(やはり)アジャイルで組込みを救うことはできないのか...

以前ブックマークした記事を読みながら、これまた以前に書いたエントリのことを考えたりしてた。

   公共部門におけるアジャイル導入: FBIとロッテルダム港の事例

こんなことが書いてある(青字で抜粋)。

公共部門でのアジャイル導入が増えてきている。予算内、期限内にソフトウェアを開発するというニーズを満たすため、そして要求変更に対して柔軟に適応できるようになるためだ。

プロジェクトを加速するため、価値をすばやく見せるため、ITマネージャたちはアジャイル開発へと向かっている。

アジャイルはプロジェクトを「死ぬほど分析して、顧客が必要としないものを作るのではなく」、すばやくリリースします。

アジャイル開発を選ぶことによって、職員たちは変化を受け入れ、途中生じる問題を解決するために、政府内外のステークホルダーと密にコミュニケーションすることの重要性を認めるようになります。

ユーザがアジャイルを選んだのは、自分たちの欲しいシステムを手に入れるためだ。

なぜアジャイルを選んだのかを考えれば、
やはり BSP やドライバの開発にアジャイルは向かないのかもしれない、と思ってみたりする。

要件が事前に決まっているのだから、お客さんだって「あとはよろしく」でいいじゃないか。
プロに任せてるんだ、動くものが出てくるだろう、ってお思いだろう。

かといって、実際はうまくいかないことだってある。

起こった事実についてあとから説明するならまだ納得して頂けるかもしれないが、
事前に見積時に「リスクがあるのでバッファを持たせてます」、なんてのは一体どうお思いになるだろう。

見積の精度は、要求が詳細化・具体化されることによって上がる。
だから通常は開発が進んでコーンの右側にくれば誤差は小さくなる。

BSP やドライバ開発の「初期」の状態とは、コーンの左側というのは、いったいどんな状態なのだろう…?
MPU やデバイスのデータシートが手元にあるなら、もうすでに詳細な情報を手にしているのだろうか。
コードに落ちるまで、もっと言って、テストをするまでが設計なのだから、
コードが書かれていない状態ならやはりコーンの左側なのだろうか。
また、以前に似たようなのをやったから、というのは、
やはり「幻想ファクター」として見なければならないのだろうか。
初めてのことは全てリスク。そう考えるのは悪いことなのだろうか。
プロのくせに「リスク管理」なんて言ってちゃいけないのだろうか。
お客さんと関係のないところでのリスクなら、システム開発よりはプロジェクトをコントロールしやすいのか?
いや、そんなバカな...。一体私は何を書いているんだ!?

こんなふうに考えていると、「システム開発」と「組込み下回り開発」とでは、
どうも性格が違うものを比べようとしているのではないか、と思い始めた。
何がどう違う? コーンは成立しないのか? いや、未来が見えないのは一緒だぞ?


リファクタリング・ウェットウェア』にならって、というわけではないが、
ぜ~んぜんまとまっていないものを書いてみた。
(読み返してみると、ぜ~んぜんアジャイルの話になっていないしw)

実はいま『ソフトウェア見積り―人月の暗黙知を解き明かす』を再読している。

なぜ見積は不確実なのか。よく考えながら読んでみようと思う。