ぜぜ日記

ブログです

ビジネスモデルとしてのプラットフォームの分類

1. プラットフォームを整理する目的

プラットフォームという言葉はあいまいです。同じ言葉を使っても、思い描くプラットフォームが違っていて会話が噛み合っていない場面を2,3回経験しました。

自分も、坂ノ途中にて、環境負荷の小さい農業に取り組む生産者さんと買い手をつなぐプラットフォーム、ファーモを開発する中でいろいろ悩んだり迷子になったりしてきました。プラットフォームの概念を整理して、建設的な議論するための土台とするために書いてみます*1。学術的ではありません。プラットフォームを成長させるための手段については別記事で整理する予定。

"platfome"のもともとの意味は「たいらな土地」。駅のプラットホームもこれで広い意味があります。「基盤」と訳されることもあってさまざまに使われています。 投資家やメディアに受けるバズワードとして流行ったことも原因。たしかにプラットフォームという言葉はかっこいいし、「基盤」も日本人が大好きな言葉。自分も好きです。

この記事では、ビジネスモデルとしてのプラットフォームについて扱います。ビジネスとつけてはいるけれど、ちょっとだけ行政主導のものも含みます。

また、この記事ではコンピュータのOSやハードウェアなコンピュータプラットフォームは扱いません。 wikipedia英語版の記事が事例も多いのでよければ参照してみてください。ただ、OSやゲームプラットフォームなどビジネスモデルとしてのプラットフォームと境界が曖昧なものもあります。

Computing platform (Wikipedia)

2.プラットフォームの定義

近年、AirbnbUberの急成長を受けて、そのようなマッチングをベースにしたサービスのことをとくにプラットフォームと呼ぶむきがでてきて、本も多数出版されています。3冊読んだので紹介します(まあまあ時間がかかった・・・)。

ひとつはアレックス・モザド、ニコラス・L・ジョンソンによる「プラットフォーム革命」*2

本書ではこう定義しています。

プラットフォームは消費者とプロデューサー(モノやサービスやコンテンツを作ったり提供したりする人) を結びつけて、モノやサービスや情報の交換を可能にするもの

その詳細として、こうも書いています。

プラットフォームとは何か。それは複数のユーザーグループや、消費者とプロデューサーの間での価値交換を円滑化するビジネスモデルだ。この交換を実現させるために、プラットフォームは、ユーザーとリソースからなり、好きなときにアクセスできるスケール化可能な大型ネットワークを作る。また、プラットフォームは、ユーザーが交流し、取引ができるコミュニティーと市場をつくる。

次いでジェフリー・G・パーカーらによる「プラットフォームレボリューション」という似た邦題の本も出ています。 原題はそのまま"Platform Revolution"なので前述の本が先にプラットフォーム革命という邦題で出版されたとき出版社は困ったのではないかと思います。サブタイトルは"How Networked Markets Are Transforming the Economy"。

本書での定義。

「プラットフォーム」とは、外部の生産者と消費者が相互にインタラクションを行うことにより、価値を新たに創造することを基本とする。プラットフォームは、相互に関係しあえるようなオープンな参加型のインフラを提供するとともに、そのインフラのガバナンス(統治) の条件を整える。プラットフォームの全体的な目的は、ユーザー間で完璧なマッチングを行い、製品やサービス、社会的通貨を交換しやすくして、全参加者にとって価値を創造しうるようにすること。

プラットフォーム革命と同じような内容です。ビジネス書としては、こちらのほうが洞察や事例が豊富な印象でどれか一冊読むならこれがおすすめです。

3冊目はセカンド・マシン・エイジの著者アンドリュー・マカフィーらによる「プラットフォームの経済学」。 原題は"Machine, Platform, Crowd :Harnessing our digital future"なので、直訳して機械(AI)、プラットフォーム、群衆と並んでいるものからまたもやプラットフォームがフォーカスされている。日本人はプラットフォームが好きだと出版社が判断したんでしょう・・・

本書での定義はこう。

プラットフォームとは、アクセス、複製、配布の限界費用がほとんどゼロのデジタル環境

それってデジタルコンテンツそのものでは?ただ、特徴としてはこうも書いています。

ハイペースで成長すること、そしてプラットフォームの所有者と参加者の両方に価値を提供できること、としています。そのほか、1 早い時期に地位を確立する。 2 可能な限り、補完財の優位性を活かす。3 プラットフォームをオープン化し、幅広く多様な供給を募る。 4 参加者に一貫性のある心地よいエクスペリエンスを提供するために、供給サイドに対して一定の基準を示し、審査をする、という特徴を備えている

定義では広すぎますが、供給サイド、参加者、という言い方からマッチングを想定しているようではあります。

前2冊の定義は、ヤフオクやメルカリなどのオークションのほか、クラウドワークスなどのクラウドソーシングがわかりやすいですね。

流行語にもなっているGAFAだと、広告主とWeb閲覧者を結びつけるGoogleアプリ開発者とユーザを結びつけるAppleGoogleandroidも)、出品者と購入者を結びつけるAmazonAWSについてはこの定義には沿わない?)、コンテンツ作者と読者を結びつけるFacebook(記事を作成しない最大のメディアでもある)はプラットフォーム。

これらの定義に従うとeBayなど、2000年以前からあったサービスも多いですが、近年、プラットフォームというカテゴリがつくられて盛り上がっているのは、AirbnbUberが社会問題になるほど世界に影響を及ぼしてきたからではないかと思われ実際に3冊とも、この二社の事例にかなり紙幅をさいています。ビジネスモデルとしては手放しに称賛していますが、コロナの直撃したAirbnbやgig workerの労働問題が社会問題になっているUberなど一筋縄ではありません。

ただ、2冊ともプラットフォームとしては営利企業が運営するWebサービスを念頭においているようで例としてもITスタートアップについてしか触れていないのは狭いと感じます。例えば、日本では公設でも民営でも卸売市場は消費者とプロデューサーを結び付けているし、ハローワークも近い。もちろんどちらも物理的な場所の制限があり、各書でプラットフォームに期待している資産を持たないことでの青天井のスケーラビリティはないという違いはあります。

補足:プラットフォームではないもの

ちなみに、前2冊は、プラットフォーム"ではないもの"に名前をつけています。プラットフォーム革命では「直線的なビジネスモデル」、プラットフォームレボリューションでは「パイプラインビジネス」。どちらも、ものやサービスを生産者から仕入れて、それを加工するか仕分けるか調整して付加価値をつくって消費者に販売するビジネス。トヨタラーメン二郎も農家も同じです。そしてプラットフォームはそうではない。

そして、誤解されやすいのですが現代のソフトウェア企業の多くとSaaSのほとんども、商品はデジタルだけれど、その価値は企業から顧客へと一方向に流れていく直線的ビジネスです。大きな違いは、ソフトウェア企業は、ITによる限界費用の安さから恩恵を得ている点。と、プラットフォーム革命では書いています。

プラットフォームかアプリか、と表現することもありますが、FacebookGoogleAmazonの例にあるように、アプリとして覇権をとることがプラットフォームにつながる道でもあるので二者択一ではないと思っています。

もうひとつ違うのは、プロダクト・プラットフォーム。これは、複数の商品の基礎となる共通の製法や部品です。たとえば、トヨタのTNGA(Toyota Next Global Architecture)*3。プラットフォームレボリューションではこれらをプラットフォームと呼ぶのは誤用とまで書いていますが、もともと定義もなく広い意味の言葉なので誤用は言い過ぎかとは思います。

重要な要素:拡張性について

拡張性、第三者による開発のしやすさはプラットフォームの重要な要素であって、一番プラットフォームについてのイメージがわかれる原因だと思います。

これの有無がプラットフォームかどうかを分けるわけではないけれど、質を変えうるもの。 たとえば、初期のTwitterではAPIを公開することでサードパーティTwitterを利用するさまざまなアプリを開発できてエコシステムができてユーザを増やすことができた。

また、SalesforceFacebookではプラットフォーム上でサードパーティアプリをプラグインすることで機能を拡充してサービスとしての魅力を高めました。 日本だとfreeeも取り組んでいて多数アプリがそろってさまざまな外部サービスと連携できます。ソニーのカメラもアプリストアがあります。

これ自体がプラットフォームの目玉となっているものにAndroidGoogle PlayiPhoneapp storeがあってマーケットとして成功していますが、app storeはフォートナイトともめています。いち民間企業のマーケットがデファクトスタンダードになりつつあっての社会的責任をどれくらい持つべきか議論になっています。

プラットフォームレボリューションでは、これを、インテグラル型ではない、モジュール型のプラットフォームと表現しています。 自分は、ソフトウェア開発の、伽藍とバザールでいう、バザールモデルに近いのでは、と思っています。

伽藍とバザール(The Cathedral and the Bazaar) 山形浩生訳

特に、初期の、APIを開放したTwitterや、SNSとしては後発ながらプラグインで機能を拡充して覇権をとったFacebook。 ただ、プラットフォーマーは胴元としてベンダーの生殺与奪権を握るという意味では、みな中央集権で、TwitterAPIを閉じたりしてサードパーティを切り捨てたり、FacebookAPIを急に変えて参加企業を閉鎖に追いやったりして、真の意味でのバザールモデルではありません。

本当のバザールモデルでやっているプラットフォームがあるかどうかは気になっているのでよい事例あれば教えてください。GitLabは近いけれどちょっと違うかな。

余談ですが、このあたりはネットスケープ創業者のマーク・アンドリーセンがプラットフォームには3つのレベルがあるとしている2007年の記事とつながっています。彼はプラットフォームを「プログラミングできるもの」として定義しているので今回対象とするプラットフォームとは違いますが着眼点は鋭い。*4

www.atmarkit.co.jp

3. プラットフォームの分類

さて、ようやく定義がでそろいました。各書でも微妙に違ったり、ちょっと不満なところもあるので自分なりにまとめていきます。漏れもあるし重複もあります。

プラットフォームレボリューションでの、交流型・交換型・交差型という分類と近いですが具体例がなく交差型がなんなのかはわかりにくいので名前も含めて分類しなおしています。

3.1 交流型プラットフォーム

  • 情報を書くひとと消費するひとをつなげるサービス。大多数のSNS。自分と多数という意味で1対多。
  • だれかと交流できるから、プラットフォームの価値が向上していく。
  • 生産者と消費者の区別がない。ただ、instagramcookpadのように、カリスマ生産者については後述のコンテンツ型とも近くなっていく。
  • 世界の例)FacebookTwitterInstagramなど
  • 日本の例)LINE、みてね、マチマチやsansan、爆サイはてなブックマークも?

3.2 マッチングプラットフォーム

  • 生産者と消費者を1対1でつなぐ。生産者にとっては、顧客を、消費者にとっては必要なものやサービスをすばやくマッチングできるからプラットフォームの価値が上がっていく。ツーサイドマーケットプレイスともいうらしいです。
  • 世界の例)ドライバーと乗客をつなげるUber、使っていない部屋と旅行者をつなぐAirbnbなどのシェアリングエコノミーをなすプラットフォームや、オンラインデーティングアプリなどのマッチング
  • 日本の例)メルカリ、ジモティー、クラウドワークス、ポケットマルシェなど。ハローワークもこの一種。
  • デジタルなサービスの場合、たとえばクレジットカードやモバイル決済もこの一種。

3.3 コンテンツプラットフォーム

  • 任天堂Netflixのような、コンテンツを作る側と、利用者が分かれているようなプラットフォーム
  • また、AndroidiPhoneのようなアプリのマーケットもこひとつ
  • 期待のコンテンツやアプリがあるから消費者は参加するし、コンテンツ提供者もそれでますます参入してくる
  • ゲーム、配信、また、交流型でもあるinstagramでもインフルエンサーのような、読者と読み手が分かれているものはこちら。
  • 映像コンテンツなどコンテンツのコピーが容易な場合、コンテンツ提供者は複数のプラットフォームに参加できるため、プラットフォームで覇権をとるのが難しいように思う。

3.4 メガプラットフォーム

  • GAFAM: GoogleAmazonAppleFacebookMicrosoft
  • BAT: Baidu, Alibaba, Tencent
  • 巨大すぎてうまく分類できないし、上触れてきた3冊の本でも意外なほど触れられていないんだけれど、これらの企業がプラットフォームだということに異論はないと思う。
  • 先にも触れているけれど、広告主とWeb閲覧者を結びつけるGoogleアプリ開発者とユーザを結びつけるAppleGoogleandroidも)、出品者と購入者を結びつけるECと、kindleで本の作者と買い手をつなぐAmazonAWSについてはこの定義には沿わない?)、コンテンツ作者と読者を結びつけるFacebook(記事を作成しない最大のメディアでもある)はプラットフォーム。MicrosoftはOS、Officeでつなげている。
  • そして、それらのデファクトスタンダードに近いサービスから、データとキャッシュを集め、関連サービスをつくってスタートアップを買収して多角化してさらにデータを集め強力になっています。
  • ただし、AppleiPhoneでは最初はappstoreをやるつもりがなかったことや、AmazonもEC、Facebookもアプリとしてはじまっていて、Google検索エンジンというアプリからはじまったことを思うと、どれも最初からプラットフォームになろうとは思っていなかったことは、メガプラットフォームに限らず、プラットフォームになるための重要な示唆があるように思えます。
  • これらの企業がある中で、これらの規模のサービスになる方法は、わからなさすぎますが、いわゆるスーパーアプリが近いかもしれません。

komugi.jp

まとめ

というわけで4つに分類してみました。それぞれマーケットごとに工夫があったり、エコシステムがあります。

では、プラットフォームをどうつくって、伸ばしていくか。成功したプラットフォームや失敗したものの振る舞いから成功するための方法論や知見が取り出せるはず。 次回、特にマッチングプラットフォームの伸ばし方について、各書や、自分が考えたことをまたまとめてみようと思います。 ポイントは、生産者と買い手をつなぐ一番重要な取引、いわゆるコアインタラクションに集中するか、だと思っています。

余談:行政のプラットフォーム

あとあと、上記の分類でうまく振り分けられなかったけれど行政もプラットフォームを冠する事業をいろいろやっています。 例えばこんな感じ。会議体からソフトウェアまでさまざまでこの文章で扱ってきたプラットフォームとは違うけれど。

近い領域でデータ提供者とデータ利用者をつなぐようなサービスは、存在すればプラットフォームだけれど、このデータのハブとでもいえるものは提供者やプラットフォーム事業者にとってお金になりにくく、どうすれば実現するかは悩ましく思っています。別サービスで成功してデータを収集したところが一機能として公開するのがわかりやすい道ですが、データの種類によっては行政ならでは仕事かもしれません。その場合、使われるものをつくるにはどんな座組が必要だろう・・・。

きわめて例外だと思うのですが、これくらい強いRFPが必要なのかもしれません。

togetter.com

*1:あと、3年前の自分に向けて・・・

*2:原題は"Modern Monopolies"で サブタイトルは"What It Takes to Dominate the 21st-Century Economy"

*3:いつもテンガと読んでしまう

*4:レベル1は、APIを公開しているサービス。例えば、APIを公開したことでサードパーティがアプリや関連サービスをつくることができたTwitterなど。レベル2では、プラグインが可能なもの。これはFacebookSalesforceなどサードパーティの開発者がそのプラットフォーム内でアプリをつくるもの。そして、レベル3では、開発者が書いたコードがすぐ動作できるものだとしてAWSに言及しています。この記事では名前はつけられていないけれど、このレベル3のプラットフォームは、後になってPaaS (Platform as a Service) と呼ばれ、GoogleAppEngineやHerokuのことを指すものです。これまでWebサービスを運用するためにサーバや環境を自前で調達していた時代から、アプリケーションのコードだけを用意すればわりあい手軽にWebサービスを運用できるようになるサービスでエンドユーザからはそのPaaSを意識することはないですむもの。自分も便利に使っています。このレベル1やレベル2は以下で述べるプラットフォームの武器のひとつでもあります。

パナソニックのベビーモニタ KX-HC705-W は便利だけれど難あり

子が2か月くらいになってきて、そろそろ、夜に大人が起きている間は暗い部屋で寝かせつつも、様子をみておきたい。 親が寝たときも別の部屋で寝かせたい、という思いでベビーモニタを買った。

暗くても映るし便利なんだけれど、いろいろ難がある。

よいところ

  • 暗くてもうつる
  • 子の声がモニターを通して聞こえるので別室で泣きだしてもすぐ気付ける
  • モニターにバッテリーがあってポータブルで便利
  • カメラを動かせるので向きを変えられて便利
  • スマフォとかでみる機能がないのは製品自体をシンプルにセキュアにしていてとてもよい気がする

暗いとこんなふうに映ります。目をあけていると、白目も真っ黒にみえてグレイのように見える。 f:id:daaaaaai:20200927000252j:plain

直してほしい

  • 映っているものが動くと動作センサーが反応するけれど、手を動かしたりあくびしたりでも反応する。感度は1-7まで段階があって選べるけれど、一番弱くしていてもよく反応するので動作センサーは切れるようにしたい。
  • 内蔵されている温度計が室温より+3-4度高い。これは本体が発熱しているからではないかと思う。実際にけっこう熱くなっている。排熱がんばってほしい。

ほかの製品

使って試せてはいません。 この記事で紹介されているベビーモニタがよさそうだけれど、Amazonで取り扱いされていなかった・・・

yulily100.hatenablog.jp

ほかの育児の話題

dai.hateblo.jp

育児2か月目の雑感

いつのまにか子も生まれてから2か月とちょっとたちました。 ここのところの感想。

先月 dai.hateblo.jp

成長

  • 顔立ちがしっかりしてきて人間らしさがでてきた
  • 焦点はあっていないけれど見つめて首を振る
  • まつげが長い
  • お風呂気持ちよさそうにする。一度だけ水をかけて大泣きしたけれどあとはずっとおとなしい
  • 夜の睡眠時間も長くなってきた。23時から6時まで寝る日が6日続いたり
  • でも夜中2時とかにぐずりだして1時間泣き続ける日もある。そういう日は消耗する
  • 最初の1か月の夜中は、3時間ごとにミルクやらねば、なにかあったら気付かねば、と思って張りつめていたけれど、ゆっくり寝れるようになってきた
  • 移動すると寝る。抱っこひも・車・ベビーカー、だいたいおとなしい
  • たまに、ほー、という声をあげはじめた
  • 相変わらず、おしっこや便をしていてもなにも表情を変えないのでちょっと心配
  • 人間らしくなってきている
  • ちょっとずつ変わってくるのがおもしろい
  • 妻としては、産前にはかわいがれるか不安だったけれどかわいいと感じてきているとのこと

生活

  • 動き出さないからまだ楽
  • 家事などもぼちぼちまわっている、気がする
  • でも料理してミルクつくって飲ませてオムツ変えて泣いたらあやして洗濯してとりこんでお風呂入れてまたミルクやって、としていると時間がどんどん過ぎていく。手抜き料理スキルをもっとあげないといけない
  • ミルクやオムツの消費量が思ったよりも早い
  • mixiの「みてね」をつかっている。便利、これをきっかけにスマフォを使い始めてコメントの文量が増えていく高齢者をみてすごいプロダクトだと感じる
  • コロナの状況的に正月に実家に帰れないかもしれないと思っていて、10月に落ち着いていたら顔を見せに行きたい
  • 内祝いは2か月以上たってから送った。一番懸案でした。ネットフレンズ各位には送ってません。ごめんよ・・・
  • 衣装持ちになった

  • 妻が何年か前に友人に出産祝いに送っていた服をまたもらってきておもしろい
  • そんなふうに、自分の世代で子どもを1人だけと決めているところが多い。実際、2人以上の子を親が無理せずに育てていけるイメージはわかない・・・
  • ともかくも親をしている方々への尊敬の念を強くする。みんなすごい
  • 妻の飲酒解禁された。相変わらずおいしいそうです。論文読んで調べてミルクスクリーンで確認して12時間あいていれば大丈夫と判断しているとのこと

保育園

  • 保活シーズン
  • 市役所に電話したら第1希望にいれるの難しそうと思えてきた
  • 第一希望のところは、去年は0歳児2名入園していて、2人とも点数はフルタイム共働きよりも一段上のシングルマザーなどらしい
  • 産前に2ヵ所みていたけれど、あわせて6か所くらいみてきた
  • きれいな建物で子どもが遊びに熱中しているところや、みんな元気だけれど、3-4歳くらいの子が男女問わず3名ほど性器を露出させてて不安になった浄土真宗系のところ、企業が運営しているコンパクトな小規模園、はいったらいきなり仏壇の見える和室で子どもが9人くらい遊んでいる民家っぽい小規模(奥でシャワー室とかキッチンとかはちゃんとしていた)
  • 一番印象的なのは保育士さんが0歳児にミルクをあげようとしたら2-3歳の子3名がそれを支えていたこと
  • 希望順位、迷う。どんなマッチングのアルゴリズム使っているか気になる
  • でも、前職のときに話できいていた東京と比べるとだいぶんマシなのだとは思う

里帰り出産について

前回は触れなかったけれど、じつは出産1-2週前から1か月目まで夫婦で妻の実家に住んでいた。 リビングにふすまでつながる和室で生活。プライバシーのあまりない空間だったけれど、ごはん作ってくれたり洗濯してくれてたいへん快適。ただ飯を食らっていただけではなく買い出しはしたし毎週2-3回くらいだけれど自分が料理をしてたいへん好評だったと申し添えておきます。子の様子もみてくれるし妻もしゃべり相手がいてよさそうであった。 自分はストレスなかったけれど、一日中家にいる妻からするとけっこうストレスがあったようで家に戻る。 自分も妻が出産で入院しているときにいたらさすがに居心地が悪かった。

もちろん、こんなことができるのは、妻の実家から自分が通勤できるからで恵まれている状態だとは思う。 コロナ禍でリモートで勤務できるというのもあるし、出社するときも、コロナで電車通勤を避けて(妻の)車を使えたというのもある。 特に東京で夫婦とも地方出身で子育てしている人たちほんとすごい。

便利グッズ

  • ベビーモニタ。便利だけれど、いろいろ不満もあるので別に記事を書こうと思う。
  • リッチェルのベビーバス。6か月までしか使えないけれど一番買ってよかった。溺れないし汚れた水につかり続けることもないしお風呂いれるのがかなり楽になった。ただ、冬は寒いかも?

そんな感じです。引き続きやっていきます。

出産と育児の一ヶ月の雑感

先にこんなブログを書いていましたが、その後、無事母子ともに無事で退院しようやく1ヶ月ほどたちました。

dai.hateblo.jp

センシティブな話題なので書くのに引け目もありましたが所詮は個人の日記なので個人の感想をいくつか書いてみます。

f:id:daaaaaai:20200716113151j:plain

出産のとき

ずっと逆子だったこともあって予定帝王切開。コロナ禍のなかで立ち会いや面会もできず不安な時期だったので、予定がたつ予定帝王切開は、妻としては安心だったようです。

出産後、配偶者のみ10分間の面会ができるのとのことで当日は会社を休んで病院前で電話を待っていました。しばし待ったのち電話で呼び出されて病棟へ。すれちがうスタッフさんがみなおめでとうと言ってくれます。廊下を進み小部屋にいる赤子とガラス越しに対面しました。ふにゃふにゃしています。足をぴんと伸ばしていたのですが、帝王切開だと伸ばしているものだよと、すれ違ったスタッフさんが聞いてもいないのに教えてくれました。

その後、妻の病室に行くと、みたことないほど蒼白な顔をしていてどきりとする。後から聞くと1300mlも出血したそう。やっぱり出産は大仕事でぞっとします。立ち合ってみたかった(胎盤を食べることもできなかったし)。

10分ほどたった後、病室に主治医の先生も現れていろいろ説明してくれました。先生はたぶん大丈夫、という雰囲気でニコニコはしていて安心しましたが、帝王切開中に筋腫をみつけてとったとのことで、小瓶にはいったピンポン球より一回り小さい白い塊をみせてくれました。ここで急に緊張を感じましたが後に1ヶ月検診で良性だったとの説明を受けます。

ここから退院までは会えず。これだけ長い間妻と会わないのは付き合って以来かな、と思いきや思い返すと去年の平成から令和に変わるときのゴールデンウィーク、妻は一人でフェリーに車を積んで北海道を一週間くらい回っていたのでそのときぶりだと思い直します。

一週間後、退院の日にひさびさに妻に会うと、なんだかきれいになってる気がしましたが、そう伝えると久々に化粧したとのことで照れ笑いをしていました。

今のところの育児

今のところの感想と発見です。

  • しばらくはミルクを欲しいときしか泣かなくてお行儀いいね、と言われたていたけれど、理由不明で泣くことも増えてきています
    • 義母からは育てやすい子、と言われたりもして、ほめられているのだとは思うけれど、妻にとって、育てやすい子なのにこれだけたいへんなのは自分の努力不足・・・と感じてしまいそうな言い方なので、そういうの言わないでくれ、という話をしました
  • はじめ3週間ほどは夜中も3~4時間おきに泣いて、そのつどミルクをあげないといけなくて、いろいろ準備していても睡眠は継続できなくてたいへん
  • ミルクのタイミング調整がうまくいってか、ここ数日は夜中に起こされることは減っていて穏やかになってきています。このまま続いて欲しい
  • 3週目くらいから目も大きく見開かれだして人間らしさがでてきています。蹴る力が強くなってきています
  • いっぽう、最初はミルクを飲んだ後のげっぷが上手だったけれど、だんだん下手になってきている
  • ここ一週間ほど便や尿が漏れるのが続いていて、オムツの種類やつけかたなど試行錯誤中
  • 哺乳瓶からミルクを飲むの、飲むのをあきらめた残りで自分も試してみましたがけっこうたいへん。うまく吸えないし、100mlを飲む競争をしたら子に負けそうです
  • 暑い時期なので湯冷めなども気にしないし洗濯物もすぐ乾くので助かっています

普段の家事に加えて、ミルク作りと消毒、オムツや沐浴などのルーティーンがあってさらに出生届や検診などのイベントもあってたいへん。 効率的に回していくための業務フローをつくって、義父母を巻き込んでいくのは業務改善の練習問題感があります。そして子の成長によってこれまでのやり方が通じなくなって変えざるを得なくなっていくのも、事業の成長によってオペレーションとシステムを変えていかざるを得ないスタートアップとちょびっと通じるものがある、気がする。

どうしても、仕事や学習にさける時間は減ってしまうので、もっと工夫したり集中力を高めないといけないし、これまで時間をうまく使えていなかったことに気付いてしまいます。

そう考えていると、地方出身者2人の共働きで都内の狭い部屋で子育てはかなり負荷が高そうに思えます。1人でもすごいし2人育てるのは偉業。みんなすごい。 しかし、まわりでは子ども1人と決めているところも多く、日本の少子化は加速する未来しか見えない・・・。どうしたらいいんでしょうね。なんとか工夫して欲しいし支援があってほしい。

今のところの便利グッズ

世の中でいろんな人が便利グッズを紹介しているので探すといいのですが、あまり触れられていないもの2つだけ紹介。

1.ホワイトボード
Amazonで1000円で買った小さいホワイトボードに、いつ、どれくらいミルクをやったか書いておくのがよかった。引継ぎもスムーズだし義母もサポートしやすい。見える化大事。 いろいろアプリもあるけれど、夜中寝ぼけ眼でスマフォを探すのが難しく・・・。

2.沐浴時にでかい計量カップでお湯をかける
洗面台で沐浴させているんだけれど、手でお湯をすくうと狙いがぶれて耳に入ったり口に入ったりしそうになる。そこで、計量カップをつかうとコントロールがよくなって頭も洗いやすくて便利でした。

この時期、自分の世代で出産ラッシュなようで、Facebookをみると何人も友人一家に子が生まれています。ただ、近所に同世代があまりいないのでよかったら親友(おやとも)になってください。もうちょっと育ったら相撲とらせましょう。

また、出産・育児あたりで思った価値観の多様さとか、冒頭に書いたセンシティブさについても別に書いてみようかな。引き続きよろしくおねがいいたします。

そろそろ、父になるかも。

日記です。 最近は妻のおなかに妊娠線予防クリームを塗る仕事をして暮らしています。 そうです。じつは妻が妊娠していて近々、出産予定なのです。

無事に生まれることを祈りつつ、準備をしていますが、いろいろ本やWebで調べたりTwitterをみていると妊娠や出産、子育てはそれぞれ人によって大きく違う困難があるようで、なかなか不安。

ここにきてようやく、自分の親の苦労を思うことができています。 自分がうまれたときのはなしは聞かずじまいでしたが、母が亡くなったあとに出てきた、自分を産むときにつけていた日記をいま読むとにやにやできる。 逆子で子宮口が開きかけているとかで出産2週間前から入院していたそうで、父や親類がえんえんお菓子を持ってきている様子がわかります。

その一節。

f:id:daaaaaai:20200710135125j:plain
日記

なんだかんだ、父は2週間毎日病院に通ったそうですし、母も父が来るのを楽しみにしていた様子です。 このコロナの影響の中、自分は立ち合いや面会は基本的にできず、当日に配偶者のみ5分間だけ母子別々に面会できるというだけ。

出産という命に係わる重労働をする妻の代わりはできませんが、一緒に子育てして楽しく暮らしていきたいものです。

とりあえずこの期間に気付いたこと。

・無痛分娩、まだ普及していない。無痛でもない。
・医療関係者(特に助産師さん)もさまざまな価値観の人がいてたいへんそう。母乳絶対主義・下から出産主義はちょっと母体やメンタルへの負担があってよくない気がする。
・妊娠も子育ても負担がすごそう。子育てしながら妊娠とか無理なのでは、と世の母親を尊敬する・・・
・以前から思っていたけれど、地方出身で東京共働きで子育て無理ゲーなのではという思いを新たにする。
不妊治療で苦労されている方、さまざまな過酷な環境の方がいることなどこれまで知らない苦労がある。うかつに子育て話はできなさそう。
・子どもの性質によって育てやすさは全然違うこと、世間(の一部)からの無配慮・無自覚な嫌がらせがあることはこれまで知らなかった。
・保活たいへん、だけれど、住んでいるところはまだだいぶんましの様子。
・なんかこれまで知らず知らずいろんな人を傷つけてきたかもなあ、と思えた。反省。。

このあたり。 また不定期でブログを書こうと思います。

読んだ本。

妻の同僚から貸していただいた。シリーズ8冊。古いけれどとても臨場感あって、たいへんさといっぽうでの手を抜いてもいいんだ感があってよい。

さらっと読めておもしろかった。

まあまあ定評のあるガイドブック。

世の中の問題について

世の中にはたくさん問題があって、苦しんでいる人がいたり、解決しようとする人がいる。なかには、放置することで利益を知らず知らず得ている人もいるし、ときには解決しようとすることが誰かに別の問題をもたらしてしまう場合もある。

今年は、世界中でCOVID-19の対応について揉めて、国内でも検察庁法改正やら、種苗法改正などSNSで大きな動きがあった。海外では香港の民主化運動にも大きな動きがあったし今はアメリカを中心にBlackLivesMattersが広がっている。

BlackLivesMattersは、日本にいると空気感がよくわからないけれど、公権力による人種差別のある殺人をきっかけに、大勢の人がデモをしたりSNSで声をあげている。

その中の一部には、デモに便乗して略奪する人や、逆にデモを扇動・激化させようとする人もいるという不穏さは見え隠れするけれど、これまでもデモをきっかけに時代が変えてきたこともあるし、社会の分断をひとつ減らせればいいなと思って応援はしている。

日本でも「#検察庁法改正案に抗議します」のムーブメントは、著名人を巻き込んでSNSで発生してニュースにもとりあげられたひとまずは採決を見送らせることができた。なかには批判もあるけれど、自分はすごいことだったと思う。

ただ、こういう政治意見を表明するのは、自分にはすこし怖い。 そういう理由と、自分が漠然と思っている社会の問題について書いてみる。

問題の複雑さ

理由のひとつは、問題の複雑さ。 例えば、先に触れた検察庁法改正案の抗議でも、これがほかの国家公務員についても影響し、長年議論されてきたものの一部ということは気付かなかった(それも含めても政府による恣意性はよくないと思うけど)。芸能人が反対の声をあげて話題になった種苗法改正についても、一部を取り出して主張する人の声に惑わされかけたけれど、ちゃんと意見をいえるまでには複雑な経緯と意図を追いかける必要があった。

技術の変化や法制度の変化、メディアの多様化が積み重なって世の中が複雑化していると思う。自分がよく知っている問題についてマスコミが誤った報道をしているのに気付いてしまうと、ほかの、自分が詳しくない分野の問題も誤っているものが少なからずありそうだと思える。そうなるとメディアのニュースだけで考えを決めるのは恐ろしく感じる。また、味方を増やそうとして単純化して伝えるメディアやSNSによって、先入観をもって単純化して考えてしまいそうなものも多い。

もちろん、気になった問題はちゃんと調べればいいんだけれど、問題は無数にあって時間は有限。 そういう、自分の理解の範囲がわかっていないのに発言しにくい。いっぽうで、限られた情報からでも意見を表明する人がいることで議論が巻き起こって詳しい人が解説してくれたりもするので、意見表明している人をくさすわけではなくむしろ尊敬するのだけれど。

インターネットバトル

ふたつ目はインターネットバトルにまきこまれたくないこと。 問題が単純化されて敵か味方かの二元論になりがちなのは人間のさがだと思っているけれど、これがインターネットで加速しているように思う。それで専門家が勇気をもって発言していても叩かれているのをみると、おそろしくなる。また、それでも発言する方々は尊敬する。黙っていいねだけつけています。 自分がTwitterでフォローしている人の中にはいつのまにか強硬な反体制主義な人々や国粋主義者も少数いて同じニュースでも意見が正反対でかつ、自分が絶対正しいと信じている人たちもいる。そして彼ら彼女らは、それぞれエコーチェンバーで意見が強化されているのもおそろしい。

民主主義を健全に維持するには、市民の政治参加が必要だと思うのだけれど、この複雑化して、インターネットバトルにまこまれやすいなかで発言していくのは難しい。

とりあえず問題リスト

こういうわけで、こうするべきだ!とか今の~はおかしい、と声をあげるのは自分にとって恐ろしく感じる。繰り返しになるけれど、そういう発言をしている人は尊敬するけれど、自分には難しい。

とはいえ、こういうの問題だと思うんだよな、というのは表明しやすいと思ったので自分が世の中の問題だと思うものを羅列してみた。 ほかにも重要な問題はたくさんあるはずで、いま思いついていないものもあると思うけれど、ひとまずの表明。もれている重要な問題教えてください。 行動しないと変わらないけれど、まず一歩ということでご容赦を。順不同です。

国内

  • 資産家優遇・学費高騰による格差の固定化
  • 就職氷河期世代の不安定さ
  • 生活保護の窓際対応、貧困ビジネス、貧困の再生産
  • 正規雇用者の社会保障のなさ
  • 自己責任論による貧困者の救われなさとそれによる社会治安の悪化
  • 社会不安と排外主義の蔓延
  • 労働時間の長期化とうつ病
  • 地方の過疎高齢化
  • 補助金依存な地方再生
  • 農業者数の減少による、食料自給力の低下、農の多面的な機能の毀損
  • 技能研修生の搾取
  • 行政・教育・医療などのIT化の遅れ
  • IT人材やITに理解のある経営者の少なさと増えつつあるレガシーシステムの保守運用コスト
  • 医師の当直明け勤務や無給医など異常な労働環境
  • あずのみ里裁判や大野病院事件、湖東記念病院事件などの警察・司法・メディアの医療現場の軽視
  • HPVワクチンを代表とする反ワクチンのデマの流布と普及の遅れ
  • 教師の労働環境と人材確保
  • いじめ問題と学校や教育委員会のことなかれ主義
  • 司書や学芸員の扱いの悪さと文化の軽視
  • 研究者の非正規雇用と負担増とそれらによる大学の研究力低下
  • 利益供与や法令・公文書の軽視など長期政権の腐敗と野党の弱体化
  • 腐敗・身分化する地方議員
  • ポピュリズム
  • 視聴率に振り回されて過激化・デマを流布するマスメディア
  • フェイクニュースとデマ、それらのSNSでの拡散と中傷依存
  • ネットに蔓延していて規制されないアダルト広告・誇大広告
  • 表現の自由への過度な制限の動き
  • 夫婦別姓問題や医学部不正試験などに代表されるさまざまな女性蔑視
  • LGBTQ者の困難
  • 育児の女性の負担が集中してること
  • 同調圧力的なPTAとか
  • 保育士の待遇の悪さ
  • 介護士の待遇の悪さ
  • 鯉の放流・ノネコ問題など行政・市民の生態系の軽視
  • コインハイブ事件やWinny事件など警察・司法のITへの理解のなさ
  • 取り調べの可視化の進まなさ、推定無罪の徹底されなさ
  • 入管での虐待とその改善のされなさ
  • なかなか進まない水産資源の適切な規制
  • 原発の廃棄スケジュール

海外

世界

こうして並べてみると、海外など遠い場所の問題はみえにくく、近い場所・自分に関わりそうな場所に関心が強いのがわかる。当たり前っちゃ当たり前なんですが、そうなので、なにかの問題を指摘するときに、一貫性を求めないでは欲しい・・・。

おち無し。

日本沈没、気候変動、進化する植物

Washington Allston: Elijah in the Desert
Washington Allston: Elijah in the Desert
*1

まとめ

  • 最近続けて読んだ3つの本がジャンルも違うけれどつながって人類社会の危機について触れていたので紹介します
  • 小松左京の「日本沈没」は、タイトル通りの危機に直面する社会を描いたSF。読み応えがあり古さを感じません。コロナ下のいまと通ずるところもあり、災害下のケーススタディにもなりそうです
  • 中川毅の「人類と気候の10万年史 過去に何が起きたのか、これから何が起こるのか」は気候の調査からこの数千年がたまたま安定していたことや予測の難しさが書かれています。古代文明の衰退の一因に短期的な気候の動きが影響しているのではないかという指摘があり、現代文明の危うさを感じました
  • 稲垣栄洋の「たたかう植物」では、植物の進化の工夫をおもしろく描いています。そのなかでも恐竜が植物の進化に翻弄されて絶滅した説があることや、人類との共進化で生き残ってきた作物が気候変動にどう耐えるかが気になりました
  • 大きな気候変動は人類社会に、コロナウイルス以上の危機をもたらしうるけれど、ぼくらはどう備えられるのでしょうか

日本沈没

─災厄は、何事につけても、新旧のラジカルな衝突をいやがる傾向のあるこの国にとって、むしろ人為的にでなく、古いどうしようもないものを地上から一掃する天の配剤として、うけとられてきたような ふしがある。この国の政治も、合理的で明晰で図式的な意志よりも、無意識的な皮膚感覚の鋭敏さに、より多くのものを負うてきた、この古くからの高密度な社会における政治においては、誰一人意識的にそうするわけではないにもかかわらず、結果的には、 災厄を利用するという国民的な政治伝統がそなわっているみたいだった。

まず一冊目は小松左京日本沈没
1973年出版なので50年近く前の古い作品だけれど、400万部以上売れて何度か映像化もされているので知っている人も多いと思います。 むしろ、作中で起こる衝撃的な事象そのもののタイトルを耳にしたことがない人は少ないかもしれません。

具体的な結末を書名にもってくる小説はめったにないような気もしますが、日本沈没というオチがわかって読んだとしてもそのとてつもない破局が簡単に想像できない分だけ強い印象になるように思います。平和な日常から描かれつつも、破局に進んでいくのが読者にはわかってしまいながらも、どうしてくのだろうと引き込まれていきす。

時代を感じる描写もあるけれど、はなしの本筋や人間と組織の描写は全然古くなくとても読みやすい。 特に、都市部で発生する地震と、そのあとの流通や経済活動への影響などの描き方は迫真。そして、この想像を絶する危機に対する政府の危機管理や世間の動きは、今のCOVID-19の危機に対応する各国政府や右往左往する人々ともかぶります。

そしてこれはケーススタディになるかもしれません。
自分がこの危機のさなかにいたら、生活や事業はどうなるだろうか、そしてどう行動するべきか、あるいは事前にできることはなにかあるだろうか。と考えながら読めました。 もっとも、首都直下地震や富士山噴火による中長期の都市部の物流断絶に個人でできることは限られているのですが・・・。

日本が沈没するという事象について、作中では理屈付けがありましたが、実際に起りえないものです、ただ、こういう地学的な事象を考えると、1815年のインドシアの火山噴火では「夏のない年(Wikipedia)」として世界的な不作になったし、フィリピンのトバ火山などや阿蘇山が噴火すればより長的な影響があるはず。 地球の46億年の歴史からみたら人類の歴史なんてほんの瞬きほどでしかなく、自が仕事としても関わっている農業はさらに短いことの薄氷を踏むような危うさもじます。 安定した四季のもと代々選ばれてきた農作物と農業は、そういった破局にどう立ち向かえるでしょう? そのときのためにも、種と農法の多様性があることは人類の生存につながるのかもなあ、とぼんやりと考えながら次の気候についての本を手に取りました。

日本沈没 決定版【文春e-Books】

日本沈没 決定版【文春e-Books】

人類と気候の10万年史 過去に何が起きたのか、これから何が起こるのか

昨今、コロナウイルスによる経済活動の低下により、短期的にではありますが世界的に化石燃料の消費が大きく減って、各地でスモッグが減ったというニュースが報じられています。もし仮に、これが続いたとして、これで異常気象・地球温暖化は止まるのでしょうか? この本を読んでいくと話はそう単純ではないことがわかります。

本書で一番はっとさせられたのは、異常気象(Climate Change・・IPCCのCCですね)とはなにかを考えるためには、正常な気象とはなんなのかを考える必要があるということ。

じつは、現代は何億年かのスケールのなかではむしろ寒冷な時代であって、今から1億年前から7000万年前頃のように北極にも南極にも氷床が存在しない時代とは比べられないほど寒冷。いっぽうで、数十万年のスケールでみると、9割ほどの期間はいわゆる氷期だったことを考えると現代は例外的に暖かいことがわかっています。そしてそのなかには、1万1600年前ごろのように、全世界で氷期が突然おわったあとわずか数十年で5度から7度も気温が上がったくらい変動が激しかった瞬間もあるそうです。こうみると私たちが考える正常な気象というのは地球の歴史からみたらほんの瞬きほどの数千年のものでしかないのかもしれません。

とはいえ、IPCCが予測しているような、これからの100年で5度気温が上がるかもしれないと予測されているほどの急激な変化はこの1万年とはまったく異なるため、経験則もさらに通用しないとも指摘されています。

さらに、別の説では、人間が関わる地球温暖化はなにも産業革命からだけではなく、有機物の発酵を促しメタンが放出される水田や、森林伐採などによって、8000年前からはじまったという考えもあるそうです。そして、これらによる地球温暖化によって、「とっくに来ていた」はずの氷期を回避していた可能もあるとか。まだ一つの説でしかないようですが、もしそうだとすると、これまで地球温暖化を防ぐため、という目的が崩れかねません(それとは別に限りある化石燃料の節約は必要とは思いますが・・・)。

日本が沈没するほどではないですが気候を通して人類に大きな影響を与える事象として火山があります。 火山には、その名の通り火の熱いイメージがある人もいると思いますが、実際には大量の噴煙や噴火物は太陽光を遮断し気温を下げます。核の冬と同じですね。たとえば1782年から続いた天明の飢饉を長期化、深刻化させたのは1783年のアイスランドラキ火山の噴火と言われていますが、これはヨーロッパでも冷害を発生させ食糧供給の不足と物価の高騰を引き起こし、一説によると、これによって生じた社会不安が1789年からはじまったフランス革命の遠因であるとも言われています。東日本大震災の先例として注目された貞観地震が約1150年前であることを考えると、天明の大飢饉ははるかに直近です。

火山以外にもエルニーニョ現象などによってもたらされる干魃は予測しにくく、人類にも大きな影響を与えています。1980年代にアフリカで発生した干ばつは、4年にわたって継続したことで300万人の命を奪ってもいますし、さらに、栄華を誇ったマヤ文明の衰退も、過去の気候の調査でほぼ同じ時期に、9年の間に6回もの干ばつに襲われた時期があったことがわかっており、これが原因になっていることが考えられるそうです。

この現代に長期化する干魃や、火山による長く続く冷害が発生したとしたら、どんな影響があるでしょうか。農業に生存の基盤を置いた社会が深刻な影響を受けるのは間違いないと思います。そのとき、農業や流通はどう適応して人類社会を支えるか考えるとうすら寒いものがあります。

たたかう植物

上記で暗い気持ちになったので、おもしろい本を読もうと思ったのが本書。まず、章立てが最高。この章立てをつくった時点でもう勝ちです。 「植物vs植物」からはじまって「植物vs環境」「植物vs病原菌」「植物vs昆虫」「植物vs動物」そして最後は「植物vs人間」。

ほんとうは弱い雑草が生き残るための戦略や、菌類との共生、共進化ともいえる虫との進化は興味深いのですが、特に、気になったのは恐竜の絶滅についてのくだり。

恐竜が絶滅した理由は、寒冷化と関係しているとされている。しかし、いくつかある恐竜絶滅を説明する説の中には、それ以外の理由で恐竜が絶滅に向かって衰退していたのではないかと考えるものもある。その原因の一つが植物の進化である。恐竜が繁栄を遂げていた中生代ジュラ紀後期から白亜紀にかけては、植物も劇的に進化を遂げた。ジュラ紀には、大型の針葉樹が繁栄していたのに対して、白亜紀になると花を咲かせ、やがて実をつける被子植物が広がっていったのである。(中略)大型の針葉樹は、時間を掛けて巨大な体を作る。一方、草本被子植物は、速やかに成長して花をつける。そして昆虫が花粉を運ぶようになったことによって、効率良く、確実に受粉が行えるようになったからとのこと。その結果、短いサイクルで世代交代を繰り返しながら、進化を遂げていったと考えられている。(中略)恐竜は、被子植物を消化するための酵素を持っていなかったために、恐竜たちは消化不良を起こしてしまったとも言われている。

進化のスピードに追いつかなかった恐竜が滅びたというもの。 サイズ感が違って全然比較に意味はないのですが、今の人間と、進化の早いウイルスを連想してしまいました。

気候変動と人類

「たたかう植物」にも触れられていますが、米や麦や野菜は、人間が形質を選りすぐって育種してきたものです。 これの選抜には、安定した気候の中で数百・数千年の時間がかかってきたことを考えると、「人類と気候の10万年史」で触れられていた急速な気候変化に耐えられるのでしょうか。 とれうる対策は限られていて、大勢の人間が飢饉に直面することになるかもしれません。一つ、根本的な解決策ではありませんが、さまざまな工夫で戦っている植物のはなしを読んで思ったのは、生き残る人間をすこしでも増やすためにも、世界中でさまざまな作物が育てられていることが役立つかもしれないということ。いろいろ育てていれば、ひとつでも気候変化に対応するものがある確率は増えます。そういう意味でも、生物多様性は重要だと思うのです。

いま人類は、新型コロナウイルス感染症への対策やそれで露呈した経済問題、格差、差別、デマのはびこるネットや権力の腐敗など深刻な問題と向き合っていますが、もしかすると、急激な気候変動という巨大な危機も迫っているかもしれません。これにまともに立ち向かうためにも(もちろんそうではなくとも)、この現代の諸問題をすこしでも解消してもうちょっと科学的・合理的なアプローチがとれる社会にしていきたいものです。ちょっと中高生のころ思っていたような理想主義に過ぎるかな・・・

日本沈没のセリフを引用して終わります。

敗戦 は日本にとってとんでもない幸運をもたらした。あれによって、明治以前から維新ののちもかかえこんでいた、もろもろの古い社会の殻をふっとばしてしまったからだ。軍事力さえ、大っぴらには持たないことにしたんだからね。──だが地震はちがう。こいつは、社会構造や、国家シンボルの変革などひき出さない。だから、さまざまの矛盾や危機が、社会構造の変化を通じて、社会に吸収されず、矛盾はいっそうはげしくなる

ソフトウェア開発を仕事にするなら読んでおくべき古典 Joel on Software

2000年から2005年くらいに書かれたJoel Spolskyのエッセイをまとめた本、"Joel on Software"をこの年末に読みました。
尊敬する友人である荻野氏がプログラミングを仕事にするうえで一番学びがあった本として、2011年に教えてくれた本だけれど、なんでそのときに買って読まなかったのかと後悔するほど学びがあって、もっと早く知っておきたかったことが書かれていたのでメモと感想を書いておきます。

Joel on Software

Joel on Software

時代背景をさっぴいて読む必要はあるけれど、そのあとの歴史を知っている時代に読むと答え合わせができて楽しかったり次の未来予測に役立つかもしれません。

エクストリームプログラミングや、エリック・レイモンドのThe Art of UNIX Programmingへのコメントはそれらの名著の副読本としても鋭い指摘があるし、いまは意識する人の少なくなった文字コードやメモリ管理などプログラミングの重要なところにも触れられている。そして、プログラミングについてだけではなく、ソフトウェアビジネスの戦略として、のちにフリーミアム戦略や、プロダクトマネジメントSaaS、カスタマーサクセスなどと名前がつけられた重要な概念のアイデアの核が詰まっている。

ソフトウェアビジネスの知見やプログラマの採用など経営やマーケなどいわゆるビジネスサイドの人が今読んでも得るものありそう。
著者のJoel Spolskyは1990年代、MicrosoftでExcelVBAの開発を仕切ったり、FogBugsというバグトラッカーやのちにTrelloを開発したスタートアップFogCreekを創業したり、9年間ほどStack Overflowという世界で一番開発者の問題を解決している(と思う)サービスのCEOもしていた。さらにプログラマになる前は実戦経験的に世界最強と思っているイスラエル空挺部隊にもいたらしい。時代的にもてはやされたハッカーとはすこし毛色が違って(なにしろ彼はWindowsアプリケーションの開発を長くしていた)、彼はディベロッパーであって、ヒーロー。

ちなみにだいたい以下のJoelのWebサイトで原文を読めるので英語がわかる人は読みましょう。

www.joelonsoftware.com

はじめに

プログラミングでコンピュータをうまく使うよりも、人間をマネジメントしてソフトウェアをつくっていくことが難しい。 人間のチームをマネジメントしていると、C++のテンプレートさえまったく簡単なものに見えるようになる。

プログラミングも、もちろん難しいんだけれどそれとは質的な難しさが違う。

ソフトウェアプロジェクトのマネジメントというのは、あまりよく知られている技術ではない。誰もソフトウェアプロジェクトマネジメントの学位を持ってないし、このテーマに関する本も多くはない。 ごくわずかの非常に成功したソフトウェアプロジェクトに従事していた人々の多くは、金持ちになり、蓄積された経験を次世代に伝える前に引退してマス養殖場を始め、その他の多くの人々はただ燃え尽き、スラム街の悪ガキだちに英語補修の授業をするというような、もっとストレスの少ない仕事に転職した。

こういうジョークというかJoel節がたくさんあってよい。こういう言い回しできるようになりたい。

ジョエルテストについて

開発チームのクオリティを評価するためのテスト。
Yesの合計が点数。11点以上が健全とのことです。2000年に書かれたもので、いまだと当たり前のものもあるけれど、どうでしょうか。

1.ソース管理してる?
→ 今時していないチームはないと思うので省略。この本の次代はCVSが最先端だった。
2.ワンステップでビルドできる?
→ 同じく。
3.デイリービルドしてる?
→ CIの走りですね。
4.バグデータベースはある?
→ いまどきExcelでしか管理していないチームはないと思う。
5.新しいコードを書く前にバグを直している?
→ 特に、Webアプリと違って頻繁なリリースのできないパッケージタイプではバグを先に直すべき。バス修正にかかる時間は読みにくいけれど、新規機能開発は読みやすいはず。
6.アップデートされているスケジュールがある?
→ 「プログラマがスケジュールを立てたがらないのはよく知られている。彼らはビジネスの連中に向かって、「いつ出来上がるかって?そりゃ、出来上がったときさ!」と怒鳴る」。けれど、もちろんビジネスや他チーム連携のために重要です。
7.仕様書はある?
→ 後述
8.プログラマは静かな環境で作業している?
→ 重要。フローやゾーンと呼ばれる集中した状態は簡単に消されてしまうのでそれを減らすためにも必要。日本の小さな組織だとどうするべきなんだろう?常にいるというより、週何日かだけでも小部屋にいるとかいいのかも。
9.手に入る最高のツールを使っている?
→ ビルド時間を短縮するマシンだったり、ディスプレイだったり。
10.テスタはいる?
プログラマ2-3人につき最低でも1人の割合で専任のテスタがいないとバグだらけの製品をリリースするか、時給30ドルのテスタにできることを時給100ドルのプログラマにさせて金を無駄にする、とのこと。自分のチームではここをビジネスサイドの人にやってもらっている・・・
11.採用面接のときにコードを書かせてる?
→ 最近は当たり前のようになってきていますが、どうでしょうか。
12.ユーザビリティテストはしている?
→ 廊下で5人くらい捕まえて試してもらうとユーザビリティ上の問題の95%を明らかにできる、とのこと・・・

このテストは、チームの状態をマネージャが把握したり、会社に応募するときや投資するときに目安になったりする、とのこと。

仕様書について

仕様書はデンタルフロスのようなもので、みんな書かなきゃいけないとは思っているけれど、誰も書かない。

アジャイルソフトウェア開発宣言*1では「包括的なドキュメントよりも動くソフトウェアを」と書かれていることもあって、仕様書を軽視するプログラマは多いと思うけれどビジネスサイドと話を積めて安全効率的に開発するにはやっぱり必要。どのレベルのものか、が難しい。
Inspiredなどプロダクトマネジメントあたりでは、紙芝居のように動作する「ハイファイ・プロトタイプ」が仕様書としてよいのでは、とも言われているけれど、Joelの意見はちょっと違う。あまりにもデザインができすぎたものは、ビジネスサイドがほぼできていると勘違いしてしまうからよくないと、、これは、ハイファイ・プロトタイプが効くのはユーザの、利用者の、言葉にしにくいフィードバックが重要な、どちらかというとB2C向けなのかもしれないし、ちゃんと運用できるのはリテラシーの高いプロダクトマネジメントチームがいるときだけなのかもしれない。

必要な理由としては事前にビジネスや他チームと共有するためなのが大きいけれど、ほか気になったところをピックアップする。 まず、プログラマは、時間をかけて書いたコードが、仕様上どんなにまずいコードであっても、それに執着するようになるのでこれを避けるため。はい、心当たりがありますね。 次に、プログラマというのは「正しい答え」ではなくかれらがコードとして書いたことに即して質問に答える傾向があるから。これは自分もやりがちです。

仕様書の中身について、ユーザ観点でどう動くかを記述する「機能仕様書」と内部の実装についての「技術仕様書」があって、Joelのいう仕様書は前者、内容は具体例がおもしろいので読んでほしいけれど、ユースケースのシナリオや対象、簡単なフローチャート、画面が紹介されていて、「カタログ」のようなものだと感じました。あいだに未解決の問題やテクニカルノートが挟まっている。テンプレートは使うべきではない。
そして、証書は1人の人間によって書かれ、所有されるべき。重要なのは仕様書がアップデートされてその差分がわかるようになっていること。

そんな仕様書を書いて価値あるソフトウェアをつくっていきたいです。
この、バージョン差分を分かりやすくてだれでも使いやすいドキュメント管理システムはないだろうか・・・

プログラムマネージャについて

プログラムマネージャという、いまプロダクトマネージャーとして知見が積み重ねられているものの前身と思われる役割にも紙幅が割かれている。 プログラムマネージャーはコーディング以外のあらゆることをやり、会社の「ビッグピクチャー」を心に抱いていることが期待され、要求を集めて仕様をつくり、外交 手腕。マーケットに対する意識、ユーザ理解、良いUIデザインをつくる。コーディングへの理解も欠かせない。

重要なのは
・コーダーをプログラムマネージャに昇進させないこと。
マーケティングの人間をプログラムマネージャにしないこと。
・コーダをプログラムマネージャの監督下におかないこと。

難しいですね・・・正しい資質のある人を採用するなり抜擢する必要がある。
このあたりは、最近2版が出たInspiredを読むのがよいと思う。

5つの世界

いろんなひとがさまざまな文脈でソフトウェア開発についての知見を語るけれど、たいていの人はその人の知っているソフトウェア開発を念頭においているので、話を聞くときは、どの世界のことを話しているのか気にしましょう、というはなし。

5つの世界とは、
・パッケージ
・インターナル・・・特定の組織内で使われるもの
・組み込み
・ゲーム
・使い捨て

それぞれ求められる品質や基準が違う。
いまネットで多数の記事があって人々が働いているwebアプリケーションは、多数のブラウザで使われるという点でパッケージの変異として分類されているけれど、今なら独立させてもよさそう。B2CかB2Bかで分けてもいいかもしれない。
ただ、Joelはユーザが1000万人いるかどうかで区別はしていたので、特に自分のような凡百の開発者とは桁が違うことだけご留意を・・・。

使い捨てプログラムはすぐにインターナルソフトウェアへと変化し、さらにMBAがそれを見つけて「これを使って新しいビジネスをスピンオフできるぞ」と言うと、ジャジャーン!ひ弱な「エンタープライズソリューション」を提供するコンサルティングウェア会社が生まれる。

ある・・・

Amazonを目指すのかBen&Jerry's を目指すのか

Ben&Jerrysは東京とかデパ地下とかで売ってる高いアイスクリーム屋。2000年にユニリーバに買収された会社。
スタートアップは急成長を目指すという点でスモールビジネスと違う、と思っていたけれど、その中でもAmazonスタイルともうちょっとゆっくりなBen&Jerry'sモデルがあるのうまく区別できていなかった。
競合がいるかどうかや資本が必要かどうか、ネットワーク効果の有無、損益分岐点の近さ、リスクなどが違うなどなど(それぞれどちらのモデルかはわかるよね)。 ひとつ自分が意識できていなかったのは、Amazonモデルでは企業文化(を維持していくのは)不可能だということ。そして最悪なのはAmazon型の会社にならなければと思いつつお、Ben&Jerry's型のように行動すること。どちらか決め切れているでしょうか。

Joelによれば、MicrosoftはBen&Jerry's型のもっともよいモデルとのことで、Ben&Jerry's型が巨大化しないわけではないけれど、もう時代は違うかもしれない。

その他

アーキテクチャ宇宙飛行士を雇わないこと

アーキテクチャ宇宙飛行士とは、アーキテクチャや抽象的なことがらについて議論するばかりでなにも生み出さない人間のこと、らしい。 類似性を見つけて抽象化をすすめていくの、楽しいけれど、解くのが楽しい問題ではなく、解く価値がある問題を解決したいものです。

デザインというのは、コストを増やすよりも早く価値を追加することができる、漠然とした領域のことをさす。 たしかに漠然とした領域・・・。とか言いようがないのかも。

プログラマの評価について
逆効果になることが多く、するべきではないと書かれている。
評価が高くても、それが生産性につながらず、評価が低い人のモチベーションを下げるだけ、華々しい成果を出していなくとも目立たぬところで重要な役割を担っている人を評価するのが難しい、ということもある。 それは、わかるんだけれど、適切にストレッチさせるためにどうなのかは気になる。なんらかの目標管理的なものは必要なのかどうか、ちょっと悩ましい。

などなど。
Joelのブログはまだまだ続いているので2020年は英語をがんばって読めるようにしていこうと思う。

ブログ名が変わりました

三行まとめ

・ブログ名を「うんこめも」から「ぜぜ日記」に変えます
・理由)食べ物についても触れることが多くなってきたのでちょっときれいな名前にしたかった
・意味)ぜぜは住んでいる滋賀県大津市の地域名である膳所(ぜぜ)と是々非々をかけています

経緯

あまり更新されていないブログの名前なんて誰も気にしていないのでしれっと変えてもよいとは思うのだけれど、なにかを変更する際には、意図を書いておくことは、プログラミングにおけるコミットメッセージのように職業倫理的に必要なので書いておきます。

この旧名の「うんこメモ」というのは冷静に考えると汚い名前ですが、自分がうんこを好きということでも、うんこのような文章をかくと卑下しているわけでもありません。もともとは「自律分散うんこ製造システムについてのメモ」という名前のブログを書いていたんですが、長くてよくわからないと略してうんこメモになって、なぜか自分ではあまり汚さを意識できていなく、たまにコメントやはてなブックマークで、ブログ名ワロスみたいに言われてハッとするのが積み重なってようやく変更に至ったのでした。

「自律分散うんこ製造システム」とは、勝手に自由意思をもって動いていて、なにかを消費してうんこを生産するだけのエージェント、端的にいうと人類のことを社に構えた学生が皮肉った言い方です。優れたエンターテイメントや文化をつくりだせている人類をそんなふうにいうつもりはなく、ただ、学生時代、人工知能あたりを研究していたときに、分散人工知能という概念の略語、Distributed Artificial Intelligenceの頭文字のDAIが自分の名前っぽいと思ったというのが安直な理由。

ひねった名前にしようかとも思ったのですが、尊敬する小町さんの武蔵野日記(旧生駒日記)を意識して、住んでいる膳所(ぜぜ)という地域にちなんでいます。

武蔵野日記

膳所というと膳所高校という滋賀県有数の進学校で知っている人も多いかもしれません。自分は福井という田舎出身なので関係ないです。

2000年代後半のブログブームのときにニュースサイトやGoogleリーダーで読んでいたさまざまなブログたちは、どんな名前だっただろうか、と調べようと思いましたが、Chrome以前の時代のブックマークやGoogleリーダーの登録リストが不明で調べられない。
たまにはてなブックマークなんかで流れてくると、まだ続けてたのか、と嬉しくはなることもありますが、ほかはいまどうなっているのか分からず思いをはせています・・・。

またたまに好き勝手書いていこうと思います。今年もよろしくお願いいたします。

Rails Girls Kyoto 10thにコーチ参加したこと。考えたこと。

RailsGirlsという、女性がRuby on Railsでプログラミングを学ぶイベントにコーチ役として参加してきました。とても楽しく、得るものがあったので感想を書いてみます。

Rails Girls - Japanese

Rails Girlsについて

このイベントはフィンランド*1のリンダさんが2011年にはじめたものです。 目的は「女性に技術の理解とアイデアを実現するためのツールとコミュニティを提供する」こと。原文はこう。

Our aim is to give tools and a community for women to understand technology and to build their ideas.

コミュニティベースの動きといろんな企業のスポンサーシップとで世界中で何百回も開催されていて、男女で数の差があるプログラマーで女性に機会をつくる機会になっています。 背景については、英語ですがYuryuさんのこの資料が現状(2014年)の数字と取り組みについて説明していてわかりやすいです(5年で改善されているでしょうか)。

日本では東京でやるといつも満員で京都でももう10回開催されているくらいそうです。
自分の勤め先でアルバイトとしてエンジニアをして重要な戦力になっている女子学生がRailsGirlsに参加していたことがプログラミングを学びはじめたきっかけ(の一つ)だったり、知り合いや友人がコーチとしてコミュニティに貢献していたことから自分も参加してみました。教えることでなにか発見があるかもという期待と、社会のエンジニア層を厚くしたいという気持ち。

パソコンとインターネットがあれば学べるプログラミングは、表面的なスキルの陳腐化は早いけれど、Webアプリケーションの開発の考え方の根底はしばらく変わらず、需要はまだまだ大きいと思っています。向き不向きはあって万人におすすめできませんが、向いているかどうか知る機会のひとつとしては、いきなり、お金と時間をかけてスクールに行ったり、自学だけよりRailsGirlsは気軽で便利でおすすめです。

自学は、どの段階のひとにとっても重要だけれど、最初は知らない概念が多すぎたり、玉石混交の記事を見分けられらなかったり、どこから手を付けるかで挫折しやすい。自学だけだと、自分がなにをわかっていないかもわからず、ネットのQAサイトやGoogle検索で困っていることを言語化するのも難しい。とはいえ、自学で一度挫折した人が、経験者に気軽に聞ける時間としてもRailsGirlsはよい場所です。もちろん地域のコミュニティ、京都だと Kyoto.rbRuby舞鶴 - connpassもおすすめです。

あとあと、プログラミングを仕事にしなくても、プログラミングやWebアプリケーション開発のことを知っているというのは、多くの仕事や人生で役立つとも思っています。

Rails Girls Kyoto 10th

今回は、半年ほど前に大阪でRailsGirlsに参加したという大学2回生の人がオーガナイザーでした。
教授1人に6-70人の授業でプログラミングを教わったけれどわかるわけもなかったのが、RailsGirlsで理解が進み、これを同じ大学の人にも伝えたいということでの開催でした。尊敬。

参加者9人にコーチが1人ずつという贅沢な体制。 コーチやスタッフは4割ぐらい女性です。 自分は、大学の授業でRubyによるプログラミングに触れたけれど、よくわからないままなのをなんとかしたいという学生さんにコーチとして付きました。

RailsGirlsでは、このチュートリアルの1つ目から4つ目までを10:30-12:30、14:30-16:30の4時間で取り組みます。

Rails Girls - Japanese

このチュートリアルを読むだけでは背景や意図は理解できないので、参加者の理解度や、興味にあわせて調整します。
今回はプロジェクトをつくる最初の rails new の次 rails generate scaffold idea name:string description:text picture:string とこれでできたファイルの役割の説明で午前中ほぼすべて使いました。 ユーザがアクセスしてからroutes.rbでどのコントローラが呼ばれるか決まって、コントローラがモデルを読んで、対応するビューをユーザに返す。
ファイルをみたり、 rails routes でルーティングをみたりなどなど。納得するまで粘り強く質問してもらえて理解が深まったのではないかと思います。午後は、gemをつかって画像登録を簡単にできるようにしたり、パーシャルをつかってhtmlを便利に管理できるようにしたり、githubに登録して、herokuにデプロイして世界中に見えるように公開するところまで。そのあとは時間の都合で、1対多関係のモデルをつくるところを手は動かさずに概念だけいろいろと説明しました。

たった4時間ですが、これまで知らなかった複雑な概念を理解するというのはとても消耗するし、それを理解度を追ってフォローするのもなかなかたいへん。参加者の集中力や、理解してやろうという気迫、疑問と理解のサイクルはめちゃめちゃ学びがありました。 自分も、知らない概念をがんばって会得しようという気持ちになります。

アフターパーティではほかのコーチの方々、さまざまな現場で活躍している人たちともエンジニアリングやマネジメントについておしゃべりできて楽しい時間を過ごせました。

参加者とコーチのみなさま、オーガナイザーさん、スポンサー企業さまありがとうございます! (弊社、株式会社坂ノ途中もコーヒーを提供するスポンサーをしていました)

最後に今回コーチをする中で考えていたこと3つを書いておきます。

コーチとしての狙い

1.なんでも質問できる関係をつくる。

特に、なにかを聞いても一度で理解できるわけはないので、同じ質問を何度してもよいし歓迎、ということを繰り返し伝えました。
今回はわからなかったらいつでも、と話をしています。職場だと15分考えたり調べて進まなければ聞いてね、と言っています。

2.自分のペースでやる

ほかのひとも同じことやる環境は刺激的ですが、焦ったりしないように自分のペースでやれるようにしました。
でも、ほかの参加者も含めてみな自分の理解にフォーカスできていたようだったので杞憂だったかな。

3.自学できる準備をする

エラーは怖くないということと検索のやりかたについて話しました。
プログラミングをしているとエラーは日常茶飯事です。でも環境構築などでは、真っ黒い画面によくわからない英語の文字列がたくさんでてきて特にはじめのころは拒否反応とストレスを持ちがち。それでも、エラー文を読めばヒントが書いてあるし、検索できるということを伝えています。
今回だと、コマンドを打ったり、コードを書く場面でタイプミスを見つけても、あえて指摘せず、実際に画面表示時にエラーを起こしてから、その読み方と原因を説明しました。エラーが出ることは完成を高めていくのに必要なこと。
もうひとつ、エラーが出て読んでもわからないときに、エラーをGoogle検索するとわかることがある、だったり、今回つかったgem CarrierWave の意味を調べるために、公式サイトを検索したり、日本語でも解説記事があること、なかには間違った情報を書いているものもあって鵜呑みにできないことなど。そして、今回のRailsGirlsの参加者のSlackチャンネルなどで相談があればできることや、またfollow upイベントも開催することやコミュニティを活用することを話しました。

ここらへん、意外と初学者向けの教材やカリキュラムにはない気がしています。 学習の高速道路*2、みんなでつくっていきましょう。

ウェブ進化論 本当の大変化はこれから始まる (ちくま新書)

ウェブ進化論 本当の大変化はこれから始まる (ちくま新書)

*1:LinuxMySQLがうまれた場所ですね!

*2:梅田望夫のWeb進化論から