kowさんは天ざる大好き

創作に絶望すると、世界が反転した日記

月例去人たち活動報告会@ニコ生(2016/04/29) - シーズン1最終回

今月のニコ生

2016年04月の月例報告会をニコ生で行います。
これまでの月例報告会をシーズン1とし最終回になります。
今後は、定期的に活動を報告できるようになったら、シーズン2としてやっていこうとおもっています。

■日時

 2016/04/29 (金) 22:00 ~

■ニコ生チャンネル

 美の去人たち-ニコニコミュニティ

■参加

■内容

  • 去人たちプロジェクトは Enty をはじめるようです
  • 創作にいかす芸術鑑賞のコーナー
    • kow@suhito担当
      ピュリツァー賞 受賞写真 全記録 - ハル・ビュエル
    • nitino担当
      未定
  • ユーザ質問など
  • 雑談など

事前に質問などがあれば、コメントや @kyojintachi でおねがいします。


ピュリツァー賞 受賞写真 全記録

ピュリツァー賞 受賞写真 全記録

続きを読む

去人たちをプレイしたら精神科を受診しよう!~実践編~

K2Ceeの同人デジタルノベルゲーム『去人たち』を愛してやまない、ちょっと様子がおかしい方々、いかがお過ごしでしょうか。
いえいえ、あたしへのお気遣いありがとうございます。あたしは何の問題もありません。万事オーケー、ノープロブレム。よろしくやってます、ええ、大丈夫です。完全にクリア、オールグリーンな状態です。ええ、ええ、お気遣いありがとうございます。

今回は、みなさんお待ちかね
去人たちをプレイしたら精神科を受診しよう!
の実践編です。
今回は実践編ということで、久しぶりに精神科を受診してきましたので、それについて書いていこうかと思います。

ああ、この記事ずっとまってたよね!
という方は大変多いのではないかと思います。
大変お待たせしてしまったようで、あいすみません。

今回は、去人たちZERO-prologue-もリリースしたということもありますので、ユーザの皆さまのメンタルヘルスを自身で配慮していただこうという趣旨で、この記事を書こうと思います。
今後、去人たちという完全なる虚構の作品では精神、幻想、現実を虚構なりにテキトーに記述されていますが、今後リリースされる『去人たちの続編』も同様の傾向がありますので、注意喚起と親愛なるユーザへのサポートの意味があります。
あ、でも、こういうと誤解されるかもしれませんね。
きちんと行っておいた方がいいかもしれません。

『去人たちをプレイしたせいで気がくるったじゃないか!』

とクレームをつけられても困ります。
わたしたちに、あなたがたの気を狂わすほどの能力はないのです。間違いなく。
気が狂っているのはあなた方だけの問題で、あたしが気が狂うのはあたしたちだけの問題です。

ということですので、K2Ceeといたしましては、去人たちをプレイしたことでメンタルヘルスに著しい変調を来しても一切責任を負えません。

前書き

この記事は虚構みたいに見えますが、精神科受診の実践的で現実的な内容です。
ですので、歌穂*1のような女子高生の無免許精神科医はでてきません。
誰か死んだりするような話もでてきません。
精神科を受診するというはなんにも難しいことではなくて、気軽にいけるということ、そして精神科にあらぬ幻想を抱いても幻滅するという話です。

前提として:「死にたい」なら「死にたい、イエイ!」と言おう

抽象的に書きすぎると日記文学だと誤解されて虚構化されるので、事実を簡潔に書いておいたほうがいいかもしれない。
まず、「自分がそう感じている」ということは事実です。誰がなんと言おうと。
誰かが「甘えだ」と言ったとしても、問題はまったく別です。
神みたいな存在がいて、完全に公平に判断した上で「あなたのは甘えですね、たいへん遺憾ですが……」という事態になっても気にしなくていいです。
いま、自分がどう感じているか、まずそれだけをきちんと言葉にすることです。偏りのない気持ちはありません。そして、自分がどう偏っているかなんて気にしないでオーケーです。

kow@suhito/14歳のカルテ

  • 社交的な場が大嫌い
  • 混雑したところが大嫌い
  • 人前で話すことが苦手
  • 人の視線が恐い。社会的に非難されないな範囲で目線を合わせない
  • 『ルール』はゼッタイ守るべきだと思う
  • 過去に、抑うつで精神科を受診し、主にSSRIによる薬物療法寛解
  • ただし、慢性化した抑うつの自覚症状がある
  • 今回はパニック発作で精神科を受診することにした(←いまここ)

パニック障害のはじまり

朝の満員電車、急行。身動きがとれないほどの混雑。
「朝だるし、やる気無いし、人多くて嫌だなあ。毎日毎日、こんなこと繰り返して何になるんだろう。はあ……」
これの繰り返し。繰り返しのなかで徐々に、奇妙な違和感が入り込んでくる。
「ん? 心臓がばくばくしてる? 手汗。指先がふるえる。二日酔で脱水症状かな。水分足りてないかな」
身体症状だけでなにか自分では納得していて気付いていなかった。一番問題だったのは言葉にできなかった「説明できない不安感」である。

はじめてのパニック発作

朝の満員電車、急行。時間ぎりぎりの電車に乗る。身動きがとれないほどの混雑。
「はあ……、今日はぎりぎり。しかも、やりたくない仕事ある……」
動悸……胸のつかえ……手汗……、調子悪いなあ。
坂を転がり落ちる石……まさに、あんな感じ。速度をあげてどんどんと転げ落ちていく。
自分の乗車している車両の輪郭がはっきりと意識される、密閉された空間の中で自分の意識と鼓動だけが肥大化する。
自分はそこから逃げることできず、理由もない不安感に支配され。首に縄をくくりつけられて、ぎりぎりつま先立ちしながら耐えている、そんな感じ。
新鮮な空気を吸いたい、両手を伸ばして、自由に身体を動かしたい、電車降りたい。
そして、先行車両がつかえて、電車は停滞中。
脱出できないこの状況、混雑、閉鎖空間。
立っていらないほどの動悸、そして不安感。全身に冷や汗。手足の指先が、ふるえて痺れてくる。認識できる視野は狭まる。満員電車でしゃがみ込むこともできないので必死につり革にすがりつく。
それでも、ずっと考えていたのは、
この電車逃したら遅刻する、なんとか、もう少し……
ということだった。
降りればいいものを、降りずに我慢して、目的の駅で下車。閉鎖空間から出て、深呼吸する。転げ落ちた坂をゆっくりと元の状態にもどっていく。
でも忘れることができない悪夢のようにずっと、一日その恐怖感はつきまとっていた。

極力電車通勤はやめようと、決めた。

そのときの病識

自分の症状がパニック障害という認識はあった。
だが、そのときは精神科を受診しようとは思わなかった。
たまたま、調子が悪いだけだ。必ず発作が起こるわけではないし。
満員電車で閉鎖空間でないことを認識しなければまだなんとかなっていた。
深呼吸をし、素数を数えれば、短い時間だがそこが閉鎖空間であることを忘れることができていた。

パニック発作の発動条件が追加されました

はじめての発作から、2ヶ月ほどたった。
相変わらず、満員電車の状況では大小の程度はあれ、発作が起こった。
発作の経験頻度が多くなっていくことで、いわゆる「予期不安」が生まれ、それが発作をさらに起こしやすくしていった。
状況は悪く進行していて、それを裏付けるように発作の発生状況が追加された。

  • 行列ができるほどの人気がある飲食店
  • 床屋

おいしいものを食べるのが好きで、いろいろ食べ歩いていたので、これはライフスタイルに影響した。
床屋もがっちり逃げられない状態で死にそうになりました。

発動条件

「○○○しなければならず、それが完遂するまではその状況から退避できない空間」にいるときに発作がおこる。
しかも、それは自分以外の対象が関わっている。
満員電車では、自分以外の乗車客、飲食店では、店員とお客、床屋では理髪師。
自分以外の対象が「自分に求めていること」を自分で勝手に規程し、自分はそれ以外の行動をとってはいけないと思い込むことで「逃げられない」状態を関係的に作り出している。そこに閉鎖空間という知覚的な認識が加わるとばっちり発作が起こる。

精神科を受診してみよう

これまでの慢性化した抑うつは、「障害」ではなかった。それとの付き合い方を分かるようになっていたし、ある程度共存共栄していると思っている。
だが、パニック発作の症状は「障害」だった。
この「障害」の解決策は精神科は受診だと判断した。でも、精神科受診は本当はできればしたくなかった。
なぜ、精神科をしたくなかったか

  • 暗澹とした待合室
  • やたら長い診察待ち時間
  • 薬物療法を開始すれば、経過が良好でも断薬まではとてもつもなく時間がかかる。(受診の時間的コスト、費用的コストは馬鹿になりません)
  • 歌穂みたいなとんちきな精神科医がいないので面白くない精神療法がない

そもそも病院が好きという人は少ないと思うが、その中でも精神科の待合室の雰囲気は最悪だと思う。
まるで自分が重病人のような気持ちになってしまう。あの場所にいるだけで、ありもしない自殺願望が生まれてくる。
でもすべての精神科が「暗澹とした待合室」や「やたら長い診察待ち時間」という訳ではない。こざっぱりしたクリニックで予約制のところを選べば大丈夫。都市部ではメンタルクリニックは多くホームページを確認してみよう。ただ地方になると、クリニックを選ぶほど多くないかもしれないが「予約制」があるとないとでは待ち時間がちがうので、できるだけ予約制のところをおすすめしたい。
あたしが今回受診したクリニックは明るくきれいで待合室もプライバシーに配慮してあって本当に関心してしまった。
予約制なので待ち時間も少なく、心理的な負担も少なかった。

次に神経症、うつで精神科を受診した場合、治療方針は薬物療法になるとおもっていいと思います。(※統合失調症のように精神療法も重要なケースは違うのかもしれません)
診察の中で心理学用語や精神分析用語などでてこないので安心してほしい。(そもそもクライアントに専門用語つかわないと思いますが……)
精神療法を希望するなら、心理カウンセリングという方法もあるかと思います。値段クソ高いですが。

ザ・初診

さて、これらの状況を念頭に初診に臨めば診察はスムースに進めることができると思います。
クライアントは精密機械でドクターはそのメンテナンス係のようなものです。
ドクターは機械の調子が悪い部分を推測して、ネジを締め直したり、オイルを差したりしてくれます。
ただ、スパナやオイルの代わりに向精神薬を使うだけです。

ですので、診察では、

  • 混雑した電車で動悸がして、冷や汗がでて、立っていられなほどしんどくなる
  • 人に怒られると死にたくなる
  • 天井に誰かがいていつも自分を監視している

などようにはっきりと自分が感じていること伝えましょう。
ドクターとはいえ、そんな今まで誰にも打ち上げたことがないことを初対面の人にいきなり言えないと思うかもしれません。
であればまず話せるところだけでも、断片的でもいいです。

なんども言いますが、ドクターは精密機械のメンテナンス係程度です。
「クライアントの気持ちに寄り添って、心理的な根本原因を見つけ出し、解決してくれる」などと思っていると失望するだけです。
メンテナンス係は、30分未満の時間で効率よく精密機械の調子を確認して、今のメンテナンス方針に間違いがないかを確認するお仕事の人です。

もし、自分の心理状態や会社の口や人間関係のストレスを聞いてくれ、アドバイスしてくれるドクターを探すなら、たくさんのクリニックを試すしかないと思います。
そしてそんなことを聞いてくれるドクターがいたとしても、Yahoo知恵袋と同程度のアドバイスしかかえってこないかもしれません。
完全なメンテナンス係を決め込んだドクターの場合は、アドバイスどころか、逆に冷たい目で蔑むように見られたうえに、説教されることもあります。
そんな場合は、藪医者!といって怒鳴って診察室を出ましょう。


あたしが今回の初診でドクターに話したことは簡潔。

  • 自分のざっくりしたプロフィール
  • 現在の生活に関する情報
  • 過去の病歴(既往歴)
  • つらいと思っている症状
  • その症状がではじめた時期
  • 他に飲んでいるクスリ

調子が悪くて診察をうければ、何科を受けようと問診があるものです。
精神科ではそれに心理面に重点をおいたプロフィールや、現状の生活環境のヒアリングが追加されるだけ。
これらは、対話のなかでやりとりしてきますが一通り話し終われば、ドクターが所見と治療方針を説明してくれます。
こんな感じ

どう、精神科の診察はなにも特別なことないでしょう?

あたしの場合、うつについては現状のままにしておき、とんぷくとして抗不安薬を服用しましょうとなりました。

通院治療

あとは通院治療です。
これも精神科だからってなにか変わったことはありません。

  • 症状が改善したか
  • クスリの副作用はあったか

症状が改善していれば、継続して経過をみる。
症状が改善しない、悪化している、または副作用がつよければ、別のクスリに切り替えてみましょうとなるだけです。
精神科はクスリを複数組み合わせて処方して、それの飲み合わせであーだこーだがあるようなので、経験がものをいいます。
薬物の処方は職人技なのかもしれません。

あたしの場合は、抗不安薬の服用で症状は完全になくなったわけではないですが、発作が起こらなくなったので、変化がなければこの対処でいくことになりました。

長期的なプランを確認しておくとなお良し

安定したところで、長期的な治療プランを聞いてみましょう。
理想は、減薬からの断薬です。
根本原因を解決しないでこれができるのは、環境が改善した場合、器質的な原因による場合です。
減薬、断薬の話をしても、合理的な返答をされないのが当然ですが(そもそも対症療法しかしないので)、もしきちんと返答してくれるドクターはけっこういいなあと思います。

まとめ

精神科というと、いわゆる心理カウンセリングをイメージする人がいるかもしれませんが、症状を緩和させるお薬を出してくれるところです。
精神科のドクターは、多種多少なお薬の調合師で、絶妙な配分でお薬をして問題を解決しようとします。
一方で、心理的問題を抱えたクライアントは、薬物療法に疑問を持つと思います。自分がいましんどいのは、自分がダメな人間だからとか、宇宙的規模の運命の人と死別したからだとか、小学生以下の女の子にしかなにも感じず衝動が抑えきれないとか、クソ上司のパワハラのせいとかによるもので、ドーパミンとかセロトニンとかアンフェタミンとかなんだか知らないがそんな見たこともない脳汁のせいではないと感じるからでしょう。
精神科のドクターはクライアントの環境に干渉することはできません。ですから、クライアントがそれぞれに訴える過酷な環境下の中でも症状が緩和される、あるいは悪化しないようなクスリを処方するだけです。
さらにいえばドクターにとって「根本的な問題を解決したら、患者がいなくなってしまう」という経済上のデメリットがあるので、わざわざ精神療法という治療点数に見合わない多大なコストをかけてまで治療してやるつもりはない――ってのは、あたしの穿った見方でしょうか?

だから、大事なのは次に述べることです。
人格障害なり精神障害なり診断名は置いておいて、「つらい」と思うことに対して、薬物療法は一定の効果があるのは事実である。
その関係性を理解してスマートに精神科を利用しましょう。

SlackにGoogleアナリティクスのレポートを自動通知するようにしました

去人たちZERO-prologue-をリリースしたとなっては、あとは効果測定フェーズである。
効果を測定して陰鬱とした気持ちになるかどうかは別にして、冷静に数値を確認して今後に活かすのは大事です。
この「効果測定は陰鬱とした気持ちになる」という心理的理由は認めましょう。

制作者はいろいろな気持ちをもつことでしょう。
「何百、何千時間をかけて作ったのに……」
「めっちゃ金かけてつくったのに……」

でも、そういう現状は、作っていた者の「目的」がちくはぐであったり、あるいは、その目的を達成する「手段」が効果的でないからではないでしょうか。
この2つと照らし合わせて、効果測定はしたほうが、損得でいったら得です。
目標値がわかれば、開発も楽しくなります!

心理的抵抗にツールで適応する

google アナリティクスのダッシュボードにはいって結果を確認するという、日々の作業。効果が上がっていないことを毎日目にするのはつらい。
これをSlackに自動投稿するようにすることで、気軽に確認できるようにします。
自動投稿されるので、「毎日確認」することで、問題を常に意識するようになります。心理的抵抗に対しての1つの解決策です。


K2Ceeでは5つのサイトを管理しているので、それぞれGoogleアナリティクスのレポートをSlackに自動投稿するようにしました。
下記の記事を参考にさせていただきました!

datahotel.io

設定する

Googleアナリティクスを導入していて、レポートを自動投稿するようにする対象サイト


プロジェクトのSlack のアカウントを用意します。

slack.com

Googleアナリティクスの結果をSlackに流してくれるStatsbotを利用します。

Statsbot

f:id:kowasuhito:20160327114159p:plain

「Add to Slack」から先に登録したSlackアカウント指定して、statsbotがアクセスするGoogleアナリティクスのアカウントを指定すれば登録完了。
Slackに @statsbot ちゃんがジョインしたことを確認しましょう!

f:id:kowasuhito:20160327114656p:plain

Googleアナリティクスの自動投稿をまとめたチャンネルを作ったほうがいいかなと思ったので、
#ga-reports というチャンネルをつくって @statsbot をチャンネルに参加させました。

定期的に投稿してくれるように設定します。
#ga-reports チャンネル上で @statsbot と対話しながら設定していきます。


複数サイトを管理している場合、対象のサイトを指定する
f:id:kowasuhito:20160327115604p:plain

ここではK2Ceeサークル公式サイトを対象にしました。

毎日、過去7日間のサマリーレポートを通知するように設定する。
(おのおの興味ある期間で設定すると良いと思います)

f:id:kowasuhito:20160327120250p:plain

これで、毎日朝、6:30に K2Ceeサークル公式サイトのサマリーレポートがSlackに自動投稿されるようになります。
他の管理サイトも登録するには最初の手順の

@statsbot setup

で対象サイトを変更して、同じ事を繰り返します。

ツールで全ては解決しない

もちろんですが。
心理的抵抗はそもそも何故あるのか? そのためにプロジェクトを見直してください。
そしてどうして効果がでないのか。そのために自分のプロダクトを見直してください。
これは同人サークルじゃなくても、多くのスペシャリストが今も試行錯誤しています。

スクラム開発について勉強しよう!

ある時、ぴこーん! となりました。

同人サークルでもスクラム開発できないかなあ。

でもスクラム開発のことは、小さなチームで短い期間でがんがんリリースするから差分少なくて安全な開発ぐらいにか考えてなくて、
きちんと勉強したほうが良さそうだなとおもって、早速本をかって勉強してみました。


スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)


個人的なメモっぽくなってしまいましたが、
スクラムをまったく分からない人が、ざっとみるだけでも、スクラムの雰囲気が伝わってくる……といいな。
なぜ、スクラム開発なのか、どのようにスクラムチームを作るのか、スクラム開発は実際にどうやるのか、参考になれば。

ソフトウェア開発は困難すぎるけど、それをスクラム開発で立ち向かう!

ソフトウェア開発が困難ってどういうことだろう。
困難さを理解することで、その困難さにたいしてどのように「スクラム開発」が適応するかが分かる。

ソフトウェア開発における困難

  • 本質的な困難の4つの性質
    • 複雑性
      ソフトウェアが、人間の作り出す最も複雑な構造物であること
    • 同調性
      ソフトウェアが、現実世界の複雑性に対して同調(適応)する必要があること
    • 可変性
      ソフトウェアが、常に変更という圧力にさらされていること
    • 不可視性
      ソフトウェアは、目に見えないものであり、空間に埋め込むこともできないものであること
  • さらにこれらの本質的困難は解決不可能
  • 不可視性という困難のために、開発者が複雑性に対処することがますます困難になり、さらには、変化し続けるソフトウェアを前にして、コミュニケーションに齟齬が生じてしまう。

不可視性によるさらなる困難

  • ソフトウェアの不可視性:ソフトウェアの汎用性
    開発する側にとってもユーザにとっても、機能的な広がりの限りのなさゆえに、その領域を確定しがたいという困難
  • コミュニケーションの不可視性:ビジョンへの時間の影響
    新鮮なビジョンに基づく、緊密なコミュニケーションとともに始まったソフトウェア開発において、時間が経つにつれ、当初の目的が次第にないがしろにされていってしまうのは、人間は物事を確実に記憶にとどめておくのが難しいという至極当然の理由による

では、この目に見えないソフトウェアとはどこにあるか

  • ソフトウェアは人々の心の中に
    それぞれの視点、立場、趣味嗜好、自己の能力や経験の範囲でソフトウェアを認識している
  • ソフトウェアは人々のコミュニケーションの中に
    各人の心の中に独立して存在する思いが、集団作業というコミュニケーションを通じて、時には齟齬をきたしたり衝突したりしながら、ソフトウェアの輪郭をおぼろげながらも浮かび上がらせる。

ソフトウェアの困難に立ち向かう

  • 5W1Hによる問題の分解、整理
    • 誰が
    • 何を
    • いつ
    • どこで
    • なぜ
    • どのように
  • 5W1Hでわかること
    5W1Hにより切り出される下位問題にきちんと回答を与えられれば、最終的な問題にも、実現可能性の高い回答が与えられる
  • Whatとしてのソフトウェア
    5W1Hで分解、整理して得られた、Whatに関する下位問題を解決することは、ソフトウェアの見えなさに対する解決を与える事
  • Howとしての開発プロセス
    コミュニケーションは目に見えないという問題に解決を与える事

スクラムとは何か

  • スクラムの定義
    複雑で変化の激しいもな痔に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるものである。

スクラムで複雑で変化の激しい問題に対応する

  • 目的の不可実性、手段の不可実性
    • 目的の不確実性:最終的なプロダクトのフィーチャーを取り巻く不確実性
    • 手段の不確実性:プロダクトを開発するために用いられるプロセスやテクノロジーを取り巻く不確実性

この不確実性に対処する必要がある。

  • スクラムは、複雑で変化の激しい問題に経験主義で対処する
  • 経験主義に基づく問題解決のための反復的かつ漸進的な手法
  • スプリント - 時間を一定に区切って反復する
    スプリントは1週間から長くて1ヶ月。スプリントの最後には「スプリントレビュー」「スプリントレトロスペクティブ」と呼ばれるイベントを行い、計画遂行に対する評価を行う。複雑で変化の激しい問題においては、事前に何を作るべきかがすべて明らかになっていることはない。そのため内容によって工程を区切るのではなく時間によって区切り、繰り返し、少しずつ作成物を積み上げていく。
  • WhatとHowにおける検査と適応
    検査は、開発の結果としての作成物や開発プロセスに問題がないかどうかをチェックすること。適応は、もし問題があるとすればその解決を図ることでより良い開発を行えるようにすること
  • スプリントレビュー
    スプリントを通じて何を作り上げることができたのか、あるいはできなかったのかを検査し、その解決を図るイベント
  • スプリントレトロスペクティブ
    開発プロセスに問題があるとすればそれはなんであったのかを検査し、解決を図るイベント
  • スクラムにおける役割
    • プロダクトオーナー - What を担う
      開発チームの作業とプロダクトの価値の最大化に責任を持つ。環境の複雑さの矢面に立ち、作り出すべき何かを確定する
    • スクラムマスター - Howを担う
      スクラムの理解と成立に責任を持つ。変化の激しい環境にさらされるスクラムチームが、多種多少なコミュニケーションを通して開発に取り組む上で、スクラムという開発プロセスを用いて、より円滑な開発を行うことを支援する。



スクラムチームとは何か

  • 自己組織化とは
    システムダイナミックスの分野において、ある系が自ずから、不規律な状態から規律をもった状態へと、進化、変化していく様を表す
  • スクラム文脈での自己組織化
    自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態。
  • スクラムチームのロール
    • プロダクトオーナー
      スクラムチームが作ろうとしているプロダクトの最終責任者
    • 開発チーム
      プロダクトオーナーが決めた要件を、プロダクトオーナーが要求する順番に従いプロダクトを実現
    • スクラムマスター
      プロダクトオーナーと開発チームによるスクラムの実行を支援し、組織へのスクラム導入を支援する

プロダクトオーナー

  • プロダクトオーナーは1人
    1人にすることで責任を明らかにし、何を作るべきかやその優先順位を確実に決定する
  • 開発チームからの独立
    開発チームから独立させることで、スクラムチームが作ろうとしてりうプロダクトに妥協せず、かつ価値の最大化に努めることが可能となる
  • プロダクトの完成に関わることはプロダクトオーナーだけがステークホルダーとやりとりを行い、作成するプロダクトの内容や要件の優先順位づけについてはプロダクトオーナーの責任で決定する。
  • 要件の決定
    プロダクトを価値あるもにとするために要件を作成、決定する。要件は優先順位に従って開発チームが作成する。作成されたプロダクトが決定した要件を満たしているか確認する責任がある
  • 優先順位の管理
    スクラムチームが実現すべき内容の優先順位の決定権は、プロダクトオーナーのみが有する。

開発チーム

  • 開発チームとはなにか
    プロダクトオーナーが決めた要件を、プロダクトオーナーが要求する順番に従って、プロダクトとして作り上げる専門家集団
  • 開発チームは3人~8人
    これ以上多いと、コミュニケーションパスが多くなる
  • 機能横断的チームであること
    機能横断的チームとは、チーム以外に頼らずに作業を成し遂げる能力を持っているチームのこと。
  • 全員「開発者」
    プログラマ、デザイナといった職種により区別されない。お互いの作業内容に壁を作らずに、協力しながらプロダクトを作り上げる
  • リリース判断可能なプロダクトの開発
    作成しているプロダクトをブラウザ上のデモとして動作させたり、プログラムの処理結果を表示させたりすることで、プロダクトオーナーにリリースできるかどうかを確認してもらう。

スクラムマスター

  • プロダクトオーナーへの支援
    プロダクトオーナーの優先順位の更新方法、ビジョン作成のためのワークショップなどを開催し支援する。
  • 開発チームへの支援
    開発チームが未熟な場合に、品質、自己組織化などをアドバイスする。
  • 組織全体への支援
    スクラムチームに他チームの作業を兼務させたり、プロダクトオーナーに決定権がないなどの問題があれば、勉強会などを設けてスクラムの方法を組織へ伝える



スクラムイベント

  • 5つのスクラムイベント
    • スプリント
    • スプリントプランニング
    • デイリースクラム
    • スプリントレビュー
    • スプリントレトロスペクティブ
  • スクラムイベントを通して透明性を確保する
    スクラムチーム全員で現状への共通理解を得る。透明性とは、プロダクトの状態やスクラムチーム現状などの重要な情報を誰でも入手できるようにすること。
  • 検査と適応で変化に対応する
    透明性で明らかになった情報をもとに、問題を検知し対応すること。

スプリント

  • スプリントとは何か
    スクラムでの開発期間の1単位。スクラムチームは一定の期間のスプリントを繰り返し、その中でスクラムイベントや開発を行う。期間内はスクラムチーム全員がゴール達成に向けて集中することが重要。スプリントの期間は1週間から1ヶ月。もしスプリント期間内に予定していた仕事が完了していなくてもスプリント期間は延長しない。完了した仕事量を計測し続けることで、スクラムチームがスプリント期間で完了できる仕事量を推測できるようにする。
  • タイムボックス
    1週間のスプリント期間のように固定された期間のこと
  • 通常のスプリント - リリース判断可能なプロダクトを作り続けるスプリント
  • スプリントゼロ - 開発を始めるための特別なスプリント
    開発の前段階を「スプリントゼロ」と呼ぶ
    • ビジネスモデルの仮説を立てる
      顧客の課題を解決してビジネスとして成立するであろう仮説を立て、検証しながら、見込みユーザと関係を作ってプロダクトを育てる土壌をつくる
    • プロダクトを作る理由と実現方法を明らかにする
      • プロダクトを作る背景や理由
      • 期限内に達成したい目標
      • プロジェクトの関係者とのコミュニケーション手段
      • 実現するためのアーキテクチャ
      • 目標を達成するための体制
      • おおよその予算とスケジュール
      • リスクと対策
    • チーム作りのワークショップを行う
    • 開発環境を準備する
      • Pull Requestベースの開発ができる環境
      • ユニットテストからエンドツーエンドテストまでの自動テスト環境
      • CI環境
      • HipChat/Slackなどを使った、人と人、人とマシンのコラボレーションを加速させるチャット環境
      • Chef/Pupperなどのインフラ構築の自動化環境
      • Capistrano/Fabricなどの自動デプロイ環境
    • プロダクトバックログを準備し、完成の定義を決める
      プロダクトバックログとはプロダクトで何を実現すべきかを優先順位を決めて一覧化したもの
  • リリーススプリント - リリースをやりきるための特別なスプリント
    リリーススプリントでは機能の追加や修正は行わない。リリース作業のみ
    • 各スプリントで積み残したテストの実装
    • 各スプリントで積み残したドキュメントの整理
    • リリースのリハーサル
    • 本番へのリリース
    • プレスリリースの発行
  • リリース後にスクラムチームやプロダクトを見直す

スプリントプラニング - スプリントの計画を作る

  • スプリントプラニングとは何か
    スプリント開始時に「スプリント期間内で何ができるか」「どうやって達成させるか」の2点を明らかにさせるミーティング。スクラムチーム全員が参加してみんなで計画を立てる。スプリントプラニングもタイムボックスを設けて実施。スプリント期間が1ヶ月であれば最大8時間、スプリント期間が1週間であれば1~2時間が目安。
  • リファインメント - スプリントプランニングの準備
    次のスプリントで開発に着手できるように、プロダクトバックログを整理する活動。スプリングプランニングの数日前までに実施。
  • リファインメントでプロダクトバックログを更新する
    スプリントレビューなどのフィードバックで新たに発見した要求について議論し、必要に応じてプロダクトバックログに追加したり、優先順位を入れ替える
  • リファインメントでプロダクトバックログアイテムの見積もりを行う
    ※プランニングポーカーは良く利用される
  • リファインメントでプロダクトバックログアイテムの内容を具体化する
    着手しやすいように手頃なサイズに分解したり、内容を具体化しておく。
  • 直近のスプリントで着手予定のプロダクトバッグログアイテムを具体化することができれば、リファインメントは完了
  • ベロシティに基づくスプリントゴールの設定
    スプリントゴールとはスプリントで達成したいことやプロダクトバックログアイテム。ゴール設定はプロダクトバックログの優先順位の高い順にスプリント期間で完了できそうな範囲を選ぶ。達成可能かどうかはプロダクトオーナーと開発チームで会話。
  • ベロシティ
    スプリントゴールを設定する際に利用。1スプリントにスクラムチームが完成させられる作業量のこと。過去の実績からベロシティは算出。
  • スプリントゴールの合意
    完了したスプリントバックログを俯瞰し、達成可能なゴールなのかをあらためて開発チームで判断する。スプリントゴールは、プロダクトオーナー、開発チームの双方が納得いくものにする。

デイリースクラム - 日々の進捗、予定、問題を共有する

  • デイリースクラムとは何か
    1日に1回15分間のタイムボックスで、進捗、予定、問題の共有を行うミーティング。開発チームとスクラムマスターが参加。
  • 明るく元気な声であいさつ
    表情の明るさや声のトーンはプロジェクトがうまくいっているかの指標になる。元気のないメンバーはサポートする。
  • 昨日したこと、今日やること、困っていることを話す
    特に困りごとや不安に感じていることを積極的にはなし、協力を仰ぐ。
  • 日々のデイリースクラムを通じてスプリントゴールを達成できそうか開発チームで確認する
  • 時間内に終わらなければ二次会を開催する

関係者に絞って、デイリースクラムの直後に臨時のミーティングを開く。

  • 達成がむずかしい場合は、プロダクトオーナーに相談

スプリントレビュー - スプリントの成果を確認する

  • スプリントレビューとは何か
    スプリント期間中に作成したリリース判断可能なプロダクトであるインクリメントの確認を行い、フィードバックを得るためのミーティング。スクラムチーム全員で開催。タイムボックスはスプリント期間1ヶ月で4時間、1週間であれば1時間程度が目安。通常、スプリント最終日に実施。
  • スプリントで達成できたことの報告
    開発チームはスプリントゴールで完成したもの、完成できなかったものを説明する。完成でできなかった場合は、理由と今後の対策も説明する。
  • 動くソフトウェアでデモをする
  • インクリメントの受け入れ確認
    プロダクトオーナーは開発チームがデモしたインクリメントを受け入れるか否かを判断する。受け入れられない場合は開発チームに理由を説明する。
  • インクリメントに対するフィードバックを得る
    目標達成のために何を優先するか軌道修正する
  • 今後のスプリントでつくるものの議論
    フィードバックをもとに、プロダクトバックログアイテムの追加、優先順位の入れ替えなどを行う

スプリントレトロスペクティブ - 仕事の進め方を改善する

  • スプリントレトロスペクティブとは何か
    スクラムチームが自分たちの現状を見直し、次回以降の仕事の進め方を改善するためのミーティング。開発チームとスクラムマスターでスプリントレビュー後に開催する。タイムボックスを設け、スプリント期間が1ヶ月であれば3時間、1週間であれば30分から1時間が目安。
  • 仕事の進め方の見直し
    スプリント期間中の仕事の進め方をふりかえり、みんなで共有する。「良かったことや続けたいこと」、「困ったこと改善した方がよいこと」に注目して話す。
  • 仕事の進めたの合意
    話し合いで上がった、良いこと困ったことを受けて改善案を出す。「問題の原因は何か?」「いつ、どこで、誰が、何のアクションをとると困りごとが解消できるか?」を話し合い、次のスプリントで実施する。



スクラムの作成物とはなにか

プロダクトバックログ - 何を実現するかの一覧

  • プロダクトバックログとはなにか
    プロダクトで実現したいことの優先順位をつけた一覧。プロダクトオーナーがその内容と優先順位に責任を持つ。
    メリット
    • 開発チームが作成すべき機能の全体象があきらかになる
    • プロダクトに必須となる機能から順に完成できる
    • 限られた期間の中で作成すべき機能を厳選しやすい
  • 意志決定可能なプロダクトバックログの作り方
    • プロダクトバックログアイテムの内容を完結に表現する
      ユーザストーリーで、「誰のため」に、「何を作る」か、「必要とされる理由」を記述する。
    • 見積もりを記載する
      見積もりの責任は、開発チームにある。
    • 優先順位を用いて1列に並べる
      優先順位が高い順に開発していく
    • プロダクトバックログの内容を見直す
      フィードバックを通じて、追加、削除、順序入れ替えをし鮮度を保つ。

スプリントバックログ

  • スプリントバックログとはなにか
    スプリント期間で行うと判断したプロダクトバックログアイテムを実現するためのタスクを俯瞰できるように表したもの。開発チームが責任を負う。
    メリット
    • スプリントゴールに対して、開発チームとして何をすべきかを議論できる
    • 現在どのタスクが完了して、どのタスクが完了していないかを俯瞰できる
    • タスクの進捗状況から、開発チーム全体の雰囲気や調子の良し悪しを確認できる
  • 実現可能なスプリントバックログを作る
    • プロダクトバックログアイテムを実現するためのタスクを洗い出す
      1つ1つのタスクは開発チームの誰もが理解でき、具体的な行動がとれるほど詳細で、課題に対処する際に議論可能な内容にする
    • タスクの進捗を可視化する
      タスクの担当者、期日、進捗を妨げる障害は何かを開発チームで常に把握する。
    • スプリントバックログを見直す
      日々の開発を通じて、追加、更新、削除する。必要があればプロダクトオーナーと相談する。

インクリメント

  • インクリメントとはなにか
    開発チームがスプリントごとに作成するリリース判断可能で利用可能な動作するプロダクト
    メリット
    • 開発チームが作成した機能差分を視認でき、進捗が明確になる
    • 実現方法が不透明だったプロダクトバックログアイテムの実現方法が明確に
    • 現時点のプロダクトをリリースするか否かの判断を行える
  • リリース判断可能なインクリメントの作り方
    • 常に動く状態に保つ
      CIツールなどで常に動作各員できるように。チームメンバーだけでなく、ステークホルダーも触れるように。
    • 完成の定義を守る
      完成とはスクラムチーム全員が納得し、ユーザへいつでもリリースできる状態。完成の定義はスクラムチーム毎に取り決める。



さて、では、これをどう同人サークルの開発にいかすのか

ネット上で分断されて共有した時間を取ることが難しい同人ゲーム開発について
スクラム開発ツッコミどころ満載になりそうです。
また、これについてはまた記事にできたら。

去人たちZERO -prologue-リリースしました!!

K2Ceeは本日2016/03/25に、去人たちシリーズの最新作となるデジタルノベル
去人たちZERO -prologue-
をリリースしました!!
フリーゲームですので、是非プレイしてみてください。

↓↓↓↓ ダウンロードはこちらから ↓↓↓↓
www.freem.ne.jp


■ストーリー

あの秋の2年前、新人のワタナベは舎密部警保局捜査1課に配属されることになった。
ワタナベは舎密部警保局諜報課によってはじめから結論が決められ形骸化した捜査にうんざりしていた。
そんなとき、ワタナベは捜査1課課長の斑猫に声をかけられコンビを組まないかと持ちかけられる。
なぜ新人の自分とを訝しむがワタナベではあったがそれを了承する。

それからしばらくして、ワタナベに内偵の命令が下る。
膨雀高校2年の重村が『ネットセクト』と関わりがあるのではないかという疑いがあった。
『インターネットが停止した日』以後、各国で濫発されたネット規制法案に反発、抵抗したハッカー集団の残党、それが『ネットセクト』だ。
もし、重村が『ネットセクト』と関係があるなら舎密部が適切な方法で『処理』する必要があった。
ワタナベは初めての校内内偵捜査を開始する。

■みどころ

まるで絵に描いたかのように豪華絢爛で、かつユーモラスMAXなイラスト!
心耳をときには優しく、あるときには壮烈に揺さぶる嘆美でパッショネートなハイグレードBGM!!
そして、流麗に惜しみなく垂れ流され続けるケレン味たっぷりで其れっぽいテキスト!!!

■ケイちゃんかわいいよ!

f:id:kowasuhito:20160325183452p:plain

■開発者から一言

去人たちZERO-prologue-の開発はみなさんの協力があってこそリリースすることができました。
本当にありがとうござました。
プレイしてみての感想、批判、ダメ出しなんでもあったら
去人たち公式(去人たちZERO公開中) (@kyojintachi) | Twitter
にいただければと思います。
どんなリアクションでも、本当に今後の開発の励みになります!
続編の『去人たちZERO本編(仮』もがんばります!