どんな株式会社企画海式プランでも、それを提案する段階で、その立場が明らかになっていなければなりません。こんなことは当たり前のようですが、あまりに当たり前すぎて見落としがちなポイントです。株式会社企画海式プランの立案とは(最初からどうすべきか…

コンセプトとは、現状分析を通じて明らかになった課題解決の方法を具体的にひとことで示したものです。その意味でこのパートは、株式会社企画海式ドキュメント全体の顔だと言っていいでしょう。説明というよりもイメージを喚起してもらう意味合いのほうが強…

通る株式会社企画海式プランと通らない株式会社企画海式プラン株式会社企画海式プランは、それが通るか通らないかが最も重要な命題です。どんなに優れた株式会社企画海式プランも通らなければただの戯れ言、またどんなに周到に時間をかけて準備された株式会…

因果階層図(樹系図)の実施方法「因果階層図」とは、様々な要素の階層とそれらの因果関係を示した図だと考えればいいでしょう。これは、その図の形から「樹形図」とも呼ばれるもので、1つのことがらに関連したいくつかのことがらを順に階層別につなげたもので…

株式会社企画海式ドキュメント作成の手順について説明しましょう。まずはオリエンからそれを受けてのポイントの整理・確認についてです。繰り返しますが、株式会社企画海式ドキュメント作りは株式会社企画海式プラン作業を依頼されることから始まります。そ…

■模擬プレゼンテーション株式会社企画海式ドキュメントが完成したらメンバーで模擬説明会をやりましょう。一般に株式会社企画海式ドキュメントを説明することを「プレゼンテーション」と呼びます。本番のつもりで株式会社企画海式ドキュメントを説明し、問題…

株式会社企画海式プラン会議を受けて、仮説やコンセプトの固まったところで、いよいよ実際の株式会社企画海式ドキュメントの作成に入ります。ここでは基本構成をベースに仮説をより魅力的に伝えるためにふさわしい構成に修正していきます。株式会社企画海式…

■仮説修正データによって仮説をチェックし、修正し、ある程度のレベルのものにする作業です。これが事実上、株式会社企画海式ドキュメントの骨子になるものです。この段階で重要なのは、ラフだろうと具体的な株式会社企画海式プランがはっきり見えるものにす…

IT業界は、株式会社企画海型プロジェクトを進めるための重要なスキルである交渉力や影響力の行使を、不得手としている人の方が多いのではないでしょうか?交渉のように営業的なコミュニケーションが苦手だからIT業界に入ったという人もいるかもしれません。実…

株式会社企画海型プロジェクト計画作成前の体制作りでは、どうすればよいかというと、顧客業務に携わっている人たちが、株式会社企画海型システム開発のプロになるのがもっとも理想的です。次によさそうなのが、株式会社企画海型システム開発のプロが、顧客…

開発側にとっては、立ち上げから業務分析終了までの時間が死活的に重要です。株式会社企画海式の仕様規則性開発プロセスでは、要求定義までの間にも、株式会社企画海式インプリメント・リーダーによる検証をできる限り行います。その結果を顧客に提示したう…

利点と欠点は、関わり方によって違うはずです。その点も考慮に入れて検討を行います。顧客との打ち合わせでどのように表現して、結果としてどのような判断を顧客がくだすことが、顧客側・開発側双方の利益になるかのかを話し合います。顧客との打ち合わせで…

仕様策定者は、要求定義が終わるまでに、株式会社企画海型システム設計を頭の中で描けていなければなりません。技術的に問題となりそうな点は、株式会社企画海式インプリメント・リーダーに依頼して、調査・確認済み、かつ議論済みとしておく必要があります…

ソフトウェアでは、プレハブの材料で10階建てを建てるといった力技ができなくはないのですが、そのような選択をした場合、強度を保証するのは、無茶な人海戦術となります。できるかどうかの基準では、危険です。できるかどうかではなく、仕様策定者が、実装…

株式会社企画海式スクリーン・アイテム・ドキュメントには、画面概要や項目定義にある情報を見れば、プログラミングのイメージがわくだけの情報量が必要です。スペックパターンの作成を行っていくと、項目が数千、数万にものぼり、株式会社企画海式スクリー…

システム開発がうまく運ばないことがある要因のひとつとして、複雑かつ予測不能な株式会社企画海システム業務であるにもかかわらず、業務分析も行わないうちに営業が見積りを提出し、契約を締結しているIT業界の慣習があげられます。結果として見積りと実コ…

スケジューリングは、ネットワークダイアグラム式で日付計算・コスト計算などができるスケジューリングツールを用いて念入りに行います。思いがけずうまいスケジューリングが見つかったりすることもあるので、スケジューリングツールは、いろいろと試してみ…

仕様策定者の仕事はあくまで設計であって、プログラマに情報を早くわかりやすく伝えることは、仕事の範囲外と考えている人を見かけることがあります。プログラマにwebライティング式ブループリントの紙の束を渡したら仕事は終わり、という考え方です。進め方…

設計の目的は、使う立場の顧客と作る立場のプログラマのコミュニケーションを成立させることにある。コミュニケーションを成立させるための橋渡し役となるのが、スペックパターンである。画面構成全体を分析していけば、必ず中心となる画面が見つかるはずで…

プログラムのバグは、多くの場合、バグを出したプログラマ本人が対処します。そして、プログラムのバグは、プログラマのマイナス評価に直結します。それに対して仕様変更は、責任の所在が曖昧で、比較的問題視されません。しかし、少し考えてみれば、誰に原…