仕様の表現力で発注者の力量が分かってしまう - rabbit2goのブログ
「この位の仕様で上手く作っておいて」とひと言伝えておけば、望み通りのシステム一式が出来上がって来ると嬉しい。これなら細かい点まであれこれと指示する必要も無く手間が省けるし、期待通りのモノが期待通りの納期、品質で出来上がってくれば万々歳だ。 しかしながら、世の中、そんな「あうんの呼吸」が通じる関係というものはなかなか無い。明文化できないノウハウは暗黙知として開発者の頭の中に入ったままなので、頼れる人がいなくなってしまうと、誰も作業を代行できない。長年に渡って作業を担当してくれていたベテラン開発者も「寄る年波には勝てず体調を崩して休み」が続くと、途端に問題が噴出してしまう。 だからこそ、設計資料は必須だ。組織として開発をすすめる以上、人が入れ替わっても作業を継続出来るように設計情報の伝授は不可欠なのだ。何を何処まで作成するのか開発スコープを定め、設計の意図や方針検討時の代替案などソースコードに
最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
自動車の電子安全に機能安全の進化を見る - rabbit2goのブログ
日経エレクトロニクス（2011年1月10日号）に、自動車の電子制御系に関する安全規格ISO 26262の記事が載っていた。自動車の開発には関わった経験が無いけれど、ソフトウェアの安全性がどのように捉えられているのか興味があるので目を通してみた。 ISO 26262を一言で言ってしまうと「IEC 61508を自動車向けにカスタマイズ」したものだ。機能安全に関する規格といえばIEC 61508が有名だけど、下記の理由で自動車業界では受け入れられないものだったらしい。 IEC 61508はもともと石油化学プラントなどを想定して作られた規格であるため、自動車のような大量生産品を想定した仕組みになっていなかったからである。 日経エレクトロニクス2011年1月10日号 | 日経 xTECH（クロステック） 実際のところ、機能安全に対する様々な批判（例えば、確率論に偏りすぎている等）を受けて、機能安全以
成功事例を可視化できないか？ - rabbit2goのブログ
ソフトウェア開発の実体はなかなか見えにくい。部外者からの「あいつら何をやっているのか？」という冷たい視線を感じることもあるし、隣の開発者の作業内容すら理解していないことも多い。仕様書の山やソースコードのリポジトリを参照すればそれなりに成果物は見えてくるのだけど、それが全てというわけでもないし、そもそもその中に障害が含まれていたりするのでややこしい。だからtrac等を使ってプロジェクトの見える化を図ったり、不具合成長曲線を描いてゴールまでの距離感を掴んだりするわけだ。確かに内容が幾分見えるようになり、これはこれで分かりやすい。 しかし、このような形で表れてくるのは障害という「負の成果」ばかりなのだ。ソフトウェア開発にバグはつきものとは言え、そんなものばかり列挙されて楽しいかと言われると、実はあまり楽しくないような気がする。発生件数が少なければ嬉しいけれど、それでもネガティブな要素であることに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
