<HOME> ― <XP (エクストリーム プログラミング)> ― <イベント参加レポート集 2>
■ XP (エクストリーム プログラミング) - イベント参加レポート集 1 (前の頁)
 |
セミナー「〜米国で話題!! 新概念のソフトウェア開発プロセス方法論〜 エクストリーム・プログラミングとリファクタリング技術解説」 |
2001/12/20〜21 |
|
「XP 祭り 2002」 |
2002/07/08 |
|
「エクストリーム・プログラミング & アジャイル開発プロセスセミナー」 |
2002/09/09〜10 |
■ XP (エクストリーム プログラミング) - イベント参加レポート集 2 (この頁)
|
「Developers Summit 2003」 |
2003/02/20〜21 |
|
「XPエクストリーム・プログラミング 入門セミナー 〜 XP行脚 in 福井 '03年 春 〜」 |
2003/04/30〜05/01 |
|
「XP祭り2003」 |
2003/07/18 |
|
「エンジニアのためのコミュニケーション トレーニング」 |
2003/11/12 |
|
「XP&アジャイル開発セミナー 〜ブームから現実へ〜」 |
2003/11/28 |
■ XP (エクストリーム プログラミング) - イベント参加レポート集 3 (次の頁)
|
「Developers Summit 2004」 |
2004/01/28〜29 |
|
「第11回 日本XPユーザー会 Martin Fowler 夫妻と Gregor Hohpe 氏を囲む会」〜「.NET アーキテクトセミナー 2004」〜「ソフトウェア再利用とパターンに関する特別セミナー」 |
2004/04/19〜20 |
|
「XP 祭り 2004」 |
2004/07/26 |
|
「Developers Summit 2005」 |
2005/02/03〜04 |
|
「XP 祭り 2005」 |
2005/09/03 |
|
: | 頁内へのリンク |
|
: | サイト内の別頁へのリンク |
 |
: | 外部サイトへのリンク |
上記に参加して来たのでレポートしてみたい．
タイトル：Developers Summit 2003
http://www.shoeisha.com/event/dev/
場所 ：東京表参道 青山ダイヤモンドホール
日時 ：2003/02/20(木) 〜 21(金)
主催 ：株式会社 翔泳社
以下のセッションに参加した．
「Developer Summit 2003」で扱われた主な技術テーマは，「.NET」，「UML/開発プロセス」，「データベース」，「ストレージ&バックアップ」，「XML」，「Java/EJB」，「スキルアップ」，「セキュリティ」である．
※ ちなみに当日のセッション資料は，http://www.shoeisha.com/event/dev/session/session.html で参照することができる (2003/03/04 現在)．
主催者側の予想していた以上の来場者が有った為整理券が配られたが，人気の有るセッションが続いている場合は初めの方のものを聞いている間に整理券の配布が開始・終了して仕舞う為，どちらかを諦めざるを得ないことが有った．
楽しみにしていたセッションの一つである長瀬 嘉秀 氏 による「マーチン・ファウラーの最新モデルパターン論をめぐって」もその為に聞き逃して仕舞い残念な思いをした．
「UML/開発プロセス」を中心に「スキルアップ」と「.NET」関連にも参加したが，「UML/開発プロセス」の人気の高さが印象的であった．整理券の配布時にも長い行列ができていた．今回もアジャイルな人達が元気だった．
Stephen Mellor 氏 の実行可能な UML (Executable UML) が如何にアジャイルかの話も面白かったし，同じく Executable UML に関する 二上 貴夫 氏 と 平鍋 健児 氏 の掛け合いも楽しかった．また，亀山 信昭 氏 のプロジェクトマネジメントの話も色色な意味でためになった．
特に，橋本 隆成 氏 と 山田 正樹 氏 の "SCRUM" のセッション中の暗黙知と形式知に関する話が印象に残った．野中郁次郎 氏 の著作「知識創造企業」に関する話である．
以下その点に関して考察してみたい．
■ 野中郁次郎氏のSECI モデル
これは，組織において知識が創造されるときの四つの知識変換プロセスのモデルについて説明したものである．
知識には暗黙知と形式知の二つがある．
そして，共同化 (Socialization)，表出化 (Externalization)，連結化 (Combination)，内面化 (Internalization) の四つのプロセスが相互に作用することで，組織及びその構成員としての個人の知識レベルが上がっていく．
私事で申し訳ないが，今年の私のテーマは，「学而不思則罔，思而不学則殆 (学びて思はざれば則ち罔し，思ひて学ばざれば則ち殆ふし)」である．
形式知を暗黙知にし暗黙知を形式知にしていくことが知識の習得には大切だと考えている．単に情報を持っていることと，知識としていることは異なる．実際に体験したり考察してみることで自分のものとしなければ知識として使えるものにはならない．
■ フィードバックを伴う繰り返し開発の必要性
- 何故ウォーターフォールはナンセンスか Part III -
ウォーターフォールでは，
納期が近づいてくると，決まって仕様変更が相次ぎ，設計はぼろぼろに成っていく．皆が当たり前のように残業や休日出勤を始め，それによりどんどん開発コストがふくらんでいく．
果たして，その残業は「予定通り」だったのだろうか．
その時間当たりにして通常より高い残業代や休日出勤分の給与は，コストとして計画されていたのだろうか．プロジェクトは予定通りの黒字になるのであろうか．さもなければそのプロジェクトは失敗ということになりはしないか．そもそもそのプロジェクトはどうなれば成功することになっていたのだろう．幾ら儲かることになっていたのだろう．大体においてプロジェクトが終わったときにプロジェクトの構成員には失敗したかどうかが判るのだろうか．
様々な疑問が浮かぶが，ともあれ，大概はうまく行かないようなのである．
最後に決まって，仕様の不十分さや見積もりの甘さが指摘される．
だが，本当にそれが原因なのだろうか．或るいは，仮にそれが原因だとして，そこを解決できるのだろうか．
だとしたら，なんで「いつもいつも仕様は不十分」で，「いつだって見積もりは甘い」のだろう．本当に．もう何十年も．
考えるに，仕様には，暗黙的な仕様と明示的な仕様があるのではないだろうか．それぞれ，暗黙知と形式知に当たる．
仕様書は勿論明示的な仕様である．その部分に関する知識はプロジェクト内で共有される．しかし，暗黙的な仕様がない完璧な仕様書を作成することはできない．もし完璧な仕様書があれば，それを完全に別の二つのチームに渡しても瓜二つのものができることになるが，そのような全てを網羅した仕様書は作れない．
最終的に望まれる仕様は，初めはその一部が暗黙知の形で存在しているに過ぎない．暗黙知が暗黙知である間は文書化できない，のである．
これがウォーターフォールが無効である理由の一つでもあると思う．
ウォーターフォールによる精度の高い開発には，精度の高い見積もりが必要だが，その為には精度が高い仕様が必要になってしまう．しかし，初期段階では，仕様の一部は暗黙知であり個人的な知に過ぎないため，その部分に関してはコミュニケートできない．仕様を共有する為の文書が存在しえない．
最終的な仕様となるためには，暗黙的な仕様が共有され，そして表面化することで更に新たな仕様が生まれていく必要がある．
即ち，
その為には，体験による数々のフィードバックが必要となる．一気に行うことはできず，スパイラルなアプローチが不可欠となる．
このことは，「何故，最初に言われた要求仕様通りに作ったのに満足してもらえないか」の答えにもなっているように思う．
■ 暗黙知を伝えよう - メタファー
暗黙知を人に伝える場合には，メタファーが有効な場合がある．
仏教において，釈迦は深い思考の末真実を悟ったとされる．
そして，釈迦は自分の知識を人に伝えるのに，それが一般の人には余りに難解であったがために，直接的には語らずメタファーを使って語ったそうである．
「真理・悟りの世界は比喩で語るしかない」という言い方をよくされる．釈迦が直接その概念を口にできたとしても，言葉だけでは中中他の人の知識にはならない．言葉として文法的に理解できたとしても体感できないのである．
アインシュタインの言葉に「何かを学ぶためには，自分で体験する以上に良い方法はない」というものがある (この言葉は最近マイブームに成っている)．体験なくして知識を吸収することは困難である．知識を己のものとする為には，体験によるフィードバックが必要になる．
そこで，メタファーを使い，その人との共通の他の体験に喩えることで，知識の一部を伝えようとするのである．
これは，つまりこういうプロセスであるが，
XP (エクストリーム プログラミング) でもメタファーを使うことをプラクティスの一つに上げているが，プロジェクトにおいてメタファーを使うことで，「表出化」のプロセスをスムーズに行えるのではないだろうか．
■ 暗黙知のみのプロジェクト
以上，プロジェクトにおける知的創造スパイラルの必要性を考察してみた．
最後に，いつまでも個人の暗黙知の段階に留まっているプロジェクトがあったらどうか考えてみたい．
参考資料:
(財)岐阜県産業経済振興センター主催
北陸先端科学技術大学院大学知識科学研究科長 野中郁次郎氏 の講演会 (1997/09/02)
「知識創造企業」
上記に参加した．以下にレポートしてみたい．
※ 主催 オブジェクト倶楽部 からのレポートはこちら
<『日本全国XPセミナー レポート in 福井』>
タイトル：XPエクストリーム・プログラミング 入門セミナー 〜 XP行脚 in 福井 '03年 春 〜
<http://www.objectclub.jp/event/past-event/angya/report_fukui/>
場所 ：福井コンピュータ株式会社 ウィン・ラボラトリ 4F 研修室
日時 ：2003/04/30(水) 〜 05/01(木)
主催 ：オブジェクト倶楽部 <http://ObjectClub.esm.co.jp/>
共催 ：福井コンピュータ株式会社 <http://www.fukuicompu.co.jp/>
会場の福井コンピュータ株式会社 ウィン・ラボラトリ．
ちなみに，これまでの開催地を市町村名で云うと，
仙台市 → 博多市 → 札幌市 → 京都市 → 浜松市 → 丸岡町
という順である．最後だけ段違いに田舎のような気がしないでもないが，多分気のせいなので気にしないようにしてほしい．
会場に貼られていたポスター．
■ 2003/04/30
さあいよいよ「XP行脚 in 福井」が始まる．
一日目の昼 12 時半過ぎから，少しずつ参加者の方が集まって来た．
 |
 |
受講者は全部で 37 名．
福井コンピュータの社員と福井コンピュータの社員以外の方が半々くらい．福井コンピュータの社員以外の方の中では，福井県内の方と県外の方が半々．
やがて開始時刻となる．
最初は，共催の福井コンピュータ株式会社からの挨拶から．
福井コンピュータは建築 CAD などを作っている会社．
共催の福井コンピュータ株式会社 安井開発本部長の挨拶．
そして講師陣の挨拶．
 |
 |
 |
写真は，左から 平鍋 健児 氏，天野 勝 氏，そして 北野 弘治 氏．
前の週に過密スケジュールで行脚 (*1) してきた筈が，元気そう．
すっかり慣れた感じ．「聴いていて『その通りだ』と感じたら，こんな風に『うんうん』と頷いてくださいね」
(*1) 『日本全国XPセミナー スケジュール』参照のこと．
一日目は，講義が中心．XP の特長が熱く語られる．
それから XP の導入事例や XP の導入について問題になることなども．
途中，XP についてどんな内容が聴きたいか手を挙げてもらってアンケート．顧客の要望にアジャイルに対応．
『XP概観』でのひとコマ「ペア・プロで似顔絵書き」．
「どうですか．ペアだと勇気が出ましたか」
最後に質疑応答や，明日に向けての宿題の説明があり，一日目が終了．
・一日目夜の懇親会．
場所は福井きっての繁華街片町にある「クー」というお店．フレンチと赤ワインがメイン．
一部の参加者の御用達のお店．グルメな参加者の方も満足されていたらしい．
技術者同士，濃い話題で盛り上がった．
お約束のポーズで記念写真．
「宿題」も出ていたし，明日に備えてこの後は二次会までで大人しく (謎) お開き．
■ 2003/05/01
明けて二日目．この日がメインでワークショップがある．やっぱり体験しないと身に付かない．
□ 「計画ゲーム ワークショップ」
四つのチームに分かれて計画ゲームを疑似体験．題材は「ガーデニング」．
最初に，ロールプレイングのお手本．
「とんとん．こんにちは．庭を造って欲しいんですけど」
そして，各チーム第一イテレーションの開始．先ずは計画ゲームから．
各チームから顧客が一人ずつ出て，開発者に要望を伝えストーリー カードを書く．
開発者はそれを分割してタスク カードに書く．また，優先順位や見積もりをしたりしてイテレーション計画を立てる．
ストーリーカードやタスクカードは，壁やホワイトボードに貼って行く．
各タスクカードには，見積もりとしてポイント数が書いて有る (1 ポイントは，ここでは一人が作業に集中出来たときに一分間でこなせる量)．そして開発者が，サインアップ (自分がどのタスクをやるかを表明) していく．開発はペアで行われる．
講師陣の三人がエンドユーザー役で，「犬小屋が欲しい」のような要望を時折言って来る．
イテレーションは，全部で三回．イテレーション毎に，顧客の望むものをリリースする．
イテレーションが終わると，反省点や良かった点，改善すべき点などを紙に書いて貼り出す．
そして次のイテレーション．大分うまく回るように成って来る．
「エンド ユーザーからの要望が来ちゃった．ストーリー カードを追加してもらわないと」
最後に各チームが成果の発表を行った．
一チーム目の発表．「出来ていないところはお客様が自由に拡張可能となっております」
二つ目のチームの発表．
三つ目のチームの発表．
最後のチームの発表．「コンセプトは．ずばり『叶姉妹』．ゴージャスな造りと成っております」
発表では，顧客役の人による庭のアピールと，開発側からの苦労した点や良かった点・工夫した点の説明があった．
見積もりの精度やコミュニケーションについての問題点等．
□ TDD (Test-Driven Development: テスト駆動開発) ワークショップ．
Java と JUnit を使って簡単な課題をテスト駆動開発してみる．
JUnit を使ってペアプロ．「テストが通ったら拍手をしましょう」
こうして二日目も終了．お疲れ様．
やっぱり XP のイベントは楽しい．この楽しさが XP の魅力だと思う．
講師の方々は，さすが「XP の達人」といった印象で，XP の魅力がどんどんと伝わってくる．
特に体験イベントは楽しかった．
・今回 XP について改めて思ったことなど
XP は，開発の楽しさを思い出させてくれる．
そして，XP は問題をとてもシンプルにしてくれる．
XP の目的は，第一にはビジネスで勝つことであろうが，XP では，顧客とプログラマ，その他プロジェクトに関わる人が一つのチームとなり，チームとしての勝ちを目指す．ゼロサム ゲームでなく，参加者全員が勝ち組になることを目指す．チームで，顧客の問題は何かを表面化していき，その問題を解いて行く．顧客は，望みの価値を得て対価を支払う．
・XP でないものの場合
多くのソフトウェア開発プロジェクトは，なんらかの問題を抱えていると思う．何か問題があって，中々望み通りに勝つことが出来ない．
それら開発における問題を解決したい，と考えているのは多分皆 (顧客もプログラマも管理者も) 同じである．その筈である．
ところが，何故か次のようなアプローチを目にすることがある．
例えばこんな調子の言い方を耳にすることがある．
「まあ，理論的にはそうなんだろうけど実際に現実はそんなに単純じゃない．現場は甘くない」
「そうは言ってもうちにはそう出来ない特別な事情がある」
「判っているけど，今は忙しくてそれどころじゃない」
「いやあ別の部署がそれでは納得しないんですよ」
「プログラムも趣味でやっているうちは楽しい．でも，なんでもそうだけど，それで食ってくってことになれば楽しいとか言ってられなくなるよ」
何時か誰かにそんな風に言われた事が，多くの開発者のトラウマになっているのかも知れない．そして勿論，言われたときには多分どれももっともなことなのである．しかし，このようなアプローチは，問題を増やすか問題を放置しているだけである．
「お役所仕事」と云うメタファーを考えてみた．「お役所仕事」という言葉は通常余り良い喩えには用いられないが，今回もそうである．
この「お役所仕事」では，問題解決のため，次のような工夫が為される．
「お役所仕事」は，勿論，単純な問題を複雑にするシステムのメタファーである．良い工夫ばかりした心算であるのに，何故か，時には問題が解決困難な方へ困難な方へと追いやられ，時間切れになるか，忘れ去られるまで放置される．
確かに現実に問題は沢山有る．
多分シンプルな事をシンプルな儘やるのは，難しいことである．
「単純な問題」が「簡単な問題」であるとは限らない．
何より「勇気」が必要である．
・そして XP
XP はそれを実際にやって見せてくれるのである．XP は，「実践可能で現実的な」一つの解と成っていると思う．
今回のイベント参加を機に，改めて XP の四つの価値について考えてみた．
コミュニケーション (Communication) + シンプルさ (Simplicity) + フィードバック (Feedback) = 勇気 (Courage)
このシンプルな式に XP の精神が凝縮されているようである．
「シンプルさ」も「コミュニケーション」も「フィードバック」も実践には「勇気」が必要である．XP は，良く言われることだが，実践となると中々難しく感じてしまって腰が引けてしまう面が確かにあると思う．だが，逆に「シンプルさ」と「コミュニケーション」と「フィードバック」がその「勇気」を与えてくれる．
今回のイベントの参加者は，体験によりこの「勇気」を共有出来たのではないだろうか．
上記に参加した．以下にレポートしてみたい．
タイトル：XP祭り2003
<http://www.shibu.jp/xpjug/maturi2003>
場所 ：国立オリンピック記念青少年総合センター 417号室 (東京都渋谷区代々木)
日時 ：2003/07/18(金)
主催 ：日本XPユーザーグループ <http://www.xpjug.org/>
とても楽しく有意義な一日であった．
世界でも日本でも XP が開発の現場に与えている影響は相変わらず大きいようである．日本でも色々な形での XP との関わりが見られる．
今後 XP に関して以下のようなことを考えて行きたいと思った．
上記に参加した．以下にレポートしてみたい．
タイトル：エンジニアのためのコミュニケーション トレーニング
<http://www.tech-arts.co.jp/event/xp/>
場所 ：株式会社 グローバルエンジニアリング 研修室 (名古屋駅近く)
日時 ：2003/11/12(水)
主催 ：翔泳社，テクノロジックアート，独立学校(エムズ)
ソフトウェア開発エンジニア向けに，コミュニケーションの方法を実習を中心として学んだ．
メンタル トレーニングと XP を用いた演習が行われた．
先ず，ソフトウェア開発でネックになり勝ちな「コミュニケーション」と「コラボレーション」に関するヒューマン スキルを高めるトレーニングを行った．
講義と実習があったが，実習が多かった．実習には自分の考えを書き出すものやブレイン ストーミング，グループ討論，様々なゲーム等があった．
そして，次にそこで学んだテクニックを用いて XP の演習を行った．この演習では，レゴ ブロックを使用し，顧客と開発者がコラボレーションにより，開発を行った．
講師は，人材開発研修コンサルタントの有限会社エムズの
「コミュニケーション」はソフトウェア開発の成功のためには非常に重要である．ソフトウェア開発プロジェクトはその七割が失敗している，とか言われているが，失敗したプロジェクトでアンケートをとってみると失敗の理由に「要望がうまく伝わらない」「開発員間の連絡が疎であった」等の「コミュニケーション エラー」をあげる人が多かった，という話を聞いたことがある．
「コミュニケーション」が開発では大切である．唯，そう頭で理解している心算でも，実際には中々うまく行かない． つまりは，判った心算になっている．
本講座の前半では，様々なヒューマン スキル，「聴く力」や「承認する力」，「質問する力」，「提案する力」，「統率する力」，「考える力」，「コラボレーションする力」を付けることでコミュニケーションがスムーズになってくる，ということを学んだ．そしてそれらにはコツが有り，そのコツをゲーム等を通して或る程度体験することが出来た．
「コミュニケーションのためには，相手の『こだわり』を知ろうとし，それを大切にしてあげることが大切」という言葉が特に印象に残った．
「ヒューマン スキルを上げるには，脳の日頃余り使っていない部分を使っていくことが大切」との言葉も有った．
いつも同じような脳の使い方をするのではなく，意識的に非日常的な脳の使い方をし，脳内の神経ネットワークに新たなシナプス結合を作ったり古い結合をリフレッシュしたりすることは大切である．
自分の中にない新しい考え方を取り入れる，というのは中々骨が折れることであるが，これをして行くことで，自分自身で新たな発想が出来るようになって行く．エンジニアに必要な「創造する力」が育って行くのだと思う．
トレーニングは，全体的に「ゲーム」等の頭と体を同時に使うものが多く，体感型であった．このトレーニングにより実際に脳が活性化していくのが感じられた．矢張り，頭だけでなく体も使うことが重要なようである．
講座の後半では，XP の手法による「コラボレーション」が行われた．
XP は短い繰り返し (イテレーション) による開発を行うのが特徴であるが，各イテレーションで顧客とコミュニケーションを行い，レゴ ブロックによる成果物を作り上げる，というものであった．これもゲーム感覚の演習であった．
全体を通して和気藹々としていて，楽しく学べた．
ヒューマン スキルというのは一日のトレーニングで急に上がるものではないが，このようなトレーニングによりヒューマン スキルを上げる部分の脳を活性化することが出来る．そして，徐々に良いコミュニケーションを実践していけるようになるものと思う．
エンジニアとしては心掛けていくべきではなかろうか．
上記に参加した．以下にレポートしてみたい．
タイトル：XP&アジャイル開発セミナー 〜ブームから現実へ〜
<http://www.xpjug.jp/xpjug/event/agileSeminar2003/agileSeminar2003.html>
場所 ：大阪市 中央公会堂 小集会室 (3階)
日時 ：2003/11/28(金)
主催 ：日本XPユーザグループ関西支部
 |
 |
 |
写真は会場となった大阪市 中央公会堂の外観と懇親会会場
・会場など
今回，13:20 から始まって夜までの大阪での開催ということで，懇親会を含めても福井から余裕を持って日帰りで参加することが出来た． こういう機会が増えてくれると嬉しい．
ちなみに，会場は大阪市中央公会堂でなんとも立派な建物であった．
・今回のテーマなど
今回のセミナーのテーマは，XP をはじめとするアジャイル開発を「ブームから現実へ」というものであった．
一点目について，少し箇条書きに
・「アジャイルを現実に」について考えたことなど
最近強く感じることではあるが，「アジャイル」には確かに幾つかのハードルが存在するようである．
ここで，「アジャイル度」の低い順に適当にレベルを想定してみたい．
それぞれのレベルの間にハードルが存在していると思うが，私が最近，特に高いハードルの存在を感じるのは，レベル 2 と レベル 3 の間である．
未だ暗中模索の状態であるが，個人的には「コミュニケーション スキル」がここをクリアするための鍵になるような気がしている．そこには，多くの問題が存在しているように思うが，その多くがコミュニケーションにおける問題であり，高い「コミュニケーション スキル」があれば解決可能であるように感じている．
ただ一方で，「高いコミュニケーション スキル」がアジャイル プロセスの前提条件であってはいけない，とも思う． 多くの人が利用出来るものでなければ，開発プロセスとして意味のあるものとは云えない，と考えるからである．
パターン技術もそうであるように，偉大な先人の尊いトライ&エラーから生まれた「こうやればうまくいく」というノウハウを多くの後輩が利用出来ることが大切である．一部のとてもスキルが高い人にしか使えないものをプロセスとしても，余り意味がない．
勿論，多くのアジャイル プロセスの中ではコミュニケーションを重要視しており，既に具体的なコミュニケーションの方法が語られている．だが，それだけでは中々ハードルを越えられない人もいる．
これからは，「アジャイル」な人達が段々と話題に上げてきている，コミュニケーション関連の技術，コミュニケーション ツールだとか会議の方法，質問の方法，「コーチング」や「ファシリテーション」なんかがアジャイル プロセスの中で語られるようになるのだろうと思う．
・「アジャイルを現実に」していこう
「アジャイル」をやるのも最初は中々骨が折れる．とは言え，「所謂ウォーターフォール (逐次開発モデル)」は，今後益々非現実的になるケースが増えていくだろう．「従来の方法で勝ち続ける」方が多分骨が折れる．
「確かに『アジャイルをやることのリスク』は考えた方が良いが，『アジャイルをやらないことのリスク』も考えた方が良い」
講演者の一人の方が語られたことである．
その通りであると思う．
・懇親会など
懇親会に出席した．大阪の方ばかりかと思っていたが，そうでもなかった．
今回も多くの技術者の方から刺激を受けることが出来，大変美味しいお酒が飲めた．懇親会は，コミュニケーションの場としてやっぱり大切．
XP (エクストリーム プログラミング) - イベント参加レポート集 1 (前の頁)
XP (エクストリーム プログラミング) - イベント参加レポート集 3 (次の頁)
Copyright © 1997-2008 Sho's Software
<HOME> ― <XP (エクストリーム プログラミング)> ― <イベント参加レポート集 2>