プログラマーとＳＥのフリーランスのススメ♪管理人がシステム開発の仕事を始めて１年目でフリー（個人事業主）になった経験から、プログラマーやＳＥがフリーランスになる方法や体験談を書いてます☆
古き悪しき詳細設計書 - SiroKuro Page
詳しすぎる詳細設計書 - SiroKuro Page の続きです。前の記事ではブクマありがとうございました。 はてな界隈の拒否反応を見る限り、詳しすぎる詳細設計書に良い印象を持ってる人は少なそうです。もっとも、私は良い面も持っていると思っていまして、 プログラマの技術的知識や業務的知識の量に左右されることなく、一定の品質を保つことができる なんてメリットがあります。属人性の排除ですね。 あたりまえですね。実は設計者が書いたプログラムを詳細設計書と呼んでいるんですから。しかもテストどころか処理系に食わせてすらいないプログラムです。悪く言えば机上の空論です。良く言えば……絵に描いた餅？ プログラマの技能に左右されないかわりに設計書の品質に左右されるので、一定の品質が「悪い方に一定」だったりすることもあって、色々と下流工程の鬱憤が溜まりそうです。既に溜まっていますね、ごめんなさい。 本題：古き悪
詳しすぎる詳細設計書 - SiroKuro Page
「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力： 「性別と身長のペア」のリスト 出力： 男性の平均身長」と「女性の平均身長」の差 処理概要： 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を１つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
内製する以上は｢すごい｣ものを作らなければ、意味が無い。 - GoTheDistance
孤高というやせ我慢をしながら、会社の経営に直接関わっております。 私のミッションの１つには、会社を回す仕組みを高度化させ本業に貢献する業務システムを作ることがあります。 サラリーマン時代、結構な人が自分の会社の売上があがる仕組みを理解していないことに驚きました。お金が降ってわいてくるわけが無いのに、自分の給与の源泉にさしたる関心が無いものかと不思議に思ったものです。自分が存在する組織の成り立ち・競争原理も理解していないにも関わらず、会社の不平不満を言うだけとはトンデモナイ。 前職は｢人月｣という単位で売上を立てておりましたが、入社して人月単価なるものがあると知った時、自分の売価と自分が手にする給料のあいだには何があるのだろうか、と疑問に思ったものです。自分の給与の数字は売上から｢何か｣を天引きされている数字です。それを知る為には、ご自分の会社の大きな仕事の流れを理解しなければなりません。そ
マネジメントのスピードが開発のスピードに直結する - プログラマの思索
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。