下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・個人開発の瓦礫の記録

XP祭りで開発高速化の話をしました #xpjug

概要

XP祭り2017に参加して「新米エンジニアがレガシーシステムを死に物狂いでグロースハックした話」というタイトルで発表しました。

イベントについて

アジャイル分野の方々が参加するイベントだそうです。 他の方々の発表は以下のページにまとまっています。

XP祭り2017

発表スライド

当日の資料は以下になります。

すでに新米ではないのですが、当時を振り返るとアジャイルプラクティスを(結果的に)適用していた!ということで、この機にケーススタディとしてまとめてみました。

CfP内容(一部抜粋)

グロースハックプロジェクトでの試行錯誤を共有します。

10年物のレガシーシステムにおいて、120の開発案件を捌き、 4ヶ月でユーザーアクション数を2.8倍にしました。

1つ1つボトルネックを愚直に解消していくことで、 気付いたらアジャイルのプラクティスが適用されている状態になりました。

http://xpjug.com/xp2017-session-a3-2/

ざっくり概要

  • ステークホルダー
    • 多様なステークホルダーからの五月雨の依頼に対して、結果的にスクラムのような開発プロセスで対応することになりました。
    • 1個流しで案件を捌き、その過程でリードタイムに影響を与える阻害要因(ボトルネック)を特定・排除することで、フロー効率の改善を図っています。
  • スキル
    • 新米状態から素早く一人前になるために、アーキテクト・プロダクトオーナー・リーダーのように振る舞いました。
    • 当然ながら上手くいかない→「何が足りないか」を把握できる→その差を埋める、を繰り返すことで、ハイスピードでスキルを向上させることができました。
  • システム
    • レガシーシステムに対して改善サイクルを回すために、まずはGit/Jenkins/SonarQubeといったツールを導入して、最低限の開発環境を整えました。
    • その上で、過剰な設計書フォーカスからソースコードフォーカスに移行したり、「よい設計」の共通認識を揃えながら徐々にシステムの複雑度を解消していきました。

ビブリオバトル

LT形式で書籍を紹介しあうコーナー。せっかくなので出てみました。

「システムは作って終わりではない」ということで、マラソンに関する科学がメタファー(あるいはアナロジー)として参考になるのではないか!と『マラソンの練習法がわかる本』をお勧めしました。

感想

  • 良い意味で変な人が多かったです。女装率が高い。LTは笑いすぎて腹が痛かった!w
  • 運営者の法被(?)が祭り感あって良いですねー。
  • 初めて来た人や遠くから来た人を優先して書籍プレゼントする、といった配慮が素敵だなぁと思いました。
  • 内容面で新しい発見は特になかったかなぁというのが正直なところです。プラクティスや原理原則はある程度固まっているように見受けられるので、パラフレーズのネタを増やすよりも、「いかにエンジニアの枠を超えたケーススタディを積むのか」が求められているのかもしれないと思いました。私が言えた話ではないのですが。

終わりに

運営者・発表者・参加者の皆様、本当にありがとうございました!

エクストリームプログラミング

エクストリームプログラミング

PyConJPでデータ分析基盤とチーム文化の話をしました #pyconjp

概要

PyCon JP 2017というカンファレンスに参加しました。 Day2の最終セッションにて「SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsした話」というタイトルで発表しました。

f:id:yuzutas0:20170912194610j:plain

イベントについて

実施風景や発表内容

togetterや他の参加者のブログで良い感じにレポートされているので省略。 「こういう観点の感想もあるのかぁ」といった発見があり、読んでみると結構面白いです。

他の方の発表を聞いて

よかったです! 小学生並みの感想ですが!

  • 分析ネタ系・作ってみた系:やっぱり面白い。ニコニコ学会や自由研究に通じるものがある。こういうの大好き。
  • 足りない機能をハックする系・中身を読み解くぜ系:プログラミング言語を触るってこういうことだよなー、みたいな良さ。

あとLT聞いて思いついたんですけどPythonで実装した彼女とマッチングするWEBサービスを(略)

とまぁ、技術カンファレンスは今回が初参加で、最初はどうしたものかという感じでしたが、想像以上に楽しめました。

発表について

スライド

当日の資料は以下になります。

CfP内容(一部抜粋)

多様な部署・職種が関わる大企業において、どのような目的・用途・制約が与えられ、そのためにどのようなシステム・プロセスを採用したのか共有します。

プロダクト開発におけるデータ活用の指針・参考事例を持ち帰っていただきます。少しでも多くの開発現場がPythonという武器を手に、データを最大限に活用し、世の中に良いプロダクトを提供する助けになれたらと思っています。

https://pycon.jp/2017/ja/proposals/vote/159/

アジェンダ

  • 分析基盤をDev&Opsする
    • データ利用のユースケース
    • 分析基盤が必要となった背景
    • 設計ポリシー・技術選定
    • データフロー(収集>蓄積>加工>活用)
    • 構築プロセス
  • データ駆動文化をチームに装着する
    • Measure:効果測定と開発工程
    • Learn:顧客理解とSECIモデル

いただいたコメントなど

ありがたいことに色々とコメントをいただきました。

「タイトルだけ見てスルーしてた」

「文化の話いいね」

言われてみれば。 タイトルから中身を想像できないですね……。 どういうのが良かったんだろうなー。

「Jupyterはバッチ処理を試すのに相性が良い」

なるほど。 明文化できていませんでした。 確かにそういうことですね!

「朝の何時までにデータを疎通しなければいけない!みたいな話を伺いたい」

サービスレベルとオペレーションレベルを設計・運用しています。 詳しくは以下を参照いただければと。

yuzutas0.hatenablog.com

今回の質問であれば、バッチ処理の機能要件に該当するトピックとなりますね。 このあたりはいわゆるSREトピックとして、他のシステムと同じように運用・改善を行なっています。

SREやDev&Opsとタイトルに付けた割には、構築後の運用保守に対する言及が少なかったのはミスでした。 「それっぽいシステムを作るだけなら誰だってできるよ!大変なのはその先だろうが!」と言われたらそりゃそうだ、という感じです。

まさにGood Questionというやつですね。終了直後にわざわざ話し掛けてくださいました。

補足(蛇足?)

システム面

  • 話を聞いた人は「そこまで大したシステムではない」と思ったはずです。自分でもそう思います。ただ、大したシステムは必要ないと考えています。だからこそ簡単に書けて便利なPythonを技術選定しました。
  • 半年後には違う姿になっていると思います。システムは生き物と同じで日々変わるので。特にワークフローエンジンの運用保守については強い課題意識を持っています。むしろぜひ助言が欲しいくらいです。
  • 「大規模データだ」「他と比べて大変だ」と言うつもりはありません。たかだか数年程度の若いサービスなので。
    • 技術制約として「この規模のデータだとN/Wレイテンシがボトルネックになる」という話はしましたが。
    • 本当にヤバいやつは「みんな死ぬしかないじゃない!」状態だったりしますよね。未踏出身の先輩が20年物のシステムを数年掛けて少しずつ直すのを見て「こういう人たちには敵わないなぁ」と尊敬しております。

プロセス面

  • エンジニア向けなので「システムを直す優先順位が1番低い」と伝えました。実際にそう運用しています。ただ、ビジネスサイドには別の伝え方をすることもあるので悪しからず。「ボトルネック発生時は他作業を止めてシステムを直す」(その頻度は少なくない)という但し書きが伝わるかどうかで切り分けています。
  • 終わってから気付いたのですが、1番リードタイムを費やしたのは(着手前の)「工数確保のための根回し・調整・擦り合わせ」で、要するに社内政治でした。さらに泥臭い話になりますなぁ。そこまでやって初めて「業務」になるわけですからねぇ。
  • 改めて振り返ると「言うは易し行うは難し」だと思いました。今回の構想は、システムもプロセスも文化装着も、1時間のホワイトボードミーティングで描いた戦略がベースとなっているのですが、それを実現するのに半年以上を費やしております。

メイキング裏話

ひたすら試行錯誤

  • 100枚超えのスライドを5回丸々作り直した。
    • 伝わる構成にならなくて苦労した。
    • もともと扱うトピックが広すぎたというのはある。
  • 10回リハーサルした。あのザマでしたが。
  • 20人からフィードバックをもらって細部を修正した。
    • 例:「楽して」が「楽しい」に見えるので「ラクして」に書き直す。

準備面での振り返り

  • 【Keep】スライドが真っ白の時から毎日リハーサルしてフィードバックをもらい続けたこと。
  • 【Problem】スライドに全部書き出してから余計な箇所を削る方式で始めたこと。これは無理があった。物量が多いので修正がキツい。単純にバッチサイズの問題。
  • 【Try】結局は「30秒だったら何を話す?」から考え直して今の構成にした。「じゃあ1分だったら?」「3分だったら?」と広げていった。最初からこのやり方を採用すべきだった。

当日の反省など

反省点多し。マイクに声が入っていない、時間はオーバーする、余計なことを言うの三拍子。 そんな中で最後までお付き合いくださった方々、声を掛けてくださった方々には感謝の気持ちでいっぱいです。

最後に

ベストトークアワードで優秀賞という栄えある評価をいただけました。 私自身の拙い発表というよりは、チームの仕事が認めてもらえたのだと解釈しています。

何はともあれ、運営者・発表者・参加者の皆様、本当にありがとうございました!

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

スクラム開発チーム立ち上げの失敗談を話しました #GWD_Nulab

概要

Nulab様が主催する Geeks Who Drink in Tokyo - Agile Team という勉強会に参加しました。 なるべく具体的なケーススタディ(特に失敗談)を共有したかったので「スクラム開発チームの立ち上げでアンチパターンを踏みまくった話」という発表をしました。

イベントの様子

イベント風景や発表内容は、以下のブログでレポートされています。

モブプログラミング?アジャイル?自分たちに最適な開発手法を本気で考えてみた「Geeks Who Drink Agile Team Edition」をレポート! | ヌーラボ

会場の合いの手スキルがやたら高くて面白かったです。

発表資料

当日のスライドは以下になります。

PEXELSにラグビーの画像がなく、アメフトでごまかしたことについては、深く反省しております。

内容

かいつまんで説明します。 詳しくはスライドを見てもらえると嬉しいです。

この話の位置付け

  • とあるスクラムチームの立ち上げでアンチパターンを踏みまくった話を共有します!
  • 反省を活かして、それ以降のチーム立ち上げ時には、比較的スムーズに話を進められるようになりました!
  • 「失敗談」と「こうすべきだった」を共有することで、同じように困っている方のヒントになれたらと思います!

アジェンダ

  • チーム立ち上げの背景:モバイルアプリ開発チームを立ち上げました!
  • アンチパターン
    1. 改善とビジョン:目指すゴールの共通認識(=Good/Badの基準)がないと改善のやりようがありません!
    2. 課題とフォーカス:解決したい課題を明確にせずに「アジャイルっぽいやり方」をやろうとしても本末転倒です!
    3. 出荷とロール:下手に役割分担するのではなく、全員が優先順位の通りに行動することで、ボトルネックが可視化されます!
    4. 作業とストリーム:1つのチームで1つのプロダクトの1つのゴールに向かって作業しないと、綻びが生じてしまいます!
  • スクラム開発:「What」と「How」を見直す → 継続的な「課題発見」と「課題解決」による進化を支えるフレームワークだと解釈しています!

スライドの一部抜粋

f:id:yuzutas0:20170902200832j:plain

f:id:yuzutas0:20170902200848j:plain

f:id:yuzutas0:20170902200905j:plain

f:id:yuzutas0:20170902200919j:plain

f:id:yuzutas0:20170902200931j:plain

補足

誤解が生じないように補足すると「これがスクラムだ」と断言したり押し付ける意図はありません。 正直なところアジャイルスクラムという言葉を使う必要さえないと思っています。

あくまで位置づけとしては

  • ビジネス価値の最大化が目的である
  • その過程でチームビルディングが必要となる
  • 開発プロセスフレームワークとしてスクラムを採用する
  • 運営の過程で何かしらの問題は起きる(コンテキストによって違いはある → とはいえ類型もある)
  • なのでアンチパターンや失敗談を起点にして知識を整理した

という感じです。

ケーススタディとして含めなかった話

なぜスクラムを採用するのか

中長期のプロジェクト型開発(ウォーターフォール)は必要悪だと思っています。

  • 事前に定めたQCDS目標を達成するために、学習頻度を犠牲にしがちだからです。
  • 半年間のプロジェクトなら、半年もフィードバックを得られない(仮に得ても活かせない)ことになります。

可能な限りイテレーションを回せるプロセス設計が望ましいです。 そうなると、何らかのアジャイルプラクティスを(結果的にであれ意図的にであれ)適用することになるでしょう。

特にスクラムは型が明確で「最初にこれをやりましょう」の会話がしやすいです。 それゆえに意図の解釈や議論があちこちで起きてしまいがちなので、ビジョンの補完やフォーカスの徹底、ロールやストリームの考え方を装着することが必要になります。

また、スクラムデファクトスタンダードゆえの恩恵をもたらしてくれます。 困った時に参照できるリファレンスや知見が世の中に溢れているのです。 新規参画メンバーに話を通しやすい、別の場所に移っても学びを活かせる、といった利点もあります。

チーム立ち上げ時に使う資料

ホワイトボード

下の図を描きながら、スクラムとは「What」「How」の「問題発見」「問題解決」を繰り返すフレームワークだと伝えます。

f:id:yuzutas0:20170902200950j:plain

参考図書

最初に読んでもらう → 必要に応じて輪読会をします。

URL

いちおうチームに共有しておく → 結局自分で見ることが多いですが。

  • Scrum Guide:邪道ですが「スクラムガイドには書いてないので、自分たちでやりやすい方法でやってみたらどうかな!」と言うために参照することがしばしばあります。
  • Ryuzee.com:困ったときによく見ます。

アジャイル博士になることがチームの目的ではないので、提供する情報量は最小限に絞ります。 なるべく余計なことを考えずに、目の前の問題に集中してもらうことが大事だと繰り返します。

感想

自発的に継続進化できるチームの構築は、基本であり奥義でもあると改めて思いました。 顧客価値にコミットできる良いチームを作っていきたいです。

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

社内政治をリーンにやろうぜという話をしました

概要

某社の社内勉強会にて「エスカレを支える技術 - アジャイル報連相と情報流通」という発表をしました。 炎上現場を生き抜いた権謀術数(というか土下座テクニック)を共有しました。

スライド

ざっくり内容

「既存の業務フロー」と「ステークホルダーコミュニケーション」を無駄なく結びつけようぜ、という話です。

  • 偉い人に働きかけることで、必要な資源をスムーズに得ることができるぞ!
  • 報連相をより効果的にするには、リーン(トヨタ方式)が参考になるぞ!
  • 今回は「チャット」「レトロスペクティブ」「人事評価シート」「ちょっとした雑談」を利用したぞ!

1営業日あたり2件の障害が発生した中で編み出した技法たちになります。

チャット

ノイズを減らす&気軽に投稿する、を両立するために無駄を削減する。

  • 上位レイヤの前にまずは現場チームで課題意識の共有・解決を試みる。
    • #dev_times チャンネル:技術・仕様面でのハマリどころ。
    • #kpt チャンネル:チーム運営でのちょっとしたご相談。
  • 上位メンバとの1on1で話すことは事前に #times_{myname} チャンネルに投稿する。
    • 現場メンバから「これも忘れずに会話してくれ」リマインドが来たり。
    • 上位メンバが事前に目を通してスムーズに会話できる。

レトロスペクティブ(振り返り)

いろんな会議で同じ話をするのは無駄なので、情報流通フローを整理する。

  • メンバーは思い立ったタイミングで#kptチャンネルに上げる。
  • チームの振り返り会で#kptを見ながら大事なものをチョイス。
    • チーム内で解決できるならTryに繋げる。
    • チーム内で解決できないものは分ける。
  • マネジメント会議で、KPTのサマリーを上位層に伝える。、
    • チーム内で解決できない課題を受け渡す。

人事評価シート

目先の課題とは別に、攻めるための目標・進捗を管理して、なおかつ担当者は取り替え可能な状態にする。

  • 前提:人事評価シートの目標設定(xxxまでにxxxを達成するのだ!)をもとに、人事面談で攻めの目標についての認識合わせがなされる。
  • 課題:マネージャーとメンバーたちの1対nの関係になりがち → 各メンバーが受け持っている目標が開示されない → チームで進捗確認できない → 報連相が個人に任されて漏れが生じる → 色々こじれがち。
  • 打ち手:メンバー全員に同じ目標を設定する → 各目標の進捗管理を週次ミーティングで実施する → 進捗を妨げる問題があればチームとして検知 → ミーティング同席の上位陣にそのままご相談。

ちょっとした雑談

毎日の終業時刻に偉い人を10分弱ほど捕まえて、小さなバッチサイズで報連相を行う。

  • 「もうダメっすねぇ」→「xxxに困っているんですよ」→「xxxがあれば助かるのになぁ(チラッ」
  • 相談の中で課題が整理される。
  • 必要であればサポートを受ける。

名付けてデイリーエスカレ。

言いたかったこと

エッセンスとしては、「開発・運用の現場」から自然と「経営層」に情報を流せるように仕組みを作りましょう、ということを伝えたいです。

でないと、ある日突然偉い人から「xxはどうなっているのか」と言われて、現場は「な、なんだってーーー!」と混乱したり、ある日突然現場が「xxで困っています」と伝えて、偉い人は「な、なんだってーーー!」と混乱したり、とにかく碌なことにならないです。

しかるべき情報共有をするだけで、あっという間に解決できるような問題は山ほどあります。 だったら、わざわざ未解決のまま放置する理由もないでしょう。

情報の「流し方」の話になるので、滝(ウォーターフォール)のように一気にドバーッと流すよりも、無駄なく(リーンに)流した方がよかろう、という話です。

当たり前だけど難しいこと

悪い言い方をすると、ただの社内政治(の第一歩)にすぎません。 お粗末な言い方をすると「報連相をしっかりやりましょう」という話です。 また、制度・文化・コンテキストに強く依存するので、プラクティスは組織によって変わるはずです。

ただ、このあたり、ビジネスとシステムを繋ぐ立場の人なら、似たような問題意識を持っているのではないかと思っています。CTO、技術マネージャー、開発リーダー、プロジェクトマネージャーなど、呼び方は多々あれど。

特に、組織がスケールして三階層を超えたら、確実にこの手の問題が浮上します。トップがメンバー全員ときめ細やかにコミュニケーションできなくなるので、情報流通をきちんと設計しないと阿鼻叫喚です。

各プラクティスの考案タイミング

上記の取り組みは、最初からスマートに仕組み化できていたわけではありません。 あとから俯瞰したらこうなっていた、というだけです。 仮に、最初からやろうとしても、関係者には必要性が伝わらず、浸透しないと思います。

実際には、目の前の課題をチームで1つ1つ取り除いていただけです。 チーム内では解決できない問題も山ほどあるので、必然的に上位レイヤーに働きかけて、間接的に解決することになりました。 その中で、プロセスに無駄があれば地道に取り除いていき、結果的にこれらのプラクティスに辿り着きました。

大事なのは、可視化(透明性)を担保した上で、課題発見(検査)と課題解決(適応)を繰り返すことだと思っています。 結局はDevOpsというかスクラムというかアジャイルというかリーン的な話に繋がるのかなと。

あえて言わなかったこと

あまりLT受けする話ではなかった(というか完全に社畜養成講座になりそうだった)ので、あえて言わなかったのが後工程の話です。

階層化された大規模組織だと、エスカレ後に「ポケットの内側」と「ポケットの外側」で、次の行動が変わると解釈しています。

追加予算の獲得や他部署の協力が必要な場合だと、ステークホルダーを説得する必要があるのです。 説得ストーリーを描き、エビデンスを集めて、軽くジャブを打って反応を見て、といった営業チックな活動になります。 ここは現場と偉い人が力を合わせると比較的スムーズに進むはずです。

ただ、最初から細かい数字やエビデンスまで抑える必要はないかなと思っています。 確保済みの予算など「ポケットの内側」で済む場合は、それこそ臨機応変差配するためのポケットだと思うので、規模感だけ把握すれば問題ないはずです。

なお、組織の状況がどうなっているのか(特に予算と人員)を把握しておくと、何かとスムーズなのかなとは思います。 これも順番があって、こまめな報連相・サポート需給を通して上位レイヤーと信頼関係を構築することで、そのうち情報が開示される機会が巡ってくる、というのが妥当でしょうか。

まとめ

顧客への価値提供を主要な企業活動と捉えると、こうした社内の情報流通は本質的な部分ではありません。 だからこそ、無駄なく話を片付けるために、型化が大事なのかなと思っています。 過剰にこだわってしまうようだと本末転倒ですが、完全無視はもったいないです。

上手いことやっていきましょう。

リーン開発の本質

リーン開発の本質

社内勉強会の運営について話しました

概要

さくらインターネットさんで開催されたエンジニアのためのプレゼン技術研究会にて、 「エンジニア組織のスケールに伴う社内勉強のTry&Error」という発表をしました。

スライド

ざっくり内容

改善サイクルをひたすら回したという話になります。

10人の時代

  • 形骸化したミーティングを乗っ取った。
  • 社外ではあまり話されないトピックのLTがベース。
  • アドオン:相談LT+ワールドカフェ → ワークショップ → もくもく会 と推移。

200人の時代

  • 本格的なイベント運営の型を作って運営した。
  • よくあるLT(カンファレンス参加報告や自作ツール紹介や退職LT)がベース。
  • 各チームの担当業務を紹介したり、テーマを設けたり、講演形式をやってみたり。

500+人の時代

  • ボトムアップの個別勉強会、トップダウンのゲスト講演、トピックごとの分科会。
  • この規模になると、ピラミッド型の組織を教科書通りに運営することが最優先。

社内勉強会とは結局何だったのか

  • 組織運営の抜け漏れを検知するセンサーの役目を果たした。
    • 社内勉強会=組織運営(関係構築+情報流通)の側面が強い。
    • 特定技術に習熟するためなら、実践・個人学習の方が良い。
    • ケーススタディやアウトプットの場とするなら、社外勉強会の方が良い。
  • 無理しない程度に楽しくやっていきましょう。
    • ないと組織が硬直化する。
    • しっかりやると高コストになる。
    • 適当にやるとグダグダになる。

汗と涙の取り組みだったので、詳細についてはぜひスライドを読んでいただけると嬉しいです。

発表・イベントについて

持ち時間は5分だったので、最初のフェーズ(5人→10人)について話しました。 いただいた感想やQ&Aとしては以下の通り。

Q.事務連絡をSlackだけで完結できるのか? → A. チームごとの会議が別にあって、そちらで対面コミュニケーションの補完がなされた。

Q.ビールとピザでLTすると大体グダグダになる印象 → A. ゆえにあの手この手で変えていった。特に、相談LTとワールドカフェの組み合わせは、活発な議論やチーム横断のTips共有に繋がったので良かった。

色々なスピーカーが雑多なトピックで話す中で、共通の話題(私の発表だとSlack運用方法についての質問など)を即座に決め打ちして、Q&Aタイムを盛り上げた他の参加者の方々はさすがだなぁと思いました。 おかげで良い雰囲気の中で話せました。

当日は体調が優れなかったため(個人的には)色々と燃焼不良&ご迷惑をお掛けしてしまったように思いますが、諸々のフォローを含めて、非常に丁寧でありがたい場だったと感謝しております。

補足

「急スケールする組織では、コンテキストのリセットと再発見が螺旋のように繰り返される」とスライドで書いています。

人の出入りが激しいと、以前の勉強会での「これが良かった・悪かった」「だからこうしよう」が運営者・参加者で共有されていないので、無理にやろうとしても賛同を得ることができず、1からやり直しになってしまうのです。 まるでコミュニティの解散と立ち上げを繰り返すようなものです。

ただ、「螺旋」と述べたように、1度経験しているので、同じミスを発見・予防しやすく、同じ改善アイデアを素早く活用できるので、少しずつ高い位置に登っているのだなとも思います。

このあたり、ノウハウを社内向けに文書化するだけでは、参照機会・想起タイミングが限られます。個人の頭の片隅に蓄積された暗黙知を活かすか。社外に資料を公開して何らかの機会に引っかかるのを期待するか。何らかの工夫が必要になります。

これは勉強会運営に限らず、開発チームの運営も同じだなぁとひしひしと感じております。 だからこそ各フェーズをひととおり経験したことのある人間がチーム運営にジョインすると話が早かったりするわけですね。 何事も挑戦して経験しての繰り返しということで。

アメリカ海軍に学ぶ「最強のチーム」のつくり方

アメリカ海軍に学ぶ「最強のチーム」のつくり方

デジモンが20周年を迎えたので熱く語る #デジモンの日

本日8月1日は「デジモンの日」と呼ばれている。 さらに今年2017年は、初代デジタルモンスターのゲーム発売から20周年に当たる。

そこで(おそらく誰もついてこられないだろうが)デジモンについて熱く語りたい。

f:id:yuzutas0:20170801212144j:plain (わざわざ撮影したぞ、お台場メモリアル)

もくじ

短編小説『デジモンテイマーズ1984

せっかくなので、絶版になった『デジモンテイマーズ1984』という短編小説を読むことにした。 図書館検索によると都内に3冊あることが分かったので、問い合わせて書庫から取り出してもらい、読んでみた。

シリコンバレー発・OSSプロジェクトとしてのデジタルモンスター

このSF小説は、2001年に放送されたアニメーション作品である『デジモンテイマーズ』の前日譚という位置付けだ。

80年代に若手研究者たちが集まって、OSSプロジェクト「デジモン」を作り上げていく。 彼らはパロアルトの大学(おそらくスタンフォード)の博士課程に所属するメンバーで構成されている。

子供がスケッチブックに描いた空想の生き物を、プログラミングによって電脳世界に射影する。 粗いドットではあるが、画面上で人工生命体が動くのを見て、ひらすら楽しんでいる。 モンスターたちは搭載されているAIに従い、野生の動植物と同じように、デジタルワールドで生存競争を繰り広げる。

「電子頭脳による命ある生物の創造」として、当時の人工知能であるセルフオートマトンノイマン)やライフゲームコンウェイ)にも言及している。 それゆえに「ゲーム的な性質」を持つのは必然だとソフトウェアエンジアリング担当は論じる。

また、当時は巨大なコンピュータの先にあるものとして「ノートブックで開いて眺める」インターフェースのコンセプトが提唱された時期であった。 しかし、むしろ「ネットワークそのものに入り込む感覚」が適しているのではないか、と作中のデザイン担当は考える。 結果として、現代のスマートフォンに近い(ユビキタス的な概念を支える)UIとして、携帯ゲーム機のような小型端末を考案する。

SF(サイエンス・フィクション)としてのデジタルモンスター

ここからがSF展開となる。

ほとんどのメンバーは、アプリケーションレイヤー上での人工生命体を見て満足していた。 ただ1人「SHIBUMI」と呼ばれるメンバーだけは別の野望を持っていた。 彼は他のメンバーの隙を見て、とあるプログラムを混入させる。

結果として、開発者たちが想定していなかった事態が起きる。 画面の向こうの架空の生き物のはずなのに、深夜の研究室には唸り声が響き、デスクには爪痕が残される。 プロジェクトは凍結されるが、既にオンライン上にデータは広まっていたのだった。

現実世界への侵食、そして本編へ……

ここからアニメ本編につながる。

デジタルモンスター(ならびに削除プログラム)は、ネットワークの奥底で、人知れず自己進化を遂げていた。 15年の沈黙を経て、2001年のリアルワールドに実体化。人類は危機に陥る。

その危機に対抗する実行部隊はアニメの主役である子供達だ。 しかし、その根本解決策を立案・支援するのは、当時のOSSコミッターである大人たちとなる。

改めて作品を見直すと、大人には大人の戦いがあることが垣間見える。

  • 子供達を危険な目に合わせている事実。
  • 過去に自分たちが作った仮想生命体が世界に危機をもたらしている事実。

そういったものと向き合って苦悩しているのである。


これらの裏設定については、小説の著者であり、3作目のアニメ監督である小中千昭氏のホームページに年表が記載されている。 はっきり言って、主な視聴者である子供には、理解が難しい舞台設定だと思う。

サマーメモリー的解釈

同じように、大人の視点で見直してみると、シリーズ全体を通して読み取れることがある。 一言でまとめると「郷愁」だ。ここでは便宜的に「サマーメモリー的解釈」と呼ぶことにしよう。 考察ではなくあくまで解釈である。

なお、1999年〜2002年まで放映された初代4部作のアニメーション作品(アドベンチャー・02・テイマーズ・フロンティア)を対象に考察する。 また、映像・台詞と同様に重要な構成要素である音楽(その場面に流れた歌)についても引用する。

「進化」とは何だったのか

一連の作品を通して、重要なキーワードは「進化」である。 ゲーム作品としてはモンスターが強くなるわけだが、青春物語としてはもう1つの意味を持つ。

テイマーズ(3作目)の主人公が「僕ももっと進化しなくちゃ」という発言をしている。 これは人間的な成長を意味している。 つまり「子供の成長」と「パートナーデジモンの進化」は連動している(比喩表現である)ことが読み取れる。 「なりたい自分 夢に見るのは 誰にも頼めない」のである。

「なりたい自分」になれなかった者たち

一方で、テイマーズの主人公は「進化して強く大きくなると、友達でいられなくなる」ことを懸念する描写がなされている。 大人になってしまうと、かつての友達と、友達のままでいられなくなってしまうのだ。

特に作中前半では、子供たちの敵対者として大人が描かれていることも影響している。 主人公の担任教師は「どうして先生になったの」と問われて「安泰だから」「私には向いていない」「どうしろっていうのよ」と小学生に当たっている。 そのエピソードの挿入歌では「ボクたちもいつか大人になるの?」「わからないフリしていたんだ」と流れる。

また、アドベンチャーの黒幕は「進化できなかったデジモンたちの怨念の集まり」である。 それまでは「子供たち」サイドの成長を軸に描写されていた。 最終決戦で初めて「子供たちの敵」サイドの心情が提示されたのだ。

続く2作目(02)では、「子供たちの敵」である「闇」サイドに焦点が当てられる。 兄に虐待を受けたのと同じように、他者を暴力で支配して、電脳世界を支配しようと目論む少年。 自分が「破壊行為を目的として人為的に作られた」と自覚して、自分の存在意義に戸惑うデジモン。 さらに決定的なのが「子供の頃にデジタルワールドに行くことを夢見ていた」大人が、その願いを叶えるために、黒幕(の代理)として一連の事件を引き起こした点だろう。

郷愁・回想・回顧・懐古・憧憬

2作目以降に強調されるのは「大人」の側面である。 「02」の最後に、「アドベンチャー」「02」という作品が、大人になった登場人物(の1人であるタケル)による回想だったことが提示される。 アニメではナレーションという形式を取っていたが、冒険譚を記した著者による語りだったのだ。

余談だが『ウォーゲーム』や『スタンドバイミー』のように80年代の作品を元ネタにしたエピソードは多々見受けられる。 ちょうど2000年頃のアニメを作った人たちが10代だった頃の作品だ。例えば細田守氏はその年齢に該当する。 そう考えると、ある意味では大人が過去の自分に向けた作品なのかもしれない。

このことを如実に反映しているのが、劇場作品3作目で、「戻れない過去」がテーマとなる。 舞台はアメリカの「サマーメモリー」という架空の土地。 敵は作中で(幼い頃のあの日に)「帰りたい、帰りたい、帰りたい、帰りたい」とひらすら連呼する。

そのEDテーマ曲は「スタンドバイミー - ひと夏の冒険」で、「いつか見た映画のように線路は続いていく」という歌詞。 該当の映画、スティーブン・キングの『スタンドバイミー』は、大人になった主人公が子供の頃の冒険を回想する話。 まさに02と同じ構造である。 一緒に冒険をした友人たちは、亡くなっていたり、疎遠になっていたりする。 線路を人生と解釈すると「窓越しに変わる景色」はもう取り戻せず、その上で「線路は続いていく」のだ。

なお、劇場3作目の敵は、過去に戻れないことを悟り、なおかつやり直すこともできない状況となり、最終的には自ら消滅を選ぶ。

自ら扉を閉ざすという選択

このシリーズには他にも「子供の頃の夢を捨て切れなかった大人」が出てくる。 前述した「SHIBUMI」もその1人である。

電子生命体による現実世界への侵攻を防ぐことがミッションの「ネットワーク管理局」の人間は、SHIBUMIを「大人になりきれていない」と評している。 彼は研究仲間たちの中でただ1人、量子テレポーテーションによる「リアライズ」(=モンスターの現実世界への物質化)や、デジタル世界に行くことを、20年間ずっと夢見ていた。 他のメンバーは、「できるわけがない」と一笑に付し、時の流れの中でデジモンの存在を忘れていた、にも関わらずである。

ウォルト・ディズニーが言うように「どんな洗練された大人の中にも、外に出たくてしょうがない小さな子供がいる」のだ。 そして02の黒幕(代理)である「及川」や、テイマーズの「SHIBUMI」は、その「子供」を自意識から追い出しきれなかった存在と言える。

しかしその「SHIBUMI」も、リアル世界に侵食した削除プログラム(デ・リーパー)を退化させるため、自ら2つの世界の扉を閉じる選択をする。 そのことで(本人の意図した結果ではなかったが)子供たちとデジモンのお別れという形でテイマーズは幕を閉じる。

子供たちの1人は明確に「お父さんはこうなるってことが分かってて」(あえて選択したのか)と大人を批難する。 同時に「今は分からない でも分かる日が来る いつかきっと」「誰も分からない でもそれでいいんだ 今はきっと」とも感じているのだ。

この結末はどういう意味を持つのだろうか。 「現実世界」(社会)のために、自分が守りたかった「子供の頃に憧れた世界」を捨てるということなのだろうか。

「大人」を超えるために必要だったもの

もう1度振り出しに戻ろう。 最初に以下のように述べた。

つまり「子供の成長」と「パートナーデジモンの進化」は連動している(比喩表現である)ことが読み取れる。

アドベンチャーでは、明確にデジモンの進化フェーズと、必要なものが提示されている。

  • 成熟期(大人)になるには「食事」(エネルギー)や「パートナーを守りたいという意思」(成長への欲求)が必要
  • 完全体(理想の自分)になるには「紋章の輝き」(後述)が必要
  • 究極体(理想を超えた自分)になるには「愛する者の願い」(後述)が必要

「大人」を超えたあとは、2つのフェーズがある。

まずは「理想の自分」になるフェーズ。 その「進化に必要な紋章」とは、1人1人が「小さい頃に本来持っていた個性」だと解説されている。 中盤にて主人公たちは「いつの間にか見失ってしまった自分らしさ」を取り戻すことになる。 1度は大人になり、その上で、子供の頃の自分を取り戻すことで「理想の自分」になれるのである。

さらに「理想を超えた自分」になるフェーズ。 アドベンチャーでは、愛する家族の力を借りることが必要だと(遠回しに)言い伝えられていた。 ジョグレス体(02)やハイブリット体(フロンティア)も同じで、自分以外の誰かの力を借りている。 ジョグレス体は、まさに合体で、他者との交わりである。 ハイブリッド体は、古代のスピリット(=受け継がれた思い)と一体化するのである。

これは『7つの習慣』で述べられている内容と同じである。 まずは「自分にとって大切なものは何か」と問い直し、自己を再発見する。 その上で「他者との相互作用」を経て、ようやく自己実現がなされる。

予定調和を超えるための「何か」

短編小説『デジモンテイマーズ1984』では「エンテレケイア」という存在について解説している。 アリストテレスが提唱した後、生気学者ドリーシュによって再解釈された概念だ。 本編では「クルモン」と呼ばれた存在だが、それだけに留まらない。

「エンテレケイア」とは、進化を促すものだ。 予定調和を超えさせるものであり、「外側から生命を与えるもの」である。 そしてそれは「この(現実)世界にいくらでもある」ものだ。

アドベンチャーでの老人(ゲンナイ)の言葉からも同じメッセージが読み取れる。 子供達に対して「進化そのものに正しいも誤りもない」と釘を刺しているのだ。 子供が大人へと変わっていく中で、正しい成長というものは存在しない。 「生き方に地図なんてないけど、だから自由 どこへだって行ける」のである。

死と再生の循環

では、「なりたい自分」になれなかった者たちは、どうだったのだろうか。

02の「子供の頃にデジタルワールドに行くことを夢見ていた」及川が消滅する場面に注目したい。 ここで流れる曲名は『Sun goes down』(日が沈む)で、「誰にも言えないほどの壊れそうな悲しみでも 君だけの特別な宝物だ」と言う。 そして「明日は違う色の世界をきっと照らすから」「君はいつでも生まれ変われる」のである。

これは死と再生の物語だ。 まさに作中では「デジタマ」という概念が表現している。

サマーメモリー的解釈においては「子供」(自己)と「大人」(世界)の循環を意味する。 自分らしい自分で居られない状態とは、自己の欠落であり、個性の損失であり、自分の人生を生きていないということであり、それはつまり死なのである。 その上で、死と再生(=自己の再発見)を循環するのである。

外部影響があるから大人(成熟期)になる。 そして、内なる自分らしさを取り戻して理想の自分(完全体)になる。 そして、外にいる他者との繋がりを経て自己実現(究極体)が達成される。 この内的発見と外部発見のスパイラルが、人間的成長、つまり進化なのである。

ゆえに、「02」(第2作)の最終決戦後に描かれた「大人」(闇)の消滅、「テイマーズ」(第3作)の最終決戦後に描かれた「子供」(光)の消滅とは、果てしない螺旋における1つの踊り場にすぎないのである。

旅の終わり

他の作品が親子の関係性を描いているのに対して、4部作最後のフロンティアでは大人の描写がほとんどない。 代わりに、大人に翻弄されて生き別れた双子のエピソードがある。 やはりここでも大人とは子供の世界を乱すものなのだ。

だが、子供たちはそれ以上に「選んだのは誰でもないさ 俺たち自身だったろ」と前向きな主体者として描かれている。 これは「自己実現」を達成して、他者に対して影響力を及ぼす存在であることを意味している。

また、フロンティアでは、子供たち全員に平等に見せ場は与えられていない。 一部のヒーローと、サポートする立場に分かれている。完全な役割分担制になっているのだ。 これはむしろ「大人」らしい描写に見える。同時に、自然な「子供」らしさとも言える。

最終作にほとんど大人が出ないのは、一連の4部作を(大人が大人に対して問いかける)「子供時代を取り戻すための旅」としたときに「本作がその旅の終着点だから」と言えよう。

はてしない物語

なお、4部作最後のED曲は『an Endless tale』である。 これは1984年(これも!)に上映された映画『Neverending Story』(邦題『はてしない物語』)と同じ意味である。

原作小説の『はてしない物語』は、前半は英雄譚だが、後半は異色の展開となっている。 特別な力を得て英雄になった主人公が自分を見失って暴走する。 だが完全に消滅する直前に、それまでに出会った友人を通して、本当の自分を取り戻す。 そういうシナリオだ。 まさに「大人になって個性を見失う」「他者を通して再発見・自己実現する」という解釈が可能な作品である。

そして、EDの歌詞は「たくさんの出会いとさよならが道しるべさ 僕らの」で閉じる。 この世界に溢れているエンテレケイアを通して「冒険は進化する」のだ。

デジタルパートナーと共に歩む未来

ここからは自分語り。

価値観や幸福の定義が多様化した社会においては、ビジョンが求められる。 そして「私たちが子供の頃に憧れたXXX」という言葉は、1つのビジョンになりうると思っている。

空想の世界におけるOSSコミッターたちが熱中したように、私もデジモンのようなものを作りたいと思った。

  • あるいは、モンスターよりはロックマンエグゼのナビゲーターの方が適切だろうか。
  • あるいは、ドラえもんのような(四次元ポケットはないけどWEB上で必要な情報を取り出してくれる)良き先輩であり、相談相手であり、親友のような存在だろうか。
  • あるいは、サマーウォーズの(『僕らのウォーゲーム』から細田監督が展開した)OZのような世界観だろうか。

何かそういう「10年後に当たり前になっているかもしれないもの」を形にしたいと思った。

そこで試しに生活支援のチャットボットを作ってみたりもした。 だけど、もっと本格的なデジタルパートナーを、OSSプロジェクトとしてやってみたい。

ただ便利なだけでなく、自分らしい生活を送るための支援者としてのデジタルパートナーを作ってみたい。 子供たちがパートナーデジモンと出会って自分の個性を取り戻したような。そんなパートナーだ。 ストレス社会で、コーチング・メンタリングの重要性が注目されている社会的文脈とも合致するように思う。

初代のアニメ放送が1999年。あれからもうすぐ20年。 20年前、私たちが子供の頃に描いた理想の自分になっているだろうか。 理想の20年後の世界を実現できているだろうか。

せめて今からでも、20年後に向けて、何かできないだろうか。


というポエム。 せっかくの夏の夜ですので。

自分でも正直キモいと思ったのですが、たまにはこういうのも風情があっていいかなぁということで投稿します。

10個のWEBサービスを個人開発した振り返り

概要

PORTもくもく会というイベントにて、「10個のWEBサービスを個人開発した話」というタイトルで、振り返りLTをしました。

スライド

つくったサービス

これらをざっくり紹介していきました。

振り返り

  • K:楽しいよ。スキルにもなるよ。
  • P:1人で続けるのは大変。
  • T:一緒にやりませんか。

聞かれたこと

Q. 作りたいものが思いつかない!アイデアの出し方は?

困った時に「これがほしい」を考えています。

例えば、さきほどから雨が降り始めましたが、私は傘を忘れてしまいました。

  • 最近だと天気予報を見ない人が多い → 雨の日だけ朝に通知するサービス。
  • 会場付近(新宿)は地下道が多い → 雨に濡れる時間を最小限にするためのマップ検索サービス。

といった感じでアイデアを出していきます。

Q. 実際どれくらい時間が掛かるもの?

モノによります。

  • 短いやつだと、(もはやWEBサービスか怪しいが)30分で作ったプロトタイプもあります。チャットボットも丸1日くらいのお手軽実装です。
  • 反対にQiita:Teamクローンは、工数で1ヶ月弱、工期で1年弱も掛かっています。

Q. 完成まで続けるコツは?

続けざるを得ない環境を作ることでしょうか。 予定が入っていない日は、仕事終わりにカフェで1人もくもく会をやっています。

Q. 使っている言語やFWは?

趣味開発だとアプリレイヤは大体がRailsですね。

(フロントは?Bootstrap?) Bootstrapをラップして使うことが多いです。

他にも、iOSアプリを作るときはCocoa/Objective-Cとか。 最初の方は勉強のために、Java Servletフルスクラッチで書いたりしていました。

Q. 早く作るためのコツは?

(言うほど早く作れていないのですが)要件はなるべく絞り込んでいます。 非機能要件はいつも同じで「この観点だけは遵守する」という形で決めてしまっています。

あとは、いつの間にか型ができているので、パーツを組み合わせるように作ることはありますね。 特にインフラ・ミドルウェアは同じスクリプトを使い回すことが多いです。

Q. 自分も同じように作りたいが、各開発工程で何を意識すべきか?

最初から綺麗にやろうとすると色々と大変だと思います。 まずは雑な開発でいいから、リリースさせることに集中するのが良いのではないでしょうか。

Q. サービスをクローズするときの基準は?

ユーザーがいない、明らかに使われない、トラブル時の保守が極めて困難である、といったサービスは、クローズせざるを得ないですね。 最終的にはノリと勢いです。

Q. 収益は考えている?

(個人開発では)重視していません。

多少の売上はありますが、雀の涙です。 はるか昔に作った広告サイトのほうが未だに稼いでいます。

趣味のサービス開発だと、せいぜい月に数十万いけば上出来くらいの相場観だと認識しています。 それなりの単価・客数が必要になりますが、その分だけの(仕事と言える)運用・集客が求められます。 ソフトウェアエンジニアの人件費を月100万円と考えると、金銭面に着目するには難しいものがあります。

だからこそ成功例を作ろうとする個人開発者の方々は心から尊敬しています。

一方で、私が持続可能な収益を考えるのであれば、やはり「個人」ではなく「組織」、「サービス開発」ではなく「ビジネス開発」になるのかなと思っています。 (そちらにシフトしたほうが良いのだろうなと考え始めています)

感想

正直、作業のもくもく度合いだけだと、1人でカフェ作業のほうが捗ったかもしれないです……。

ただ、「こういうのやりたいんですよね!」「まずはここから着手しています!」といった感じで、意思と行動を兼ね備えている人が多かったので、話していて楽しかったです。

「これ一緒にやろうよ!」ということで、ちょっとしたコラボが生まれたりもして、イベント終了後にも連絡を取り合ったりしています。

いやー。いいですねー! 今後が楽しみです!

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)