サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
www.itnetinc.co.jp
プロジェクト管理の実践的な手法として“出荷判定会議”があります。簡単に言いますと、ソフトウェア製品の出荷基準を設定し、それを満たしているかどうかを判定する会議です。基準が満たされているか否かが問われ、開発プロセスや手法について触れることはありません。 出荷判定会議の目的は、言葉通り、出荷基準を満たしているかどうかを判定することですが、出荷判定会議の真価は関係者をやる気にさせる、あるいは創意工夫にまい進させる副次効果にあります。出荷判定会議のキー・ポイントは「プロジェクト関係者が出荷判定基準を満たすことを約束して、その実現に向けて努力すること」にあります。その結果、開発現場に規律を持ち込む足がかりにすることができます。 出荷判定会議を行うに際して必要な事柄を整理すると以下の通りです。 1.出荷基準の設定 出荷判定会議に先立ち、関係者の間で出荷基準を決めておきます。 出荷基準は関係者が決める約
名著「知識創造企業」(野中郁次郎+竹内弘高、東洋経済新報社、原書:The Knowledge-Creating Company)の序文に次のような主張が述べられています。 この本で我々は、人間の知識を二種類に分けている。一つは「形式知(explicit knowledge)」と呼ばれ、文法にのっとった文章、数学的表現、技術仕様、マニュアル等に見られる形式言語によって表すことができる知識である。この種の知識は、形式化が可能で容易に伝達できる。またそれは、西洋哲学の伝統において主要な知識のあり方であった。しかしあとで論じるように、より重要なのは、形式言語で言い表すことが難しい「暗黙知(tacit knowledge)」と呼ばれる知識なのである。それは人間一人ひとりの体験に根ざす個人的な知識であり、信念、ものの見方、価値システムと言った無形の要素を含んでいる。暗黙知は、人間の集団行動にとって極め
形式知は文書化した形を持っているので、多くの人に伝える力があります。しかし、形式知だけでは使える知識とはなりません。使える知識となるには関連する暗黙知が融合されなければなりません。暗黙知が融合したとき、形式知は使える知識となります。沢山の形式知を持っていても、それを活かすにはその形式知に関連する暗黙知が必要となります。 暗黙知は、個人ならば、「この場合はこうすれば良い」というように、個人の頭脳内部の感情や意思、外界との関連で知識の種類や働きが異なる、状況との関連の中で記憶されている知識です。骨の髄から理解している状態の知識です。暗黙知はそこから別の知識を生み出す力を持っています。理屈にかなうかどうかではなく、予測したり、こうではないかと勘が働いたりする元になる知識です。 組織においては、暗黙知は、その組織の文化と言えるような知識です。個人がバラバラにもつ暗黙知でなく、組織のメンバで共有され
ITプロジェクト失敗の原因は様々です。関係者が情報交換を怠っていると、プロジェクトは混沌としてきます。失敗の規模が大きくなれば、混沌からの脱却は困難になります。プロジェクトのメンバは休みなく、疲労困ぱいして働くのですが、状況は悪化して行きます。このようなITプロジェクトを、私たちは「泥沼プロジェクト」と呼んでいます。最近では、田舎でさえ、泥沼を見ることが少なくなりましたが、底なし沼の恐ろしさに似ているということから、このように命名されたのだろうと思います。 どうすれば泥沼プロジェクトに陥らないようにすることができるのでしょうか。今日では、泥沼プロジェクト予防策や打開策は分かっています。しかし、ITプロジェクト失敗の原因は様々であり、医療におけるような“標準治療”と呼ばれる方法が確立されていないのが現状なのです。 本稿では、私がコンサルティングした事例と私自身の失敗体験とを取り上げ、これらの
ITプロジェクト管理考はブログへ移行しました。http://itnetinc.co.jp/wp/ あまり話題になったことはありませんが、ソフトウェア産業は重要な基幹産業です。このように言うと、意外に思われる方がおられるかもしれません。しかし、コンピュータは当然のこととして、携帯電話、テレビ、情報家電、カメラ、冷蔵庫、洗濯機に到るまで、ソフトウェアなしには動作しないのです。ですから、「ソフトウェア産業は基幹産業」だと述べて憚ることはありません。 私は、ITのプロジェクト管理に関わって30数年になりますが、今日ほど日本のソフトウェア開発プロジェクトに危機感をもったことはありません。 ソフトウェア開発のプロジェクト管理に精通した熟練者が年々減る一方で、新しく育ってくる人達が少ないのです。そうした、状況に加えて中国やインドのソフト開発企業の台頭が著しく、日本企業の競争力は年々下がってきているという
構成(構造)仕様設計書を書くために必要な知識は、要求仕様(外部仕様)設計書と、ここで定義された機能と動作を実現するために必要なシステム技術です。利用者(顧客)の要求が完全に要求仕様(外部仕様)設計書に反映されることは先ずありません。コンパイラの設計であれば、言語仕様書として定義されていますから、比較的完全に近い表現がされていますが、通常の顧客のシステムの場合、どうしても曖昧さが残ります。従って、構成(構造)仕様設計書を書くためには、図5に示すように、利用者(顧客)を含む人たちからの知識継承が必要となります。 図5 ソフトウェア構築のための知識継承 構成(構造)仕様設計の作業は、次に控えている詳細仕様設計工程で、複数モジュールの詳細仕様設計が平行開発できるようにすることを目的としています。複数のプログラマは、図6に示すように、要求仕様(外部仕様)設計書と構成(構造)仕様設計書を元に詳細仕様設
このページを最初にブックマークしてみませんか?
『www.itnetinc.co.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く