無料ブログはココログ

« 2014年3月 | トップページ | 2014年5月 »

DSLとXTextとお好み焼き - 第56回 SEA関西プロセス分科会に参加して -

DSLを、同じように仕様記述に用いられる形式手法に当てはめると、事前条件と事後条件を示すものと、アルゴリズムなどの操作を含むものがあります。前者は実装との比較テストや目的の状態になる(ならない)かの確認に、後者は不整合の確認や動作させることに向いています。

分科会「Eclipse XText によるドメイン特化言語の応用」で紹介されたXTextは、コードがジェネレートできるDSL環境です(細合 晋太郎さんの資料:ドキュメントチュートリアル

乱暴に言ってしまうと、とても良くできたyacc/lex(構文解析/字句解析)環境で、eclipse上でのバリデーションやjava来無頼の利用、プラグインかが可能です。

今回の分解会を終えてから、DSLでコードをジェネレートする理由を考えていました。ようやく、言語の汎用性、簡易言語のような生産性、ドメイン特化のメリットとスモールスタート、に思い至りました。今回は、お好み焼きに例えて説明してみます。

言語とは何か

言語と言うのは、ある特定の概念に言葉を定義して、その言葉の組合せや抽象化された概念で、高度な情報を効率的に伝達する方法です。

「小麦粉・玉子・水・キャベツを材料と共に焼いてソースをかけたもの」

と毎回言わなくても「お好み焼き」と言うことで伝わります。ここでは「材料と共に」と書きましたが、これはすでに抽象化された概念で、材料も混ぜる「練り込み」と、鉄板に材料を先に置く「重ね焼き」があります。

関西のお好み焼き屋さんでは練り込みが多く、「材料名」+「玉子」を指定する意味で「豚玉」のように言うだけで、豚の練り込みのお好み焼きが注文できます(YAHOO!知恵袋)。

このように言語とは、言葉を定義して、その組合せや抽象化された概念で、情報を効率的に伝達する方法です。情報が計算機で実行するプログラムなら、プログラミング言語になります。

より高度な言語は、細かなプログラミングをしなくても設定だけでプログラムを実現できます。ここでは設定だけで実行できる言語を簡易言語と呼びます。

簡易言語との違い

ここで「モダン焼き」を考えてみます。モダン焼きとは、片面を焼いたお好み焼きを焼きそばの上に載せて一体化させたもので、重ね焼きの一種です。

重ね焼きが定義されているなら、焼きそばの定義を追加すればモダン焼きを表現できます。しかし、重ね焼きが定義されていないと、少々面倒です。

簡易言語では、あらかじめ定義された部品を組み合わせることで、プログラムを実現します。基本的には、用意された部品と組合せ法が実現できるものの限界になります。

限界の解決法には色々あって、オープンソース化や拡張インタフェースなどもあるでしょう。しかし、パッケージングされているメリットを考えると、基本は多様な機能をサポートして汎用化してある方が便利でしょう。

ドメイン特化のメリット

さて、お好み焼きの一種と言えなくもないのが、地元でお好み焼きと呼べレテいる「広島焼き」です。全体を一体化させないで、クレープのような作り方をします。

汎用性を考えるなら広島焼きを含めて定義すべきですが、広島で商売をするのでなければコストメリットがないかもしれません。そうなると、広島焼きを食べたい人は自分で定義せざるを得ません。

注文を聞いてくれるお好み焼き屋さんなら、オープンソースのツールのように改造も不可能ではありません。しかし、全体のコーディネート(設計)のほか、正式メニューにならなければ調理師さんがかわる(バージョンアップ)ごとに一から注文のやり直しになる可能性があります。

そこで、専用の調理師(XText) を雇って、作成したレシピどおりに作ってもらいます。広島焼きのテクニックを定義しておけば、色々な広島焼きもお願いできるでしょう。

しかし、レシピを作る際に関西風のお好み焼きを含めてしまうと、レシピは膨大なものになってしまいます。レシピを作ることが必要な部分(ドメイン)だけに特化することで、大きな効果が得られるでしょう。

スモールスタート

XTextのようなDSL作成環境があれば、特定のドメイン専用の簡易言語を開発することができます。定義した言語は類似のものを汎用的に処理可能で、簡易言語の様に高い生産性を得ることができます。

類似のものを処理する場合、テーブルプログラミングのような方法もありますが、汎用性に限界があります。より汎用的にするにはテープルに言語的な定義を入れ、再評価(evaluation)して実行することも可能ですが、定義の間違いを簡単には検証できません。

XTextはeclipse環境と一体化して、コード補完やバリデーションが可能です。汎用性と信頼性を簡単に両立できる方法だと言えるでしょう。

細谷さんの講演では通信プロトコルのDSL定義にXTextを用いられていました。通信ヘッダーにあるデータ長は、ヘッダー以外のバイト数がほとんどですが、ヘッダー部のバイト数を含むものもあるので、その分類を定義することで共通に処理できるようにされていました。

お話の中では「必要なところから実施すれば良い」という言葉が気になりました。ドメイン定義と聞くと全ての定義する様に思ってしまいますが、必要なところ、役に立つところをドメインとしてスモールスタートすれば良いのだと理解しました。

おわりに

SEA関西プロセス分科会をきっかけにDSLとXTextについて考えました。世の中にはXTextを初めとして、様々なツールがあります。ここぞと言う時に、迷わずにふさわしいものが使える様に、腕を磨いておきたいと思いました。

[#xpjugkansai] 失われつつある企業文化をアジャイル開発に学べ - XP祭り関西2014 -

失われつつある企業文化は、アジャイル開発に生きていました。XP祭り関西2014 (togetter)に参加して、そう思いました。

今回は、ライトニングトークをさせていただきました。テーマは「 リーダー諸君!アジャイル開発を学び未来への道を切り開こう」です。

失われつつある企業文化

「昔はこうじゃなかった」とおじさんは思うのです。そりゃ大変なこともありましたが、みんなで助け合い、育て合い、知恵を出し合って開発していました。

リーダーは段取りを決めますが、強権的でなく、メンバーも意見を出しました。おかしなことを言うメンバーにそっと同僚がアドバイスしてくれることや、関係の悪くなった同僚との間をリーダーや上司が取り持ってくれることがありました。

変わってきたのは会社が株主のもの、と言われるようになってからかもしれません。会社の利益が重視され、責任を果たしていることを株主に示すかのように標準プロセスの遵守が求められました。

大規模開発向けに作られたプロセスは、役に立つ内容もたくさんありました。しかし、利益が重視される反面、以前よりも管理作業が増え、リーダーはそのゴールの達成に必死になってしまいました。

そのようなリーダーに育てられた世代は、プロジェクトの暖かみをあまり知らないのかもしれません。周りのアドバイスを得られずに育った人たちが、目先の目標達成に必死になって、より厳しく管理してしまうのは仕方がないことかもしれません。

日本の企業文化がアメリカ経由で帰ってきた

コミュニケーションを取って協調して開発することは、目先の生産性や利益を考えると無駄に思えるかもしれません。しかし、プロジェクトの反省会で必ず問題にされるほど、コミュニケーションは重要です。

昔の日本企業では様々な現場でカイゼン活動が行われ、社内勉強会や組合活動など仕事のあり方を考える場がありました。しかし、米国流のトップダウンのプロセス改善や利益優先の考え方によって、多くの企業文化が失われました。

米国でもプロセス改善は行われましたが、それは信頼性が最も重要とされる国防や航空等が中心でした。一方、新規ビジネスを立ち上げる場合などは、チームで同じゴールに向かった、知恵を出し合い、助け合う漸増的な開発法が行われました。

それはアジャイル開発と呼ばれ、日本発のSECIモデルを活用したスクラムや、トヨタ生産方式の流れを汲むリーン開発など、日本の企業文化を取り入れたものです。

XP祭り関西2014

XP祭り関西2014でも、これらに繋がるお話がありました。

前川さん、西河さん、細谷さんの「わかりやすいアジャイル開発の教科書 ~ 教科書の向こうに何が見えてますか? ~」では、成長できるアプローチがアジャイルの良いところ、打ち合わせの際にアメを置くだけでも場が和やかに変わる、とされました。

会社は、仕事という義務を果たすだけでなく、仕事を通じて成長し、仲間と共に歩むのだと思いました。

あきぴーさんの「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」では、同じ景色がどう見えているかを認識することや、タックマンモデルのように雨降って地かたまる場を作ることが大切とのお話がありました。

本当に腹を割って話すことは重要です。考えは違ってもみんなで目指すゴールが同じなら、互いに尊重して助け合うことが可能です。

失われつつある企業文化をアジャイル開発に学べ

XP祭り関西で話したかったのは、西河さんらが言われていた「緩やかに危なくなってるけど、やり方を変えないといけないことに組織が気付いていない」という危機感です。

プロジェクトという短期ゴールだけを見ると、ガミガミ言うことで乗り切れてしまうかもしれません。しかし、それではいつまでたってもそのままで、リーダの限界がチームの限界です。

あきぴーさんによると、「改善」は一度だけ、「カイゼン」は継続する意味が含まれているそうです。今を乗り切るだけでなく、チーム全体が成長することが未来に繋がると思います。

日本から失われつつある企業文化は、アジャイル開発の中に生きています。アジャイル開発を学んで、未来への道を切り開きましょう!

このエントリーをはてなブックマークに追加


対外発表する理由 #RxTstudy #seakansai

先日のSEA関西/RxTstudyの帰りに講師の大杉さんとお話をしていたところ、外部発表する理由を

「そう育って来たから」

と言われたのが印象的でした。

「サメと同じで死んでしまうんですよ」

とも。大杉さんらしい表現です。

この感覚は、同じ研究室だったのでよくわかります。発表もしないのに研究会には行かせてもらえないので、発表し続けないと研究者として死んでしまいます。

そうは言っても習慣だけでもないよな〜と思いましたので、まとめてみました。

整理したい

世間話はできても人に話そうとすると、自分が理解できていない事が明確になります。わかっていない事は調べますから言葉の定義が明らかになり、それを踏み台にできるようになります。最近は現場に戻ったので、この思いが強いです。

Give & Give で情報収集

昔からある発表のモチベーションは情報を得たいというものです。常に情報を提供する事で情報が自然と集まります。

能力を発揮して人の役に立つ

年をとったこともあってか、社会の役に立ちたいという思いがあります。自分の能力を発揮して誰かの役に立てれば幸せですし、それで誰かが幸せになるならとても嬉しいです。 映画の「ペイ・フォワード」とかNHKの「ごちそうさん」の様な感じです。

会社の評価に少しはプラスになるようにしていますが、会社のために発表するならもっと営業的なバイアスをかけるでしょう。また、目立ちたいとか、それで新しい仕事などとは考えません。無理をしてやってもつづきませんから。

結局、 自分が我慢するのでも利己的な理由でもなく、それが楽しいから外部発表をしているのでだと思います。


[#TiDD] 複雑な並列作業における変更 - 受け入れ、協調、分離の定石 - #RxTstudy

チケット駆動開発に限らず、ツールや技法を導入する際に否定的な意見を聞く事があります。不勉強なだけなら説明するだけ良いですが、理解された上での発言の場合は、そもそも向いていないものを当てはめようとされている場合もあります。

その判断は簡単ではありません。問題を明確にした上で、定石をあてはめ、その善し悪しを検討し、その組織に会わせた実施するといった一連の手順が必要です。

定石とは組合せ可能なベストプラクティスではなく、アンチパターンにもなりうるツールや技法の典型的な方法と言う意味で使っています。プログラミングと同じように、様々な制約の中でバランス考慮してその採否や組合せを決めます。

ここでは、前回のRxTstudy/SEA関西で議論が時間切れになった大規模な並列作業における変更について考えてみます。複雑とは規模の大小ではなく、基盤ソフトウェアとアプリケーションなど、互いに依存する複数チームからなるという意味で使っています。

複数チームが並列に開発している中で仕様変更が会った場合、どのように対応できるか、変更の受け入れ、協調、分離の定石にあてはめてみます。

変更の受け入れ

まず、各チームがどのように変更の受け入れるかを考えます。変更の受け入れには、同期、バッファ、パイプラインの定石があります。

XPやスクラムでは、仕様変更の受け入れがイテレーション、あるいは、スプリントと呼ばれる繰り返し期間の区切りに同期されます。つまり、イテレーション中の仕様は凍結して実施され、次のイテレーションを開始する前にスコープが変更されます。

FDDやハイブリッドアジャイルでは、あらかじめ仕様変更に対するバッファがそれぞれ10%と20%用意され、開発中に変更に対応されます。バッファを超える変更はマネージメントが介在して、計画の見直しが行われます。

リーンかんばんでは各工程の作業がパイプラインで実施されます。 それまでの入力は仕様凍結されたまま、新しい仕様はパイプラインの入力になって順次実施されます。

仕様を凍結して同期させるとプロジェクトの混乱は押さえられますが、小規模な手戻りは避けられません。あらかじめバッファを用意して仕様変更を随時変更を入れる場合は、受け入れに限界があります。それぞれの想定を超える場合は、実行中の作業を含めて見直しが必要になります。

協調

規模が増大して複数のチームで並行開発する場合、仕様変更を正しく伝達・分担できるようにする必要があります。その定石は階層的協調と同期です。

リーン開発やスクラムオブスクラムでは階層的協調が行われます。リーン開発では日々のミーティングを同時間に行い、その後に階層的なミーティングを行います。スクラムオブスクラムではリーン開発と同じようにスクラムマスターが日々集まり、さらに多くの関係者を集めたステアリングコミッティが週次に行われます。

階層的管理では情報共有が重要で、必要に応じて文書の作成や対面の会議をします。こうして仕様変更が伝搬されますが、上に書いたようにそれぞれの方法で受け入れられ、実施、統合されます。

実施時にGitなどの分散バージョン管理ツールを利用していれば、効率よく修正パッチをそれぞれに適用できるかもしれません。Subversionのような集中バージョン管理ツールでも、修正パッチや共通ライブラリを作成すれば、作業が効率化できるでしょう。

統合する際はチーム間の同期を取る必要があります。固定的な繰り返し期間を持つXPやスクラムでは、電車の駅の待ち合わせの様にリリースのタイミングを合わせるアジャイルリリーストレインと呼ばれる方法がとられます。

リーンソフトウェア開発では、工程毎のチーム間にバッファがあり、作業の無駄なくで同期が取られ順次統合されます。

このような同期を取らない方法では、あらかじめ基盤部分のモックを用意するなど統合の戦略が別途必要になります。

統合はそれぞれの仕様が明確でないとうまくいきません。そこで、各チームの協調が重要になります。

分離

仕様変更による作業の変更は、体制に会わせてチケットを階層的に使い、依存関係を持たせるとうまくいくように思われます。しかし、当初の決定に認識違いがあった場合や、さらに変更があった場合には、複雑な依存関係をメンテナンスしないといけません。

これは完全型チケット駆動開発を目指す際に生じる難しさです。現状のプロジェクトはそのままに仕様変更プロジェクトとして補完するチケットを分離するとうまくいく場合があります。 仕様変更の分離は、抽象クラスの修正が難しい場合に、派生クラスを作成して影響を局所化する戦略に似ています。

補完チケット駆動開発に類似する定石としては、変更仕様書あるいは改造仕様書として仕様の差分だけを別プロジェクトにまとめる方法や、XDDPのような派生開発があります。

これらはマスターを直接修正するのではなく、差分を整理します。差分だけのプロジェクトで、差分だけを管理しますので、全体の管理よりは把握やレビューが容易になります。

差分で作られたものはマスターからの派生ですが、ドキュメントを整備してマスターにする事もありますし、差分を取り込んで新たに作られるものをマスターにするかもしれません。いずれマスターになるのであれば、マスターの関連する作業を中断し、マスターから削除すれば手戻りを少なくできるでしょう。

チケット駆動開発で、全体の管理を理論的に実現しようとしても、必ずしもうまくいくとは限りません。全体と部分の独立性を高め、階層ごとに管理することも検討してください。

チーム間で協調・同期するのは仕様・リリースであって、チケットではありません。むやみに依存関係をつかうと、完了しないことや、開始できないこともありますし、変更が難しくなります。 一方向の参照を利用して、クエリでレビューする方が変化に強くなります。

チケット駆動開発であっても、コミュニケーションは必要な時に必要なものを使いましょう。人と人をつなぐことが目的で、チケットをつなぐ事が目的ではないからです。

まとめ

変更の受け入れ、協調、分離の定石を説明しました。ソフトウェア開発においてプロセスの影響は大きく、プロジェクトの混乱を押さえる事も、混乱を増大する事も可能です。

ツールや技法と同じように、問題を明確にした上で、定石をあてはめ、その善し悪しを検討し、その組織に会わせた実施するといった一連の手順によって、大きな効果を得られるでしょう。

しかし、そこで忘れてはいけないのは、価値を提供するのはソフトウェアだという事です。仕様変更が生じた際にその影響を狭い範囲に抑えられるか、それとも全体の見直しが必要になるかは、ソフトウェアのアーキテクチャに依存しています。

より良いソフトウェアへの配慮をした上で、 より良いツールやプロセスを導入すれば、より大きな効果が得られるでしょう。


[#TiDD] ツール・技法の導入法

メトリクスと同じように、ツールや技術もゴールからスタートすれば、必要なものだけを効率的に導入できます。

問題の明確化

ツールや方法論を導入する場合は、まず現在の問題点を明確にします。そして明確になった問題が解決できるように導入します。とはいっても、問題が明確ならすでに対策が講じられているでしょうから、問題を見つけ出す事から始めないといけません。

その第一歩は調査です。関連がありそうなツールや技法を調べます。良さそうなものが見つかれば、それが最初の候補です。しかし、まだ導入してはいけません。

善し悪しの見極め

候補となったツール・技法で解決できる問題を考えます。そして、その問題が解決できれば、効果がどの程度あるのかをざっくりと考えます。

チケット駆動開発なら、進捗の見える化や情報共有が期待できますが、過去のどのような問題が解決できるかを考えてみてください。その効果は、案外少ないかもしれません。

逆に地味に感じる履歴の検索の効果は、意外に大きいかもしれません。バグを解決する際に、複数の関係者に問い合わせて過去の経緯を確認したり、時間をかけて類似の不具合を探すことが良くあるからです。

このようにツールや技法の善し悪しは、冷静に、具体的に、 多面的に検討すると良いでしょう。

ツール・技法の選定

よほど特殊なものでない限り、類似のツールや技法があるでしょう。チケット駆動開発でも、様々なツールの組合せや、タスクボードなど、複数の方法を比較すると良いでしょう。

問題点が明確なら、より効果の得られるものを選ぶことが基本です。しかし、ツールや技法には長所だけではなく、短所もありますので運用方法を含めて検討しましょう。

過大な期待はしない事が重要です。ポイントを絞って導入すれば、問題は解決できます。もし、パレートの法則に従って2割8割になっている問題なら、大きく改善されます。

しかし、すでにプロセスに習熟して最適化されている場合、習熟したプロセスを変更する事で効果が薄れる、あるいは逆効果になることもありますので、注意が必要です。

実施

問題、ツールや技法の善し悪しが明確になり、実施方法が決まったならいよいよ導入です。この時に、一度に組織全体に導入しては行けません。リーンスタートアップを参考にスモールスタートして、予定通りの効果が得られないなら方向転換します。

導入は補完型チケット駆動開発のように既存のプロセスに従うなら、こっそりはじめる事もできます。しかし、なるべく上司のコミットメントや協力者を得て進め、プロセスチャンピオンを育てながら、徐々に広めると良いでしょう。

おわりに

上記の内容は一度に実施できないので、行きつ戻りつ繰り返しながら進める事になるでしょう。

チケット駆動開発のコミュニティで、どうすれば良いか、 イメージできない、なぜできないか、と言う質問が出る事があります。ツールや技法も様々で、プラグイン、改造、運用の工夫も色々ありますが、実施する人がイメージできないものはうまくいきません。

良さそうだからとやってみるのではなく、問題を明確にして、成功のイメージできるまで考えてください。

また、答えが単純でない場合も考慮してください。世の中にはそもそも難しい問題や、そのツールや技法に向いていない問題があります。そのような場合は、全面的な導入をあきらめてピンポイントに導入する方が良い場合があります。

次回は難しい問題の例として、大規模な並列作業における変更を考えてみる予定です。


メトリクスの採用とGQM - ムダの無いメトリクス活用法 -

先日の「チケット駆動開発とメトリクス」のベストツイートは@akahane92さんだと思います。

現場も管理も経営も喜べるメトリクス、良いですね。

同じ勉強会に参加しながら、私はGQM(Goal, Question, Metric)を思い浮かべていました。GQMはソフトウェア工学の重鎮であるバシリ先生の提唱されている計測の枠組みおよびモデル化手法です。

メトリクスを収集する理由は目的があるからです。GQMでは、その目的の達成篦撓めに必要な質問を考え、前提となるモデルのメトリクスを計測します。

つまり、「とりあえず」とか「良さそうだから」ではなく、目的を持って合理的なメトリクスを収集することで、ムダを無くせます。これは、リーンの引き取りに代表されるアジャイル開発のエコシステムと同様の方法です。

ここで、@akahane92さんのつぶやきを読み直すと、ゴールの共有が大切な事がわかります。現場、管理、経営で、問題とゴールを共有できれば、それがムダの無いメトリクス活用法のスタート地点になるでしょう。


[#TiDD] チケット駆動開発とメトリクス #RxTstudy

第10回 RxTstudy/第57回 SEA関西プロセス分科会を開催しました(Togetterまとめ)。

今回はNTTデータの大杉さんと書籍「チケット&計測でITプロジェクト運営の体質改善」の神谷さんに講演していただいた後、あきぴーさんとともにパネルディスカッションをしました。私も司会として参加させていただいたので、スライドを公開します。

講演やディスカッションで色々と考える事がありましたので、追々書いていこうと思います。今回は、講演とポジショントークのメモを公開します。

大杉さん

大杉さんの講演はSQiPでの発表をベースにより詳しくお話ししていただきました。

  • 階段:+αで健康
  • 管理のためのメトリクス
    - 保守:80=>26名、新規:4=>2名
    - 管理は兼務
    - 手順・ツールとルールの整備・監視
  • 軽量開発プロセス
    - 案件ごとの設計~結合テスト+システムテスト+移行
    - レビュー中心の品質向上
    - SVN、Wiki、Trac(進捗、故障、課題、メトリクス)、Jenkins
  • チケ切り地獄
    - MS Projectからチケットの生成(設計、製造、テスト)
    - バグ管理用のチケットは手動
  • レビュー
    - チェックリスト
    - チケットトSVNを介して非同期化
  • 構成管理
    - truncには単体テスト済みのもののみ、stableは別
  • メトリクス
    - 週次の定量分析、、
    - 上位マネジメントへの報告
    - チケットに記入
      ・工数(作業、レビュー)
      ・ページ数
      ・開発・テスト規模(ステップ数)
      ・レビュー・有識者指摘件数
      ・試験項目数
      ・すり抜けUTバグ
      ・開発期間
    - 導出メトリクス
      ・生産性
      ・規模
      ・件数
  • 見積
    - 案件数ベース
    - Kstepベース
  • スコープ調整
    - 生産性
    - 稼働時間
    - 要員
  • メトリクスの有効性
    - 見積、規模は有効
    - テスト密度は中規模以上で役に立つ
    - カバレージ、コードクローン分析も使えるのでは?
    - バグ密度は課題あり(出てはいけない、中小では、、)

神谷さん

  • 進化した現代のソフトウェア開発スタイル
    - ドキュメンテーション
    - モデリング
    - ダイアグラム描画ツール
  • チケット
    - 作業分類・記録型
    - 作業指示受け渡し
      ・障害分類、原因、バグ混入工程、摘出すべき工程
      ・多くのデータ、可視化
      ・発行不可、管理先行
  • チケット
    - フィーチャー型
      ・モチベーションを高めやすい
      ・可視化
    - WBS型
      ・契約が含まれる
  • EPM-X
    - 10,000を超すダウンロード
    - サンプルセット(WBS、課題、障害)
  • 可視化
    - EAダイアグラム(DMM(曼荼羅チャート)、WFA、ERD)、UML、メール
    - 統合的なソフトウェア開発環境
  • アジャイル開発
    - 傾斜線表
    - ビルド中心の生活
    - ソフトウェアを上手に育てる
  • インプロセスの計測と可視化

あきぴーさん

  • WFではメトリクスが使えない
  • 信頼度成長曲線
  • 集計したいメトリクス

決定のリスク

デシジョンメイキングといいますが、デシジョンにはリスクが伴います。

早く決めるリスク
決定によってその後の作業が束縛されます

決定が遅れるリスク
早く決めないとボトルネックになって作業が進まない

間違った決定のリスク
知らない、詳しくない、やってみないとわからないことを、先に決めてしまうと、間違った決定で手戻りが発生します

対処方法

上記のリスクに対して、以下のような対処方法があります。

仮決め:検討を進めてから見直す
保留:決定を遅らせることで自由度を確保する
試行:一部を実施する。段階的に実施する
調査:文献にあたる、 早めに有識者に聞く

いつ、何を、どのように決めるかでリスクは大きく変わる事になります。プロジェクトやその周辺の全体像を踏まえた上で、デシジョンについて考えると、より良い対処ができるでしょう。

« 2014年3月 | トップページ | 2014年5月 »