Agileの最近のブログ記事

勉強会用に事例的な資料を探していたら Improving Video Game Development: Facilitating Heterogeneous Team Collaboration through Flexible Software Processes という文書を見つけたので、購入した。

Abstract からちょこっと引用。

Based on a state of the practice survey in the Austrian games industry, this paper presents (a) first results with focus on process/method support and (b) suggests a candidate flexible process approach based on Scrum to improve VGSD and team collaboration. Results showed (a) a trend to highly flexible software processes involving various disciplines and (b) identified the suggested flexible process approach as feasible and useful for project application.

まだ1/3くらいしか読んでないけど、割と面白い。例えば、Scrumでの「良いユーザーストーリー」は「顧客にとって価値があるもの」でなくてはいけない(INVEST の V)とされているけど、この論文は 2.1 あたりでいきなり、価値についてこんなことが書いてあった。

経済的観点から言うと、製品は価値を産み出すための製品(実利的なもの)と、価値を生むためではないもの、例えば映画や音楽のように、エンターテインメントや娯楽を主な目的にするものに分類できる。ゲームは後者だ。(ちょー意訳)

まぁ、そうですよね。世の中の Scrum を解説した本とかは、前者の「価値を産むためのソフトウェア」について論じているものが多いので、後者の価値とは別の視点で考えた方がいいかもしれない。
全体的にすごくコンパクトなので、すぐに読み終わりそう。

デザイナー(アーティスト)も含めた混成チームでどうやって協業するかは、 Agile Game Development with Scrum の11章にも書いてあったから、後で読み直す。

ちなみに € 29.95 がいくらになるのか計算しないでポチったけど、意外と高かった... orz

昨日書いた通り、こちらのイベントでスクラム開発の話をしてきました。

【増員!→200名】「開発現場を加速させる!」 アプリ制作勉強会 / Unityスマホアプリ / アジャイル開発「Scrum」 / チャットワーク式ワークスタイル

雨にも関わらず、多くの方に来て頂けてとても良かったです。僕の準備不足で質疑応答の時間が取れなかったので懇親会で質問に受け答えする形で何名かとお話させて頂きましたが、お話した皆さんには概ね好評だったので、大変うれしく思ってます。

資料を slideshare にアップしてますので、貼っておきますね。

Problem vs Us のスライドは、平鍋さんの資料からお借りさせて頂きました。
プロダクトオーナーの役割が1枚で分かる資料は、 @ryuzee さんのblog からお借りしました。
引用を快諾していただいたお二人に感謝します。

スタッフの皆様、会場をご提供いただきました GMO 様、ありがとうございました。
GMO Yours は居心地のいいスペースなので、行ったことがない人は是非一度行ってみるといいよ!

タイトル嘘ついてます。二言です。

ゲームポットで配信しているiPhone / Android向けアプリ、「ゆるロボ製作所」についてファミ通さんのインタビュー記事が本日公開されました。開発担当スポークスマンとして偉そうに語ってますので、まだご覧になってない方は是非ご一読いただけるとヨロコビます。

まずは一言目。 
飯田様、編集担当様にはお忙しいなかわざわざ弊社までご足労いただき、さらには大変な労力をもって記事としてまとめていただけたことを大変ありがたく思っております。本当にありがとうございました。 

二言目。 取材を終えて、のくだりに "チーム全員でアイデアを出し合って作った" とありますが、この「チーム」とは「スクラムチーム」であったことをここに強調しておきたい。僕が言いたい、タイトルの"一言"はこれです。
  
ゆるロボの制作チームは、スクラムチームとしてはまだまだ未熟かもしれない。が、ゲームのゴールを自ら認識し、そこに向かって誰が言うでもなく建設的な意見を出し、かつ、その意見を「ここは誰々がやってくださいよ」とか言うでもなく「自発的に手を動かす」ことでゲームの挙動として、楽しさ・面白さとして具現化した。

ベストなスクラムチームだったかはわからない。だが、強いスクラムチームだった。 
その結果が 50万+ ダウンロード。
つまり多くのお客様が面白いゲームだと思ってくれる、 "価値" を提供できた。 

僕がこのエントリで強調したいのは、インタビュー記事で「チーム」と書いてあるのは「スクラムチーム」と認識してもらい、ゆるロボをアジャイルなゲーム開発の一つの成功事例と捉えてもらえるとそれはとっても嬉しいな、って。

今日は Agile Game Development with Scrumの読書会に行ってきた。
会場を提供頂きましたAiming様、ありがとうございます。

詳細なメモは後日Facebookのグループに上がるはずですのでそちらに譲るとして、7章の図中に出てきた Complex と Complicated に違いについてメモ。

complex も complicated も「複雑な」という意味の形容詞で対義語が simple ですが、以下の違いがあるかと思っています。


  • complicated : 込み入ってて、まぁ説明しようと思えばできるんだけど、大変なんだよ、複雑で。

  • complex : 何が何だか分からないくらい入り組んでて。説明?うーん、できなくはないよ、多分。理解しようと努めているし。


というニュアンスの違いがあるのかなと。。英語ネイティブの方のツッコミをお待ちしておりますw

手元にある Oxford Advanced Learners Dictionary をひいてみると、complex も complicated も


difficult to understand or explain because there are many different parts;

と書いてあるけど、例文で示されている利用法が明らかに異なる。

complex の方は、


a complex argument, theory, subject, etc.

であり、 complicated の方には

He's married to her, and she's in love with his brother-in-low, and...oh, it's too complicated to explain!

とある。
complicated の方には、複雑だったり雑然とした現状があるけど、本来あるべき姿がある、という点で complex と使い分けられる。
そういうことかと。

ちなみに Facebook の Relationship にも it's complicated という選択肢があるので、該当される方はそれを選べばいいと思いますw


川口さんに誘ってもらい、品川界隈で働く人達で集まって Mike Cohn の Succeeding with Agile を読みましょう、という会に参加してきました。その名も Shinagawa.agile 。

ちなみに品川界隈とは、JR品川駅を中心とした半径30km以内を指すようです。
地図で表すと↓こんな感じ。

というのを呟いたら思いのほか反響があったので、WORKDAY関数のサンプルとして僕が業務で使っているバーンダウンチャートのテンプレート(.xlsxファイル)を晒してみます。

ファイルをダウンロード

このファイルのグラフシートをA4サイズで印刷し、壁(タスクボード)にマグネットで留めて使っています。数字のプロットは手作業ですが。こんな感じ。

20120411_3.jpg

■このシートで何ができるの?

20120411_1.png

  • Sheet1 に イテレーション(スプリント)開始日と、そのイテレーションでの見積もり時間を入れると、 Chart にバーンダウンのひな形を作ってくれます
  • バーンダウンのひな形は、グラフのタイトルが付いて、日付を横軸、見積もり時間を縦軸にして、理想線を入れてくれるだけです
  • そのまま印刷すればすぐ使えます
  • 土日はスケジュールから除外してくれます

■使い方


  • A列2行目、グラフタイトルには「Sprint #2」とか「Iteration #5」と書いてます

  • B列2行目、見積もり時間の所にそのスプリントの見積もり時間を入れます

  • C列2行目にイテレーション(スプリント)の開始日を入れます

  • 間違って余計な所を書き換えないよう「シートの保護」がかかってます。保護用のパスワードは空文字です(パスワードを設定していない)ので、変更したい人は保護を解除して下さい

  • 5行目、E列からM列に「平日」を計算して表示するための WORKDAY 関数を使っています。これで土日が除外されます

  • イテレーション(スプリント)の長さは2週間固定です

全てのプロジェクトが「月曜に始まり、翌週金曜日に終わる」とかだと何の苦労もないのですが、必ずしもそうとは限らないので、以前はバーンダウンチャートは割と地味に手作業で作って(作らせて)ました。毎回手書きはさすがに面倒になったのでやっつけで作ったシートではありますが、単純に日付から土日を除外してくれるだけでも十分に便利だと思います。

ということで、エクセルでガントチャートや開発線表を書いている人はworkday関数使うと便利だよ、というお話でした。

3/5 (Mon) は 10:00〜18:00 まで Scrum Essentials Tutorial というセッションに参加しました。 Agile Game Development with Scrum の著者、 Clinton Keith さんの話です。

構成はだいたいこんな感じ。

  • 10:00 〜 スクラムの概要説明 & ワークショップ
  • 12:00 〜 昼休み
  • 13:30 〜 幸せなチームを作るための「科学的な」アドバイス by Scott Crabtree
  • 14:30 〜 Sprint について & ワークショップ

発表資料は .pdf ファイルがコチラで公開されています。
(アニメーションしないので、そのままこれだけを見ると逆に分かりにくいかもしれない)

■感想
スクラムは軽量ゆえにIT系の開発に関わらず色んな分野に応用の効くフレームワークだと理解していますが、それをゲーム開発に特化して細かい説明を受けられたのはとても有益だったと思います。
Agile Manifesto の紹介では、ゲーム開発のコンテキストに則していくつか単語を置き換えて説明していましたし、 Potentialy Shippable Increment については Playable Game と、完全に言い換えていました。
こんな感じでスクラムの用語をゲーム開発用に適宜変換して説明してましたが、置換が非常に絶妙で、ゲームを開発した経験のある人であれば、このセッションに参加することでスクラムを理解しやすくなったかと思います。

個人的にこのセッションに参加しての最大の収穫は、弊社の執行役員(CTO)も同席させたことですかねw
認定スクラムマスターコース、俺も受講してみようかなぁ」と昼飯食べながら言っていました。
# 「経営者ですから、CSPOの方がいいんじゃないですか?」 と言ってみましたが

いずれにしても、そのレベルでスクラムに理解をしてくれる人が社内に増えるのは喜ばしいこと。

ソーシャルゲームをスクラムで開発してるんですが、社内の(隣の部の)プロダクトオーナー (Product Owner : PO) にデモをしたら
「なにこれ、すげーじゃん!もう出来てるじゃん。これで出しちゃおうよ!」
って言われた。

Potentially Shippable Increment を作る、ということがちゃんとできたんだなぁ、と思った。

資料やドキュメントで語るよりも、あるいはコードで語るよりも優れたコミュニケーション手段は動いているものを見せることだと思うので、スクラムはゲーム開発に向いていると思う。


From Legacy to Agile ~レガシー開発からアジャイル開発へ~

  • 野口さん
  • 塩谷さん
  • レガシー開発からアジャイル開発へ
    • 移行するのに障害があるはず。それをどのように乗り越えていくか。またキャリアデザインなど

アジェンダ

  • 3周回った俺達のアジャイル
  • レガシーの現実
  • レガシーからアジャイルへ
  • クロージング

3周回った俺達のアジャイル

  • 塩谷さん
  • dwango の中の人。1月からドワンゴモバイル。

このセッションについて

  • 去年の9月にXP祭りで喋ってきた内容の再演みたいなもの
  • もう少し時間をかけて、大勢の前で喋りたいと思った
  • カオスなゲーム開発からSI式ウォーターフォール(略)アジャイルという草原にやってきました
  • 一昨年のdevsumiで、 @yoshiori さんの3周遅れのXP → ベストスピーカー賞
    • その時はまさか同じ会社で働くことになるかとは思わなかった
  • 一昨年そのセッションで感銘を受けた人が、実際に現場に入ってみてどう感じたかを紹介します

きっかけ(社内事例紹介)

  • きっかけ1
    • ホワイトボード1枚にタスクボードとバーンダウンチャートをつけている
    • 新卒で入って1年目、がんばってタスクボード更新したりしてる
  • きっかけ2
    • プランニングポーカーをして見積もりをしているチームがある
  • きっかけ3
    • コードレビューをたくさんやっている
    • ペアプログラミングが大好きで、作業量全体の半分くらいはペアプロでやっている
    • セオリー通り、キーボードを奪い合うような感じではなく、後ろでコード書いているところを見守るとかしてる
  • きっかけ4
    • 朝会(夕方やっているので夕会)
    • イテレーションを1週間でやっている。リリースとはリンクしていなくて、振り返りするための区切りにしている
    • KPTをアレンジ -> KPTZ
    • Z -> 雑感
    • 「今日は8/33。夏休み終わりたくないでござる」
    • 「烏賊がなくなりそうでござる」
      • 大所帯なので、コミュニケーションの役に立っている
  • 傾向
    • 導入プラクティスは割りと共通
      • 朝会、CI、バーンダウン、
    • アレンジを恐れない
      • 本に書いてあるとおりに続けて硬直化して続かないよりも、現場に合わせた方がいい好例
    • 飢餓感
      • プラクティスに縛られない。自分たちのチームをよくしていこう、という意識が強い
  • アジャイルサムライが発売されてすぐの時期のこと
    • 「今までやってきたことに名前がついているのを知った」

まとめ

  • 高速道路がたくさんある
    • こうするとうまくいくことが多い、うまくいく可能性が高い、という知識は本とかWEBに書いてある
    • 高速道路を活用すればいいが、現場では守破離が大事
    • 守 → 最初はセオリー通りにやる
    • 破 → アレンジしてみる
    • 離 → 自分たちのやり方を確立させる

自分がやったこと

  • 壁にホワイトボードでタスク看板作成、みんなで(企画職の人も含めて)朝会
  • 見える化されたので、他職種の人ともタスク量を共有することができた
    • こういうアナログなツールは、Redmineとかよりも効果を発揮するケースがある
  • 事例を紹介しましたので、devsumiの「次は君の番」の慣例に従って、あなたのところでもやってみてください

レガシー開発の現実

自己紹介

  • 野口さん
  • 2011年12月に転職。dwangoの中の人。ニコニコ静画とかやってます
    • それまではエンタープライズ向けシステム開発

レガシー開発とは

  • 開発をレストランだと考えてください
    • 予約されたコースをその通りに出す(フルコース)
    • カウンターで、お客さんと話しながら一つ一つ注文していく
  • それぞれにメリット、デメリットがある
    • 結婚式とかのパーティーに向いているのはどっち?
    • 無駄が多いのはどっち?
  • カウンターで、お客さんと話しながら一つ一つ注文していく → アジャイル
  • 予約されたコースをその通りに出す(フルコース) → レガシー
  • 変更を許容しない
  • 顧客と開発者は別
  • 決められたとおり(仕様書)に従ってモノを作る

現場のあるある

  • ヒトが倒れたりするw
  • それ、〇〇さんの書いたコードなんで
  • 「なんかいけてないんだよねー」(ざっくりした要求)
    • ざっくりした要求をマネージャーが部下にRT(右から左に流すだけ)
  • 「仕様書とテスト項目少ないよ」 → 「え?これ以上どうしろと?」
    • 仕様書少なすぎるパターン
  • 「何ステップ書いた?」 → 「200くらい。見積もりより少ないです」 → 「少なすぎ。さぼってね?」
    • コード何ステップ書いた?パターン。ステップ数で生産性図る時点で問題がある
  • 「あー、今回もデスマだったけどリリースできたわー」「3日寝てねーからつれーわ」

レガシー開発をまとめると

  • 人のコードは人のもの
  • 伝言ゲーム
  • Document Driven Development
  • 開発標準 ISO9001
  • 「開発ってのは辛いもの」というイメージを持ってしまう。仕事だから辛いのは当たり前だよね

生存戦略

  • このスライド、今回のデブサミで相当見ていると思うんですけどw
  • これからこの生存戦略を皆さんと一緒に考えていこうと思います

質疑応答

  • レガシーな会社を変えることができるか?
    • できると思っています (野口さん)
  • なぜ会社を変えたんですか?
    • 人生そんなに長くないので、つまらないことには付き合いきれないなと思った (野口さん)

座談会的な

  • アジャイルに対する誤解
    • 優秀な人たち向け
    • モノだけ作る
    • お客さんのいいなり
    • 対話とかいいから、お前ら手を動かせ

優秀な人たち向け

  • よれよれと手書きでホワイトボードに書いているようなやり方でも実践できる
    • そう言えるのは優秀だからですよね?w
  • レガシーのやり方だと、数割のスゴイ人と残りの普通の人だけど、アジャイルだとみんなでスゴイことをやろうよ、というやり方。
    • できるところからみんなでやろう

モノだけ作る

  • 仕様書とかドキュメントとかは要らない?
  • 仕様書は30kg納品してください → 仕様書の単位としておかしい。環境破壊だからヤメレ
    • 引継ぎのドキュメントとか、共有にドキュメントが必要であれば最適で効率的なやり方を探した方がいい
    • wikiは便利だけど、wiki最高!は思考停止
  • エクセル方眼紙は人の心を汚す
    • 最近のエクセルは方眼紙がデフォルトテンプレート。マイクロソフトはソフトウェアエンジニアをこr(ry

お客さんのいいなり

  • お客さんを「同じバスに乗せる」というのが成功に一番近い
  • 「お客さんがこう言っているから」というマネージャーのセリフはおかしい
    • お客さんをコントロールできるマネージャーは強い。はい、というよりいいえ、といえる方が強い。それはアジャイルであれレガシーであれ変わらない

対話とかいいから、お前ら手を動かせ

  • アジャイルのツールの多くはコミュニケーションのためのものなので、対話要らないってことはない
  • 朝会が「朝礼」になっちゃっているとかヒドイ。1時間朝礼で立ちっぱなしとか
  • 開発現場でしゃべるか?
    • その場の空気。隣の席の人とチャットすることもあれば、大声で話すこともあるし

アジャイルはじめるには?

  • ドキュメントどうする?
    • 砂でも入れておけば。アマゾンで1トン買うとか
    • 全くドキュメントを書かない、と思っている人がいるが、そんなことはない。必要なドキュメントは書く
  • ペアプロの生産性
    • チームのコードの作り方を学んだり、教育にとても有効
    • 書いたものをレビューするよりも、書きながらレビューする方が品質は高い。お得。割安。
    • コードの読みあわせ。プリントアウトしたものを1時間くらいかけて説明するようなことをレガシー開発ではやってた
  • 見積もりは?
    • お客さんとの信頼をコツコツと作っていくしかない
  • 仕様変更
    • 仕様変更は、発生するのが当然として考えておかないとダメだと思う(野口さん)
    • 仕様変更が発生するのは、別に誰も悪くないと思う(塩谷さん)
      • エンジニアにできるのは、仕様変更に強い作りにしておくことだと思う
    • レガシーな開発だと100%納品が求められる
  • スケジュールは
    • 確定するのは難しいので、だからこそお客さんを巻き込むのが重要
    • 正確な見積もりは不可能だし、要件はどんどん変わっていくので、外れた時にどうするのかコンセンサスをとっておくことが大事
    • ガントチャートがない世界に行きたいw
      • 変化がある以上、期日通りにはなかなか難しい

アジャイル関連書籍

  • アジャイルマニフェスト
    • レガシーなものとアジャイルの対比、で書かれている
    • 10年経っても色褪せない
  • アジャイルサムライ
    • 各地で読書会が開催されているヤツ
    • カッコ悪さを隠していないところがいい。脱力しまくりのイラストとか、それが現場のリアル
  • アジャイルプラクティス
    • Javaとかで言うデザインパターンとかに近いような気がする
    • 八重洲ブックセンターで「なんじゃこりゃ」って手にとった本。衝撃的だった。
    • 現場で試しにやってみよう、というのであればアジャイルプラクティスは最適。朝会とかやり方が具体的に書いてあるし。
  • アジャイルな見積もりと計画作り
    • 見積もり手法について書いてある。計画ってのは立てて完遂するのが美ではない。いかに修正するか
    • 自分のチームの生産性を把握しておくことが重要
    • チームが5~6人以上であれば、読んでおくことをオススメ

プランニングポーカー

  • 他の人のタスクであっても、みんなで見積もりして共通認識を作るのって大事
(第2部は手書きなので後ほど・・・)


  • 見入ってしまって全くまとまってない

アジャイルマニフェスト ディケイド

  • 角谷さん

自己紹介的な

  • 「ご講演いただく感じじゃぁないですw」
  • E和のRubyistです
  • Ruby Evangelist in Japan
    • Ruby会議を運営していました
  • アジャイルサムライという本を同僚と一緒に翻訳しました
    • もともと洋書なので、サムライは Jedi くらいに捉えるといいかも

宣伝

  • 3/24 Agile Samurai Dojo Gathering @ オラクル青山センター
    • スポンサー募集してます

これまでの振り返り

  • 2001年2月、アジャイルマニフェスト
  • アジャイル以前の主流はウォーターフォール式のソフトウェア開発
    • 人工のソフトウェア
    • 経済的な要請に基づいて、要請されたソフトウェアを作成する
  • HWの進化、要素技術の発展、全球的ネットワーク、ビジネス変化の加速
    • 自然なソフトウェア
    • ウォーターフォールの作り方に合わない
    • 不正義。正義が行われていないというのが20世紀末の状態
  • Kent Beck -> XP
    • 建築の手法をソフトウェア開発に持ち込んだ
  • ココらへん話すと長いので、パターン,wiki,xpを読んでください

アレグザンダー

  • 少しずつ成長させる
  • 人間の完成に深く基づく
  • 繰り返し実施される

今日のタイトル decaed

  • decade = 10年
  • ググると仮面ライダーディケイドが出てくる
  • 仮面ライダーディケイドの説明
    • (興味ないんで省略)

  • ソフトウェアの作り方は決まっていた ie. water fall
    • それが今は前提として回らなくなってきている
    • 決められたやり方でやればいい、という時代は終わった
  • water fallじゃないやつって、どうすればいいのか
    • 一人一人がやらないといけない時代

現在のアジャイル

  • 受け入れられている
    • イギリス政府で採用されたりしている
  • そういう一般的な話はいろいろなところに書いてるので、今日はそういうところに出てこない話をする

The Nature of Software

  • Nature => 本質的なもの、特性、特質
    • 人とソフトウエアの間に価値がある
      • ソフトウェアに価値があるのではなく
    • システム全体を構成する
    • 変更に対応できることが求められている
      • 「ソフト」なんだから、本来変更に対応できるはず
    • 人がソフトウェアを使ってみないとわからない
      • 動かすのにハードウェアやドキュメント、場合によっては運用支援も必要
      • 変化に対応するために、作りっぱなしじゃなくて変化に対応しないといけないがなかなかそうはいかない、技術的負債がある

人とソフトウェアの間に価値がある

  • ソフトウェアは頭の中にある
    • 目に見えない
    • 使った人が「あ、こういうことね」と認識するもの。使ってもらって、FBをもらったりしないとわからない
  • ビジネス要求からビジネス価値につなげるまで、end-to-endのサイクルをつなげていかないといかん

変更に対応できること

  • Programming as thearoy building
    • プログラミングは世界観を構築して、それを創りだすこと。文字列を並べる簡単なお仕事ではない
    • プログラマがどう捉えて、どう表現しているか
  • 変更できるようにつくらないといけない
    • "「コードはドキュメントである」と受け入れることだ。それからコードをクリアにしようと務めること"
    • コードにしたことと、しなかったことがプログラミング
    • どういう世界観をコードを通じて伝えれば伝わるかを考えて、プログラマはコードを書く

自然のソフトウェア

  • 人工のソフトウェア
    • ビジネス上の要請に基づいて作られる、仕事のソフトウェア
  • 自然なソフトウェア
    • Free / Open Source Software
    • Bazzar style
    • 使われるソフトウェア

開発プロセス

  • 人が作るので、そこにプロセスは何ら頭の形で存在する
  • アレグザンダーのパターンによる建築プロセスの特性
    • 少しずつ成長させる
    • 人間の完成に深く基づく
    • 繰り返し実施される

アジャイル開発

  • you can't do agile.
    • アジャイルは名詞ではなく形容詞。アジャイルをやることはできないが、身軽に、活発にいきいきと動くってこと
  • どれだけアジャイルにできているか、度合いを形容するもの。プロセスがどれだけいきいきとしているかを示す度合い
  • 現場は全部異なるので、全部に当てはまるものはない。その場状況に当てはまるものを作り上げていくしかない
  • スクラムの概要
    • 軽量
    • 理解が用意   * 習得は非常に困難
  • 3回おこればパターン、名前をつけると流通する、流通すると他の人が使うようになる
  • 名前の後ろに、問題が起こっているコンテキストとか、解決方法とか制約があって、それらが全く同じという現場はない
  • 朝会で「今日やること」を聞くのと「今日ぶちかますこと」を聞くのの違い

アジャイルマニフェスト

  • 噛み締めて呼んでください
  • 自分だったらどうするか、という視点で噛み締めるように

次の10年に向けて

  • アジャイル開発はもう皆知ってるし、一つのゴールにはきた
  • 自然なソフトウェアに近いものを、どう人工的なソフトウェアの環境で作っていくか
  • Social Coding で他の人と関わるとか
  • やれることを一生懸命やる
    • やれることだけやっているとなかなか先に行けないけど
  • アジャイルは素晴らしい考え方だけど、その考え方に対して問を発していく
    • 答えは自分で探す

このアーカイブについて

このページには、過去に書かれた記事のうちAgileカテゴリに属しているものが含まれています。

前のカテゴリはAdobe Integrated Runtimeです。

次のカテゴリはAndroidです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 6.1.2