要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
マークアップ、Excel方眼紙 - 勘と経験と読経
自分の所属がSIerだからなのかもしれないけれど、一定比率で「文書はExcelで書くのが効率的」と主張する輩が周りに出現する。Excelはやめてと言っても聞いてもらえない。いわゆるExcel方眼紙。とはいえ、SIばっかりやっていて、おバカになってるのだけが理由とも思えないので、いろいろ考察してみたりした話。ちなみに自分は反Excel派。 公務員が公開するネ申Excelが日本の生産性を落としている話 - Togetterまとめ 「ネ申 Excel」問題 - 奥村研究室 - 三重大学(PDF) ExcelがWYSIWYGなのじゃないか仮説 Excel派の話を聞いていると、なんとなくExcelこそがWYSIWYGだと思っているような気がする。 Wordは、思ったように資料を作りにくい。文書構造を意識したり、各種のワードプロセッシングが煩い。あと罫線引いたりが難しい PowerPointは、自由自
ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経
最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた
勘と経験と読経
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第68回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。 さて、今回読む本は「組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る」である。 組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る 作者:Douglas Squirrel,Jeffrey Fredrickオーム社Amazonなお私は電子版で読む派なのでよくわからないのだが、物理書籍派のバディから「けっこう分厚いっす」というタレコミがあったので今回は1週間延ばして3週間で読んだ。確かに2週間はちょっと難しかったかも。 『組織を変える5つの対話』の概略 ひとことで言うと、アジャイル開発を下敷きに「組織内部のコミュニケーションの質を上げる」ことにフォ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
