横浜で電動スクーター(電動キックボード)を体験してきた!

8月にサンディエゴに行った時に感動した電動スクーターシェアですが、日本でもAnyPayが福岡市で実験を始めるというニュースが流れてきました。

kawaguti.hateblo.jp

prtimes.jp

...という昨今なのですが、東京近郊でもはじめたいという熱い想いで「いまできること」からはじめている、Kimさんのスクーターシェアの情報をいただきまして、さっそくですが、試乗させてもらってきました。

f:id:wayaguchi:20190113130529j:plain

ナンバー取得済みの電動スクーター!公道を走れます(要原付免許、ヘルメット)

光栄なことに私たちが最初のユーザーだということです。わーい。 
機材はシンガポールの企業が作っているものに、ミラーやウインカーなどを追加で装備して、ナンバーを取得しているとのこと。

f:id:wayaguchi:20190113141153j:plain

説明を受けて、ヘルメットをつけて、公道へ!


Scoot20190113

電動スクーターは、スクーターみたいに場所取らないので、都市部の足に最適なんです。荷物は載せられないので、観光とか、通勤とか、ちょっとした足に最適です。自転車より全然楽しいし、個人的な感覚では歩道を走ってくる自転車よりも恐怖感がないです。


電動キックボードでみなとみらい走ってみた 

もう自動運転までは次のイノベーションはないんじゃないかとおもっていたモビリティ業界に、彗星の如く現れた電動スクーター。アメリカではすでにBirdとLimeがユニコーン企業になっています。日本でも乗れる日が来るといいなぁと思います。

www3.nhk.or.jp


毎週末に横浜で試乗会をやって、少しずつ認知を広げていきたいとのこと。

ぜひ体験してください。正式サイトオープンだそうです。

hop-on.jp


P.S. もう100kmも走ってるのか!

#7 都内で電動キックボード100km走って見てきた景色|chocopie116|note

 

 

 

RSGT2019 も Day3(金曜日) はオープンスペーステクノロジーとクロージングキーノートです

Regional Scrum Gathering Tokyo 2019 は今週水曜日から開催です。チケット、スポンサー枠ともに完売しております。皆様のお越しをお待ちしております。

confengine.com


Day3は、昨年から復活しました、オープンスペーステクノロジーを行います。
概要は昨年と同じです。

kawaguti.hateblo.jp

OSTは事前にアジェンダを決めないセッションです。その場にいる人が議論したい内容を提案し、自分でセッション枠を割り当て、自己組織化でセッション表を作っていきます。OSTスクラム "ギャザリング(集まる)" の象徴ともいえるセッションの1つで、海外で行われる Global Scrum Gathering では定番となっており、近年ではさらにCSPやCSTだけが集まる前日イベントでも同様の形式が取り入れられています。実践者自らが未来を考え、同じ課題を持つ人同士が繋がりあう、この"ギャザリング"とクロージングキーノートをもって会期を締めくくります。

f:id:wayaguchi:20190107153102j:plain f:id:wayaguchi:20190107152958j:plain

f:id:wayaguchi:20190107152935j:plain f:id:wayaguchi:20190107152901j:plain


クロージングキーノート

クロージングキーノートは、ヤッホーブルーイングの井手社長です。「13年連続増収増益・国内クラフトビールNo.1」のチーム作りについてお話しいただきます。もちろんクラフトビールで乾杯しましょう!

confengine.com


今年も皆さんによってよい場所になればと願っております。
では、会場で!

経営者がITを学ぶインパクトは、プログラマが経営を学ぶより大きいかもしれない

前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。

kawaguti.hateblo.jp

さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。

 

リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか

前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。

ビジネスマンがプログラミングを学ぶ価値 

アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、1週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。

togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。 

confengine.com

これらの例に対して(だと思いますが)、IT技術者が経営を学ぶ方が早い、というご指摘をいただきました。この点はまったく同意です。

個人のキャリアパスでいうと、経営や管理手法を先に学ぶより、まず基盤となるコンピュータサイエンスや数学や統計を学んでおく方がスムーズかなと思います。すでにIT技術者としてキャリアを積まれている方が、経営について学ぶほうが、ビジネスマンにITを教えるより早い感じがします。

なのに、なぜ逆手順ともいえる例を紹介したのかといいますと、組織の観点で考えた時に、経営側・マネジメント側の主流がITに明るくない人だった時に、どうやってIT側の人を必要な職につけるのか?という大きな課題があると感じたからです。

誰がITに明るい人間をマネジメントに引き上げるのか?

前のエントリでも Microsoftの例を出しましたが、以前のスティーブ・バルマーCEOはマーケティングやセールスの側の方と聞いています*1。そのバルマー前CEOの下で、自社WebサービスBingやAzureを立ち上げてきたのが現在のサティア・ナデラCEOということです。有能な雇われCEOがポッと組織に入っていきなり社長になったわけではなく、実ビジネスをやりながら昇進のステップを踏んで、CEOになったというわけです。

多くの大企業で、同様に社内評価をえながら、同社を任せるに足る実績とビジョンを持った人材を育て、いずれ組織長に据える、ということを理想としていると思います。その人物が何者なのかを事前に見極めるステップがあります。次に優れたリーダーが選ばれるためには、その前に選球眼を持ったリーダーが必要になります。

任天堂の故岩田聡さんを社長にしたのは、創業2代目で花札の会社からテレビゲームの会社に導いた山内溥さんです。ファミコン初期から実際にゲームをプログラミングしてきた本当のハッカーの社長登用(その前のHAL研究所の支援の経緯も含め)は大きな決断であったろうと思います。

matome.naver.jp

www.mag2.com

ナデラ氏や岩田さんを社長に据えたバルマー氏や山内さんの選球眼が鋭かったことに反論の余地はないと思います。そして彼らは、もともとコンピュータ技術者であったわけではありませんエンジニア出身のリーダーを、彼らが引き上げていなければ、エンジニア出身者が社長になることは、なかったわけです。

最近の日本の事例だと、DMM.comの亀山さんがピクシブ創業者の片桐さんを社長に登用したのも記憶に新しいところです。

logmi.jp

f:id:wayaguchi:20190105034307p:plain

翻訳者がいいリーダーになるとは限らない

ところで業界には「ITに明るくない人に上手に説明する、そこそこITがわかっている人」というのが大勢いらっしゃいます。プロジェクトマネージャーとか副部門長とかをされてたりするかもしれません。コンサルタントさんかもしれません。パワポが上手で、細かいところをさっと端折って、AかBか選べば経営判断下せる感じにしてくれる人たち。ITがわからない経営陣にとっては手放せない存在であることでしょう。

一見、優秀そうな方々なのですが、経営やマネジメントを任せた途端にボロを出してしまう方もいるようです。たとえばこんなような理由が思い浮かびます(実例ではないです)。

  • 上を見て仕事をしていて部下に人望がない
  • 資料はまとめられるが本質の理解がない
  • 他人を信用出来ず、任せるのが不得意
  • リーダーシップ経験がない
  • たんに権力が好きすぎる

自分の言うことを聞いてくれた人をリーダーに据えるパターンは、なかなかうまくいかないというのは想像しやすいところかなと思います。

全部当たるわけではないけど、数を増やせば当たりも増える

選球眼がだいじという話でした。選球眼を養っていただくためにも、ビジネスマンがITを実体験することで、共通言語を持つことはとても大事だと思います。もちろん、現役の経営者やリーダーが少しでもITに明るくなることは、組織にとっても即効性が高いのではないかと思います。話が通じるだけでずいぶん働きやすくなるわけです。

そして、数の問題があります。IT技術者の数を増やすことも重要でしょうが、ビジネスマンの数はもっと多いので、ビジネスマン自身が積極的にITを学んでいけば、何倍も早いスピードで業界が変わっていくのではないでしょうか。その学習への投資が、将来的に無駄になるとも思えないので、個人としても組織としても積極的に投資して良いのではないかと思っています。あ、翻訳者を増やすためのパワポやレポーティングばかり学ばせてもダメかもしれませんけれど。その点は人事/教育研修担当さんの選球眼も必要になりますね。

モブプログラミング体験会で得られた反応

ところで、ビジネスマンの方々で、プログラミングの現場を直接見たことがある人ってどのくらいいるものなのでしょう?ポストイットを壁に貼っているアジャイルの現場を見た、ということではなく、コードを書いている現場や、コードそのものを見た経験のことです。どうでしょう?

2017年から自分たちでも取り組み、様々な形で紹介してきた、モブプログラミングという仕事の進め方があります。これは一箇所に開発者も企画者も集まって、一緒に作業を進めていく、という考え方です。会議の時だけ集まって資料を見ながら議論をするのではなく、常にそこにいて、仕事の状況を把握し、いつでも質問や議論を進められる状態を保ちながら、コードも書いていきます。


A day of Mob Programming

この手法を編み出したのが 米Hunter Industries。スプリンクラーの大手企業です。CEOがWoody Zuill氏にIT部門の再生を託し、あるチームが成功を納め、そのやり方を全体に広めたものだそうです。

私が所属していた楽天の部門でもこれを取り入れました。そして、さらに多くの人に広め、仲間を集めるべく、見学会を多数おこなってきました。(この点もHunterから学んだことです。)

ある見学会の時に、プログラマー出身じゃない方からこう言われたことがあります。

エンジニアの人って、一日中パソコンに向かって打ち込んでいるのだと思ってました。 

その方ももちろん、キーボードを握ってコードを書いていただいたのですが、それだけでなく、観察によって、プログラマーがどのように仕事を進めているのかを発見されたようです。逆にいうと、こんな基本的なことも私たちは共有できていないのか!と気づかされました。まさに現地現物です。現場に行って、見てみるだけで、こんなことも発見できるのですね。

ビジネスマンがITを学ぶのは大変かもしれませんが、モブプログラミングをやってみることは、それほどハードルは高くないと思います。それだけでも、多くのことが学べるのだとわかりました。

モブプログラミングについては、昨年のDevelopers's Summitで実演を行い、ベストスピーカー第2位に輝きました。

speakerdeck.com

 

本場HunterのDirectorが来日するので、モブプログラミング体験会をやります

また、これは宣伝になってしまいますが、Hunterの現役DirectorのChris Lucian の来日に合わせてモブプログラミング体験会を行います。Chrisは上のビデオで「Driver」の吹き出しのところにいる人です。

ご興味のある方はぜひ実際にどうやっているのかを覗きにきてみてください。ほんとうは現地に見にいくのが一番学びが多いと思いますが、全員がそうすわけにもいかないと思いますので、電車で行ける体験の機会を生かしていただければと思います。

www.eventbrite.com

 

さいごに、新しいことを理解するには

多くの企業で、ITが急速に経営課題になってきたのが、この20年くらいの変化だと思います。さまざまな業種の方が、ITをさまざまなレベルで理解する必要が出てきました。なぜなら、それが仕事の重要な一部になったからです。

何か新しいことを理解するために必要なことは、まず第一歩、学び始めることです。人間は、今持っている知識を元に、新しいことを学ぶので、下手でも苦手でも、まずは第一歩を学んでみることが、大事なのかなと思います。

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄, 三宅なほみ 『教育心理学概論』 第一章 P.13-14) 

kawaguti.hateblo.jp

 

また長くなってしまいました。みなさまの参考になれば幸いです。

*1:ただ、日本にきた時に「Developer! Developer! Developer!」と連呼するなど、開発者の重要性は同社の根幹をなす、という感覚は持たれていたようです。

業務知識とIT知識を分けて考える時代は終わったんじゃないか

昨日のエントリは思いがけずアクセスをいただきまして、はてブホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。

kawaguti.hateblo.jp


この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。

SIerで業務知識といえばお客さんの業務に関する知識

システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か?みたいなエントリが盛り上がってました。

d.hatena.ne.jp

業務知識は業務実現に必要な知識すべて ... だと思う

私はSIerにいたことがないので、そのあたりどうも疎いのですが、私としては「業務知識といえば、業務実現に必要な知識すべて」のことで、それは担当する業務によって変わってくる、ということではないかな、と思っております。そういう筋で前回のエントリを書きました。

もちろん、SIerの業務であるところの「ユーザー企業から発注をもらってシステム開発をする業務」においては、業務知識といえばお客様が実現したい業務に関する知識ということになろうかなと思います。ドメイン知識とも言ったりしますね。

で、そう考えると、マネジメント層にとっての業務知識は、部下や組織をマネジメントするために必要な知識、という感じではないかなと思います。前回のエントリで参照した米Microsoftの河野さんの話でも、マネージャーにとっての主たる業務はそこにあるようです。

logmi.jp

IT知識と業務知識って分けられなくなってきた

私の業務知識に関する認識は上記のようなものなのですが、その前提で、さらにIT知識というものをどう捉えるか、というところに前回エントリの主題がありました。伝わるように書けてなかったみたいですけれど(ごめんなさい)。

全ての業務にITが入り込んできているので、もはやIT業務を明確に分解することが難しく、業務知識の範疇にITの基本的な理解が入り込んできている、ということです。

マーク・アンドリーセンが書いたように「ソフトウェアが世界を飲み込む」の時代なので、あらゆる業務がITを一緒に考えないと回らないようになってきている、もしくは、ITをうまく使わないと競争に勝てない/儲からないというところに来ている、ということかなと考えております。(池田信夫 blog : ソフトウェアが世界を食う に一部日本語訳がありましたのでそちらもご参照ください。)

a16z.com

っていうことで、「業務知識の一部となったITがわからない経営層やマネジメント層のままで大丈夫か?」というのがエントリでの核となる問いでした。

経営陣がIT知識を持っていて瞬時に判断ができるグローバル企業との競争 

経営やマネジメントにIT知識が必須だなんて言っても、急に関係者のみなさんがITに詳しくなるわけでもないので非現実的と思うかもしれません。GAFAじゃないんだし。私もそう思ってました。Microsoftに遊びに行くまでは。

少なくとも米国で時価総額一位に返り咲いた米Micriosoftでは、エンジニアの上司はCEOまで遡ってもエンジニアないしエンジニアの言葉がさっと通じる人になったみたいです。現在のサティア・ナデラ氏がCEOになったのは2014年だそうです。30年企業ですので、それなりに分厚いマーケティング企業になっていたところを、グッと技術側に引き戻したのがここ数年の躍進につながっているのではないかとおもいます。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

 

日本でも2013年に創業したメルカリや、AIで躍進するPreferred Networks(2014創業)などは、同じように経営陣までその言語で通じる人たち、な感じがします。もはや業務知識とIT知識を分けるというマインドはかけらも持ってないんじゃないかと思います。

ビジネスマンがプログラミングを学ぶ価値 

アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、1週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。

togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。 

confengine.com

そんなような話をユアマイスターの高山さんにお話ししたような気がするのですが、そのあとブログにこんなことを書いてくれました。ビジネス側でキャリアを積んできた方からみても、腑に落ちる点があったようです。

takayamamusashi.hatenablog.com

結局、話が通じる組織が強そう

業務知識とIT知識の話から、長い話をしてきましたが、IT知識、開発、営業、文系、理系 ... クロスボーダーで理解し話し合わないと解けない問題が主戦場になってきた、というのが背景にあるかなと思います。ひとことで言えば、業務に関して話が通じる組織が強いということかなと。あれ、これは別に新しいことでもなさそうです。

自動車会社でいえば、現地現物や三現主義。クルマやユーザーの話が通じることを大事にしているわけです。米Microsoftであればソフトウェアやそれを開発する人々について、すぐ判断ができるくらいは知っていないと、マネジメントは開発者をサポートすることができません。簡単なことではないと思いますが、それを維持している企業が時価総額の上の方にいる感じがします。

業務知識とIT知識で分けて考えるのは、そんなに普遍的な話でもなさそうだし、あったとしてもそんな時代はとっくに終わっているのかもしれません。

金融機関とかはそうじゃない説

蛇足ではありますが、金融とかはそうじゃない...とおっしゃる方がいるかもしれませんが、AIでトレーダーが激減してみたり、当の金融機関の方はそんな悠長なことは考えてないと思います。
gigazine.net

えっと、業務知識ってなんの話でしたっけ。

SI業界が開発するシステムの目的は何か? それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。

https://aike.hatenablog.com/entries/2008/06/15

ああそうでした。それは多いでしょうね。でも必要な知識だと思います。持たなくても食っていけるっていうのは、SIerの非常に限られた世界の常識に過ぎず、しかも、そもそもそれすら間違いなのではないかと思いました。

業務とITはもうとっくに切り離せないのだとすると、「こっから先は学ばなくてもよい」と言っていた領域がいろいろ言い訳できなくなってきてしまうなぁ、と言う感じがします。すくなくとも、相手と話せるくらいの理解がある方が、仕事が進めやすそうです。小学生向けにプログラミングを教える時代です。教材はたくさんあります。

 

ということで、またも答えはないわけですが、今後のヒントになれば幸いでございます。

 

(追記) さらに補足を書きました

kawaguti.hateblo.jp

 

 

業務知識を持たないリーダーで大丈夫か?

2017年1月に米Microsoftに遊びにいって感じたことを、そのあといろんな人に伝えてきたのですけど、ブログには書いていなかった気がしますので、年頭にあたり書いておきます。

f:id:wayaguchi:20190102225644j:image

機動警察パトレイバー アーリーデイズ | Netflix (ネットフリックス)

ツアーの際に現地で講演してくれた方の1人が河野さんで、ありがたいことに翌年のRSGTで基調講演していただきました。(もう1人Chap AlexはDevIpsDaysでお呼びできました。)

米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1 - ログミーTech

ここで痛感したのは、ビジネスに必要な業務知識を経営層・マネジメント層が持っていないと、もう儲からないんじゃないか?ということです。ソフトウェアに関する業務知識というと、コンピュータサイエンスだったり、もうちょっと基本的なレベルで、エンドユーザーに価値を感じてもらうことを、プログラミングを通じて実現するという行為を、自分ごととして認知可能かどうか?ということにあたるのではないかと思います。

 

「かわぐちくんの言うことは難しすぎる。私にわかるように説明してほしい。」

これまで社会に出てから、このような質問をいくつか受けてきた気がします。アジャイルの文脈だと「どうやって上司に説明したらいいでしょう?」という質問は必ず出てきます。いまやソフトウェアが関係しないビジネスはほとんどなくなったわけですし、なんらかのソフトウェア開発(Excelかもしれないし、自動生成のものも含め)とその生成物のマネジメントは必須の知識だと思うんです。わからないのが普通ではなく、危険なことなんじゃないかと思うんです。そして、多くの日本企業には機能不全のリーダーを見つけ出す仕組みとしての360度評価がありません(360度評価は多面的評価の仕組みではなさそう - kawaguti’s diary )。危険は危険のまま放置されて、スキルのある若手社員の絶望を生み出してしまっているかもしれません。あたりまえを疑うには、他人の言葉ではなく自分自身の目と耳で現場を見ることが必要で、理解するには業務知識が必要なのだろうと思います。部下や業者に求める業務知識を当事者の方々は持っているのでしょうか?学ぼうとしてきたのでしょうか。

 

エンジニアの環境がどうこう、給与・待遇がどうこうという話は、それはそれで大事なんですけど、お金や予算以前に、話が通じるか?が大事なんじゃないかと思います。「お前コード書いてんの?」という話でもたぶんないです。

これから景気後退局面に入るようです。そういえば、シリコンバレーで2001年のネットバブル崩壊後に伸びていた企業はGoogleVMwareだという話も聞きました。トップは創業者であり、ITサイドのネイティブで言葉を理解する人たちでした。テクノロジーを使ってもっと活人・活スペース(山田日登志さんの言葉)を進められる実行者に利があります。同じ価値をもっと効率的に生み出せるのです。

ちなみに、ソフトウェア業界経験は長いけど、指示出しとかマネジメントしかしてない人たちもいらっしゃって、こういう方々はわからない人にわかりやすく説明してくれるものの、効率化はしない傾向があります。そして、どんどん付加価値のない人を増やす傾向もあり、注意が必要です。組織ばかり作っても、製品はよくなりません。儲からんのです。あれっ?と思ったら、ちょっと考えてみてください。

 

皆様のご健勝をお祈りしております。

 

 

 

(追記 “業務知識”の使い方が違うというご指摘をいただきまして、補足的なエントリを書きました。)

業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary

 

2015年の Rakuten Tech Confの後の感想

Facebookから出てきたので貼っときます。特に深い意味はないです。あーそんなこと考えてたのかぁ。

年末最終日に2つ3つ請求書の処理をお願いして、TechConfのあらかたの作業が終わった(気がする)。請求書系は膨らむことを覚悟してたけど、きっちり仕事できる人達が動いてくれたおかげでほとんど自分でやることはなかった(多少のカバーだけ)。後回しにしたやり残しが2つあるけど順々に。様々な人々に明示的にも自働的にも動いていただいて、自分に全体が見えきっているかというと全然そうじゃないし、決して平坦ではなかったし、途中で誰かが気づいてカバーした課題は多量にあったし(見えてないところもきっと多量にあっただろう)、問題がなかったといえば全くもって嘘になるけど、昨年よりはいくつかうまくできたんじゃないかとも思う。そういうのは昨年やってない人には見えないだろうし、未経験の人にとって難しいのもとても認識した。こだわりたい(やるべきという義務感がある)ところにそこそここだわれるように、というように(個人的には)お任せしたいと思うのだけど、それじゃわからんという反応ももちろんいただいて、そりゃそうですよね私もわからん、という件は結構あったけど、結果的にはいい感じにしていただけたので、みなさんすごいな、と勝手に思う。初年度から、誰も燃え尽きないカンファレンスにしたいとだいたいいつも言っている気がするんだけど、そんなん聞いてないよという人もいるだろうし、実際にうまくいってないところもあったと思う。怒られたところもあった。ごめんなさい。そういう部分はたぶん来年やりたいって言ってくれないはずなので、対応が必然になる。ツーマンセル、スリーマンセルで動けるようになっていけばノウハウが引き継がれるのだろうけど、役割的に多重化できてなくて、人がばさっと抜けちゃう部分は難しい。ともあれ、会として(外から見る限りは)大きな事故も怪我もなく終えられたことに、1メンバーとして大変感謝しております。ありがとうございました。

「去年やったからって今年も当然できると思っちゃ困るよ」って2年目に言われた気がするけど、それは自分でも毎年思っている(すべての仕事に対して)。必要でないならやらないし、実際担当できるかもわからず、確定要因はない。病気するかもしれないし。

失敗を許容するファンディング

昨日はカンファレンスのキャッシュフローについて書いてみたのですが、意外と大変という反応もいただきました。

カンファレンス運営のキャッシュフロー - kawaguti’s diary

これは考えようなのだと思いますが、私が一番避けたいな、と思うのは、こういうことです

  • 答えのない問題に、集団で悩む
  • 誰かにご迷惑をかけて、平謝りする
  • ご支援をいただく代わりに精神的物理的な対価を求められて気を使う
  • 忙しくて、楽しめない
  • なにか価値のあることをやりたくなった時に、できない
  • 誰かの責任を問う
  • あらゆる意思決定にフィルタを入れる(常に慎重を期すとか)
  • 状況がわからないまま議論する
  • 未来を信じてとにかく走る(強迫観念)
  • 不安で死にそう
  • 孤独で辛い
  • 誰かのために自分を犠牲にしている感覚に酔う
  • 徒労感
  • 「大変だったけど終わったから忘れよう!」

これら避けたいことの、割と多くの部分が「具体的で実現可能な案があれば発生しない」んじゃないかと思っています。そして、そのような具体案の実現性を維持するために「資金的なリスクと余裕を適切に管理できている」「タイミングが良い」というあたりが重要なのだと思います。(わぁ、プロダクトオーナーシップっぽい!)

そこに向けての具体的なプラクティスとして、タイムラインを引いてキャッシュフローを管理することが有効だと考えています(カンファレンス運営のキャッシュフロー - kawaguti’s diaryはそのお話でした)。そして長期的には、将来に向けての余裕を作っておくことも、やっておけるといいなぁと思います。

もちろん各回のカンファレンスを良い場所にするということが第一のゴールなので、それを満たした上で、ということになりますが。

f:id:wayaguchi:20181228052019j:image

多少の失敗は許容できるカンファレンス運営にできるといいなと思っていて、そのためにちょっとだけお金のことを考えるだけでだいぶ楽になりそう!....なんて考えてまして、そういうことがおすそ分けできたらいいなと思って、ブログにしてみました。

f:id:wayaguchi:20181228051200j:image

蛇足ですが、法人税まで払っていたりします。日本の財政は世界的にもやばいレベルっぽいので、ちょっとでもお役に立てれば幸いです。微々たるものですが。

ボランティアワークでなければそんな余裕も生まれませんので、スタッフの皆さんに本当に感謝です。

 

あ、さらに蛇足ですが、Beyond Budgeting (脱予算経営) という概念について - kawaguti’s diary あたりもちょっと念頭にあります。