開発プロセスの最適化手法 | オブジェクトの広場
※本稿は、株式会社アイ・ディー・ジー・ジャパン発行の 『ITアーキテクト vol.1』に掲載された「開発プロセスの最適化手法」の元原稿をITアーキテクト編集部の許諾を得て公開したものです。 ※一切の転載をお断りします。 はじめに 筆者らが、オージス総研で「オージステーラリングサービス」という開発プロセスのコンサルティングサービスを行う中で、ユーザー企業の情報システム部門のお客様からは「開発委託先が何をやっているのかわからない」という相談をよく受ける。一方、SIerやソフトハウスのお客様からは「Javaにも慣れたがソフトウェアの品質が一向によくならない」といった相談もよく受ける。どちらも開発組織に明文化された開発プロセスが無いことが原因で、プロジェクトの利害関係者から開発側の活動が見えなくなったり、開発側の品質の改善が進まなくなったりしていることが多い。また「以前、市販の開発プロセスを導入し
<4D6963726F736F667420576F7264202D2091E58B4B96CD835C837483678345834683418A4A94AD8AC7979D>
WATERFALL Model 再考 ソフトウェア開発管理とソフトウェア開発方法論の融合について 北陸先端科学技術大学院大学 情報科学研究科 落水 浩一郎 本フォーラムの目的は、W.Royceが論文[1]で提起した大規模ソフトウェア開発管理に関 する問題を、ソフトウェア工学40年の歴史（その後の技術発展やコンセプトの進化）をふま えつつ、再度検討することにより、今、明日、何をすべきかについて考えることであると 理解する。まず、W.Royceの論文内容を著者なりに要約する。つぎに、1970年のW.Royceの 論文を基準点として考え、彼が提起した問題に対して、その後どのような解決が試みられ たかを整理する。最後に著者なりの問題提起を行い、フォーラムにおける議論のきっかけ の一つにしたいと思う。 １．W. Royce による”Managing the Development of Large
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
プログラミング言語雑感 2017春 - うさぎ組
まえおき kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。 Groovy こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。 GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。 WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。 C# Visual Studioと.N
なぜ「ヒアリング」をしただけで、その人の実力がある程度わかるのか？
コンサルタントをしていた頃、仕事の一つに、「ヒアリング」があった。組織で働いている人に聞き取りを行い、その企業と業務をより深く理解するために行うものだ。 もう15年以上にわたり、何百、何千という人へこの「ヒアリング」を行ってきた。 そして先日、この「ヒアリング」に関して、ある方から 「コンサルタントは、ヒアリングをなんのためにやっているのか？」 と聞かれた。 別に隠すほどのものでもないので、「業務、人間関係、文化の理解」「課題の発見」など、一般的なことを答えたが、 「本当にそれだけか」と改めて問われた。 どうやら、会社にコンサルタントが入ったらしく、色々と聞かれるとのこと。 意図がわからないので、どこまで正直に答えてよいのかわからないらしい。 「そのコンサルタントが同じ考え方でヒアリングしているかは、わからないよ」 とお伝えしたが、「それでもいい、参考に」というので、少し話をした。 実は、
「事実」と「解釈」を明確に区別しない会議は、恐ろしく効率が悪い、という話。
今回は私が会議のファシリテーションを行う上で最も重視していることの1つ、「事実と解釈の区別」について、書いてみたいと思います。 最初に確認しておかなければならないのは 「事実」と「解釈」 のちがいについてです。 例えば、「スターバックスの店舗はあちこちにある。」 「これは事実でしょうか？ それとも、解釈でしょうか？」 と問われて、皆様はどのように答えるでしょう。 読者のあなたは、「もちろん解釈です」とお答えになると思います。「あちこちにある」という言葉は、人それぞれの解釈に委ねられているからです。 その通り、これは解釈です。 それでは「セブンイレブンは大手企業です」は事実でしょうか、解釈でしょうか？ …… こちらも読者諸兄の方にはすぐに分かってしまうかもしれませんが、もちろん、これも解釈です。「大手」という言葉が何を指すのか、人の主観が入っているからです。 「いやいや、それは屁理屈だろう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エリック・エヴァンスのドメイン駆動設計 読書メモ5 - FLINTERS Engineer's Blog