アカウント名:
パスワード:
毎日の記事にこうある。
- 同庁の審査部門などから、機能の追加要求が断続的に寄せられたことが混乱に拍車をかけた...
- 特許庁が発注段階で、どういうシステムが必要かを詳細まで文書に落とし込む『見える化』をしていれば、ここまで開発が混乱することはなかった...
#なんだかなあ。
予算の段階から、プロトタイプ作成を分けておくのはどうですか。お役所ならではの、予算が初めにあって、そっからモノをいきなり作っちゃうから失敗しちゃうんじゃないかな。
初年度: XXシステムのプロトタイプ開発。予算NNNの範囲でXXのプロトタイプを開発。 プロトタイプによるユーザー調査から、本ちゃんシステムの要求機能、予定価格の見積もりを作成次年度: XXシステムの入札、本開発。
ユーザーは実物を見るまで(使うまで) 間違った意見しか言わない、ぐらいに考えとくべき。実際に動くプロトタイプを見せて、使わせなければ、良いシステムなど作れるわけがないと思います。
>> 仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、
という仮定が、現行のお役人様ルールで通用するかが最大の問題ではないでしょうか?
というか、会計検査院が納得するかどうかが最大の問題かと
はい。仰るとおりだと思います。 > 現行ルール&会計監査員
実際、懸念事項は多々あるでしょう。私も色々思いつきましたが、そういったデメリットを踏まえても、やっぱりプロトタイピングを導入する(導入のために手筈を整える)メリットは大きいのではと思うんですよね。
・プロトタイプ(必ず捨てる)というものに対する予算が付きにくいかもしれない-> いきなり開発するよりお得である、ということをどれだけ理解してもらえるかですね。
・そもそもプロトタイピングしたからって、ちゃんとしたもの作れる保証がない-> 逆に、プロトタイプで作れないなら、いきなり本ちゃんで作れるわけないかと。であれば撤退時の被害が少ないので、失敗したらむしろプロトタイピングにして良かったことになります。お役人的にも言い訳しやすいですよね!「本来困難極まるプロジェクトでしたので(俺は悪くないが)被害を最小限にする方法を選択しました(プロトタイピングじゃなきゃもっと大変だったんだぜ)」
・プロトタイプ運用に付き合わされる現場から文句が出る-> 最終的に使いやすいシステムができれば現場にとって一番得であることを納得させる特に今回のような、運用がわかりにくいシステムでは現場へのヒアリングのため特定担当者ばかり負荷がかかる(結果として十分ヒアリングできない)という問題があります。プロトタイプという誰でも目に見えるもので「深く狭く」から「浅く広く」へ負担を下げれることは大きいと思います。
・プロトタイプは裏金作りに利用しやすい-> そこはお役所の良心しだいですけど・・。というか裏金なら別にプロトタイプじゃなくても今でも普通にゴニョゴニョ・・・
ともあれ「コンクリートから人へ」と言うなら、コンクリートに合った方法(ウォーターフォール)でなく人、つまりソフトウェアに合った方法へと変えるべき、と思います。
工事という意味でソフトウェアがコンクリートに劣るところは、複雑で完成像が見えないこと。逆に優れているところは、捨てる費用がほぼゼロな点。建物は作っちゃうとなかなか壊せないですから。納得のいくものができるまで、作ってはクシャクシャに丸めてポイ、とするのがソフトウェアの正しい作り方です。(まあ実際はハードがなきゃ動かない、のはさておき)
個人的に金言としている「銀の弾丸はない」との言葉どおり、プロトタイピングが向くものと、ウォーターフォールが向くものとそれぞれあるはずです。少なくとも現状のウォーターフォール一択よりは、幅を広げるに超したことはないのではないかと。
#長文失礼
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
発注者問題 (スコア:4, 興味深い)
毎日の記事にこうある。
- 同庁の審査部門などから、機能の追加要求が断続的に寄せられたことが混乱に拍車をかけた...
- 特許庁が発注段階で、どういうシステムが必要かを詳細まで文書に落とし込む『見える化』をしていれば、ここまで開発が混乱することはなかった...
#なんだかなあ。
Re: (スコア:5, 興味深い)
Re: (スコア:3)
予算の段階から、プロトタイプ作成を分けておくのはどうですか。
お役所ならではの、予算が初めにあって、そっからモノを
いきなり作っちゃうから失敗しちゃうんじゃないかな。
初年度: XXシステムのプロトタイプ開発。予算NNNの範囲でXXのプロトタイプを開発。
プロトタイプによるユーザー調査から、本ちゃんシステムの要求機能、予定価格の見積もりを作成
次年度: XXシステムの入札、本開発。
ユーザーは実物を見るまで(使うまで) 間違った意見しか言わない、ぐらいに考えとくべき。
実際に動くプロトタイプを見せて、使わせなければ、良いシステムなど作れるわけがないと思います。
Re: (スコア:0)
>> 仮に初年度予算では満足いくプロトタイプを作れなかったとしたら、
という仮定が、現行のお役人様ルールで通用するかが最大の問題ではないでしょうか?
Re:発注者問題 (スコア:1)
というか、会計検査院が納得するかどうかが最大の問題かと
Re:発注者問題 (スコア:5, 参考になる)
はい。仰るとおりだと思います。 > 現行ルール&会計監査員
実際、懸念事項は多々あるでしょう。私も色々思いつきましたが、
そういったデメリットを踏まえても、やっぱりプロトタイピングを導入する(導入のために手筈を整える)メリットは
大きいのではと思うんですよね。
・プロトタイプ(必ず捨てる)というものに対する予算が付きにくいかもしれない
-> いきなり開発するよりお得である、ということをどれだけ理解してもらえるかですね。
・そもそもプロトタイピングしたからって、ちゃんとしたもの作れる保証がない
-> 逆に、プロトタイプで作れないなら、いきなり本ちゃんで作れるわけないかと。
であれば撤退時の被害が少ないので、失敗したらむしろプロトタイピングにして良かったことになります。
お役人的にも言い訳しやすいですよね!「本来困難極まるプロジェクトでしたので(俺は悪くないが)被害を最小限にする方法を選択しました(プロトタイピングじゃなきゃもっと大変だったんだぜ)」
・プロトタイプ運用に付き合わされる現場から文句が出る
-> 最終的に使いやすいシステムができれば現場にとって一番得であることを納得させる
特に今回のような、運用がわかりにくいシステムでは現場へのヒアリングのため
特定担当者ばかり負荷がかかる(結果として十分ヒアリングできない)という問題があります。
プロトタイプという誰でも目に見えるもので「深く狭く」から「浅く広く」へ負担を下げれることは大きいと思います。
・プロトタイプは裏金作りに利用しやすい
-> そこはお役所の良心しだいですけど・・。
というか裏金なら別にプロトタイプじゃなくても今でも普通にゴニョゴニョ・・・
ともあれ「コンクリートから人へ」と言うなら、コンクリートに合った方法(ウォーターフォール)でなく
人、つまりソフトウェアに合った方法へと変えるべき、と思います。
工事という意味でソフトウェアがコンクリートに劣るところは、複雑で完成像が見えないこと。
逆に優れているところは、捨てる費用がほぼゼロな点。建物は作っちゃうとなかなか壊せないですから。
納得のいくものができるまで、作ってはクシャクシャに丸めてポイ、とするのがソフトウェアの正しい作り方です。
(まあ実際はハードがなきゃ動かない、のはさておき)
個人的に金言としている「銀の弾丸はない」との言葉どおり、
プロトタイピングが向くものと、ウォーターフォールが向くものとそれぞれあるはずです。
少なくとも現状のウォーターフォール一択よりは、幅を広げるに超したことはないのではないかと。
#長文失礼