「レビュー」をもっとうまくやってみる - DevLOVE関西#93

devlove-kansai.doorkeeper.jp

DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。

シナリオレビューの紹介

登壇者:森崎修司(@smorisaki)
名古屋大学 大学院情報科学研究科 准教授

レビューの効果

テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね

ただし…
テストの工数が削減できるという観点のレビューでないと意味ない

じゃあどういうレビュー内容がテストの工数を削減できるのか?

レビューのアンチパターン

  • 一部だけしか見ない
    インデントはスペース4つで統一してください。とか
  • 人格攻撃
    こんなのもわからないなんてエンジニアとしてどうなんですか?とか
  • 説明会とか進行がおかしい
    ではこれから説明会レビュー会を始めます。お手元の資料を…とか

ではどうしたらいいか

レビューの準備

レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」(後述)
これらをみんなで合意することが一番大事!

レビューによる問題の検出

事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく

レビュー技法

Defect-based reading Perspective-based reading

Defect-based readingとは

漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ(一番難しい)

  • 漏れ
    検討漏れ
    →そもそも検討ができていない場合がある
    あなたにとっての「常識」とは?
    →使う人にとっての常識を定義する
    ドキュメントを読んでしまうと先入観が入ってしまう
    →ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む

  • 曖昧
    読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる

  • 誤り
    外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い

Perspective-based reading

そもそもテスターはテストを実施できるのか?
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法

シナリオレビュー

レビューの目的を共通認識として持つ
レビューの効果に応じて濃淡をつける
指摘は網羅性を確認する
(この辺駆け足だったのでメモできず…)

ワークショップ

その1
http://www.miyazaki-ac.jp/?action=cabinet_action_main_download&block_id=100&room_id=1&cabinet_id=1&file_id=1140&upload_id=3180
これをレビューして問題になりそうな箇所を5つ挙げて下さい。

問題種別の設定方法

トップダウンの例

「グローバルで使われる案件ワークフローシステム」について考えてみる
→どこが一番価値のある品質か
 →システムが停止しては困る
 →大容量ファイルを処理できる
 →日次処理に影響が出ないようにする

システムの停止の際に原因が分かるようにするとか
大容量ファイルは処理時間がどれくらい掛かるかとか複数アクセスされた場合どうなるかとか

つまりレビューで何を見るべきか、また何が大事かはそのシステムにとっての価値で決める
それを決めるのがシナリオである

ワークショップ

その2
http://www.city.matsusaka.mie.jp/www/contents/1340350276686/files/120188-3.pdf
このシステムにとっての価値を順位が高いものから5つ挙げて下さい。

まとめ

ワークショップは3人1組でやったのですが、その1ではレビューの観点がバラバラだったのが、その2では価値順位も含め、かなり近しい観点にまとまりました。
その価値順位に対してお互いが合意してからレビューをすれば、かなりいいレビューとなりそうです。

あとレビュー本すごく良さそうでした。

Google アナリティクス IQ 学習ガイド #Google アナリティクスのデータの見方と活用方法

Googleアナリティクスの仕組み

Googleアナリティクスの主要素

Googleアナリティクスのシステムは、データ収集、データ処理、構成、レポートの4つで構成される。

f:id:shibukk:20150723035845p:plain:w500

データ収集 … javascriptなどのコードを利用して、ユーザーによる操作の情報を収集する
構成    … 元データに適用するフィルタなどを設定する
データ処理 … 送信された操作情報を、構成をもとに有用なデータに変換する
レポート  … ウェブ上の管理画面やAPIを使用してデータにアクセスする

もっと詳しく

重要な指標とディメンションの設定

Google アナリティクスのレポートはディメンションと指標で構成されている。

ディメンション・指標とは

ディメンションと指標は表で表示され、最初の列にはディメンションの値の一覧が、残りの列にはそれに対応する指標が表示される。

f:id:shibukk:20150723040544p:plain:w400

例)ページごとのページビュー数・平均ページ滞在時間
ページがディメンション
ページビュー数・平均ページ滞在時間が指標となる

ディメンションはユーザー、セッション、ユーザーの操作の性質を表す。
指標はユーザー、セッション、ユーザーの操作を数値的に測定したもので、数値データとなる。

もっと詳しく

Google アナリティクス IQ 学習ガイド #デジタル解析の始め方

Google アナリティクス IQ 学習ガイド - アナリティクス ヘルプより、時間がない人向けに要点をまとめてみた。

デジタル解析の重要性

デジタル解析とは

デジタル解析とは、ビジネスデータを定量的/定性的に解析・改善し、それを業績につなげていくこと。
特に最終的なビジネス目標と、その達成度を測定する方法を定めることが重要となる。

例)ブランド認知度の向上を目的としたサイト
ビジネスの目標…認知度とエンゲージメントを高める
測定する達成度…リピート訪問を増やす

そのビジネス目標を達成するには、下記の図にあるサイクルを回し「絶えず改善する」ことが大切。

f:id:shibukk:20150723034150p:plain:w400

ビジネス上の疑問に答えるためのデータを集積し(Measure)、
ビジネス上の判断に必要な情報を意思決定者に提供する(Report)。
次に期待に基づく仮定を構築し、実際の数字がそれに一致する理由やしない理由を検討し(Analyze)、
その分析で見つかった課題に対して、様々な解決策を試してみる(Test)。
そして、これまでのプロセスを通して得られた知識を再利用し、改善していく(Improve)。

もっと詳しく

重要な分析テクニック

分析の重要なテクニックとして、データをセグメントする手法とデータにコンテキストを与える手法がある。

セグメントとは

集計されたデータだけでも、全体的なユーザーの傾向を読み取ることができるが、その理由を理解するにはセグメントをすることが重要。
セグメントとは「データの一部を抽出して分析」すること。
f:id:shibukk:20150723034206p:plain:w600

コンテキストとは

分析においてもうひとつ重要なのが、パフォーマンスの良し悪しを判断するために、データにコンテキスト(背景や状況)を与えることである。
例)売上の上昇が業界全体の傾向なのか自社だけなのか(外部コンテキスト)
自社の過去のデータとくらべて売上が上昇しているのか(内部コンテキスト)

もっと詳しく

コンバージョンとアトリビューション

ユーザーが購入に至る経路を測定するために必要な概念が「コンバージョン」と「アトリビューション」である。

マクロコンバージョンとは

マクロコンバージョンは、ユーザーがビジネス上の価値が高い操作を完了したときに発生するコンバージョンのこと。

マイクロコンバージョンとは

マイクロコンバージョンは成果に直結するものでなく、ユーザーがマクロコンバージョンに近づいたことを示す指標となるコンバージョンのこと。

f:id:shibukk:20150723034159p:plain:w500

コンバージョン ユーザー行動
マクロ 購入、会員登録
マイクロ ほしい物リストに追加、新商品のメルマガに登録

マクロ、マイクロの両方のコンバージョンからより多くの行動データを収集し、目標を達成するには何が効果的なのかを把握することが大事。

アトリビューションとは

コンバージョンに対して何が貢献したか、経路(チャネル)にその価値を割り当てること。
チャネルとは、たとえば検索から商品詳細に遷移したとか。

タイプ どんなモデルか
終点モデル 顧客がコンバージョンの直前に利用した経路に、コンバージョンの価値が
すべて起因すると見なす
起点モデル 顧客が最初に利用した経路に、コンバージョンの価値がすべて起因する
ものと見なす
線形モデル コンバージョン成立までの各経路が、均等にコンバージョンに貢献したもの
と見なす

などなど

各チャネルが果たした役割を把握するためにも、チャネルごとに価値づけをすることが必要であり、それによりコンバージョンに向けたチャネル間の連携を知ることができる。

もっと詳しく

測定プランの策定

測定プランは次の流れで作る。

測定プランを定義する → 導入プランを策定する → プランを実行に移す → プランを最適化する

測定プランを定義する

  1. ビジネス目標を文書化する
  2. 目標に向けた戦略や戦術を確認する
  3. KPIとなる指標を選ぶ
  4. データのセグメント化方法を選ぶ
  5. KPIの目標を決める

導入プランを策定する

測定プランで定義した指標をトラッキングするために、Googleアナリティクスのコードとサービスの機能を定義する。

プランを実行に移す

  1. ラッキングコードを設定し、業績評価指標のトラッキングの方法を決める
  2. フィルタ機能を使用してデータを正規化し、レポートの正確性と有用性を高める
  3. キャンペーンを使う場合は、キャンペーントラッキングAdWordsのリンク設定を行う
  4. マイレポートやカスタムレポートを活用し、レポート関連の作業を効率化する

プランを最適化する

レポートのデータの有用性を保つために、管理チームによる継続的なプランの最適化が必須となる。

もっと詳しく

Qiita:Teamとesa.ioを使ってみた感想

はじめに

今の会社ではQiita:Teamを使っている。
一番古いのを見たら1年以上前の投稿があったので、けっこう使ってるね。
で、使っているうちにいろいろ気になるところが出てきた。

なので、今お手伝いしている会社にesa.io使ってみません?と言ったら使ってくれることになった。 使ったのは大体5ヶ月くらいかなー。

両方ガッツリ使ったので、誰かのために書いておこうと思う。

情報をどうやって分類するか

Qiita:Teamではストック型ツールにもかかわらず情報が流れちゃうっていうのにすごくストレスが溜まっていて。
投稿した時に分類がされないから、どんどんいろいろな情報が流れていってしまう(日報とか書いてたときはエライことになってしまってた)。

まあ、気をつけてタグ付けしていったらいいんだろうけど、タグ付け自体エンジニア以外の人にとってはハードルが高いよね。

esa.ioは/で区切ってね。と教えるだけで階層分けしてもらえた。
このアイデアは素晴らしいと思う。

記事が書きやすいか

僕もエンジニアなのでそんなに気にならなかったんだけど、どうやらQiita:TeamのUIは記事を書きにくいらしい。
個人の資質とか企業文化とかももちろんあるんだろうけど、投稿してる人の属性がかなり違う。

Qiita:Teamに記事を投稿するのは9割がたエンジニアばかりなんだけど、esa.ioはそれが6割くらいになっている。
UIについてはそんなに詳しくないからなんとも言えないんだけど、データ的にはそんな感じで、esa.ioは非エンジニアにとってはすごく書きやすいみたい。

他の人がどういったことに興味があるか

Qiita:Teamの前のバージョンではその記事を誰がストックしているかが見れていたんだけど、なぜか見れなくなってしまった。
その記事に誰が興味あるかって結構大事だと思うんだけど。

esa.ioではwatchっていうのがストックに当たるんだけど、これは誰でも見れる。
XXXさんがこの案件に関わっているのにwatchしてなかったら、watchしといてねと言えば暗黙知もなくなるからね。

まとめ

エンジニアがほとんどの会社だったらQiita:Teamでいいんじゃないかな。
もともとQiitaから派生したものなので、使い心地は似ているし。
ただ、その分ストック型ツールとしては非エンジニアが使いにくい部分も多い。

@bash0C7さんも言ってたけど、エンジニア以外の職種の人にも書いてほしいならesa.ioのほうがいいと思う。

あと、Qiita:TeamはちょっとずつUIとかも変わったりしていってるんだけど、どこが変わったのかをユーザーに教えてくれないのはすごくもったいないなーと思ってしまう(先日大幅に変わった時くらい?)。

リリースノートとかもそうだけど、esa.ioはユーザーとの距離感をいちばん大事にしている会社だと思う。
不具合修正の対応とか見ててもOSSみたい。
サービス運営のあり方として見習いたいところです。


追記

ちなみにesa.ioはExcelもアップできちゃう。Qiita:Teamもそのうちできるようになるのかな。


直近で書きたいこと

  • エラーログ
  • esa.ioとQiita:Team
  • ChatOps
  • 自分にとっての会社という存在

書きかけばかりでこれを投稿できるレベルにするにはまだまだ時間がかかりそう。

コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント - DevLOVE関西#87 その2

devlove-kansai.doorkeeper.jp

その2です。その1はこちら

ストック型+フロー型ツールの導入で社内を巻き込んだ話

登壇者:白石尚也さん
    松尾浩志さん
TAM株式会社

はじめに

ストック型とフロー型とは…
ストック型:Qiita:Team、Docbase、esa.io
フロー型:Slack

ストック型ツールについて

登壇者:白石尚也さん
TAM株式会社 クラウドアプリケーション事業

TAMについて

パートナー型デジタルプロダクションを行っている
→身も心もどっぷり受託

体制としてはプロジェクトチーム制
最大20人でディレクター、デザイナー、マークアップで構成

発生していた問題点

顧客の満足・品質にこだわっているため、勤務時間が長くなり疲弊していく
→疲弊しない受託開発をするためにチーム力向上を図る必要あった

新しいことにチャレンジする案件がほとんど
つまり必ずどこかでハマるポイントがあり、自分がハマったことは他の人も必ずハマる
→どうやって解決したか共有、コミュニケーションを取れるようにしたい

案件が複数(常時5〜7件)同時進行
時期によっては1人に業務が集中する
→チーム全体がメンバーの仕事状況を把握し、お互いが助けれるようにしたい

問題解決のためにDockbase導入へ

Dockbase導入の苦労

3つくらい壁があった

  1. どのツールを使ったらいいのか問題
  2. リーダーを説得するにはどうしたらいいか問題
  3. 書いてもらう、読んでもらうにはどうしたらいいのか問題

どのツールを使ったらいいのか

有名なストック型ツールは3つあった

  • Qiita:Team … 一番有名
  • esa.io … デザインイケてる
  • DockBase … シンプル

さてどれにしよう…?

ツール選定のポイント

誰でも使えるわかりやすいUIのツールにしたい
エンジニアではない人が大半であることを考慮しないといけない(そもそもMarkdown書けない)
→つまり、たとえ機能が多くても直感的でないと使われない
使用ツールが増えてきているので学習コストを下げたい

3大ツールの検証

有志を募って1週間ずつ使ってみた

Qiita:Team

機能が一番豊富だが、プロジェクト・タグ・メンバーから記事が探しにくい
投稿ボタンどこやねん(解像度が低いと見切れる)

esa.io

かわいいデザインはGood!でもなんで英語?
カテゴリとタグの付け方がわからない
→結局だれもタグ付けしない
WIPって何?という意見も

DockBase

シンプルで分かりやすい(最後に試したというのもあるが)
エディタ機能付き、かつMarkdownの書き方がすぐ分かる
投稿ボタンが見える笑
メニューから記事が探しやすい
自分の活動、他人の活動が目に見える

結論

シンプル・見やすい・探しやすいということでDockBaseを採用することに

リーダーを説得するポイント

いきなり全員で使うのではなく、少人数でスタートし巻き込んでいく
リーダーが気になることを書く(朝会、日報)
リーダーになんとなく効果を実感してもらう
DockBaseは今なら無料!
→無料のうちにメチャクチャ使って寝技にもちこむっていうのもアリ

書いてもらう、読んでもらうポイント

何をかいてよいかわからないし、書く時間がないという意見がツールの振り返りで判明した

「暗黙知を作るな、すべてを形式知に変えよ」

とにかく書けるものから書く
朝会、日報、ふりかえり、議事録など
→なるべく所感も書いてもらう
調べたこと、解決した方法も形式張らずに書く
さらに、投稿を通知して読んでもらう(チャット通知に連携)
読んだら反応する風習を社内につける

壁を乗り越えた結果

チームの会話、コミュニケーションが増えた
→答えはそこになくても、あの記事を書いた人なら分かるかも
チームメンバーの状況が可視化された
→朝会、日報、ふりかえりによってお互いがフォローできた

今困っていること

記事の精度をどこまで求めたらいいのか
→記事のレベルアップ最終盤は別のWikiにまとめるとか?
タグが煩雑になりそうな予感
→すでに独自の見解による謎タグの氾濫が…笑
より活発に使われるためにはどうしたらいいんだろう
→この後のワークショップで話しましょ!

まとめ

やりたいと思ったらまずは少人数で試してみる
→協力してくれる人は必ずいる! どんなことでも残っている安心感が得られる
記事の内容も大事だが、記事を書いた人とコミュニケーションするきっかけ作りになることがとても重要

フロー型ツールについて

登壇者:松尾浩志さん
TAM株式会社 CTO

導入前の問題点

メール+チャット(Skype)が中心だった

Skypeはプライベートなやりとり向きでクローズド
オープンな場所に情報が集まらない
オープンな場所は全社メールくらい
気軽に質問・共有できない

どうにかしたい どうしたい?

知らなかったことを知ったら「これ知ってた!?」って気軽に言いたい
分からないことを知ってそうな人に気軽に聞きたい

なぜSlack?

チーム全員参加のチャットルームがデフォ
Githubなど他ツールからの通知をSlackに流せる
イケてるもん触ってる感

Slackを情報共有のハブとして

IFTTT連携も活用することでタイムライン的に情報が集まる
いろいろな社内ブログを更新したら流すようにみたいな情報共有の仕組みができた
hubotでカスタマイズしたりもできる

社内へのアプローチ

新しいモノを試すときの人の反応タイプはこんな感じ

  • 新しもの好き、試行に積極的 →少数派
  • ツールは特に何でもいい   →多数派
  • めんどくさい…       →多数派
  • ぜったいイヤ!       →少数派

まずは新しいもの好きの少人数で試行してみて、のちに多数派にアプローチしていった

コミュニケーション上の工夫

なごむ雰囲気を作る
→業務外のチャンネル作ったり絵文字を登録したりとか
→TAMくんbot

TAMくんbotとは?

→人がなごむpostするには限界がある、スベったら凹む
→かわりにTAMくんbotになごむ返信をしてもらう

TAMくんが使われる場面はこんな感じ
→お昼時を知らせたり、明日は雨の予報のときに通知したり
→ビールアイコンに反応したり
→よろしくお願いしますに反応したり

どうでもいいことを書いてOKな雰囲気に

たらいまわし作戦

誰も答えない場合はたらいまわす!
どういうことかというと…

誰かが全体にふわっと質問する

誰も答えない

やばい、このままでは誰も質問してくれなくなる

分からないなら分からないと返答しつつ詳しそうな人を名指ししてしまう

そうすることでコミュニケーションが止まらない

Slackを導入してみて

持ち寄れる下地ができた
→気軽に質問したり教えたりできる場所ができた
→チャットにいるだけで情報共有できるようになった

まとめ

「良いしくみ」をもつツールがフィットすると、仕事の流れが予想以上にいい方向に変わるケースもある
遊び要素・和み要素は重要
しくみを作って終わりではなくコミュニケーションを潤滑にまわす努力は必要

コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント - DevLOVE関西#87 その1

devlove-kansai.doorkeeper.jp

DevLOVE関西主催の勉強会に初めて参加してみました。というわけで書き起こしを。
だいぶ長くなったので端折ってる&整理してます。

ポエム駆動開発 エンタープライズ

登壇者:こしば としあきさん(@bash0C7)
ピクシブ株式会社

ポエム駆動開発とは?

pplogさんのこの記事にものすごく共感した
→ポエムの共有をして意思決定のスピードを上げる
→サービスを開発する前にポエムを書く
→思いを共有しておき、いつでも立ち戻って振り返れる

つまり『コンテキストの共有』が大切

ではポエム駆動開発エンタープライズとは?

エンタープライズとは経営資源の投入
投入するからにはやる理由やらない理由を説明しないといけない
→それをポエムから始めようということ

pixivchatの例

pixivchatはクローズの判断を一旦下したのだが…

社内のメンバーがpixivchatへの思いをesa.ioに投稿

あれこれコメントがついた

なんか新しいプロダクトを創りだした

ロードマップまで笑

『新サービス現在開発中』とユーザーに告知するまでになった

イデアについて

  • 上から降ってくる
  • 横から割り込まれる
  • 足元から湧いてくる

この3つのパターンに分類される

足元が湧いてくるとは?

こういうのやったほうがいいんじゃない?っていうのがメンバーや役員から持ち上がってくる
KPI・お問い合わせ・プラットフォーム・自分たちの理想が源泉となっている

でも湧いてくるというのは賞味期限が短い
→飲み会で盛り上がって終了
→じゃあポエムを書こう

ポエムの書き方

好き勝手に書くのではなくポエムの書き方をこしばさんが決めてみた

理由としては

  • 理屈ではなく熱意を感じたい
  • 日報は遠い日の話を書けない・エモいことも書けない
  • チャットは端的な発言になってしまう

だから反芻して発信しよう!ということ

ポエムの流れ

  1. 天啓を得る
  2. ポエムを書く
  3. 興味ある人からコメントが集まる
  4. プランとしてまとめる
  5. 有志が集まってMTG
  6. 承認を得る
  7. プロジェクトが立ち上がる

現在

数十から百数十のポエムが存在する
新卒が入社数日でポエムを書く
→議事録やアイディアメモが陽の目を見るようになった

ポエムを書くまでの悩み

マネージャーは発言しやすい
→そんな立場の人でも思いを発信する場がないことに気づいた
wikiは書いたら消えない
issueは閉じることに意味がこもってしまう(お前の話は聞かんみたいな)
飲み会は話が散らかる
言い出す勇気が必要

自分自身の、会社でポエムを発信することへの躊躇に気づいた

ポエムスタート

オフィシャルにesa.ioを使うことにした

全体の会議でポエムを書こうと言った
また自分でポエムとは何かを述べた
esa会もした
ピクシブのエンジニアブログにもポエム駆動開発エントリーを書いた

持ち寄られるようになった(なんかしらんけどとのこと笑)

ポエムを書くようになって

ふと浮かんだアイデアを意見提案してくれる(プロジェクト横断で!)
プロジェクトで試してみたことを書いてくれる
一ユーザーとしての観点として、リリース後のものに対するフィードバック
開発スケジュールの管理
広告についても、みんなが知ってほしいから書いてたりする

やったこと・してないこと

やったこと

ツールの意図の説明をした
自分から理想の利用者を演じることにした
→率先してスター・コメント・介入をしていく
意図と違う使い方を黙認した
→タスク管理ツールじゃないけどまあいいよ

してないこと

カテゴリ分けはしなかった
細かいルール策定もしなかった
→それでも使われているのは何でだろう?再現性を作りたいと思っている

質疑応答

Q.ポエム導入を小さくはじめなかったのはなぜ?
A.導入についてどう進めるかをトップに相談してみたところ、全社的にやってみたら?というアドバイス
じわじわよりパワーで進めるのもアリだなと思った

Q.esa.ioを使うことにしたのはなぜ?
A.docbaseやQiita:Teamというツールがあったのは知ってたけど、見た目がかわいかったからesa.ioにした
理由としては技術者以外にも使ってほしかったから
→エンジニア主体ならQiita:Teamでいいんじゃない?

Q.声の大きい人のほうが力が強くなってしまうのでは?
A.プレゼンではなく文章に書くからこそ、そういったことがそれが抑えられたのでは
1行はするどいから数行かこうとかのポエムのルールも寄与した
また、ポエムを読んで、誰がどう思うかっていうのを考えていながら書いてもらっている
肩書で左右されてしまう問題はピクシブの組織の性質上今のところはない

Q.長い文章を書いてくれるけど意味不明ということはないか?
A.長い文章を書いてくれるけど意味不明っていうのもあるにはあるが、書くこと自体に責任が伴うということを伝えている
またマネージャーとして寝かしたほうがいいとかのアドバイスはしてあげる
Save as WIP Ship it!という機能を使って通知が飛ばないようにできるから、それも有効活用している

Q.導入してみて盛り上がりに欠けたりかもしれないが…
A.初動を起こす人フォローする人それぞれが個性として認めている
やはりhubとなる数人のフォロワーからスタートするのがいい
人事考課とかでも賞賛するようにしている(楽しく意見を言えるように会社側もフォロー)
結果としてドキュメントを書くことが楽しいと言ってもらえたのが嬉しい


追記

こしばさんがスライドをアップしてくれていたので載せておきます。 inside.pixiv.net


その2へつづく。