ＰＭＢＯＫのお勉強 その１３ － ３．１

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回で２章が終わり、今回３．１をやります

---

■３章　単一プロジェクトのプロジェクトマネジメント・プロセス
・プロジェクトのプロセスはプロジェクト・チームによって実行されるもので、
　通常は、次の２つのカテゴリーのいずれかに分類される

　　・プロジェクトマネジメント・プロセス
　　・成果物指向プロセス

・ここでは、本書に述べる知識、スキル、プロセスを常にすべての
　プロジェクトへ画一的に適用すべきであるといっているわけではない。
　どのようなプロジェクトであっても、プロジェクトマネージャーは
　常に、プロジェクトチームと協力して、どのプロセスが適切であり、
　各プロセスをどの程度の厳密さで実施すべきかを決定する責任がある。

・プロジェクトマネジメントプロセスは、
　プロジェクトマネジメントプロセス群として知られる
　５つのグループに分類される
　　　　・立ち上げプロセス群
　　　　・計画プロセス群
　　　　・実行プロセス群
　　　　・監視・コントロール・プロセス群
　　　　・終結プロセス群

---

■３．１　一般的なプロジェクトマネジメントプロセスの相互作用

・プロジェクトマネジメント・プロセスは、明確に定義された
　インターフェースをもつ個々の要素として表現される。

・しかし実際は、ここでは十分に表示しきれない重なり合いや
　相互作用もある

・プロジェクトマネジメントプロセス群は、
　その生成するアウトプットによって、
　互いに結び付いている

・プロセス群は、その境界が明確ではなく、またその実行は
　一度限りのものではない

・プロセス群は、お互いに重なり合って生じる活動であり、
　プロジェクトの全期間を通して行われる活動である。

初めてのＲｕｂｙを読む その１３ ３．４

「初めてのRuby」を読むの続き

３章　数値
３．４　数学関係
から

---

■３．４　数学関係
・利用頻度の低い数学関数は、Mathモジュールの中に定義されている
・Mathモジュールを現在のスコープにincludeすると、Math.というスコープ解決を
　付けずに、関数を呼び出せる

---

簡単なＣＩＳＣＯルーター設定例をPacket Tracerでしてみる １

Packet Tracerで、ルーター設定例を書いておく。
ふつうのＣＩＳＣＯルーターでも大体同じだと思いますが、
かなり省略しているはずです（line なんちゃらかんちゃらとかは書いてない）

---

■今回のお題（設定例）


端末とルーター、ルーター間同士は、クロス（点線）
それ以外はストレート
（Packet Tracerは自動認識しない）

---

■パソコン側の設定
左側の端末の設定。端末をダブルクリックして、設定用のダイアログを出し、
configタブをクリック、Settingsをクリックして選んだら、

GatewayとDNSサーバーを設定。
つぎに、fastethernetをクリックして

(今回は）Staticにして
ＩＰアドレスとサブネットマスクを設定
右上Ｘをクリックして、閉じる。

同様のことを右側のパソコン(端末）に対しても行う。

---

■ルーターの設定

左端のルーターをダブルクリックして、「ＣＬＩ］タブをクリックする。


はじめn

Router＞

と一般モードのプロンプトが出たら、enable。
以降の設定は、こんなかんじ

Router＞enable
Router＃conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)＃interface fastethernet 0/0
Router(config-if)＃ip address 192.168.0.1 255.255.255.0
Router(config-if)＃no shutdown

％LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up

Router(config-if)＃interface fastethernet 0/1
Router(config-if)＃ip address 192.168.1.1 255.255.255.0
Router(config-if)＃no shutdown

％LINK-5-CHANGED: Interface FastEthernet0/1, changed state to up

％LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

Router(config-if)＃router rip
Router(config-router)＃ver 2
Router(config-router)＃network 192.168.0.0
Router(config-router)＃network 192.168.1.0

enable→conf tで設定モードにはいったら、

interface fastethernet 0/0で、インターフェース設定
ip addressでアドレス設定後、
no shutdown
これを、0/1に対しても行う。

次に、router ripでripの設定を行う。
networkで接続しているネットワークを設定する

ここまでの操作を、左側のサーバーに対しても行う。
なお、show ip routeで接続状況を見るには、

Router(config-router)＃exit

Router(config)＃exit



％SYS-5-CONFIG_I: Configured from console by console

Router＃show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

       * - candidate default, U - per-user static route, o - ODR

       P - periodic downloaded static route



Gateway of last resort is not set



C    192.168.0.0/24 is directly connected, FastEthernet0/0

R    192.168.1.0/24 [120/1] via 192.168.0.1, 00:00:17, FastEthernet0/0

C    192.168.2.0/24 is directly connected, FastEthernet0/1

のように、特権モードに戻ってから行う。

---

■確認のためにPINGをうつ

　確認するため、端末をクリックし

DesktopタブのCommand promptをクリックして開き、そこから、

pingを打つと、帰ってくる。

ＰＭＢＯＫのお勉強 その１２ － ２．４

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回２．３をやったので、今回２．４をやります。

---

■２．４　プロジェクトマネジメントに与える組織の影響

・組織の文化、スタイル、構造は、プロジェクトの実施方法に影響する

・組織のプロジェクトマネジメントの成熟度や、
　プロジェクトマネジメントシステムもまた、
　プロジェクトに影響を及ぼす

---

■２．４．１　組織の文化とスタイル

・組織の文化とスタイルは、プロジェクト目標を達成する執行能力に
　大きく影響する

・文化とスタイル→文化的規範

・固有の文化の態様の例
　　共有するビジョン、バリュー、規範、信条、期待
　　方針、方法、手順
　　権限関係についての考え方
　　労働倫理と労働時間

---

■２．４．２　組織構造
・組織構造は、資源の可用性に影響を及ぼし、かつ、プロジェクトの
　実施方法にも影響を与える組織体の環境要因である

・組織構造の主なタイプ
　　　機能型組織
　　　マトリックス型
　　　　　弱いマトリックス型組織
　　　　　バランスマトリックス型組織
　　　　　強いマトリックス型組織
　　　プロジェクト型組織
　　　複合型組織

---

■組織のプロセス資産
・組織のプロセス資産は、プロジェクトにかかわりを持つ組織の
　プロセス関連の資産であり、プロジェクトの成功に寄与するために
　活用できるものである。

・組織のプロセス資産は、以下の２つのカテゴリーに分類することが出来る
　　　・プロセスと手順
　　　・企業の知識ベース

---

次から３章

初めてのＲｕｂｙを読む その１２ ３．３

　「初めてのRuby」を読むの続き

３章　数値
３．３　比較
から

---

■３．３　比較

・数値クラスには大小関係が定義されている
　　　＜
　　　＞
　　　＜＝
　　　＝＞
　　　＝＝
　　　！＝
　　　＜＝＞（宇宙船演算子）

---

■３．３．１　宇宙船演算子（＜＝＞）

・左辺が右辺より

　　　小さければ、負
　　　等しければ、０
　　　大きければ、正

　の数を返す

・sortメソッドで大小を判定するブロックを渡せるが、
　そのブロックを記述する場合も宇宙船演算子が活躍

・comparableモジュールを使うと、＜＝＞演算子から
　すべての比較演算子を導出できる

---

REST型のＡＰＩでコンポーネントを設計することが、短期開発のコツとなるだろう

　コンポーネント開発とか、再利用とか、いろいろ言われてきたが、
結局、再利用というか、多くの人が共通して使っている機能は、
Ｗｅｂ上にある、ＲＥＳＴ型のＡＰＩをもつ、コンポーネント
ということになってきた

　ＴｗｉｔｔｅｒＡＰＩしかり、
　ＧｏｏｇｌｅのＡＰＩしかり
　ＲＳＳ，ＡＴＯＭしかり・・・

そして、Ｗｅｂ上に、ＲＥＳＴ型であるならば、その機能は、
Ａｎｄｒｏｉｄのスマホでも、
ＰＨＰやJavaでサーバー側で利用しても、
ＡＪＡＸやJQueryでクライアントでも、
さらにＢＲＥＷなんかのガラケー
　　（じゃなくって、フュージョンフォンっていうんだっけ）

でも、利用できる。

ということで、コンポーネントの本命はＲＥＳＴ型のＡＰＩであり、
アカデミックのほうは、これに基づいて理論を構築していかないと、
いけないんじゃないかなあ・・・って思います。

ＰＭＢＯＫのお勉強 その１１ － ２．３

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回２．２をやったので、今回２．３をやります。

---

■２．３　ステークホルダー
・ステークホルダーとは、
　プロジェクトに積極的に関与しているか、または
　プロジェクトの実行あるいは完了によって、
　　　　自らの利益がプラスまたはマイナスの影響を受ける
　顧客、スポンサー、母体組織、一般大衆のような個人や組織である。

・プロジェクトマネジメントチームは、
　すべての関係者のプロジェクトへの要求事項と期待を明確にするため、
　組織の内外のステークホルダーを特定しなければならない

・プロジェクトマネージャーは、プロジェクトを確実に成功させるために、
　プロジェクトの要求事項に関する、様々なステークホルダーへの影響を
　マネジメントする必要がある。

・ステークホルダーは多様なレベルの責任と権限を持って
　　　プロジェクトに関わるが、
　この関わり方は、プロジェクトのライフサイクルが進むにつれて変化する。

・ステークホルダーの特定は、困難なこともある

・ステークホルダーを特定し、プロジェクトに対する度合いを理解することは、
　　　非常に重要である。
　この理解を誤ると、スケジュールの大幅な遅れや
　　　コストの大幅な増加をもたらすこともある

・ステークホルダーによってはプロジェクトがもたらす結果が
　　プラスであると考えるものも、
　　マイナスであると考えるものもいる
　　　　→不利益を見込むステークホルダーを見逃すと
　　　　　失敗の可能性が高まる

・プロジェクトのステークホルダーの例
　　・顧客やユーザー
　　・スポンサー
　　・ポートフォリオマネージャーや
　　　ポートフォリオ・レビュー委員会
　　・プログラムマネージャー
　　・プロジェクトマネジメントオフィス
　　・プロジェクトマネージャー
　　・プロジェクトチーム
　　・機能部門マネージャー
　　・事業マネジメント
　　・納入者やビジネスパートナー

---

次は、２．４

初めてのＲｕｂｙを読む その１１ ３．２

　「初めてのRuby」を読むの続き

３章　数値
３．２　数値演算
から

---

■３．２　数値演算
・加減乗除、譲与、べき乗、符号操作などをサポート

---

■３．２．１　除算
・演算対象の値によって挙動が異なる
　　・両辺がIntegerオブジェクトだと、整除
　　・一方がＦｌｏａｔであれば、実数除算
　　・整除の場合０で割ると例外、実数除算だと、無限大などが返る

---

■３．２．２　符号操作
・単項マイナス演算子は、数値の符号を反転　
・単項プラス演算子は、なにもしない

---

■３．２．４　その他
・利用頻度の高い演算は専用の演算子
・そうでないものはメソッドの形で利用

---

■３．２．５　型と自動変換

・データ型が自動変換されることはほとんどない
　　・整数と浮動小数点の演算は例外的に自動変換
・明示的に型を変換する場合、to_i()、to_fメソッド等を使う

---

■その他の数値、第数系
・Ｒｕｂｙで標準添付されているもの
　　　　有理数（Rational)
　　　　複素数（Complex）
　　　　可変長１０進（BigDecimal)
　　　　行列（Ｍａｔｒｉｘ）、ベクトル（Ｖｅｃｔｏｒ）

---

次は３．３

オークションサイトを２日で作るための開発方法論-その２

そうそう、「オークションサイトを２日で作るための開発方法論」続きを書いていなかった。

　昔は、ソフトウエア開発は、数ヶ月、下手したら１年以上かけるのが普通にあった。
　でも、現在は２～３ヶ月かけるのでも、結構長いのかな？
　場合によっては、数時間っていうのもある。

　こういうふうになった背景には、４つあると思う。

---

■１．基本的に、同じような開発法、利用法の場合、一部だけを取り替えればよい
　　という開発法が増えた。

　まるで、パッケージソフト・・・じゃないけど、
　マッシュアップみたいなものや、基本的に動きが決まっているものについては、
　もう、使い方も運用方法も決まっているわけで、そうすると、差分だけ作ればいい
　ということになる。


■２．論理的に考えてつくるというよりかは、サービスを選んで取り入れるという
　　　カフェテリア方式とでも言うべき開発法が入ってきた

　　JQueryなんかがそう


■３．そもそも、要求仕様→設計→実装→テストという流れをとらなくてよくなった。

　　カフェテリア方式なら、あらかじめ、ロジック部分をあ～でもない、こうでもない
といっぱい作っておいて、要望が固まったら、必要なものをとってくればよい。

　この方法が進むと、将来的には、要求仕様の段階で、ビジネスロジックをいろいろ
作り上げてしまい、外部設計のときに、ビジネスロジックを取捨選択してしまうかも
しれない。


■４．テストの終わりの考え方

　利用効果に応じてテストするという考えになってきた。なんでもテストするよりかは・・・

　被災地への情報提供サイトなら、テストに時間をかけて、みんなが利用できないよりかは、テストを最小限にして、バグがあるかもしれないけれど、情報提供したほうがいい。

---

　これらは結局、いままでの開発方法論とは違った、あらたな開発方法論の必要性を暗示している。その開発方法論については、また今度・・・

ＰＭＢＯＫのお勉強 その１０ － ２．２

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回２．１をやったので、今回２．２をやります。

---

■２．２　プロジェクトと定常業務

・実行される業務は、プロジェクトか定常業務かのいずれかに分類できる

・この２種類の業務には、以下のような共通の特性がある
　　　・人が実施する
　　　・資源が限られるなどの制約を受ける
　　　・計画、実行、監視、コントロールの対象となる
　　　・組織の目標や戦略計画を達成するために実施される

・定常業務は継続的、プロジェクトは有期性

・定常業務はプロジェクトを実行しているビジネスの側面を支えている
　　→両者の間には、かなり多くの相互作用
　　→プロジェクトマネージャーは複数の事業執行マネージャーと
　　　協力して作業を行う
　　→定常業務部門から提供される資源の量はプロジェクトにより異なる

・プロジェクトの性質によっては、要素成果物を生成することにより、
　既存の定常業務が変更されたり、定常業務の役に立ったりする場合がある

---

初めてのＲｕｂｙを読む その１０ ３．１

　「初めてのRuby」を読むの続き
今回から３章。まずは

３章　数値
３．１　数値リテラル

---

■３章　数値
・Ｒｕｂｙは組み込みで多倍長整数をサポート
・Ｒｕｂｙで数値を計算する上での最大の難点は、計算が遅いこと
・独自のクラスを作成することができる
　　　→演算子オーバーロードに対応

---

■３．１　数値リテラル
・Ｒｕｂｙに組み込みの数値は、
　　　整数Ｉｎｔｅｇｅｒオブジェクトと
　　　浮動小数点Ｆｌｏａｔオブジェクトに分かれる

・いずれもリテラル表記を用いて構築するのが普通

---

■３．１．１　整数リテラル

・普通に表記すると１０進数

・リテラルの先頭に記号を付け加えることで２進、８進、１６進
　　0xまたは0X　　　　　　　　１６進数
　　0dまたは0Dまたは記号なし　１０進数
　　0oまたは0Oまたは0　　　　　８進数
　　0bまたは0B　　　　　　　　　２進数

・Integerは内部的には、FixnumやBignumというIntegerのサブクラスで表現
　　　Fixnum：内部的に固定長で実装
　　　Bignum：内部的に多倍長整数（任意に大きな整数を表せる）

---

■３．１．２　浮動小数点リテラル

・Rubyで実数値を扱うには浮動小数点を用いて近似的にあらわす
・結果として誤差を生じる場合がある

・ＩＥＥＥ７３４の実装
　　　→少なくとも仮数部５２ビット、指数部１１ビットの精度

・特殊な浮動小数点の値
　　　　正の無限大(Infinity)
　　　　負の無限大(-Infinity)
　　　　非数(NaN)

---

次は３．２

「KAOSによる要求工学からUML設計への統合」とかを聞いてきた

ソフトウェアエンジニアリングシンポジウム2011のワークショップ４　要求工学の午前中の発表で聞いてきた話を報告してみる。

---

■１．KAOSによる要求工学からUML設計への統合
　本田さん（電通大大学院）

KAOSモデル
・要求抽出・定義
　系統的、網羅的＆論理的分析

UML
・要求レビュー→設計
・静的・動的構造の多彩な設計

KAOSモデリング→UMLへ
・ゴールモデル
　　洗練パターン
　　　　↓
・操作モデル
　　洗練パターンから変換パターン
　　　　↓
・ユースケース図
　　　　↓
・イベントフロー図

---

■２．アーキテクチャ指向による要求獲得－診療ドメイン事例－
　　友枝さん

・九州病院のIBMのシステムの話？
　（と発表者は言ってないけど、たぶんその話のように聞こえた）

・アーキテクチャ指向をベースにドメイン分析～要求～外部設計

・ポイント
　　・顧客や利用者の要望は聞くが、要求は聞かない
　　　　　要望：具体的でなく、ざっくりしたこと
　　　　　要求：システムに求めていること
　　　　→でも、その出所は押さえる
　　・ドメインの知見を元に、要求を明らかにする
　　・やることだけでなく、やらないことも明確に
　　・作るのはリスクなので、できるだけ作らない
　　・ドメインEngとアプリケーションEng

・手順
　診療ドメイン全体
　　→診療ドメインシナリオ
　　　　→部分共通化
　　　　　　→依頼・実施ドメイン
　　　　　　　データセキュリティドメイン
　　　　　　　お仕事実施ドメイン
　システムイメージ


・まとめ
　・ドメインモデル：相互理解に有効
　・シナリオ：確認、納得を得るのに有効
　　　システムの統合的な動き
　　　ここの部署システム
　・WFでなく、タスクとその状態で業務を連結
　　柔軟性向上に寄与
　・概略確認に有効だが、本件だけでは
　　システムの要求定義は完了しない

---

「KAOSによる要求工学からUML設計への統合」については、
ちょっと自分の考えを別エントリで書きたいと思います。

9月12日(月)のつぶやき

08:47 from goo
ソフトウエア開発や、UML、その他ダイアログは、ロジカルシンキングに還元できる #goo_xmldtp http://t.co/XtRp1Fa
by xmldtp on Twitter

コンテンツ制作会社の場合、オフショアよりフレームワークの高度化のほうが・・・

DeNAがベトナムの会社を買収したけど、
コンテンツ制作を継続的に行うゲーム会社のような場合、

オフショアして、仕様を海外のソフト委託会社に伝えるよりも、
フレームワークを高度化して、仕様を入れればすぐにゲームができるように
したほうが、柔軟性は高いと思う。

Androidは、アプリにおいてはPhoneGapのようにHTML5で書いたほうが
生産性は何倍も高い（たぶん、ウィジェットとかはできないんじゃないかな？）
必ずしも、オフショアが成功を意味しない気が、最近する・・・


DeNA、ベトナムのゲーム開発会社を買収
http://headlines.yahoo.co.jp/hl?a=20110912-00000028-rbb-sci

「シナリオを用いた要求定義」を聞いてきた

　ソフトウェアエンジニアリングシンポジウム2011のワークショップ４　要求工学の「シナリオを用いた要求定義」で聞いてきた話を報告してみる。

---

■概要

１．シナリオ概説
２．シナリオ言語SCEL
３．シナリオを用いた要求支援
　　－シナリオの視点変換
　　－シナリオの統合

---

■１．シナリオ概説

「要求工学」ソフトウエアテクノロジーシリーズ９　「３．シナリオ」

JISX0028.02.15（人工知能関係）

ここでは
ユーザーが目標を達成するために行う行動と
そこから得られるイベントを
時系列に沿って記述したものであり
ある状況に限定したシステムの具体的な利用例

良いところ
システムの使用法や手順をユーザーの始点に沿ってあらわすのに向いている
対話型のシステムの要求定義・設計に有用

シナリオの構成要素
・アクター
・アクターとその環境に関する背景情報
・アクターの目標（副目標）
・アクションとイベントの系列

シナリオの表現手段
・物語風の文章
・箇条書き
・絵
・ビデオのような動画像
・ストーリーボード
・フローチャート、シーケンス図、状態遷移図
・制限言語、形式言語

シナリオの分類観点
・表現方法
・形式化の度合い
・内容（中小度、文脈、議論、範囲）
・目的
・シナリオの使用法（どの開発時点で使用するか）

ユースケース
・ヤコブソンが提案したシナリオの一形態、システムの分析と仕様化のために用いられる
・外部との相互作用を用いてシステムを記述するというブラックボックスの視点を仮定
・自然言語によってアクタとシステムの相互作用を順番に記述

ユースケース記述

---

■２．シナリオ言語SCEL

制限言語を用いたシナリオ記述
・制限言語
　言語の表現範囲を制限して、機会での処理、解釈を容易にする目的で制限を課した言語

利点
・端的に、単一の形式で記述できる。単語や文章の意味をぶれを抑えることができる
・目的や動作の粒度をそろえることができる
　　→書くべきでない振りまいを書きにくくすることができる
・機械的に処理・解釈できる

シナリオ言語SCEL（せる）
・要求フレームモデルに基づく
　　格文法に基づいた
・種々の制御構造を記述できる
・アクタの視点ごとの分析ができる
・視点が異なるシナリオの統合やシナリオの視点変換、差分生成、ルールを用いた検証ができる

シナリオ記述言語SCELの要素
・タイトル
・ビューポイント（注目するアクターの視点）
　　→主語、目的語
・イベント文列（イベント文と時間的順序関係）
　　・イベント文
　　・時間的順序関係（順接、if-then-else,平行動機）
・事前条件
・事後条件

格文法と格構造
・イベント文を「述語（同士）＋名詞句」として記述
・文中の名詞句（型）との関係を構造（格構造）として定義
・顧客はシステムに著者名を入力する
　　入力する（表層）／データフロー（深層）
　　　この概念は「どこから」「どこに」「なにが」流れるのかという情報が必要
　　　顧客：どこから：源泉格「は」、「が」
　　　システム：どこに：目標「に」
　　　著者名：なにが：対象「を」

・動詞辞書と要求フレーム
　　動詞を中心とした格構造をドメインごとに決めておく
　　それぞれに格構造を定義する
　　　　源泉格
　　　　目標格
　　　　目的格
　　　　道具格
　　　　動作主格

・シナリオ言語の特徴
　　視点に依存しない内部表現に変換が可能
　　統合・視点変換・ルールによる検証が可能

・名詞辞書
　それぞれの格に入れられる名詞句の型が、格構造によって規定されている
　ドメインごとに利用されている名詞と型をあらかじめ対応付けておく

・SCELの有用性
　日本語の文法を制限する、語彙を絞り込む
　特定のアクタからの視点の振る舞いをシナリオの視点として明示できる

---

■３．シナリオを用いた要求支援

・シナリオ視点変換
　　→イベントの抜けや順序間違いを発見できる

・異なる視点のシナリオ群の統合

・シナリオの検証


・例外シナリオ作成支援
　正常シナリオと代替、例外シナリオ
　１つの正常シナリオに対して、複数の代替、例外シナリオ
　　例：正常シナリオ　カード払い
　　　　代替シナリオ　現金払い
　　　　例外シナリオ　カードが読めない
　代替、例外シナリオはわかりにくい
　　　→例外シナリオ作成支援

・差分分析

---

■演習のやり方

・正常シナリオを書く
・必要ない修飾語を落とす
・格文法を決める
・文法と語彙から逸脱しないように将来システムのシナリオを記述
・制限を緩和
・問題点と改善点
　　→表裏一体、否定表現＝問題点、肯定表現＝改善点

---

午前中の発表については、別のエントリで