下町柚子黄昏記 by @yuzutas0

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

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

概要

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

スライド

ざっくり内容

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

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

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)

3年間の振り返りLTをしました

概要

こっそりと更新。完全に自分語り。

14卒エンジニアが4年目の立ち位置を確かめる会でLTをしてきました。 与えられたお題は「この3年何をやってきたか/成長したこと」というエモいものです。

どんな話をしてきたか

スライドはこちら。

文字通り、色々なことをやってきましたよ、という話。 自分で作っておいて、最終的に何が言いたいのか、自分でも良く分からない感じになりましたが。 どちらかというとお酒がメインで、LTは出し物みたいな位置付けだったので、これで良かったということにしましょう。

擲り書きの感想

イベント自体は普通の飲み会だったので感想という感想もなく。 自分の仕事を振り返る機会としては良かったなぁと思いました。 また、他の人の発表を見て、短い時間で伝えるテクニックは参考になりました。

エンジニアレジュメ

同僚の話を聞くと、担当した仕事や学びを、エンジニアレジュメ(という社内向け自己紹介ページ)にコツコツと書いているとのこと。 また、ジョブホッパーや副業フリーランスな人たちも経歴ドキュメントを定期的にアップデートしているとのこと。 この機にポートフォリオサイトでも作ると良いのかもなぁと思いました。

とはいえですね、自分のサイトを作るだけでは企画屋としては名折れなわけです。 せっかくならむしろポートフォリオのプラットフォーム(それこそエンジニアレジュメのようなクローズドSNS)をやりたいですね。 ということで、プロトタイプはすでに手元にある!(というか半年前に作って放置していた)ので、まずは小さく社内導入でもやってみますか!

というポエム。

新規事業部署でのじたばた話をしました

概要

Gaiax Technical Meetups - あのサービスはどうやって生まれたのか?というイベントでLTをしてきました。

登壇者の話を聞いて

顧客に徹底的に寄り添っていること。 自分たちでドッグフーディングを楽しんでいること。 愚直に粘り続けていること。

そういった姿勢が伝わってきました。

どんな話をしてきたか

スライドはこちら。

要約としては「新規事業部署でビジネスを立ち上げた→3戦中 0勝 2負 1分でした」という内容になります。

振り返って

リーンスタートアップ

当時はリーンスタートアップという言葉を「とにかく早く多く出す」「テストマーケティングする」と曲解していたように思います。 そのせいで変にこじらせたのではなかろうかと。

現状での自分なりの解釈は、こんな感じです。

  • 事業開発のボトルネックを速やかに排除することが重要である(ここが「リーン」の考え方)
  • 0→1フェーズだと「時間を掛けて誰も欲しがらない製品を作ってしまうこと」が1番の問題となりがち(ここが「顧客開発」の考え方)
  • なので「誰が顧客か」「どんな課題を抱えているか」の二点を最小コストで検証することが最優先(ここから「リーン」x「スタートアップ」)
    • その方法として「最小機能でリリースして意見をもらう」「動画やLPで反響を得る」といったプラクティスを紹介している
    • 市場規模を確認するのは、製品としての勝ち筋が見えたあと

※市場規模については − 正確には「そのビジネスがどこまでスケール可能なのか」の見立てについては − 『Lean Startup』や『Running Lean』、元となったスティーブ・ブランクの『スタートアップ・マニュアル』でも、検証対象として語られてはいますが。

知識創造

なお、ボトルネックの解消の仕方は、チームや市場によって異なっているはずです。

例えば、大企業だと"SECIモデル/知識創造"の座組みが強いように思います。

  • 様々なロール(顧客の状況を把握するセールスやサポート、マス観点で市場特性を把握するマーケター、製品仕様に精通するエンジニア)がいる。
  • 各々が業務を通して意見を醸成する → ぶつけ合う → 顧客が本当に欲しかった製品を作り、欲しいと思えるやり方で届けられるようになる。

みたいな感じですね。

新規事業部署よりも、10年以上続いているサービスを運営する部署の人たちのほうが、担当ドメインの最新事情や顧客の本音について精通しています。

  • そういった問題意識を持った人たちが、自分の可能な範囲で協力者を集めて、まずは小さな成功体験を積むわけです。
  • 最初は「そんなのビジネスになるの?」と言っていたお偉いさんも、何度も会話を重ねるうちに「こうすればグロースするのでは?」と外部事例を輸入してきたり。
  • んでもって、そうした事例の積み重ねだとか、働き掛けによって、徐々に機運が高まり、やがては強力なバックアップのもとで事業立ち上げがなされる。

要するに、必ずしも「紋切り型なスタートアップ像」が正解だとは限らないよ、ということです。

社内起業

他の観点だと、『はじめての社内起業』という書籍では「偉い人をいかに利用するか」に言及しています。 偉い人のもとには、社内の様々な情報が集まっており、確度高くビジネス成功の絵を描くための材料が揃っているはずだからです。

といったことを踏まえると、失敗したと思っていた3つの事業も、まだまだやれたことはあったように思います。

おわりに

なにはともあれ、胸を張って「あのサービス」について語れるようになりたいものです。

はじめての社内起業 「考え方・動き方・通し方」実践ノウハウ

はじめての社内起業 「考え方・動き方・通し方」実践ノウハウ

Python入門者の集い #PyNyumon でLTしました&プログラミング言語の学習法の自己整理

概要

Python入門者の集い #5というイベントでLTをしてきました。 ついでに自分なりにプログラミング言語に入門するときの考え方を整理しました。

他の参加者の発表

LTテーマは「最近Pythonを触り始めた話」ということで、

  • ハッカソンでこういうの作ったよ
  • データを可視化できるようになったよ
  • 写経を始めて今こんな感じだよ

などなど、多種多様な内容でした。 全員が楽しそうに話していて、聞いていて楽しくなってくるような、素敵な発表ばかりでした。

ほとんど上がっていませんが、一応こちらのConnpassのページが資料置き場かな。

どんな話をしてきたか

データ分析基盤を作るにあたって、これまでやったことを共有&困っていることの相談LTです。

会場がレバレジーズさんで「teratail」(国内プログラマ向けのQ&Aサービス)のPRをなさっていたのを聞いて、「そういえばQ&Aサイトで聞けば良かったのでは」と気付いた次第でした。

プログラミング言語の学び方

LTでは、さくっと流しましたが。 個人がプログラミング言語を新しく習得するときの流れとして、以下の3フェーズがあるのではないか、と考えています。

f:id:yuzutas0:20170722145553j:plain

  1. 環境構築とHelloWorldと最低限のデバッグができたら、あとはひたすら調べながら機能要件を満たせるようになるフェーズ
  2. 他の人の書いたコードを読みまくって、よりベターな書き方・便利なライブラリを知り、リファクタリングを通して、保守性の高いコードが書けるようになるフェーズ
  3. ドキュメント・書籍で言語仕様を把握して、内部挙動までデバッグ&コードリーディングできるようになり、パフォーマンスを最適化できるようになるフェーズ

※追記:失念していましたが、メタプログラミングを図に追加しました。

置いている前提としては以下の3つで、該当しない場合は、おそらく違う登り方になるだろうと思っています。

  • 最低限のコンピュータサイエンスや他のプログラミング言語の知識がある
  • あくまでも道具としてプログラミングを位置付けている(作るものが先にあった上で、技術選定を行っている)
  • 必要なときに、必要な知識を、必要な分だけ吸収するスタンスである(事前に勉強するのではなく、手を動かして壁にぶつかってから学ぶ)

人によりけりだとは思いますが、勉強するものではなく、結果的に使えるようになっているものなのかなぁ、という自論です。

CM

ただ、上記のやり方だと「これくらいは知っておけよ」が漏れる可能性があります。 まさにいま、Pythonがスラスラわからなくて、相談LTをしたくらいですから。

という話をしたら『スラスラわかるPython』なる本を読むといいよ!と著者の方がおっしゃっていた(気がした)ので、 スラスラPythonをわかるようになりたい私としては、『スラスラわかるPython』を買うしかないと思ったのですが、 本棚が限界に来ているので、ひとまずは書店で眺めてみようかなと思った次第です。

スラスラわかるPython

スラスラわかるPython

最後に

ちょっと早口だったり、内容面でも色々と省略してしまって、説明が伝わりにくかったのだろうなぁと反省しています。 9月に開催されるPyConでは、システム自体をもっと進化させた上で、きちんと内容を整理&練習して登壇します。

SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsする話

がんばるぞい。