タグ

ソフトウェア開発に関するmodal_soulのブックマーク (5)

  • 一人前になるには10年: 柴田 芳樹 (Yoshiki Shibata)

    「ソフトウェアエンジニアの心得」と題した話は、講演として行ったり、技術教育として企業向けに行ってきています。基的には、拙著『プログラマー”まだまだ”現役続行』に沿っていますが、その中で「一人前になるには10年」ということで話をしています。該当部分を拙著から抜粋したのが次の部分です。 一人前になるには10年 ソフトウェア開発は創造活動であり、創造能力を高めるには、「より良くできないか」という問題意識を常に持ちながら、多くの経験を積んでいくことです。 リチャード・ガブリエルは、「ソフトウェアを書くことは芸術であり、当にうまくなるには10年を要する」とも述べています。 これは、「10年間ソフトウェア開発を経験した人が一人前である」という意味ではありません。実際の開発現場では、単に10年間を過ごしただけであり、一人前といえる経験・知識にはほど遠い人も多いのです。 デービッド・フーバーとアデワレ

    一人前になるには10年: 柴田 芳樹 (Yoshiki Shibata)
    modal_soul
    modal_soul 2013/06/28
    "自分の知識のなさやスキルの低さを「会社で教えてもらったり指導してもらったことがない」と言い訳しているようでは、20年たっても一人前になることはないかと思います。"
  • CCPMを使って組織にアジリティを注入するのは冴えたやり方 - 勘と経験と読経

    先日公開された「NTTデータはどうやってCCPMを導入したのか?」という資料を見ての感想。アジャイルという言葉を前面に持ってこずに、しかし結果として主にスクラムを中心としたプラクティスを現場に注入している(ような気がする)。CCPMを使って組織にアジリティを注入するのは冴えたやり方だなぁと思った。 そういえば、技術士の二次試験の口頭試問で自分のプロジェクトの進め方を説明した時に試験官から「制約理論を勉強されたのですか?」と聞かれたことを思い出した。自分としては(制約理論は知っていたけれども)プロジェクトの特性に合わせてアジャイルプラクティスをつまみいして運営していたつもりだった。結果としてCCPMに近いことをやっていたのかもしれない(ごっちゃになっていたのかも)。 部分最適が現場を悲惨にしている 制約理論(TOC)というとピンと来ないかもしれないが、10年以上前にベストセラーになったゴー

    CCPMを使って組織にアジリティを注入するのは冴えたやり方 - 勘と経験と読経
    modal_soul
    modal_soul 2013/01/09
    CCPMも少し勉強してみるか
  • ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経

    最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた

    ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経
  • ソフトウェア開発プロジェクトを蝕む10の典型的な過ち

    プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1.「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

    ソフトウェア開発プロジェクトを蝕む10の典型的な過ち
  • 開発者を使い捨てにする会社の話 - rabbit2goのブログ

    開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった(行かなかった)事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは

    開発者を使い捨てにする会社の話 - rabbit2goのブログ
  • 1