PHPerKaigi 2020 day2 参加レポート #phperkaigi

去年に引き続き参加してきました!

資料をまとめたり、感想やレポートを書いていきます。

PHPerKaigi 2020

phperkaigi.jp

場所は練馬駅

お祭りみたいで賑やかな雰囲気で楽しい。

テーマは「文化祭」、「同窓会」とのことで、楽しい仕掛けが多く、小さいところにもこだわっているなという印象

f:id:tiwu:20200211152216j:plain

なんと、今回からトレーディングカードが貰える!

f:id:tiwu:20200211163822j:plain

参加者同士でカードを交換して、交流するきっかけになればという意図らしい(たぶん)

効果の元ネタは気になるが、可愛い

トートバッグとその中身(一部)

f:id:tiwu:20200211193749j:plain
デニム生地で可愛い

f:id:tiwu:20200211194050j:plain
可愛いグッズたち

↓ここからセッション↓

自作して理解するxUnit

fortee.jp

speakerdeck.com

ジェネレータで無限を手玉に取る術

fortee.jp

マスターデータの管理運用と実装について

www.slideshare.net

fortee.jp

実例から学ぶ、最後まで諦めない決済システム移行方法

speakerdeck.com

fortee.jp

GMOの人で、自宅勤務について聞きたい人は後ほど聞いてくれとのことw

おさいぽ!というサービスの決済サービスの移行

おさいぽ! -ネットのおサイフ-

ペパボ内での決済をするためのAPIとかが生えている

移行の背景は決済サービスが終了するため

成功の秘訣は、事前打ち合わせ、事前に本番環境でテスト、万が一のフローを策定の3つ

APIが生えているので、利用しているペパボのサービスに影響が出る

移行計画を作っていたが、サービス側と打ち合わせをしたら、作った移行計画では無理というのが判明

作った移行計画が駄目になるのは精神的に来るものがある

GW前にメンテナンスを入れて対応をした

本番でテストができないという先入観があったが、聞けば意外とできることがある

本番で動いたという自信を持つことが大事

移行2日前に3Dセキュア決済周りでエラー

これは、契約内容ミス

無事リリース後、エラーが

旧決済サービスの返金処理でエラーが

エラー時のフローを作っておいたので、そのフロー的にはロールバックするレベルではなかった

ステージングで無理やり旧決済サービスを動かしてなんとか対応

当日は疲れている・テンパっているのでエラー時のフローを作っておくと冷静に対応ができるので良い

基本は二人で対応をしていた

感想

エラー時のフローを作っておくのはすごく同意

基本的にエラー時はテンパっているので、行動のフローがあるとそのフローに沿って動けばいいので冷静になれる

本番で動いたという自信を持つことが大事

これもすごく同意

とてもわかる

クリーンな実装を目指して

speakerdeck.com

fortee.jp

PHPerがこれから「型」とお付き合いしていくために

fortee.jp

型システムとは、元々、型理論という分野

→数学などで使われる

最初は int, floatの違いを区別する

→計算速度向上のため

データ構造の不整合が実行前にわかる

PHPは実行前には・・・

特定のバグがないことを保証する

が、柔軟性が持てない、実行されないコードのエラーも検知するというデメリットもある

CならポインターでPC破壊できるが、PCは破壊できない

→型に守られている

とはいえ抜け道はある

しかし、安全の定義が不安定なのでなんとも

コンパイルによって、実行時に効率的なバイトコードになるでメリットが有る

静的型付け

→型に不整合がある場合プログラムは実行できない

動的型付け

→実行時に型検査され、不整合は実行時エラー(にならないこともあるので注意

静的型付けは自明なものは型を書かない

動的型付けは安全のために型を書く

弱い型付けの動的型付け言語、柔軟性が高い

型システムの強化、型宣言で性能が上がる

型が進むと、後方互換性との兼ね合いが心配になる

→新規ならガンガン行ける

ケース1 古くからメンテされているPHPの保守

開発環境はPHPStormなら、PHPDocで行くべき

→急に型を入れると壊れる可能性がある

ケース3 古くからメンテされているPHPに型が定義されたライブラリ導入

→型を合わせて気をつけて入れる

感想

最近TSをわりと書くようになったけど、ちょっと実行したいときにコンパイルが通らず実行すらできないときが多々あって辛いときがある

ちょっと書いて動かしてバグっていないかというトライ・アンド・エラー的な書き方なので途中でも実行できないと困ったりする・・・

ケース1 古くからメンテされているPHPの保守

開発環境はPHPStormなら、PHPDocで行くべき

型書きたいけど、引数に int, string 書いたらバグった(しかも後ほど気づく)とかがあるので、PHPDoc から行くというのはすごく良いなと思った

PHPシステムをコンテナで動かすための取り組みのすべて

fortee.jp

Zend VMにおける例外の実装

www.slideshare.net

fortee.jp

PHPPHPを実装する 〜プログラミング言語実装入門〜

fortee.jp

プログラミング言語処理フローは主に字句解析、構文解析、評価

評価するとは、ASTをたどる、バイトコード変換、機械語に変換

PHPバイトコード変換、GoとかCとかは機械語変換

機械語に変換のほうが早いが人間が読めたりするものではない

まずはコードをパースしてASTを作る

AST = 抽象構文木

ソースを表すオブジェクト

今回は PHP Parser を利用

parser に文字列でコードを渡せば AST ができる(簡単そう

ASTは配列だから for で回して、 switch で実行していく(switch 内は再帰していく

自作PHPの強さは、再代入禁止とか、静的解析できたりカスタマイズ可能

PHP を超える PHP を作れる

感想

フロントエンドの勉強会とかにいくと、たまに話しに上がる AST

PHP Parser 食わせると AST ができて、それを for で回して switch で実行していく」と聞くと、読める・書ける・いけそうな気がしたw

いつも AST の話はよくわからなかったけど、初めてすっと入ってきた気がする

もしもPHPソースコードが読めたなら...

fortee.jp

ぼっちからはじめるレガシーカルチャー改善ガイド 〜はじめの一歩編〜

fortee.jp

PHP 4, 5 のミックスで最初は開発(XAMP

今は Laravel にしたりdocker にしたり Nuxt 使ったり

改善の最初は最初は自己研鑽と信頼貯金を貯める

勉強会などに参加して、他社とのギャップを知って、自社に展開できることを探していく

最初はインデントを整えたり、開発環境を良くしたりという、プロダクションに関係のないところから行った

一人目の仲間を見つけたのが最初のゴール

1人目を見つけた後は?

→2人目を見つける

チームが一人のときは・・・?

→外(コミュニティ)に仲間を見つける

本当に一人?

→人間なかなか、1人で仕事していることはほぼない

感想

他社とのギャップを知って、自社に展開できることを探すフェーズはすごく同意

最初のゴールが1人目の仲間を見つけるところは、カイゼン・ジャーニーっぽいなと思った

実際の改善はプロダクションに関係ないインデントを整えたりというスモールスタートなのも良さそう

チーム(エンジニア)が1人のときはどうするか?という問いに、「本当に1人だろうか?1人で仕事をしているなんでほぼありえない」みたいなこと言っていてメチャクチャ同意の嵐だった

今だからこそ振り返る register_globals

speakerdeck.com

fortee.jp

Webアクセシビリティを支えるための技術

fortee.jp

UX ピラミッドの一番下にアクセシビリティがある

WCAG というアクセシビリティのレベルがある

Web Content Accessibility Guidelines (WCAG) 2.0

レベルA 感覚的な特料

レベルAA フォーカスできる(キーボードで操作ができる

レベルAAA メディア(音声)の代替を用意する

ハイパーテキストはテキストを相互に関連付ける仕組み

→これを実現するものがHTML

サーバーサイドエンジニアとしてwebアクセシビリティを自分ごとにする

適切なHTTPステータスを選択する

感想

UXピラミッドを調べてみたけどたくさん出てきて、どれかわからなかった :eye:

alt 属性を DB に入れておくとかは、ブログメディアとか良さそうとか思った(みんな既にやっている?

ステータスコードは 200 で返して、中身でエラーとかは難しいところがあるので同意

GitHub Actionsで始めるPHPアプリケーションのCI実践入門

speakerdeck.com

fortee.jp

Issue 追加でも動く

GitHub Actions, windows 選択できる

初期状態はコードがない(Issue 発火もあるからか?

Github 公式は actions/ で用意されている

アクションは Docker + TS で作れるらしい

Creating a JavaScript action - GitHub ヘルプ

JSで作れそうな匂い

永続化の手段は公式?に用意されているそう

Persisting workflow data using artifacts - GitHub ヘルプ

感想

最近個人的にも使っている GitHub Actions

Issue で発火できるのは知らなかった

GitHub + Actions + Pages でいい感じのなにか作れそうな匂いを感じた

API リストとか、DBの定義リストとか、開発で必要な何かとか

Serverless Pattern

slide.seike460.com

fortee.jp

LT

PHPでもVTuberになりたい!

fortee.jp

FaceOSC というOSSの顔の頂点座標をとるライブラリ?があるらしい

Releases · kylemcdonald/ofxFaceTracker · GitHub

これをPHPで受け取るライブラリがないらしい

ないなら作る!

PHPでVtuberになりたいとか、機械学習とか// 第47回社内勉強会 #sa_study | BLOG | 株式会社スタジオ・アルカナ

www.slideshare.net

力こそパワー、すごい

PHPでleetCodeのeasyレベル100問ノック

fortee.jp

LeetCode - The World's Leading Online Programming Learning Platform

いろいろな問題がある

8割位PHPで書いてみた

他の人がコードが読めるので勉強になる

試し実行が10秒くらいかかる

先にテストを書いて、PHPStorm で動かしてやっていた

パズルゲームのように解いていくと楽しくできる

PHP未経験者を育てる独自フレームワークの作り方

speakerdeck.com

fortee.jp

沖縄でビーチ駆動開発(開発しづらいw

FWなど使わずブログを作っていく研修

ルーティングとかけっこう大変らしい

RFCの歩き方

speakerdeck.com

fortee.jp

Request for comment

PHPの機能追加の話

英語は基本グーグル翻訳

RFCは前書きさえ読んでおけば良い

コードがあればラッキー(英語は難しい

補足の後に互換性と投票が書かれている

PHPerKaigi2019への参加がきっかけで社内勉強会の主催するようになった話

fortee.jp

YouTube を社内で流す勉強会を開催

→準備は楽そう泣きがする

上映会で一番盛り上がった「PHPデザインパターン」を学ぶ会を主催

参加者0人のときの寂しさはとてもわかる

PHPとRustを組み合わせて音声ファイルをエンコードする話

speakerdeck.com

fortee.jp

PHP FFI

FFI = ネイティブコードを呼ぶ仕組み

PHP7.4 で採用された

PHP音声ファイルエンコードFFmpeg が定番

デフォルトでは有効化されていない

brew 経由 php ならデフォルトで FFI が有効化されているらしい

結構難しかった

自分の名前を"ちゃんと"入力したい人生だった

fortee.jp

濱とはま(変換に出ない)

異体字という

shift_jis とかでは異体字がないので、入力ができない

unicodeならいける

絵文字と同じ要領でいける

🙆‍♂️←色違い

異体字も文字と異体字スキン?で表現できる

異体字の元DB?は3種類

Adobe に濱がない

が、別のDBにあるのでそれを持ってこればいける!

(おまけ)ネットワーク

MacBook Air1台でDNSサーバーにしている

が、今回はルーター?がちょっと弱かったらしい

LAN経由で電源を供給できる機器がある

ついでに通信ができるw

今回は最大153台

最後に

殴り書きのメモの羅列になってしまった

PHP 単体の話も面白いが絡めた話も面白い(LTとか特に)

久しぶりに会った人が何人かいてテーマにある「同窓会」を噛み締めた

Twitter で部屋が暑いと呟いたらすぐ冷房が効いて、スタッフさんありがとうございました :pray:

PWA Night CONFERENCE 2020 参加レポート #pwanight

参加してきたので感想や、資料などをまとめていきたいと思います

PWA Night CONFERENCE 2020

conf2020.pwanight.jp

PWA Night はPWAのコミュニティで毎月? イベントをやっています

PWA NightはPWAに関わるすべての方のためのコミュニティです

pwanight.connpass.com

僕も何回か参加したり、登壇したりしたことがあります

毎月イベント開催するのすごいなと思ってますが、更にこんな大きいイベントもするなんてすごいなと思います

基調講演 : Edge of the web

conf2020.pwanight.jp

gist.github.com

いろいろな新しいAPIや技術の紹介で、上記にURLがまとまっています

TWA (Trusted Web Activities)

PWA をGoogle Play Storeで配信できるようにする技術(たぶん)

Google Developers Japan: Trusted Web Activity のご紹介

Project Fugu

ふぐのように毒があるか美味しい機能(まだ実験段階の機能でセキュリティリスクなどあり)という意味で、Project Fugu だったような気が🐡

Web Capabilities (Fugu) - The Chromium Projects

公開されいているスプレッドシートにリストがある

🐡 Chromium https://goo.gle/fugu-api-tracker - Google スプレッドシート

Origin Trials

まだ実験段階の機能を使って貰う代わりにフィードバックをもらうようなシステム(だと思う)

Origin Trials

Badging API

ネイティブアプリのように通知のバッジをつけられるAPI

Badging for app icons

実装自体はメチャクチャ単純っぽい

// Set the badge
const unreadCount = 24;
navigator.setExperimentalAppBadge(unreadCount);

// Clear the badge
navigator.clearExperimentalAppBadge();

Shortcuts

ネイティブアプリにあるホーム画面のアイコンから直接アプリのいろんな画面?にいける機能

今の所 Edge だけで、Chrome は実装予定らしい

MSEdgeExplainers/explainer.md at master · MicrosoftEdge/MSEdgeExplainers · GitHub

f:id:tiwu:20200201193229p:plain
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Shortcuts/explainer.md から引用

mafifest.json に追加するだけっぽいので、これも実装は簡単そう

"shortcuts": [
    {
      "name": "Play Later",
      "description": "View the list of podcasts you saved for later",
      "url": "/play-later",
      "icons": [
        {
          "src": "/icons/play-later.svg",
          "type": "image/svg+xml",
          "purpose": "any"
        }
      ]
    },
    {
      "name": "Subscriptions",
      "description": "View the list of podcasts you listen to",
      "url": "/subscriptions",
      "icons": [
        {
          "src": "/icons/subscriptions.svg",
          "type": "image/svg+xml",
          "purpose": "any"
        }
      ]
    },
 ]

Web Share

ネイティブアプリのようにシェア先の一覧を出すAPI

Share like a native app with the Web Share API

シェアするときは下記の様な実装っぽく、 share() を叩くと(たぶん)シェア先一覧のリストが出てくるんだと思う

今までは自分たちで似たようなシェア先モーダルを作っていたがそれが不要になるっぽい

if (navigator.share) {
  navigator.share({
    title: 'web.dev',
    text: 'Check out web.dev.',
    url: 'https://web.dev/',
  })
    .then(() => console.log('Successful share'))
    .catch((error) => console.log('Error sharing', error));
}

Web Share Target API

ネイティブアプリのように PWA に対してシェアが可能になるAPI

Receiving shared data with the Web Share Target API

manifest.json に追加するだけで、自動的に検知されるっぽい?

"share_target": {
  "action": "/share-target/",
  "method": "GET",
  "params": {
    "title": "title",
    "text": "text",
    "url": "url"
  }
}

SMS Receiver API

SMS 認証のAPI

インドはほとんど電話番号で認証をするとのこと

Verify phone numbers on the web with the SMS Receiver API

こんな感じで受け取れるっぽい

const sms = await navigator.sms.receive();
const code = sms.content.match(/^[\s\S]*otp=([0-9]{6})[\s\S]*$/m)[1];

Clipboard API

テキストのコピーはもともとあったが、画像もコピーできるとのこと

Image support for the async clipboard API

テキストのコピペ

// copy
await navigator.clipboard.writeText(location.href);
// paste
 let text = await navigator.clipboard.readText();

画像のコピペ

セキュリティリスクがあるらしく権限周りの確認が必要とのこと

try {
  const imgURL = '/images/generic/file.png';
  const data = await fetch(imgURL);
  const blob = await data.blob();
  await navigator.clipboard.write([
    new ClipboardItem({
      [blob.type]: blob
    })
  ]);
  console.log('Image copied.');
} catch(e) {
  console.error(e, e.message);
}

Contact Picker

端末の連絡先を取得するAPI

A contact picker for the web

こんな感じで取得できるらしい

ユーザーは連絡先一覧から任意の人を選択するようなフローで、全員を一気に取得ではないとのこと

const props = ['name', 'email', 'tel', 'address', 'icon'];
const opts = {multiple: true};

try {
  const contacts = await navigator.contacts.select(props, opts);
  handleResults(contacts);
} catch (ex) {
  // Handle any errors here.
}

Native File System

ローカルのファイルを取得できるAPI

The Native File System API: Simplifying access to local files

chooseFileSystemEntries を呼べば、OSのファイル選択ダイアログが出てくるとのこと

let fileHandle;
butOpenFile.addEventListener('click', async (e) => {
  fileHandle = await window.chooseFileSystemEntries();
  const file = await fileHandle.getFile();
  const contents = await file.text();
  textArea.value = contents;
});

書き込み処理

async function writeFile(fileHandle, contents) {
  // Create a writer (request permission if necessary).
  const writer = await fileHandle.createWriter();
  // Write the full length of the contents
  await writer.write(0, contents);
  // Close the file and write the contents to disk
  await writer.close();
}

Web Authentication

アクセストークンのAPI(イマイチ理解できていない

FIDO Authentication  |  Google Identity Platform  |  Google Developers

なお、いらすとやにアクセストークンの絵を依頼したら書いてくれたらしいw

セキュリティキーのイラスト | かわいいフリー素材集 いらすとや

f:id:tiwu:20200201194939p:plain

Cookie

先日話題になったCookieの話

Google Developers Japan: 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう

来週くらいには Chrome 80 が来るので準備をとのこと

MiniApp Standardization White Paper

最近中国とかで話題の MiniApp (スーパーアプリ)

MiniApp Standardization White Paper

中国で乱立してきたので標準化しようというのが中国のサービス同士で話題になっているらしい

PWA is just a branding. Believe in the "web"

最後の方のスライドに書かれていた言葉

ウェブを信じろ

スケーラブルPWA 〜こえのブログ最新事例〜

見てきました

conf2020.pwanight.jp

speakerdeck.com

何回かこえのブログの発表は聞いたりしたのですが、今回はスケーラブルにフォーカスをした発表でした

Single Origin を心がけ、SWのスコープやパーミッションCookieなどを扱いやすくしている

いろいろな端末に対応をするために polyfill で対応をしている

パフォーマンスにとても注力しており、いろいろなキャッシュ戦略で立ち向かっている

Faslty によるキャッシュ、SW によるキャッシュを効かせている

パフォーマンスはバジェットとして管理をしている

SpeedCurve などのデータと、実際のユーザーのデータを見ながら計測している

強豪より 20% ほど早くするのを目標にしている(20%の差があればユーザーは認知できるらしい)

ファイルサイズなどは PR などでチェックをして予算を突破したら、コードを減らせるか?機能を減らせるか?などフローに沿って対応していく

アクセシビリティにも色々力を入れており、キーボード操作やダークモードなどを対応している

Project Fugu も積極的に取り入れており、Web Share, Wake Lock (画面が自動で暗くなるのを制御できる), Native File System などなど

感想

パフォーマンスバジェットの容量エラーのときの対応フローがあるのは驚いた

Webでできる体験を考える会

こえのブログを見ていたので、こちらは見ていない

conf2020.pwanight.jp

speakerdeck.com

PWA で音ゲー?を作った人の発表

qiita.com

ツイッターを見ていたらどうやら音響機材?を持ってきていて、すごいことをしたらしい

また、暗号化の話やプッシュ通知の話や、ブロックチェーンみたいな話もあったらしい

こっちも聞きたかった😢

日経電子版のモバイル/PC版統合と今後の取り組み

conf2020.pwanight.jp

speakerdeck.com

日経電子版の高速化の話もよく聞きに行っているけど、今回はPC統合の話

SPはFastly + microservicesで作られていて、PCはモノリシックな状態

SPとPCで別の開発チームで、ドメイン知識が分散したりしてカオスな状態に

また、PCは10年以上保守をしているので結構ぼろぼろな状態

そこで、SPとPCを統合

第一弾はトップ画面

統合時に機能を色々削除

UI/UX 担当がかなり権限を持っており、ビジネスサイドと調整をして削っていった

今まで、 node.js + handlebars だったが、TS + Preact に置き換え

Pure JS だったクライアント側は web components + TS に置き換えし、 SW は workbox を利用することに

PCも Fastly を通し、トップだけSPに、他は今までのPCのアーキテクチャにルーティング

無事リリースしたが、パフォーマンススコアが70くらいで、思ったより成果が出なかった(80以上を目指していた)

リリースはゴールではなく、スタートだった

SW がSPとPCの両方を見るようになり、カオスに

パフォーマンスモニタリングを強化(SpeedCurve に加えて、Lighthouse CI)

開発時の push などで Lighthouse CI を回し、本番は今まで通り SpeedCurve を利用

チューニングは泥臭く、Resource hints や使われてないJS・CSSの削除などを行った

トップにある記事を SW でキャッシュしていが、ユーザーがキャッシュした記事を見ないことが多く、無駄にキャッシュをしていた

CTRに基づきキャッシュする記事を変えるようにして、キャッシュヒット率を高めた

ユーザー体験を高めるために、ユーザーは何が嬉しいかを一番に考え常に動く

ScrapboxでのServiceWorkerとCacheの活用

日経電子版の発表を見ていたので見れていない😢

conf2020.pwanight.jp

scrapbox.io

キャッシュ戦略の話がメインで、CacheStorage の話も

CacheStorage は自分もよく調べていたりしたり、発表をしたこともあったのでとても気になる 👀

Why PWA should be on strategy map for eCommerce companies in 2020.

conf2020.pwanight.jp

事前に収録されたビデオを放送するというスタイル

日本語字幕があって、英語がわからなくても大丈夫だった

Vue Storefront というEコマースのオープンソース

名前にある Vue は Vue.js で作られているからっぽい

www.vuestorefront.io

Eコマースの75%はモバイルで、速さにとても注力している

デスクトップをしらないモバイルを使う子供も増えてきた

端末が大きくなってきたので、親指で使えるところに一番大事なボタンを置くようにした

ヘッダーのハンバーガーメニューとかは遠すぎて使いづらい

アニメーションを多用して、楽しい・面白いサイトとの認識してもらって滞在時間を長くする

バーコードリーダーを搭載しており、店舗で見て、バーコードを読み取り、サイトで買うという流れを作っているっぽい

Eコマースではチャットボットがより流行り、CSはどんどん減っていくと予想している

購入時も簡単にアニメーションで楽しませる

しかし購入時のクレジットカード入力はモバイルで難しいので、Payment Request API で解決する

AMPも利用している

オフライン状態でもカートに商品を入れて、決済までいける(決済はオンライン状態で処理される

アレクサやグーグルホームにも対応している

サイトに対するエンゲージメントをPWAで高めるという考え

ランコムはPWAでCVを17%あげた

OLXは最エンゲージメントが250%アップ、離脱率を80%改善

アリババはCVが76%上がり、インストールしたユーザーは4倍CVした

www.storefrontui.io

https://docs.storefrontui.io/

UIライブラリも存在する

The PWA Book | DIVANTE

本も出しているらしい

PWA x PlayCanvasについて

Vue Storefront を見ていたので見れていない😢

conf2020.pwanight.jp

ゲームと PWA

AMP + PWAで実現するストレスのないページロード

conf2020.pwanight.jp

AMP はフレームワークであり、コンポーネントライブラリ

AMPキャッシュは別で考えたほうがとっつきやすい

Bento AMP で普通のサイトでも AMP Components が利用可能に

amp-script で JS を書いていく

amp-script は Web Worker で動き、DOMを触れるAPIを用意しているのでそれを利用する

AMP 用の SW もあるので PWA と親和性は高い

進化するHTTP

AMP の話を聞いていたので聞けていない😢

conf2020.pwanight.jp

PWAに取り組む前に知っておきたいSPAとSEO

conf2020.pwanight.jp

speakerdeck.com

SEOの土台

・グーグルボットにクロールされること ・HTMLが適切に解釈されること

クロールされるのは sitemap とか内部リンクで頑張ろう

OGPがSEOの文脈で語られることが多い(関係ない)

Fetch as Google とグーグルのインデックスで検証した人がいる

Fetch as Google は5秒、グーグルのインデックスは20秒待った

Google 的には5秒位らしい

Googleはサイトにアクセスをして、サイトをRender Queueに登録する

Render Queueは数時間から数週間かかる可能性がある

これはGoogleも課題に感じていおり、現在改善中とのこと

OGP取得の際はJSが動かないので、レンダリングされたものを返す必要がある

BOTとユーザーに別のコンテンツを返すのは本来アウトだが、ダイナミックレンダリングGoogleが推奨している

developers.google.com

自分たちのサイトの性質やエンジニアをみて、SSRするかSSGするかを考えるのがベスト

まもなくやってくるVue.js 3

SEOを聞いていたので見れていない😢

conf2020.pwanight.jp

speakerdeck.com

最近 Vue Composition API を使っているので聞きたかった!

Taking your web app offline (in a good sense)

conf2020.pwanight.jp

workbox の話

地球で最大規模?のPWAのSLACKグループ

https://aka.ms/pwa-slack

ここらへんでMACの電源が死んだ😭

Unlocking new capabilities for PWA

conf2020.pwanight.jp

speakerdeck.com

NFCが web にくる

developer.mozilla.org

デモ

vimeo.com

コード

github.com

エンディング講演 : PWA on Windows

conf2020.pwanight.jp

www.slideshare.net

Edge の話

Windows は SW のキャッシュ上限なしらしいw

Microsoft Store ? からインストールする PWA はラップされており、Chromium ベースじゃないので要注意とのこと

PWA じゃなくても Edge は無理やりインストールができるらしい

まだまだ Edge にはバグが多いので気をつけようとのこと

LT

懇親会は参加していないのですが、LTがあったそうなので資料を貼っていきます

docs.google.com

speakerdeck.com

speakerdeck.com

感想

PWAが話題になった当初はSWによる高速化、ホームスクリーン追加、プッシュ通知が話題になってたが、最近は Project Fugu をベースにいろいろなAPIがあり、本格的に Progressive に web を作ることができる気がしてきて、今後がとても楽しみです

最後に

PWA Night CONFERENCE 2020 お疲れ様でした!

とても楽しかったです!

Web+DB Press vol.113

ドメイン駆動設計

  • エリック・エヴァンスが提唱
  • 仕様を探すのは難しい
    • 記憶力には限界がある
    • UserというEntityはあくまでユーザーが持つ情報しか持ってない
      • 仕様ではない
    • ドキュメントは常々信用ができない
    • 登録で最大文字列をチェックしていても、更新でもチェックしていることもある(気付けるか?
    • 実際は2箇所でも(一応)全てをチェックして2箇所であると判断しないといけない
  • そのためにはコードの中に気づけるポイントをいれること
    • 例えばユーザーオブジェクトにIDとNameがあったとき、Nameだけ変更できるメソッドを用意するとか
    • UserのNameをただのstringにせず、UserNameというクラスで定義してしまうなど
  • ビジネスの変更の速度に合わせる
    • 究極的にはどんな変更でも一箇所だけにする
  • ドメイン = 領域
  • ドメインとは何かではなく、何がドメイン内に含まれるかを考えるべき
  • ソフトウェア上の表現として十分かつそれを抽出する過程をモデリング
    • 成果物がモデル
    • ドメインのうち重要な知識を抽出した結果できあがる概念をドメインモデルと呼ぶ

ティール組織

ティール組織

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

著者はフレデリック・ラルー。マッキンゼーで10年以上組織改革を行っていた。

2年半にわたり新しい組織モデルについて調査を行い、本書を執筆した。

はじめに 新しい組織モデルの出現

  • 人間の脳は3つあるが、かなり最近まで1つだと考えられていた
    • 司令塔が複数存在して人間(会社)が回るはずがないと無意識に考えたからでは?
  • 組織のトップも下層もそれぞれ辛い(トップは権力争い、下層は退屈でつまらない)
  • いろいろな組織を調査して、多くの組織が互いの存在を知らないまま新しい組織モデルで動いていた

歴史と進化

変化するパラダイム 過去と現在の組織モデル

  • 人類が作ってきた組織タイプは、その時代や世界観に密接に紐づく
  • 人間は常に進化を続けるのではなく、段階的に進化する(オタマジャクシが蛙になるように)
  • 組織も同じように段階的に変化していった

受動的パラダイム(無色)

  • 最も初期の発達段階
  • 家族などの血縁関係の集団(10人位)
  • これ以上増えると人間関係が難しいので、増えると分解する
  • 自我(エゴ)が完全に形成されていない
  • 他人や環境から自分を完全に切り離してはいなく、分業を必要としないため階層やリーダーもいない

神秘的パラダイム(マゼンダ)

  • 数百人規模で自己と他者を区別しているが、自分自身が世界の中心と考えている
  • 因果関係がわからないので、神頼みなどが流行る

衝動型パラダイム(レッド)

  • 完全に自己が目覚めており、最初の首長制度と原始的な王国が生まれる
  • 世界は危険で、力を求めだし、力があれば自己の欲求を満たせると考える
  • 組織は対人関係に力を入れる(マフィアやギャングのように、常にトップは部下に対して力を示し続ける)
  • 正式な役職や階層はなく、恐怖と服従で組織を構成する
  • 組織としては未来ではなく今が重要(カオスな紛争地帯とかが得意

順方型パラダイム(アンバー)

  • 農業・国家・宗教等が生まれる
  • 過去、現在、未来という認識をしているのでスケジュール等が作れる
  • 他人の思考を考えることができるようになる
  • 属する社会集団からはじき出されないように考え始める
  • 「私のやり方かあなたのやり方か」から「私たちか、彼らか」に変わる
  • 正しい世界を成り立たせる不変の法則がある
  • 階層化しやすくなる

順応型組織

  • 組織は中長期的な計画を立てられるようになった
  • 規模を拡大できる安定した組織構造をつくれるようになったい
  • プロセスを適用することで過去を未来に複製できる
    • 去年の授業カリキュラムや去年の収穫量など
  • 知識は個人ではなく組織に蓄えられる
  • 世界は不変と信じているから、過去と同じプロセスを踏む
  • 組織図は強固なピラミッド
  • 人類の最初のグローバルな組織はこの形でできた
  • 計画立案と実行は厳格に分けられている
  • レッド組織は暴力で支配されていたが、アンバー組織は懲戒や罰則で支配する
    • 根底には労働者は怠け者で、常に指示待ち人間という考え
  • そのため自己表現などは求められない
  • しかし、レッド組織と比べればルールを守れば見の安全が保証される
  • メンバーは自分の地位で満足し、より高い褒美を求めないから成り立つ
  • 自分の階級と業務内容に期待されている態度を自分のものとして取り込む
  • 重要なのは社会的な帰属意識
  • 「自分たち」対「彼ら」という問題
    • 「看護師」対「医師」
    • 「営業」対「財務」
  • 集団内の争いを避けるため外部に責任を押し付ける
  • 明確な縄張り意識があり、境界線に目を光らせる
  • できる限り自給自足を追求し、外の世界を不要にさせる
    • 職場と社宅
    • 辞めづらくなる

達成型パラダイム(オレンジ)

  • 世界は不変のルールに支配されているのではなく、複雑なゼンマイじかけのように捉え始める
  • 正解・不正解という絶対的ではなく、他よりうまくいくという相対的な世界観
  • 世界がどのように動いているかを理解すればするほど良い成果が出る
  • この認識を持つと、代々受け継がれてきた規則などに疑問を抱くことができる
  • そのため科学的研究やイノベーションが発達する
  • 達成型の絶対的な善悪を「成果があるかないか」という基準に置き換える

達成型組織

  • 可能性の正解に生きていて、変化とイノベーションは驚異ではなくチャンスと捉える
  • アンバー組織はプロセス重視だが、オレンジ組織はプロセスとプロジェクト重視
  • 基本ピラミッドだが、オンラインで繋がる横断的な仮想チームなど部門や階層に風穴を開け、コミュニケーションの速度を上げる
  • アンバー組織は「指揮と統制」だが、オレンジ組織は「予測と統制」になる
  • 組織内の多くの人材の知性を引き出すことが競争優位になる
  • 自ら考えて実行できる業務範囲において、権限と信頼が与えられなければいけない
  • そこで、目標管理制度が生まれる
    • トップは目標が達成されている限りは、どのように達成されたかをそれほど気にかけない
    • 目的(予測)とフォローアップ(統制)を確定するための経営プロセスが多く生まれた
    • 具体的な成功を目指して動く
      • ボーナスや表彰制度などが生まれる
  • 個人の目標と組織の目標が一致すれば、対立関係になることが多い経営者と従業員が双方の利益となる目標を追求する
  • しかし、実際には統制をやめる恐れが、部下への信頼に勝ってしまう
    • 本来委譲すべき意思決定権を与えられない
  • 実力主義の考えなので基本的には誰でも上に上がることができる
  • 組織を機械と考える
  • 企業は成功すると、より成功するためにニーズを作り出してしまう
  • 物質主義、社会的不平等、コミュニティの喪失

多元型パラダイム(グリーン)

  • 人生には成功か失敗か以上の意味があると考える
  • 人々の感情に敏感で、考えは全て平等で尊重されるべき
  • そのため、密接で協調的なつながりを築く努力が必要
  • 奴隷制の廃止や女性の解放、宗教の自由、民主主義が生まれた
  • 非営利団体、社会事業家、地域社会活動家など
  • 成果よりも人間関係のほうが価値が高い
  • グリーン組織はボトムアップのプロセスを模索する
  • リーダーは奉仕するべきと主張
  • 差別や不平等が続いているので、人生は自己中心的な成功よりも大事なことがあると主張する
  • しかし、悪いアイデアも平等に扱われる

多元型組織

  • 権力や階層をなくしたいと考える
    • しかし、白紙から階層のない組織を作ると一定の規模になると成功はしない
  • オレンジ組織のような階層を残しつつ、意思決定の大半を最前線の社員に任せる
  • 分権化と権限委譲を大規模に行うのはかなり難しい
  • トップ層は権力を分け合い、統制力を弱めるのが求められる
  • そのために中間管理職に対して期待するリーダーシップのあり方を定義する必要がある
  • 部下に耳を傾け、権限を委譲し、育てるサーバントリーダーになる必要がある
    • 管理職候補は「権限を分担する用意ができているか?」、「謙虚に引っ張れるか?」
    • 教育コストかなり払って、サーバントリーダーとしての心構えを教える
    • マネージャーは360度評価によって評価する
    • 部下からマネージャーを指定することもある
  • 今日な文化が共有されていないと、権限委譲は難しい
  • 最前線の社員はルールではなく、価値観で判断をする
  • オレンジ組織だと価値観は、利益の都合が悪くなると無視してしまう
  • リーダーが共有価値に心から従っていると、従業員は敬意をもって扱われていると感じ、権限を得て、貢献しようとする
  • オレンジ組織は戦略と執行が絶対だが、グリーン組織の最も重要なのは文化
  • CEOは文化と価値観を育てるのが重要と考える
  • HR部門が中心的に動く
  • オレンジ組織は株主の視点で経営する
  • グリーン組織は株主だけでなく従業員や社会や環境なども考え、責任を負っている

レッドからグリーンへ

  • 組織という考えは人類の歴史としてはごく最近のこと
  • 加速度的に組織は変化しており、新しい組織モデルが1,2個生まれる可能性もある
  • 別の組織モデルが同じ時代に存在するのも特徴

まとめ

  • レッド組織
    • 暴力と恐怖により支配
    • 短期志向
    • マフィア・ギャングなど
    • 労働分担と指揮権限
    • 狼の群れが近い
  • アンバー組織
    • ピラミッド型の階層構造でトップダウン
    • 未来は過去の繰り返しで「安定」を求む
    • 軍隊・公立学校
    • 長期的視点のプロセス、役割
  • オレンジ組織
  • グリーン組織
    • 文化と権限委譲を重視して、モチベーションを高める
    • 文化重視
    • 価値観、文化

発達段階について

  • 青年は幼児と比べて「良い」人間というわけではない
  • それと同じように各組織も優劣で見てはならない
  • 状況に適しているかという判断をすべき
  • 段階と色は現実の抽象化に過ぎない
  • 人類は1つの段階に収束できない
  • どの段階でも、前段階を内包している
  • 精神面、倫理観などが全て同じ段階にいることもない
  • 人はある特定の瞬間に、ある1つのパラダイムに基づいて活動をする
  • 人生の大きな試練には「解決するために複雑な視点を持つように成長する」か「無視する」か
  • 自分よりも複雑な世界観をすでに獲得した仲間に囲まれ、安心して自分の心理的葛藤を探求できる環境が大切
  • 組織に発達理論を適用するときには単純化しすぎないよう注意する
  • 社長が自由に給料を上げ下げできるのならレッド組織
  • 階級によって固定給になっているならアンバー組織
  • 目標管理による報酬アップならオレンジ組織
  • チーム単位のボーナスを重視するならグリーン組織
  • これらはあくまで組織で、働いている人を指しているわけではない
  • 組織のリーダーの発達段階をチームは超えることができない
  • 組織の神髄は、人々をその気にさせて実力以上の能力を引き出す

進化形

  • 意識レベルが1段階高くなると、世界をより広い視点から眺めることができる
  • そのためには自分の欲求を衝動的に満たそうとするのを抑えるとレッドからアンバーに移行する
  • また、集団の決まりごとを拒否するようになるとアンバーからオレンジに移行する
  • 自分自身のエゴから自らを切り離すとティールへ移行する
  • エゴに埋没していると外的要因に左右されがちになる
  • レッドの観点では自分の欲しいものが獲得できるかが軸
  • アンバーでは社会規範への順応度が軸
  • オレンジでは効果・成功が軸
  • グリーンでは組織への帰属意識・調和が軸
  • ティールでは意思決定の軸が内的なものになる
    • この判断は正しそうか?
    • 自分に正直になっているか
    • 自分がなりたいと思う理想の人物は同じように考えるか
  • 承認欲求や富や愛は結果にすぎない
  • 愛や名声や成功を追い求めると最終的に「他人の顔を身にまとう」
  • ティールでは内面の正しさを求める旅を続ける
    • 自分が何者で、人生の目的は何か
  • 人生の目的を設定してどの方向に向かうのか決めるのではなく、人生を開放しどんな人生を送りたいか考え学ぶ
  • 他人の顔を身にまとうようになるので、自分自身の強さの上に立てない
  • 欠点を見るのではなく、長所を活かす
  • ティールでは「失敗などはこの世になく、全て自分自身の本当の姿に近づくための経験にすぎない」と悟りをひらく
  • 以前の段階では人生の生涯は不運なものとして扱われる
  • ティールでは自分に原因があったのでは?そこから成長するためには?と考えるようになる
  • エゴから自己を切り離し、全体性を求める
  • 脱同一視化を経ると完全に独立し、逆説的に全てのものの1部となる
  • 判断と寛容という対立を超越する
  • 意見が異なる場合、今までは説得や間違いを正したり、意見の違いを吸収して寛容的に取り込むという手法を取る
  • ティールでは意見の違いを正さず、決めつけをしない
  • 会話をするとき修正・否定するための情報収集ではなく、他の人が自分の声や真実を見つけられる手助けをする
  • 人間のエゴによる組織の動きを極力へらす
  • ティールでは自分の人生の使命を探すことに忙しくなる
  • 収益性や成長、市場シェアよりも存在目的が組織の意思決定を道ぎく

第二部 ティール組織の構造、慣行、文化

3つの突破口と比喩

新たな比喩 生命体としての組織

  • オレンジ組織は「機械」
    • 組織の頂上でレバーを引くと従業員が機械の歯車のように働く
  • グリーン組織は「家族」
    • 父は子供に奉仕する
  • ティール組織は「生命体」
    • あらゆる細胞がそれぞれ動く

ティール組織が開く3つの突破口

自主経営

階層やコンセンサスに頼ることなく、仲間との関係性の中で動くシステム

全体性

職場に行くときは「専門家」の仮面を被るのではない

精神的な全体性が呼び起こされ、自分をさらけ出して職場に来ようという気にさせるような、一貫した慣行を実践する

存在目的

組織自身の生命と方向感を持っている

組織が将来どうなりたいのか、どのような目的を達成したいのかに耳を傾け理解する場に招かれる

自主経営/組織構造

  • 権力をトップに集め、権力者とそれ以外に分けると問題を抱え病んでいく
    • 権力は戦って勝ち取る価値のある希少なものになる
  • アンコントローラブルな状態になると、コントール可能な楽しみに引かれるようになる(プライベート
  • グリーン組織は権力の不平等という問題を、組織ピラミッドの下位に一部与えることで解決を目指す
  • 全員が強い権力を持ち、無力なものが一人もいないのという考えが最初の突破口

オレンジ組織からティール組織へ

  • オランダの地域密着型在宅ケアサービス
  • 元々オランダは地元の看護師が在宅ケアサービスを行っていた
  • 大勢の看護師のスキルや数を活かそうと組織化した
    • 休暇を取る看護師のフォロー、知識のシェア
  • 日々のスケジュールの最適化、患者から患者への移動の最適化
  • コールセンターによる患者の窓口の最適化、効率をあげるために治療の時間の設定
  • スキルによる医療の分担、効率の向上のために活動の時間の監視
  • 規模とスキルの効率化を求めるオレンジ組織からすると理に適う
  • しかし患者と看護師の個人的な信頼関係はなくなった
  • 患者を人と認識せず、商品が適用される対象となった
  • 看護が金持ちになるための仕事となった

自主経営チーム

  • 看護師を10-12名程度のチームに分けて、担当地域を割り当てる
  • ケアサービスを提供する以外にも、何人受け持つか、ケアプランの作成、休暇や休日のスケジュールも決める
  • チーム内にリーダーは存在せず、重要な判断は集団で決める

驚くべき成果

  • 介護にかける時間は他の組織と比べると4割ほど少ない
  • 他の組織は「商品」の提供の時間を分刻みに計測し分析して記録するので人数的な話をすると成果が出る

上司の不在

  • 上司(管理職)は存在せず、チームごとに発生する管理業務全般に取り組む
  • 全員「相互座用による問題解決法」を学び、集団での意思決定をするためのスキルを得る
  • 人と人との協力に関する基礎知識を学ぶ

チームミーティング方法

  1. メンバーが抱えている問題を元に、ファシリが意見を吸い上げる
  2. 検討し修正や改良が施される
  3. 信念によって異議を唱える人がいなければ案が採用される

全員が心から賛成する完璧な解決案は存在しないはず

信念に基づく反対がなければ、将来新たな情報が手に入ったときはいつでも見直すという約束をする

  • 外部の助けをいつでも呼んで良い
  • チームに難しい問題を解決するだけの権限と裁量があることを知っている
  • しかし、自由を得て責任を負えるようになるには時間がかかる
  • これは個人が成長する過程で、情熱とモチベーションを持つようになる
  • チームに上司などはいないが、平等であることを意味しない

ドルマネジメントは存在しない

  • マネージャーは存在せずコーチが存在する
  • コーチはチームの意思決定権は持っていない
    • 成果責任もなく、売上目標もない、チームが好成績だからといってボーナスが貰えるわけでもない
  • チームは組織の上部から権限を与えられているわけではなく、自分たち以上の意思決定権を持つ階層に支配されていない
  • コーチはチームのアドバイザー
  • 助言を与えたり、他のチームの解決事例を教えてくれたり、自分たちで解決策を見つけられるように示唆に富んだ問を投げる
  • チームが悪戦苦闘するのは問題ない。学びがあるため。
  • コーチは問題を防ぐのではなく、問題を解決しようとするチームを支える
  • 解決方法を知っていても、チームに選択させる
  • チームの姿をそのまま見せたり、問を投げかける
  • 出発点は、チーム内の情熱と強みと能力を引き出すこと
  • コーチは一人あたり40~50チームを見る
  • チームにかかりきりになるとチームの独立性を冒すかもしれない
  • チームの最も重要は課題にだけコーチは注力する
  • チームは12人を超えない。超えるなら分割する
  • 業務をメンバー間で幅広く分担する
  • メンバー間、コーチとの定期的なmTGを開く
  • メンバーは互いに評価し合う
  • チームは毎年取り組みたいテーマと実行計画をたてる
  • 顧客への労働は6割ほど割く

必要最小限のスタッフ機能

  • 大組織は人事、法務、戦略策定、財務、意思疎通、リスク管理などスタッフ機能が増殖してきた
  • スタッフはルールなどを改正したり、専門技術を積み上げたり、問題を探したりといった付加価値を出す方法を見つけることで、存在意義を証明しようとする
  • そのうち、現場から離れたところに権限と意思決定権を集中させるようになる
  • すると現場は権限を奪われたと感じる
  • ルールは理論的に正しいかもしれないが、現場で直面する状況の複雑さには対応ができない
  • ティールではスタッフ機能を抑える
  • スタッフ機能を大きくして実現できる規模とスキルによる利益よりもモチベーションの低下による不利益のほうが大きいこと承知している
  • スタッフ機能は指針を提供するが、ルールを押し付けることができない
  • 真に現場のサポートであり、チームから要請があったときのみ動く
  • 7000人の看護師に対して本社は30人ほどしかいない
  • 採用、コールセンターなどのスタッフもしていない
  • ほとんどのスタッフ機能がチームに委譲されている
  • 採用をしたいと思ったチームは自分たちで採用活動を行う
  • 自分たちで意思決定をするので、思い入れが強くなる
  • 専門知識グループを本社に作ると、給料の高い専門家と給料の安い格下という2階層ができる危険がある
  • チームメンバーが専門知識を身に着け、チームの枠を超えた連絡窓口になる
  • だれがどんな専門知識をもっているか見える状態である
  • ボランティアによるタスクフォースが立ち上がり、専門知識を蓄える
  • 専門家はフリーランサーとして雇う
  • チームに意思決定権を持たない状態でスタッフを雇う
  • スタッフ機能から課されるルールや手続きがないため社内には解放感と責任感が満ちている
  • スタッフ機能は効率性を期待できると議論になるが、金銭の効果は見積もりできてもモチベーションの低下を数値に示すのは難しい
  • スタッフ機能は幹部が現場をコントールできるという感覚を持てる
  • モチベーションの圧倒的な向上のために、規模の経済を捨てると思うこと
  • スタッフ機能が現場をコントロールできるという幻想を捨てる

労働者が進化型を向く理由

  • 以前はピラミッド型の工場会社だった
  • 15-30名程度のチームに分割した
  • 採用、スケジュール管理等々は以前はピラミッド型の上部に権限があったが、今はチームにある
  • 以前は注文が営業部に届き、企画部等がスケジュールをひき、人事部が人をアサインし、現場の人が働く
  • 部署をまたぐと情報はブラックボックスになり、見えなくなる
  • 営業が報告するのは営業のトップではなく、チームメンバー
  • チームメンバーとは毎日顔を合わせ、仲良くなる
  • 営業トップから与えられる目標より、チームのために働くほうがモチベーションとなる

経営陣はなく、ミーティングもほとんどない

  • ティール組織は、営業や保守などのトップが集まったMTGは存在しない
  • チームは毎日、毎週、毎月など自分たちで決定し運用する
  • MTGは上から目線の意識が生じるリスクが発生する
  • ピラミッド型の場合、情報が指揮命令系統の中を円滑に上下するように伝達するように階層間でMTGをする
  • トップに情報が集まるため、意思決定の権限が上に押し上げられる
  • 問題が発生したときに初めてMTGが開かれる
  • 有機的な組織

チーム間の人員調整と知識の交換

  • チームを超えた調整の際に、ピラミッド型であれば管理職の出番である
  • 人の割り振りは、ティール組織では全チームから誰かが集まって会話して決定する
  • 支援業務する人はチームを超える意思決定権はなく、自分たちの説得力を頼る

信頼 vs 統制

  • 生産性の管理(時間ごとのノルマなど)を辞めたら、逆に生産性があがった
  • ノルマが上げられても対応できるようにセーブをして仕事をしていたから
  • ノルマを管理し、他人をクビにする仕事は、幸せを生み出せていない

信頼のエネルギー

  • 組織の大きな阻害要因は「恐れ」である

プロジェクト

  • 本当の意味でプロジェクトに必要じゃない作業はしていない
    • 報告用の資料など
  • 意思決定、優先度の決定はシステムの持つ集団的知性を信頼する
  • 継続的改善、リーンの専門家はいなく、チームの中に溶け込んでいる
  • 課題は壁に貼られて挙手制で対応する
    • 誰も取らないのであれば重要ではないという認識になる
  • 机はキャスター付きで移動がしやすい

自主経営を数万人規模に拡大する

  • 個人の権限と責任を大きくすると、市議とは楽しくなり、業務改善の余地が大きくなる

ボランティアによるタスクフォース

  • 8割を自分の業務に当てて、2割を会社の中で動いているタスクフォースに時間を使う
  • 予算など専門的なものも多くの従業員で決める
  • 自分のスキルや才能や好みなどが見つかることもある
  • 会社を変えられる権限を持っていることに気づくと、責任感がます
  • また、学習がハイスピードでできる

組織図も、職務記述書も、肩書もない

  • 事前に決められた仕事に合わせる必要はなく、興味や才能、組織のニーズに基づき決まっていく
  • 方向性を決め、予算を立て、分析し、計画を立て、測定し、採用し、評価し、意思疎通を図るのは分担される
  • 流動的に仕事が行われる
  • 管理系が集中すると階層的な組織に戻るリスクがある
  • チームリーダーが上司のように振る舞い出す危険がある
  • メンバーはチームの移動の自由が約束されているので、権限を持とうとしても離れられる
  • 役職はエゴの蜜で、自分が役職そのものと勘違いしてしまう
  • 役職はないが、全員が同じ仕事をしているわけではない
  • 全員が互いに同僚と呼び合う
  • 外からみたらCEO的な仕事をしているかもだが、中ではCEOとは呼ばれない
  • 仕事をチームメンバーに約束をするので、互いに管理職となる

自主経営/プロセス

  • 前章では組織構造について述べた
  • この章では実際のプロセス(意思決定方法など)について述べる

助言プロセス

  • 原則として誰でも意思決定ができるが、必ず決定する前に誰かに助言を求める
  • 意思決定は上が決定するか、全員で一致させるかという2通りだけと思いこむ
  • 相談された側は同じ仲間だと思うようになる
  • 必要とされていると感じる
  • 助言をするというトレーニングになる
  • 実施する人と意思決定がかなり近くなる
  • そして楽しい

危機発生時の意思決定

  • 業績が悪いときに解雇すべきか?
    • リーダーはメンバーに素直に伝えて案を募った
  • 従業員は難しい問題を解決できないのでは?
  • といった恐怖に打ち勝つ必要がある

購買と投資

  • 誰でもいくらでも使って良い
  • ただし助言プロセスは必須
  • これは信頼の上に成り立っている
  • 管理して大量購入をしたほうが節約では?
  • それに気づいた社員が取りまとめをすればよい

暗黙の前提を明らかにする

  • 信頼か統制かについて真正面から議論されることが少ない
  • ↓古き前提
  • 労働者は怠け者だ。すぐサボる
  • 労働者は金のために働く。
  • 労働者は組織より自分の利益を優先させる
  • 労働者は繰り返し可能な単純作業をする場合に効率が良い
  • 労働者は業績に影響を及ぼすような重要な問題を解決できない。それは管理職が得意
  • 労働者は重い責任の仕事をしたくない
  • 労働者は子供のように保護を求める
  • 労働者は時間や製品の数で報酬を得るべきである
  • 労働者は交換可能である
  • 労働者は指示を待つ
  • ティー
  • 創造的で、信頼に足る大人で、重要な意思決定を下せる
  • 自分の判断と行動に説明と責任をもてる
  • 失敗したってかまわない
  • ユニーク
  • スキルで世界に貢献したい
  • アンバーな組織になると人はアンバーになる

内部のコミュニケーション

  • 情報を断絶していくと不利益が多い
  • 従業員は信用できない
  • 従業員は予測不可能で、非生産的な行動をする
  • という思い込み
  • 上が隠していると思うようになる
  • 組織改造がないので最善の判断をするためには互いに情報を知る必要がある
  • 公表されないとなぜ隠すのかという疑念をうむ
  • 情報の知っている度合いで見えない階層が生まれる
  • 全員参加、全員知れるというリスクに力が眠っている

紛争の解決

  • 前提
  • 個人は決して他の人に何位かを矯正してはいけない
  • それぞれの約束を守ること
  • ↓紛争解決プロセス
  • まずは二人だけで解決しようと努力をする。
  • 要求ではなく相手にお願いしたいことを述べ、それに誠実に返答をする
  • 合意できなければ二人が信頼をしている別の同僚を調停者に選ぶ
  • サポートをするが解決策は強要できない
  • それでもだめならば委員会を発足し合意形成を手伝う
  • 進んで互いに説明を求め会える文化がないと難しい
  • 自由と責任はコインの裏表のようでバランスが大事

役割の配置と決定

  • 役割は必要になる問題などが発生したときに自然に生まれる
  • 新しい役割が必要だという意見を助言プロセスにのっとり行っている

約束を文章化する

  • 個人的なミッションを・ステートメントを書く
  • 約束した役割をすべて書き出す
  • 作業がラインになっている場合は隣接する人たちと会話をする
  • 互いの約束を話し合い交渉をし、社員間の繋がりを強くする
  • 人との繋がりと、組織のピラミッドの階層がまざると混乱する
  • 階層がないため昇進がない
  • 経験を積むに従い、大きな責任を持つようになる
  • 上司に良く映りたいではなく、同僚にいい顔を見せるようになる

チーム内の役割とガバナンスをはっきり決める

  • 物事の進め方の最も洗練されたものは「ホラクラシー」である
  • ラクラシーは組織のOS
  • 人=役職という融合を切り離す
  • 人々は仕事を持つのではなく、多くのきめ細かな役割を果たそうとする
  • 役割が必要と感じたら、役割のみを決めるMTGを開催する
  • 提案を発表し、問題点の明確化をおこない、意見を述べ、反対意見を集め、統合する
  • 役割を決めるために裏でこそこそせず、場があることで健全になる
  • 助言プロセスの亜種
  • 目的は完璧な答えを出すのではなく、解決策を見つけ、必要があればすぐ練り直すという商法
  • 頻繁な変化で対応をしていくというマインド

全責任

  • 階層的な組織ではマネージャーは数字に対する責任を負っている
  • ティールでは役割を負い、責任範囲も明確だが、縄張りはない
  • 自分が気づいた問題は自分の役割以外でも何かをする責任を追う
  • 何かとは、問題に関連する役割を持っている同僚に話すこと

任命プロセス

  • 自分のしたいことの全権限があると、出世したいと思わなくなる

役割を交換する

  • 自主経営されていると役割は明確化されるので交換しやすい
  • 役割はホラクラシーでいうとOSの上にのるアプリのようなもの
  • 元気が出る仕事か、疲れる仕事か?
  • 才能が生かされているか、生かされてないか?
  • スキルと知識は役立っているか、いないか?

タレントマネジメント

  • 見込みのある人材を見つけ、特別な研修をする
  • 管理職ポストに対して後継者を作ったり
  • あらゆる人にキャリアパスを考えたり
  • ティールではリーダーシップは分散される
  • 自然に多くの機会に触れて学び育つので、マネジメントはいらない

チームレベルでの実績管理

  • オレンジ組織はプレッシャーをかけ手を抜かないようにさせるのが管理職の仕事
  • ティールではなぜ甘えないのだろうか
  • 仲間との励まし合いと市場の要求によって、内側のモチベーションがあるから
  • なぜ成果を上げるためにはプレッシャーを与えたほうがいいと考えるのか
  • 目的があり、意思決定と資源を持っているときは自発的に動く
  • 従来の組織は自己表現の機械はルールや管理職によって制限される
  • 情熱を持って働くなった場合は人間関係などが悪化している兆候
  • 個人の成果は測定しない
  • 誰でもデータを見れるので、ノウハウを模倣しようという機運が高まる
  • いい意味で仲間からの圧力
  • 簡単にチーム間で成績の比較をできる
  • ティールでは情報が不利になるように使われることはない
  • 事実が良くても悪くても、守ってもらう必要はない
  • 比較できないチームは同僚を前に自己評価のプレゼンを行う
  • これは数時間かかる

個人の実績管理

  • 実績と成果は真っ先にチームレベルで話し合われる
  • それでも個人のフィードバックがほしいと思う
  • 人は感覚が遮断された部屋にいるとすぐ狂ってしまう
  • つまり外部の刺激を欲しがる(フィードバック
  • 影で他人を評価するのではなく、信頼度の高い状態で評価し合う
  • 助言プロセスもフィードバックをもらう1つ
  • 従来組織では、評価はテンション下がるものになりやすい
  • 管理職は狭いところでしか見ない
  • 話し合う内容が狭くなりがち

解雇

  • 基本的には自分の実現したいところで働くことができるのであまり解雇ということはない
  • 従来組織では管理職が決定権を持っている
  • ティールのなかでは自ら適していないと重い自分から去ることがおおい
  • もし誰かが会社の大切にしている価値を壊した場合助言プロセスのフローで解雇が進む

報酬とインセンティブ

同僚間の話し合いに基づくプロセスと自ら定める給与

  • 基本的には話し合いで決定する
  • 自分で給与を決めるところは説明責任が発生する

個人への報奨金はないが、会社全体の賞与はある

  • アンバーでは地位に応じて決まるので、成果報酬はない
  • オレンジは成果報酬がある
  • グリーンはチームに対して成果報酬がある
  • ティールでは内在的欲求で動くので、報奨金は存在しないことが多い

報酬の不公平を減らす

  • 生活に必要なニーズをカバーできる最低給与かが重要

自主経営への4つの誤解

  • 長い間人間は互いを支配しあおうとすることが必要と感じていた

誤解1 組織構造も経営もリーダーシップもない

  • ティールにも組織構造、意思決定プロセスなどがある
  • 管理の仕事はなくなったわけではなく、経営陣に集中しなくなったにすぎない

誤解2 全員が平等

  • 権力の不平等を解決するのではなく、超越する
  • 解決しようとすると全員が同等の権力を持つことになる
  • ティールでは「どうすれば全員が強くなれるか?」と考える
  • 権力を誰かが持つと他の人の分が減るというゼロサムゲームと見ない
  • 全員が繋がっていることを認め合い、あなたが強くなれば自分も強くなると考える
  • 助言プロセスにより必要な権限はすでに持っている
  • 全員を平等にすると考えず、健康になることを認める
  • スキルなどの階層は生まれる

誤解3 要するに、権限移譲

  • 委譲ということはトップに権限があることを認めている
  • 自由は責任を伴う
  • 経営陣に投げていた難しい問題も自分たちで考えることになる
  • 権限は共有されるもの

これは、まだ実験段階の組織形態

  • ボランティア組織はかなりの大きさになっている
  • なぜなら会社で階層組織に触れすぎているから

まとめ

オレンジ組織

  • ピラミッド型の階層構造
  • 人事、財務などのスタッフ機能が多数
  • 階層間でMTG
  • プロジェクトはガントチャートなどで厳重に管理
  • どの仕事にも役職があり、内容は決まっている
  • 意思決定は上位で行われる
  • 危機は上位が秘密裏に対応する
  • 投資は予算で管理される
  • 情報は力であり、知る必要がある限り開示される
  • 紛争は解決されずうやむやにされる
  • 少ない昇進機会で争いが発生される
  • 実績は個人のパフォーマンスに注目され、評価は上位に決定される
  • 報酬も個人のインセンティブで上位に決定される
  • 解雇は管理職が権限を持つ

ティール組織

  • 自主経営の組織、コーチがフォローする
  • 各チームにスタッフ機能がある
  • 必要に応じてMTGが発生する
  • プロジェクトは自分たちで管理し運用する
  • 決まった役割はなく、流動的になる
  • 意思決定は助言プロセスで行う
  • 透明な情報共有
  • だれでも助言プロセスのもと予算を使える&同僚間で予算を話す
  • 紛争は解決の仕組みがある
  • 役割は流動的に再配分される
  • チームのパフォーマンスを注目する
  • 給与は互いに評価し合う

全体性を取り戻すための努力/一般的な慣行

  • 組織は仮面を付ける場所だった
  • 制服は会社が定義した役割を果たすものになる
  • 自分自身を家に置いて出社することになる
  • 組織はありのままの姿の従業員を恐れている
  • 従業員側は互いにバカにされるなど恐れている

人間性を仕事に呼び込む

  • 犬や子供を連れてくる
  • ペットや子供の前で、普段の仕事でしか見せない姿しか見せないのは難しい

開放的な、真の意味での「安心」できる職場環境

  • 自分自身を全てさらけ出すのは危険と感じる
  • 大切な部分が攻撃される可能性があるから
  • 基本前提
    • 人はみな、平等に尊い存在である
    • 人は明確にそうでないと証明されない限り、本質的に善良だ
    • 組織の問題にうまく対処する単一の方法はない

安全な環境のための基本ルール

  • まずは全員の意識を高めることから始まる
  • 人と人がいる限り意見の不一致は必ず起こることを認める
  • ただし、険悪な敵対的な怒りは受け入れられない
  • 自分が正しいという思い込みをやめること
  • 思考と行動との区別せよ

価値観と基本ルール

  • 価値観に命を吹き込むには文章だけでは足りない
  • 研修を行ったり、話し合う時間が必要

内省のための空間

  • 心を鎮めるために定期的に沈黙し、内省が必要だ
  • 定期的に沈黙の時間を作ったりなど

大集団での振り返り

  • 毎週全員集めて振り返りを行う
  • 集中筋力トレーニングのようなもの

チームへの助言

  • チームは外部コーチに助言を求められる

ピア・コーチン

  • 同僚同士で相談し合うことができる
  • ただし、オープンクエスチョンのみ

個人へのコーチン

沈黙

  • 空間を埋める言葉がなくなったとき初めて、うちにある深い声に気づける

物語ること

  • 信頼が鍵になるが、仮面をつけるので難しい
  • 飲み会を開いても仮面の状態で接するだけ
  • 大事なのは物語ること

ミーティング

  • MTGをすると、悪い部分と良い部分がでる
  • 自分のエゴを抑え、組織として全体性を実現するために、ルールがある
  • MTGの最初の1分間は沈黙する
    • 落ち着くため
  • もしくは雑談から入る
  • 組織の目的よりも個人のエゴを優先していると感じたら止める権利を持つ

紛争に対処する

  • エゴによる紛争は激しくなるが、魂の紛争は激しくならない
  • ティールでは職場で必要な対立を表面化し対処する方法を提示する
  • 定期的な討論の場を用意
  • 紛争解決のプロセス
  • 人間関係のスキルを学ぶ
    • 私はこう感じています
    • 私はこれを必要としています
    • あなたは何が必要ですか

建物と地位

  • CEOなどに大きな役割や設備を与えるとエゴが増幅する
  • 労働力を提供する場となってしまう

環境問題と社会問題

全体性を取り戻すための努力/人事プロセス

採用

  • 採用期間中に、嘘をつくことが多い
  • ティールは人事ではなくチームメイトが面談を行う
  • 互いに一緒に働きたいかという判断基準
  • 盛って紹介しても自分に跳ね返ってくる
  • ティールだと役割は流動的なのでスキルを重視しすぎない

オンボーディング

  • ティールでは新しい社員に時間をかなりかける
  • 自主経営の手法や全体性の仕組みなどを学ぶ
  • エンジニアも管理職も機械の動かし方を学んだりする

研修

  • ティールでは新たな取り組みを試そうというときに邪魔されることがない
  • 色々なスキルを共に学ぶ機械が多い

個人の責任と研修を受ける自由

  • 従業員自身が研修を企画・実施する

さまざまな研修分野

全員参加の共通研修

  • 新入社員を対象とする研修が多く実施される
  • しかし、一度の研修では難しいので定期的にやったりもする

従業員が講師になる

  • 互いに意欲が刺激される

職務経歴書、役職、キャリア・プラン

  • ティールには説明できる単一の仕事をしていない
  • 様々な役割を兼務している
  • 役割がないと自分は何者かという組織と自分の結びつきを減らせる
  • 役割が自分自身と勘違いしだす
  • 役割がなければ一人の人間として存在する

約束、労働時間、柔軟性

  • 決まった労働時間を課すのは、人を資源として扱う
  • 決まった就業時間がない場合プライベートを犠牲にしろというメタファー
  • 毎週仕事にどれくらい時間をかけるか話し合ったり
  • 時間が取れない期間は仲間と話し合ったり、解決策を探す

フィードバックと実績管理

  • 職場への貢献度を知りたいのは一般的な欲求
  • 仕事はきちんとこなすことが当たり前で、具体的にFBがもらえることは少ない
  • 後ろ向きなFBは真剣に向き合うことを躊躇され先延ばしにされる
  • その結果評価面談が楽しいものにならない
  • FBを利用し「こうあるべき」という考える方向に誘導しがち
  • 実績管理はチームで行い、評価とFBもチームで行う
  • 相手のだめなところを治すという話ではなく、マインドフルで相手のことを考え会話をする
  • 客観的ではなく主観的な自分の意見を言うことで相手もされけだしてくれる
  • FBは相手と自分が共同で行う探索である
  • 改善点は1年中言い合おう

解雇

  • 賃金カットをすることで、一時解雇をせず耐えきる
  • 人が多いと縄張り争いをするようになる

要約

  • 全体性と分離状態・愛情と恐れという対立を解消する
  • 組織から提供されていると信じている安全を得ようと分離状態を求める
  • やがて仮面をつけるようになり、分離される
オレンジ組織 ティール組織
建物と組織図 標準化された、機能に特化した、面白みのない社屋
多すぎる肩書
自分たちで飾り付けた、あたたかい雰囲気のスペース。子どもたちにも動物にも自然にも開放されているオフィス
肩書がない
価値観と基本ルール 組織の価値観は壁に飾られているだけのことが多い  明確な価値観が、組織内で受け入れられる(受け入れられない)行動や態度の基本ルールとして具体化され、働く人々にとって安全な環境を守ろうとする
価値観と基本ルールに関する継続的な討論を深めるための慣行 
内省のための空間 なし 静かな部屋
集団での瞑想と沈黙の慣行
大集団での振り返り会
チームでの監督と仲間同士でのコーチン
コミュニティの構築 なし 自分をさらけ出してコミュニティを作るための、物語ることの実践
役職と職務内容 役職は「自分は何者か」を示す標識
組織内に確立した職務記述書
役職名がないため、社員は自分が何者かを深く追求せざるを得ない
自分の役割を自分で決められる
業務時間の拘束 仕事にかけられる時間と自分が生活の上で大事にしている他の時間との割合についての誠実な話し合い
紛争 対立を明らかにし、対処するための時間が定期的に定められている
複数の段階を踏む紛争解決の仕組みがある
社員全員が対立に対処するための訓練を受けている
ミーティング ミーティングの決まり事がない エゴを抑え、全員の意見に耳が傾けられるような具体的な決まり事がある
環境と社会への取り組み 事の本質とは無関係な「金額的基準」がある
業績への影響を考慮しながら経営トップだけが取り組みを始めることができる
本質的な基準としての「誠実さ」
何をするのが正しいかを誰もが感じ、誰もが取り組みを始められる
採用 訓練を受けた人事部スタッフが行い、職務記述書が大事 社員たちととの面談で、組織と存在目的が重視される
オンボーディング・プロセス 管理面に関する入社プロセス 人間関係と企業文化に関する徹底的な研修
組織に溶け込むためのローテーション・プログラム
教育研修 人事部が設計し、スキルやマネジメント訓練が多い 研修は自由に自己責任で受ける
文化構築の研修が極めて重要
実績管理 過去の実績に関する客観的な断面を把握しようとする その人がこれまで何を学んだか、使命は何か探求する
解雇 法的、金銭的プロセス 学習機会へと転換する思いやりのある支援

存在目的に耳を傾ける

  • 組織が掲げるミッションが空虚に響くのは、勝利を優先しているから
  • 空虚に響くのはミッションが行動や意思決定を左右するほどの力を持っていないから
  • ではなぜ存在するのか?
  • 根底にあるのは恐れで、競争相手が自分たちの利益を奪おうとしていると感じる
  • 生き残るためには市場シェアを拡大すること
  • 戦いの最中に組織の存在目的を考える時間などありはしない
  • 外に競争がなかったら内側に競争が発生する
  • エゴを抑える事が必要

競争、市場シェア、成長

  • ティールには競争という概念がほぼなくなる
  • 組織が自社の目的のために存在するとき競争はなくなる
  • 例えば病院を経営する会社は別の病院の会社にノウハウを教える
  • 会社の目的は患者を助けることなので、目的に沿っている動き

利益

  • オレンジ組織は株主価値が支配的な価値観となっている
  • 優先する義務は利益の最大
  • ティールでは利益は空気みたいなもので、生きるために必要であるが呼吸するために生きてはいない
  • 良い仕事をしたときの副産物
  • 存在目的を追求しているうちにビジネスとして成立するようになった
  • 逆になってはいけない

存在目的に耳を傾けて意思決定を行う

  • オレンジは組織を機械ととらえる。機械は心はなく方針もない
  • 機械が何をするか決定するのがCEOになる
  • ティールでは組織を生きたシステムと考える

存在目的に耳を傾ける慣行

  • 組織がどこに行きたいかどうやって知ればいいのか

感じ取る

  • 特別なことはせず、自主経営に任せる
  • 人間はもともと感知器がある
  • 自主経営組織では全員が組織の感知器となり、変革をおこなう
  • しかし、従来の組織では情報は少しずつ届く
  • また、情報は歪められ届く
  • 自分のアイデアを何層も通して経営陣に検討をしてもらうという長いフローを誰が取りたいと思う?
  • また、採用された案を各チームに押し付けてうまくいくのだろうか?
  • 変化は必要と感じている人が起点となって起こる

神領域での練習

  • 瞑想や沈黙をすることでより感じ取れる

誰も座らない椅子

  • MTGに組織と組織の存在目的を考えることのできる椅子を用意する

大集団でのプロセス

  • 全員が集まり発言権を得て、会話を行う
  • グループの集団的な意思決定がリーダー1人の意思決定より優れていると信じないとできない

外部からの働きかけ

  • 会社が存在目的を明確にしていると外から連絡が来る

有機的なプロセスとしての戦略

  • 従来は経営陣が戦略を決定し、下部組織へ伝達される
  • ティールでは全員が組織の存在目的に対して明確で鋭い感覚を持っている

マーケティング

  • ニーズを満たすようになるとニーズを作ろうとし悪循環が生まれる
  • ティールでは正しい提案と感じる声に耳を傾ける
  • 顧客調査などせず、世界のニーズに答える
  • 自分たちが誇りを持てるか、世界のニーズを満たせるか考える
  • 分析よりも美と直感で導かれる

プランニング、予算策定、統制

  • 予測や管理をしようとせず、状況を感じ取り対応を行う
  • 自転車を乗るときに、予測をして予測どおりに乗る人はいない
  • 常に周りからデータを取りながら補正しながら動く
  • 目の前の現実を感じ取り調整を行う

実行可能な解決策と高速反復

  • 予測と統制で動くと完全な答えを探したくなる
  • 入り組んだ(complicated)世界で予測するのは有益
  • 複雑(complex)なセキアでは関連性が失われる
  • 予測をすると自分が統制できているという安心感を得ることができる
  • ティールでは考えられる限りでベストの判断を狙うのではなく、すぐ使える実行可能な解決策を狙う
  • 新しい情報が入ると、それに応じて見直され、どの時点でも改善が図られる
  • リーンやアジャイルの核心にある
  • 全ての部署で意思決定を組み込み、実行可能な解決策が示されると採用する
    • 誰が見ても事態が悪くならないと判断できる解決策を意味する
  • もっと多くデータを集めるか、分析をもっとすれば良い判断ができるかもしれなくても、判断を先延ばしにすることはない
  • 新しいアイデアがあれば見直す
  • 自転車であれば正しい角度を計算するのではなく、だいたいで乗って調整をする
  • 高速に反復することでスムーズに前進できる
  • ベストな決定をするために無駄にエネルギーを使うことがない
  • 判断を保留にすることはない
  • 小さな判断を何度も修正することに慣れていれば間違いを正すのが楽になる

目標を設定しない

  • ティールではトップダウンの目標を設定しない
  • 目標設定をする3つの問題
    • 自分たちは未来を予測できるという前提に立っている
    • 内なる動機から遠ざかった行動をするようになる
    • 新しい可能性を感じ取る能力がせばまりがちになる
  • 設定する目標はだいたい当てずっぽうになる
  • 標数値は人々の行動を歪める
  • 目標がなければ内なる動機と相談しながらベストの仕事ができる
  • 意味があると思ったら自ら目標数値を定める
  • 目標だけ見ていると他の視野が見えない

予算を簡素化し、予実分析をしない

  • 予算策定は、データと予測を求められゆるいとトップダウンで予測を引き上げられる
  • 予算が達成できないときは呼び出され説明させられる
  • 市場や部署への責任転嫁にエネルギーが使われる
  • 目標がない場合、従業員の達成度をどうやって図るか?
    • 誰も知らない、気にしない

チェンジマネジメント

  • 変革とチェンジマネジメント
  • 変化が大変でストレスがたまるものと考えない
  • ティールでは常に変化が自然に発生する
  • オレンジでは変化は外から圧力がかかるもの
  • 変化事態に抵抗はなく、変えられることに抵抗を感じる

顧客。サプライヤー・情報フロー

  • 自社の目的達成のために自然と周りを巻き込む
  • 取引相手は価格と品質だけでなく、価値観があっているかも判断する
  • 外部に開放的になるのは避難されるのではなく、誰かが助けてくれるようになる
  • つまるところの避難される恐れがなくすといいことが起きる

意図的な「気分」の管理

  • 組織にも、人間と同じく、気分がある
    • 諦めの気分、恐れの気分、野心が満ち溢れている気分
  • 何ができるかは気分次第で変わる
  • 組織の目的に関しては、自分の個人的な希望を投影しないよう注意をする
  • 個人の性格によって好きな気分は異なる
  • 重要なのは組織が目的達成のためその瞬間に最も寄与する気分はなにかである
  • 感謝を促す慣行を作り、感謝を起こしやすくする
  • MTGの最初に感謝したり、休みと資金をもらい感謝する日を設けたり、1人ずつ感謝し合ったり、金曜日にメールを飛ばし合ったり

個人の目的と組織の目的

  • 個人と組織は互いに成功し合う必要がある
  • 社員が各自の使命を模索する環境を提供しないと、社員は給料のために仕事と捉える
  • 社員が組織の存在目的に耳を傾けるよう求められると、自分の人生の使命を模索するようになる
  • 会社の存在目的は自分と共鳴するか、この会社で働くことが使命と感じるか、ここで成長ができるか
  • 採用、訓練、評価面談は個人と組織の存在目的の交差点を探る機会
  • 組織の存在目的との適合性は個人の存在目的を確認しないと検証が難しい
  • 最終的には「一緒に働くのは運命づけられているか?」
  • 相当深い話になるので、長くなる
  • 評価面談でも再び話し合うことになるかもしれない
  • 仕事は物事を遂行するためであって、使命を見極めたい人を助けるためでないと感じる

存在目的に耳を傾ける 要約

  • 競争相手を打ち負かし利益と市場シェアが最重要項目となる
  • これは株主モデルの本質で、経営者の義務は世界に対する目的に奉仕することではなく、株主価値の最大化
  • ステークホルダーモデル」という、投資家、顧客、環境などのニーズに答えるという主張
  • ステークホルダー同士のニーズの調整をリーダーが行う
  • ティールでは組織を資産としてみない
  • 組織は独自の存在目的を追求する1つのエネルギーが集まる場所
  • 誰も組織を「運営」しない
  • 組織の存在目的に耳を傾ける慣行を行っている
オレンジ組織 ティール組織
目的 ミッションが何を言っていても、組織の存続 組織は自らの存在目的を持った生命体として見られている
戦略 組織のトップが決める 自主経営ができる従業員の集団的知性から自発的に生まれる
意思決定 競争の中でいかに生きるか意思決定の原動力 組織の存在目的に耳を傾ける慣行
全員が感知器
瞑想、誘導視覚化、外部からの働きかけに対する反応
競合他社 競争という概念はなく、受け入れ、共に目的を追求する
成長と市場シェア 成功への鍵 存在目的の達成に寄与する限り重要
利益 先頭の指標 正しいことをしていれば自然についてくる後続的にな指標
マーケティングと製品開発 顧客の調査とセグメントが商品を決める
必要に応じて顧客ニーズが作られる
何を提供するかは存在目的によって定める
直感と美によって導かれる
プランニング、予算策定、管理 予測と統制に基づく
中期計画、年次予算、月次予算という厳しい周期
計画への固執。差分は説明し埋める
やる気を出させるための野心的な目標
感じ取る反応に基づく
予算、予実分析はない
完璧な答えを探すのではなく、実用的な解決策と迅速な繰り返し
常に何が必要か感じ取り、目標数値はない
チェンジマネジメント AからBに動かすため 常に内部から変化しているのでこういう概念はない
サプライヤーと透明性 サプライヤーは価格と品質で選ばれる
守秘が当たり前
サプライヤーは存在目的への適合度で選ばれる
透明なので部外者から提案をもらえる
気分管理 なし どんな気分が組織目的に寄与するか常に感じ取る
個人の目的 組織の役割ではない 交差点を探るためにいろいろする

共通の文化特性

  • 組織の構造、システム、プロセス、慣行という見える部分と見えない組織文化
  • 組織に属する人々によって共有されている、前提や規範
  • それについて意識しないままで物事が進んでいくあり方
  • 空気のようなもの(内装、会話や冗談、対処の考え)
  • 組織の性格
  • オレンジは文化をソフトなものとして無視をする
  • 組織をハードな機会として認識をする
  • グリーンでは文化が最大の要素

文化、システム、世界観はどのように作用し合うのか 4つの象限

  • ウィルバーの四象限モデル
内面的な次元 外面的な次元
個別的な次元 人々の信念と心の持ち方 人々の行動
集合的な次元 組織文化 組織のシステム、構造、プロセス
  • 4つの角度から現象にアプローチできる
  • オレンジ組織
内面的な次元 外面的な次元
個別的な次元 人々はお金と称賛によって動機づけられる 目標達成のために抜け駆けをする
集合的な次元 内部競争、個人の達成がチームプレーより高く評価される トップダウンによる目標設定、インセンティブ
  • 1つの象限が変化すると他の象限にじわじわ広がる
  • グリーンでは文化を重視しすぎて、構造やプロセスを見直すことをあまりしない
  • マネージャーが権限を行使しないようにするためには、常に一定のエネルギーが必要
  • エネルギーを使うのをやめると、階層主義が幅を利かせる
  • 自主経営は文化と制度は反発し合うのではなく協力する
  • 権限は自然に分配され、権限移譲しやすい環境を作る必要もない
  • そもそもマネージャーに権限がないので、委譲は発生しない
  • ティールでは文化は必要性が低いが、影響力は高い
  • 階層構造を克服するための文化ではない

進化型組織の文化

  • 追求する目的によって独特の文化が生まれる
  • ↓共通の文化的要素

自主経営

信頼

  • お互いに好意的な糸を持った存在として親しみを感じる
  • 自分たちが間違っていることがはっきりするまで、同僚を信頼することが、組織に関わる際の前提条件である
  • 自由と説明責任はコインの裏表である

情報と意思決定

  • すべての情報はあらゆる人に開放されている
  • 扱いの難しい事件が起こっても、誰もが冷静に対処できる
  • 集団的知性のちからを信じている。全員で出し合う知恵に勝るものはない。したがって助言プロセスですべて決める

責任と説明責任

  • 一人一人が組織のために完全な責任を持つ。対処すべき問題を感じたときには、行動する義務を負う。問題意識を自分の役割の範囲にとどめることは認められない
  • FBや敬意を持った指摘を通じて、だれもが安心してお互いに説明責任を問うことができなければならない

全体性

等しい価値

  • だれもが本質的には、等しく価値ある存在だ
  • 同時に、すべてのメンバーがそれぞれの役割や教育、スキルの違いを尊重し合って、自分なりのやり方で貢献できるようになれば、組織のコミュニティは豊かになる

安全で思いやりのある職場

  • どのような状況であっても、恐れと分離の精神で対処することも、愛に基づいてアプローチすることもできる。愛を選ぶ
  • 私達は誰もが自分らしくふるまえるような、安全な環境を作り出そうと努力している
  • 愛、思いやり、感謝と言った気分や雰囲気を尊重する
  • 職場の中で思いやり、魂、目的といった語彙を抵抗なく使える

「分離」を克服する

  • それぞれの人のすべての部分を尊重できる職場を目指す
  • 認知的にも、物理的にも、感情的にも、女性的にも、男性的にも
  • 私達は互いに深く結びついて、自然とあらゆる生命体を含む大きな全体の一部ということを認識している

学び

  • あらゆる問題は、学びと成長を促すヒントである。いつでも学習者になる
  • 目的に向かって大胆に努力し続ければ失敗はあり得る。失敗についてオープンに語り、学ぶ。隠したり、無視したりすることは受け入れられない
  • FBと敬意を失わない対立は互いの成長を支える
  • 弱みより強みに、問題よりも機会に注目する

人間関係の構築と対立

  • 他者を変えることは不可能だが、自分は変えられる
  • 思想、信念、言葉、行動は自分のもの
  • 噂を広めない、陰口を言わない
  • 意見が一致しないときは当事者同士で解決を図り、巻き込まない
  • 問題の責任を他人になすりつけない

存在目的

集団としての目的

  • 組織にはそれ自体、魂と目的がある
  • 組織がどこに行きたいか耳を傾け、無理に方向を決めようとしないよう気をつける

個人の目的、使命感

  • 私達は自分の使命が組織の存在目的と共鳴するか、大切にする
  • 自分の役割に対して、自分のエゴではなく、魂を吹き込む

将来を計画する

  • 未来を予測し、統制しようとすることは無駄である
  • 統制しようとせず、その場の状況を感じ取り、対応する

利益

  • 長期的には存在目的と利益の間にトレードオフは存在しない
  • 利益は必ずついてくると考える

組織文化の出現をどう支えるのか

  • 文化が単にリーダーの規範、関心事が反映される
  • 組織は自らの生命力を持つと考えると、文化も単体で自律的なものになってよい
  • 組織文化を作るには他の3つの象限を追求する努力を並行で行う
    • 組織文化を支える構造、プロセス、慣行を整える(右下
    • 社内で倫理的権威を持った人々が、模範となれる環境作る(右上
    • 個人としての信念体系が新しい文化を支えるのか、崩すのかを人々に探求してもらう(左上
  • 行事を数ヶ月続けることで文化ができあがる(右下
  • 尊敬されている人に依頼する(右上
  • 自らワークショップを開いていく(左上

進化型組織を創造する

必要条件

  • リーダーにビジネスの成功の鍵があると信じられており、注目され過ぎである
  • 倫理的リーダーシップが組織の寿命と成功に及ぼす影響が過小評価されている
  • 経営トップ
    • ティールの世界観を養い、精神的な発達をとげていなければならない
  • 組織のオーナー
  • この2つの条件が絶対的な要素
  • 業種や組織の大小、地理
  • 担当部署でティールをやろうとするのはやめたほうがいい
  • トップがアンバーーやオレンジのレンズで眺めると破壊される
  • 上司と戦い続けることになるので長期間続かない
  • 上司にティールを押し付けると、今までの組織と同じになる
  • 外側から強制されるのではなく、内側からの変化にならないと意味がない
  • 具体的な売上数値をもとにティールをおすすめすると、オレンジと変わらない
  • 色を変えるのではなく、不健全なオレンジを健全なオレンジにするといった方法をとる
  • 目標値は存在するが、社員が創意工夫でき自らを表現できる余地があるならよい
  • 支配的な色の中で健全な仕組みを作る努力のほうがよい

経営トップ

  • 組織意識はリーダーの意識レベルを超えられない
  • ティールになりたいならリーダーはティールのレンズで組織を見ないと行けない
  • ティールにおけるリーダーは意思決定をしない役割だが、組織空間をつくり維持するという役割を持つ
  • それ以外は組織のメンバーが自主経営をする
  • リーダーは外から見た代表なのは変わらない
  • リーダーはティールの運営と、空間を作り維持すること

ティールの空間を保持する

  • リーダーの役割はティールの組織構造と慣行のための空間を維持すること
  • 組織は規則や方針を作りたがる傾向がる
  • 人を統制する仕組みがあれば安全という前提
  • ティールでは信頼を守り再確認する
  • 会社の資源を私的に利用していた場合
    • 1件の窃盗で他の社員全てを疑うべきか
    • 他の社員を信頼しないしくみを作るべきか
  • 信頼という文化を維持するために規則を作らない

ティール組織を支える3つの突破口の模範となる

  • 階級的な権限はないが倫理的権威を持っていることが多い
  • 自主経営、全体性、存在目的に結びつく行動の規範となる必要がある

自主経営

  • リーダーは自分たちの権限が助言プロセスを通じて厳しく制限されることを認識する
  • 正しい意見とかは簡易なく相談が必ず必要となる
  • だれも強制ができない
  • 誰かが助言プロセスを飛ばしたら誰かが私的をして正す
  • 何かアクションしたい場合助言プロセスを通じてプロジェクトを作り動き出す
    • このとき、口出しをしたいという欲求と戦うことが一番難しい
    • 何度も仲間を信頼せよと言い聞かせる
  • 自主経営は情報が透明化されたときに進展する
  • チームで自分たちの数値を監視するのでチーム外が監視する必要はない
  • 「社員はリーダーに行動を起こしてほしいと考えている」という感覚を捨てること

全体性

  • 謙虚さ、信頼、勇気、弱さを晒すといった自分らしさを見せることで社員も同じリスクをとれるようになる

存在目的に耳を傾ける

  • リーダーたちが謙虚さを示す方法の一つは、自身と組織のメンバーに仕事が個人を超越した目的への申しであることを思い起こさせること
  • 時間と情熱などを注ぎ込むと実ってほしい、認められてほしいと考える
  • 個人や組織の成功は、意味ある目的を追求したときの結果として得られるもの
    • 成功を目的にしないようにする
  • これは無私無欲で仕事をするということではない
  • 完全に自分らしさを保ちながら、組織の存在目的に向かって努力をすること
  • どの判断が組織の存在目的に寄与するか?
  • この役割は組織の存在目的に寄与するか?
  • この顧客は組織の存在目的に寄与するか?
  • 組織に方向性を強制する必要がないと認識する

その他の役割

  • CEOは大量のMTGで埋まりがち
  • 判断を下すか承認するためのスライドの消化することが求められる
  • 全体を見ることができる組織のトップの役割になっている

助言プロセスを伴ったリーダーシップ

  • 全体に関わる意思決定はトップダウンがありがち
  • 助言プロセスは聞いて回ったり
  • ブログで気軽に何でも発信して社員が読み、意思決定をスピード高く行う
  • 弱さなどをさらけ出す姿勢が必要

CEOの役割と眺める別の方法

  • 活動、人間関係、文脈というエネルギーがあると説く「生きている組織」
  • 活動は「私達が何を、どのようにするか」という行動に注がれるエネルギー
  • 人間関係は「私達が何を、どのように言い、お互いにどう関わっていくか」という他の人々とのやりとりに注がれるエネルギー
  • 文脈は「組織全体に社員がつながることの意味や目的に宿るエネルギー
  • オレンジは活動がすべて。人間関係は悪と感じる
  • 文脈と人間関係を大切にし、残りの時間を活動に注ぐ

取締役会とオーナー

  • 2番目の条件は取締役会もティールのレンズになる必要がある
  • 取締役会はCEOを指名し、解雇する権限を持っている
  • 取締役会がティールを好きなのは、株価を押し上げていたからという理由がある

法的な枠組みを作る

  • グリーンでは株主はステークホルダーの1人
  • ティールでは組織の存在目的が超越する
  • ラクラシーでは憲法の草案を作った
  • ベネフィット・コーポレーションと呼ばれる企業形態が注目を浴びている
  • キャピタリズムコーポレーションは株主が強い
  • 組織は所有者などではなく管理者という視点を持つ

必要だが不十分

  • CEOと取締役会が組織のあり方を理解するのは必要条件だが、十分条件ではない
  • リーダーのレベルが上っても組織のレベルはあがらない
  • 権力構造、人々の職場での振る舞い、慣行、文化をリーダーが採用して初めて組織レベルがあがる
  • 不完全な人間性、自分が思い描ける像と外に示せるものの乖離が表面化すると、疲れ辛くなる
  • 忍耐と謙虚さと人付き合いのスキルを身につける必要がある

ティール組織を立ち上げる

  • ゼロから作るほうが楽
  • 考えること
    • 自身の希望や夢を無視して、組織の声に耳を傾けると目的はなにか?
    • 組織はどのような形をしたいのだろう
    • どれくらいのペースで成長したいのだろう
    • 複数、単独どちらの形で運営すべきだろう
  • 最も大切なのは自分がいることで組織にいい影響、悪い影響を考えること
  • FB、メンタリング、読書、瞑想なんでもよい
  • 人が増えたときにどうするかが組織の分岐点

前提と価値観をつなぐもの

  • いくつか前提を明らかにしてから会話をすると良い
  • 人はみな、平等に尊い存在である
  • 人は明確にそうでないと証明されない限り、本質的に善良だ
  • 組織の問題にうまく対処する単一の方法はない
  • 社員は権力または強制力を使わずに一緒に働くべきだ
  • 社員は約束を守らなければならない
  • 人はそもそも善良な存在
  • 幸福感なくして成果はありえない
  • 価値は現場でつくりだされている
  • 前提を考える際にはチームで考えること
  • そして最初にオレンジ組織の前提を考える
    • 労働者は怠け者で信頼できない
    • 年長者がすべてを知っている
    • 従業員は難しい問題を取り扱えない
  • こうした前提は理由の説明がしやすく、新しい慣行のときに利用できる

自主経営に関する3つの慣行

助言プロセス

  • 影響を受ける人や専門知識を持った人の助言を受けている限りだれでも意思決定ができる
  • だれもが承認をしてはないけない

紛争解決メカニズム

  • 問題を解決せず、紛争解決メカニズムを導入し運用させる

同僚感の話し合いに基づく評価と給与決定プロセス

全体性に関する4つの慣行

安全な空間を作るための基本ルール

  • 自分をさらけ出すには、そうすることが安全だと感じないといけない
  • 大切にする価値観を定め、運用していく

オフィスや工場

  • 働く場所で、それ以外の行動をすることが許されない状態
  • 模様替えをすべき

オンボーディングプロセス

MTGで実践すべき慣行

存在目的に関する2つの慣行

採用

だれも座らない椅子

  • MTGは組織の存在目的の達成に貢献したか

組織を変革する

  • 2つの条件が揃ってないと変革は難しい
    • CEOはティールをわかっているか
    • 取締役会は理解しているか
  • 条件が揃ってない場合、既存の組織の中で健全化するように水平的な改革をおこなうべき
  • 生きている組織は段階的に変化していくものなので3つの突破口のどれかから初めて徐々に変化させるべき

自主経営を導入する

  • 組織の下位にいる人ほど自主経営にすぐなじみ受け入れる
  • ティールでは自主経営で活躍できそうな人を採用するのが重要
  • 指揮と統制によって働いていた人たちは自主経営は難しいシステム
  • 自分の行動と関係の維持に責任を持ち、困難な選択から逃げられない

心理的オーナーシップ

  • 会社がもうけようが損しようが気にしなく、驚異や機会について心配しない
    • 修正が必要なときはリーダーが判断すると考えている
  • 自主経営の成功は「心理的オーナーシップ」を持てるかにかかっている
  • 心理的オーナーシップは自主経営の権限をもらってもすぐに生まれるものではない
  • 組織と存在目的に思い入れがなく、仕事を軽くしようと考えている人がいても驚いてはいけない
  • 内発的モチベーションを高める必要がある
存在目的
  • 明確でないとき、かき立てる要素がないと感じるときはこの問題を解決すべき
競争意識
  • チームに自分たちで計画と目標を設定し予算作成をする
  • そして、互いに発表し合う機会を設ける
  • チームが共同作業をすることが大切
  • 透明化を進めるのも1つの手
市場からの圧力
  • 発注数や強豪の価格などを知る
  • 顧客と直接つながる

条件

  • 自主経営を導入しようとしているリーダーが信頼されていなければならない

ドルマネジメント以上のマネージャー

  • 役割がなくなるので、新しい仕事を社内・社外で探す必要がある
  • 信頼が欠如した制度が多いと結果的にスピードが下がる
  • 全ての非信頼の制度を撤廃して、従業員とともに新しい組織を作ろうとした
  • 正当な退職金は用意する
  • ティールへの課題は、ミドルマネージャーやスタッフ機能の人たちをどう処遇すべきか
  • 最も適切な組織構造は
    • 自主経営チーム
    • ラクラシーのような入れ子構造か
    • 社員との個別契約組織か
  • いつ自主経営をどのように導入するか?
創造的カオス
ボトムアップの再設計
  • 組織内の全員に組織の将来像の設計に参画してもらう
  • 慣行を導入すべきかグループに決めてもらう
  • アプリシエイティブ・インクワイアリー
  • フューチャーサーチ、プロセスデザインなどが有効
  • 社員が自主経営をしたいという意欲を持てるほどリーダーが信頼されている
  • ドルマネージャーは反対だからといって、移行作業をさぼらないこと
  • マネージャーを自主経営組織に研修に行ってもらうなど
既存テンプレートの活用と切替日の設定
  • すでに実績のある方式を採用すること
  • ラクラシーなど
  • ラクラシーのためには複数の円が入れ子に重なった組織構造を決定する必要がある
  • 最初から完全じゃなくてもいい

全体性を醸成するための組織慣行を決める

  • 自主経営よりは導入が楽
    • 強制ではなく徐々に慣れることが可能
    • 仕事用の仮面を脱ぎ始める人が増えると仲間になれる
    • 組織の風土に合わせて導入ができる

全体性を醸成する

  • MTGでなにかルールを提案してみたり
  • 受け入れられたら組織全体での実践を提唱する
  • 評価面談を学びの敬意や使命感を語ってもらう
  • 素の自分で職場に来ることを語り、実践してから導入したほうがいい
  • なぜ、社員がさらけ出して付き合える組織をつくることに情熱を注いでいるのか
  • など語ってもいい
  • 全体性と組織目的を結びつけても良い
  • なぜ自分らしさが必要か

存在目的に関する慣行

  • 存在目的はすぐ忘れられるようなミッションを作る話ではない
  • 存在目的は「組織はこうあるべき」「組織はこうすべき」というものではない
  • 「自分の組織が世界の中で何を実現したいか」という独自の目的をあなたや同僚が感じ取れるもの
  • 会社が一つの生命体と感じるられるもの
  • 自分の組織がどうありたいと願っているかに耳を傾けられるか?
  • この問を探求するためにどんな手段をとってもいいし、どれくらい時間をかけてもいい
  • 耳を傾けることに加わっていた同僚が存在目的と個人的なつながりを感じる
  • 感じ取れたらそれを日々の会話に取り組み、意思決定を行う
  • 心の奥底ではだれもが目的と意味のある仕事を望んでいる
  • 自分がどう見られているか意識すること

成果

  • ペンギンは陸地と水中でぜんぜん違う
  • 組織も同じなのでは?
  • ティールの前までは外的な動機で働く
  • 「どんな問題も作り出したときと同じ意識レベルでは解けない」アインシュタイン

証拠となる逸話

  • 成功をどう定義するかが難しいのでなんともいえない
  • マネジメントは不要

画期的なパフォーマンスを引き起こす要因

  • トップの数人ではなく全員が権限を握っていれば組織としての力が何倍にもなる
  • 人が自分らしさを失わずに職場に来るので、権限の使い方に知恵が絞られている
  • 社員の知恵が組織の生命力と一致するとうまくいく
  • 存在目的を通じて、自分より大きな目的を理解すると、個々のエネルギーが高まる
  • 権限の分散を通じて、内在的基準に照らし働く
  • 学びを通じて、学習への強い意欲がわき、内面の発達まで広がる
  • 出世するために管理職的な役割を押し付けられることはなく、流動的に調整する
  • 出世のためのエネルギーがなくなる
  • 報告義務などのエネルギーがなくなる
  • 階層間のMTGがなくなる
  • 直接感じ取った知識に基づき活動する
  • 助言プロセスにより判断をし、直感や感覚で判断する
  • 意思決定をそれぞれでする
  • 意思決定を待つことがない

ティール組織とティール社会

  • 人間の意識レベルの変化とともに社会も変化していった
  • 未来の推測は難しく「未来についておおよそわかっているのは現在と違うこと」ドラッカー

ティール社会はどのように見えるだろうか

ゼロ成長、循環型経済

  • 資源が限られている世界で無限の成長はできない
  • どこかで100%再生可能な循環型経済にならないと滅びる

大量消費の見直し

  • 成長しなくなるが、反映しないわけではない
  • 最近の商品はエゴを失う恐れに訴えかけている
  • 外定期ではなく内的な訴えになるとこういった商品はなくなる
  • 顧客との人間的なつながりに訴求するサービスが増える

既存産業の再生

  • 学校のような型にはめるものはなくなり、医療は心がこもったケアになる

金融システム

  • 利子を前提とシステムはなくなる
  • 備蓄ではなく共有関係の信頼が大切になる

管理責任

  • 所有という概念がなくなる

グローバルコミュニティ

  • VRなどSNSなどのローカルとグローバルがつながる

仕事の終焉

  • 機械化が進むことで、面白くない仕事をしていた人は面白い仕事をできるようになる

ティール社会の中のティール組織

株主

  • 営利事業と非営利事業の垣根がなくなる
  • 管理責任者となって、互いに助け合う構造になる

存在目的と高通気性組織

  • いろいろな働き方が増え、組織間で協力し合うようになる

未来を作り出す

  • 未来は予測できないが、作ることはできる
  • この本を教本のように使うのは望まれない

おわり。長かった。

WEB+DB PRESS Vol.112

読んだ感想とまとめ

縁の下のUIデザイン カードUIの向き不向き

  • スマホUIは現実のものを模したデザイン(スキューモフィズム)からフラットに
  • カードUIはなんとなくとっつきやすく使いがち
  • カードUIは立体感や影をつけて使うことから、相対的に要素に存在感を出すことができる
  • 強弱をつけたいデザインに効果的
  • 不均一な情報をきれいに整理できる
    • 例えば高さが違ったり
  • デザインに必要な要素が多いのでごちゃつかないように意識する
  • カードによる入れ子は余白が多くなるのでやめたほうが良い
  • ツイッターのような短文の投稿の場合1つ1つの重みより全体のみやすさが重要なので、カードUIは適さない
  • レビューのようなしっかりしたものはカードUIで
  • PCではテーブルが多いがそれをカードUIにするときは気をつける
  • スマホでテーブルを使うと横にスクロールする必要があり使いづらい
  • 逆にPCでカードを使うとテーブルと比べて見づらい
  • カードUIと違うUIを作り比べることで使う理由をきちんと明確化する

at the front 今生きるプログラマーが、この仕事をあこがれのものにする

  • 「高度なコンピュータ・サイエンス、プログラミングスキルの現場適用の難しさ」が課題だった
  • フレームワークの中にある低層の基礎の必要性
  • 木構造の差分適用というアルゴリズムがUIの更新を抽象し、パフォーマンスと開発効率を両立させる
    • Reactなどを表面的に使うだけでもいいが、アルゴリズムを学び、APIを使うのは大事
  • 高度な技術もそれを必要とする人に説明しなければ、技術で現実的に信頼できる品質で実装できなければ、有用であると言えない
  • 適切な場所とタイミングで提示するためには、求められているさまざまな期待を理解し超える必要がある
  • プログラマーが憧れの対象であるために社会の期待に答え、本質を追い求める必要がある
  • FWが死んでも思想は継承されるはず
  • 流行り廃りは必ず発生して、変化を受け入れる覚悟必要である

Special Report ScalaMatsuri 2019

  • 2019/6/27 - 29
  • 初日はワークショップ形式、2日目は公園形式、最終はアンカファレンス

Special Report elm Europe 2019

  • 2019/6/27 - 28
  • Elmによるゲーム開発、JSのパフォーマンスチューニング、スケール

モダンフロントエンドの構造化と分割の新提案 コンポーネント設計

  • メンタルモデルを活用した設計、実装
  • 関心の分離により疎結合を実現

なぜコンポーネント設計か

  • アプリ開発は下記のようなフローで動く
    • ニーズ分析/企画
    • 要求分析/要件定義
    • 仕様策定
    • UIデザイン/プロトタイピング
    • 設計/実装
  • プロトタイピングツールの充実のおかげで、共有やFBしやすくなっている
  • しかしデザインツールだけでは齟齬が発生することが度々ある
  • デザインが完成してから開発をする場合、互いに関与できることは少ない
  • 画面単位で考えているので待ちが長くなる
  • 小さくすることで解決を図る(コンポーネント単位で考える

ビューコンポーネントの現在

import * as React from "react"
import { Switcher, OptionLabel } from "./components"
interface Props {
    heading ? : string;
}
interface States {
    display: boolean;
}


// クラスコンポーネント
export class DisplaySwitchClass extends
React.Component < Props, States > {
    constructor(props: Props) {
        super(props)
        this.state = { display: false }
    }
    render() {
        const toggleEvent = this.onChanged.bind(this);
        const display = this.state.display;
        return ( <
            >
            <StyledHeading>
 {this.props.heading}
 </StyledHeading> <
            OptionLabel text = "表示"
            onClicked = { toggleEvent }
            /> <
            Switcher toggle = { display }

            onChanged = { toggleEvent }
            /> < /
            >
        )
    }
    onChanged() {
        this.setState({
            display: !this.state.display
        })
    }
}

// 関数コンポーネント + React Hooks
import { useState } from "react"
export const DisplaySwitchFunc = (props: Props) => {
    const [states, onChangeDisplay] = useState < States > ({ display: false });
    const { display } = states;
    const toggleEvent = () => {
        onChangeDisplay({ display: !display })
    }
    return ( <
        >
        <StyledHeading>
 {props.heading}
 </StyledHeading> <
        OptionLabel text = "表示"
        onClicked = { toggleEvent }
        /> <
        Switcher toggle = { display } onChanged = { toggleEvent }
        /> < /
        >
    )
}

const StyledHeading = styled.h1 `
 font-size: 16px;
`;
  • Vue.jsはデータフローが双方向、DOMに対してディレクティブという値を代入したり、イベントを設定できる
    • 子から親へデータを渡せたりする
      • stateは存在せず、dataオブジェクトがある
<template>
    <div>
        <StyledHeading>
            {{heading}}
        </StyledHeading>
        <option-label text="表示" :onClicked="onChanged" />
        <switcher :toggle="display" :onChanged="onChanged" />
    </div>
</template>

<script>
import styled from "vue-styled-components";
import {
    OptionLabel,
    Switcher
} from "./components/";
const StyledHeading = styled.h1 `
 font-size: 16px;
`;

export default {
    name: 'display-switch',
    data: function() {
        return {
            display: false
        }
    },
    props: {
        heading: String
    },
    components: {
        OptionLabel,
        Switcher,
        StyledHeading
    },
    methods: {
        onChanged() {
            this.display = !this.display
        }
    }
}
</script>
  • ビューコンポーネントにおける再利用性
    • 名前を記入し空欄かどうかのバリデーションをするフィールドとメアドのバリデーションをするフィールドがある場合
    • 共通は「入力値のちぇっくができるフィールド」と「表示のラベル」
    • 「テキストを入力してバリデーションのチェックをできるフィールド」と「ラベル」の2つのビューコンポーネントを子コンポーネントとして呼び出して、1つのコンポーネントとして作成
    • メアドと名前でバリデーション内容が異なる
    • 親が子が何かを考える必要がある
    • そのためバリデーションは親にもたせず子に持たせる
  • どこまで分割を行うべきか
  • デザイナーは下記2点を重要と考える
    • ビジュアル(=見た目)や操作性に一貫性を持たせ、ブランドを守る
    • デザイナーどうしの協業を推し進め、効率化を図る
  • Atomic Designという考え方がある
  • 粒度ベースで分割を行うと下記メリットが生まれる
    • 開発メンバー間で意思疎通しやすくなる
    • ビューコンポーネントとしてコードを小さくできるため、変更に強くなる
    • 誰でも部品を組み合わせるだけで画面をある程度作成できる
  • デメリット
    • 粒度のみを指標にすると、どこからどう作って良いか迷う
    • 粒度の小さいビューコンポーネントから作ることが難しい
    • いつでもどこでも使えるように汎用性を持たせようとしてしまい、複雑になる
    • 将来的に使うかもしれないビューコンポーネントを、そのときに不要でも作っておく必要がある
  • 最近は粒度で分割しないほうがいいのではと考えられ始めた

設計の前に考えること/行うこと

  • アプリケーションの中でビューコンポーネントはどのような性質や役割を持つべきか考える
  • アプリケーションがどういうものなのかを理解しておく
  • 人間が理解するという活動は「学習」と「イメージ化」という大きな流れに分解できる
  • この理解の流れで作られるイメージを「メンタルモデル」と呼ぶ
  • 人や環境によってメンタルモデルがずれることがある
  • トンカチを「釘を叩くもの」「ガラスを割るもの」とずれる
    • 叩くは同じだが、何を叩くがずれている
  • アプリケーションも同じようにずれることがよくある
  • 文脈によっても同じメンタルモデルの話をしていてもずれる
    • トンカチの柄だけを見ると、木の棒と認識してしまう
  • サービスや業務の領域に関係するメンタルモデルからアプリケーションを理 解する
  • 「サービスや業務の領域」のことを「ドメイン」と呼ぶ
  • これは開発者だけでなく、使うユーザーにも言える
  • メンタルモデルの抽出はユーザーの活動に注目し、「名詞と動詞の簡単な文章」にする
  • 宛先管理サービスを例にすると
  • ユーザーは、宛先をサービスに登録する
  • ユーザーは、宛先の名前を記入する
  • ユーザーは、宛先住所の郵便番号を記入する
  • ユーザーは、宛先住所の都道府県、市区町村、丁目と番地を記入する
  • ユーザーは、サービスに登録している宛先を変更する
  • ユーザーは、サービスに登録している宛先を削除する
  • ユーザーは、サービスに登録している宛先を参照する
  • 名刺を抽出する
  • 宛先、名前、郵便番号、住所、都道府県、、、
  • その後名刺の定義を行う
  • 例 宛先:宛先とは何かを届けるための情報。届ける先の人の名前と郵便番号と住所が必要
  • 類義語はどちらの名詞を主とするか定義しておく

ビューコンポーネントの設計と実装

const Destination = (props: Props) => {
    const {
        name,
        postalCode,
        address
    } = props
    const postalCodeStrings = `
 ${postalCode.upper}
 - ${postalCode.lower}`
    const addressStrings = `
 ${address.prefecture}
 ${address.city}${address.street}`
    return ( 
      <>
        <span>名前</span> 
        <strong> { name } </strong>
        <span > 郵便番号 < /span> 
        <strong > { postalCodeStrings } < /strong>
        <span > 住所 < /span> 
        <strong > { addressStrings } < /strong> 
      </>
    )
}
const Name = (props: Props) => {
    const name = props.value
    return ( 
      <>
        <span>名前</span> 
        <strong > { name } < /strong>
      </>
    )
}
<Name value={name} />
<PostalCode
  upper={postalCode.upper}
  lower={postalCode.lower} />
<Address
  city={address.city}
  street={address.street} />
  • これらのコンポーネントGUIを通して表示される
  • ユーザーはwebのなどのGUIの部品にイメージを持っている
  • また、画面というドメインモデルが存在する
  • ドメインGUI/画面などのメンタルモデルを1つのコンポーネントの中で考えるべきではない
  • 関心事によって分離する
  • オフィスの受付にある受付アプリは「受け付け担当者を呼ぶこと」と「ボタンをタップしたら処理を開始すること」という2つの役割が存在する
  • ドメインの関心は「受付担当者を呼ぶこと」
  • GUIの関心は「ボタンはタップできること」
  • 関心事とは、対象のモノ/コトに対して持つ役割や興味の範囲を指し
  • 同じ関心事にあたるメンタルモデルやその振る舞いを1つにまとめて整理することが関心の分離
  • ドメインオブジェクトは要素を持つ関心事
  • GUIは表示の関心事を持つ
  • アフォーダンスという環境から得られる情報を鍵にして最適化を行う
  • 画面は遷移、何を表示するかに関心を持つ
  • レイアウトというドメイン同士の間隔に関心を持つ
  • 状態やコンテナ
  • ドメインオブジェクトは、ドメインエレメントを要素として持つ
  • ドメインエレメントは、GUIパーツで表示/入力を表現する
  • GUI パーツは、組み合わせて使うことがある
  • 画面は、面として表示し遷移をする
  • レイアウトは、配置に関して調整する
  • コンテナは、アプリケーションの状態データの流し込みを行う
  • 画面での入力はコンテナを経由しドメインオブジェクトに流れ、ドメインエレメントを変更し、GUIが表示を反映する

開発フロー

  1. ニーズ分析/企画
  2. 要求分析/要件定義
  3. メンタルモデル抽出/ドメインオブジェクト定義
  4. 画面定義
  5. 並列的に進める(ビューコンポーネント設計、ビューコンポーネントのデザイン、ビューコンポーネントの実装)

メリット

  • 並列的に、ビューコンポーネントの設計/デザイン/実装を小さく行えるようになる
  • デザイナー/エンジニア間でアプリケーションを一緒に理解できるようになる
  • デザイナー/エンジニア間で待ち時間などを少なくできるようになる

画面定義

  • ユーザーが使いやすいアプリケーションはタスクベース(動詞的な画面のグルーピング)ではない
  • オブジェクトベース(名詞的な画面のグルーピング)によるナビゲーション

これをOOUI(オブジェクト指向UI)と呼ぶ

ブログをタスクベースにすると

  • 編集する
    • 記事
    • プロフィール
    • テンプレート
  • 追加する
    • 記事
    • テンプレート

となる

オブジェクトベースの画面遷移は

  • 記事(一覧)
    • 詳細
    • 編集
    • 追加
  • プロフィール
    • 変更
  • テンプレート(一覧)
    • 詳細
    • 編集
    • 追加

となり、わかりやすい

実践チュートリアル

  • アパレルECサービスを例に設計をする

要求、要件定義

  • 商品を閲覧して購入できる
  • 商品はカテゴリ別やブランド別に分類して閲覧できる
  • 購入したい商品をカートに入れてまとめて購入できる
  • 購入したい商品のサイズやカラーなどを選ぶことができる
  • 購入すると商品を配送会社を使って配送できる
  • 配送にはいくつかの宛先を登録でき、その中から選ぶことができる
  • 支払いには現金/クレジットカードとペイサービスを利用できる

画面遷移図やワイヤーフレームを書くのではなく、ユーザーやサービス提供者の活動を、名詞と 動詞の簡単な文章に表す

  • ユーザーは、商品をカテゴリから探す
  • ユーザーは、商品の一覧を参照する
  • ユーザーは、商品の一覧から商品の写真やスペックなど詳細情報を参照する
  • ユーザーは、商品詳細でバリエーション(サイズやカラー)を選ぶ
  • ユーザーは、商品をカートに入れる
  • ユーザーは、カートに入れた商品を確認する
  • ユーザーは、購入を確定する
  • ユーザーは、お届け先を記入する
  • ユーザーは、お届け先を追加する
  • ユーザーは、カートの商品に関して支払いを行う
  • ユーザーは、決済完了したか確認をする
  • ユーザーは、発送/配送状況を確認する

世に存在しないアプリの場合は、似たサービスをもとに考える

その後名詞の定義を行い、オブジェクトの抽出を行う

  • 商品
    • 商品名
    • 写真
    • カテゴリ

メンタルモデルが数多くあり、複雑なときは、メンバーによるワークショップ形式ですり合わせを行う

抽出後はOOUIで画面の定義を行う

タスクベースにすると探すから商品、カテゴリ、ブランドと分岐する

ユーザが何をしたいかというと

  • A:決まっている商品を探す
  • B:商品カテゴリを見る
  • C:ブランドを見る

となるので、探すは興味のある商品に紐づく

商品からカテゴリやブランドに紐づく

検索から商品、カテゴリに紐づく

メンタルモデルから得られるもの

共通言語

建築ではパターン・ランゲージと呼ばれる

DDDではユビキタス言語

正しさの基準

  • メンタルモデルを理解することで、何がアプリケ ーションにとって正しいか判断しやすくなる
  • メンタルモデルは変わっていくものだが、基準を 一度作れば変化を捉えやすくなる
  • ユーザーが持っているメンタルモデルと同じものを 持つため、ユーザーを理解することにもつながる

RDBMS徹底比較

アーキテクチャを比べる

Oracle Database

  • 大規模システムのRDBMSとして大きなシェアを持っている
  • 高速なレスポンスが要求されるOLTP(OnLineTransactionProcessing)に対応できる
  • スループットが要求される分析システムに対しても対応できる
  • DB変更処理をオンライン状態のママ実行できる
  • 障害対応のためのクラスタウェアやファイルシステムも提供する
  • ライセンスなど高い
  • RealApplicationClusters(RAC)はスケールアウトによる拡張で独自機能
  • ストレージを共有する複数のホストで構成され、ホストの追加により仮想的に利用できるプロセッサ数とメモリ量を拡大する

PostgreSQL

  • 比較的小規模なサイズに使われる
  • 1970年代に開発されたIngresを継承し、1989年に開発されたPostgresを直接の子孫とする
  • OSS
  • Amazon Redshift、Amazon Aurora、 Greenplum Database、EDB Postgres Advanced Serverなどに派生する
  • 拡張性が高く、自由度が高い

MySQL

  • webのバックエンドなど比較的シンプルなSQLを高速に動作させる環境に適しているオープンソース
  • Amazon Aurora や Percona Server な ど の 互換 RDBMS や、 MariaDBのような派生製品が開発されている
  • OSに対する負荷が小さく、レプリケーション機能が搭載されている
  • 複数のストレージエンジンを利用できる
  • 他と比べると機能が少ないが8.0.2あたりから機能が増えて他と大差ない感じになってきた

SQL Server

  • Microsoft Windowsと親和性が高く、Azureの基盤となっている
  • Microsoftが作っている
  • Oracleと並んで高機能、Linuxでも動く
  • 高度な自動化が特上。ELT機能、レポート機能、分析システムが同時にインストールされる

プロセス構成

  • RDBMSが実行されている状態をインスタンスと呼ぶ
    • プロセス
    • メモリ
    • ストレージ
  • インスタンスのプロセス構成は、マルチプロセスモデルとマルチスレッドモデル
  • マルチプロセスモデルはユーザーからの接続ごとに新しいプロセスを起動する
    • 特定のプロセスに障害が発生した際の影響範囲を小さくできる利点がある
    • Oracle,Postgreが採用している
  • マルチスレッドモデルはプロセス内に複数のスレッドが作成される
    • プロセスより起動のオーバーヘッドが小さいので、高速に接続と切断をできる
    • 複数プロセスでメモリ共有が不要なのでシンプルになる
    • MySQL,SQLServerが採用

Oracle

  • インスタンスは複数のプロセスから構成される
  • インスタンスとは別にクライアントからの接続を受け付けるリスナーもいる
  • インスタンスを維持するための必須プロセス(バックグラウンドプロセス)
  • 接続ごとに起動されるプロセス(サーバープロセス)
  • 両方独立したプロセス
  • バックグラウンドプロセスは相互監視をしており、停止するとインスタンス全体が停止する
  • サーバープロセスはSQLの解析、実行計画の作成、実行、結果の送信をする
  • サーバープロセスに障害が起きても、トランザクションが自動的にロールバックされ他には無害
  • クライアントの接続とサーバープロセスが1対1になる構成を「専用サーバー構成」と呼ぶ
  • ネットワーク経由でクライアントからの接続を受け取るプロセスをリスナーと呼ぶ
  • 通常ホストに1個

Postgre

  • インスタンス全体を管理するpostmasterプロセスと子プロセスで構成される
  • 子プロセスには必須のバックグラウンドプロセスが稼働する
  • postmasterプロセスが接続を受けると、子プロセス(バックグラウンドプロセス)を作る
  • マルチスレッドモデルは提供されていない
  • 接続と切断が頻繁に行われるwebアプリなどでは、アプリケーションサーバーのコネクションプーリングを使って接続時のオーバーヘッドを軽減する対策をすることが一般的
  • バックグラウンドプロセスが異常終了すると全セッションが強制的に破棄される(影響範囲を小さくするわけではない

MySQL

  • インスタンスは単一プロセスとして動作する
  • 内部的には複数スレッドが動作する

SQLServer

メモリ構成

  • 一度使用したオブジェクトをメモリ上にキャッシュとして保持して再利用する
  • そのため大規模なメモリ領域が必要
  • 全セッションで共有するメモリ領域と固有に持つメモリ領域に分割されている
  • Oracle,SQL Serverは何でもキャッシュするが、MYSQLは実行結果や実行計画はキャッシュしない
  • ソート処理などはセッションを管理するプロセスのローカルメモリに保存
  • マルチプロセスモデルはOSの共有メモリ機能を使う

Oracle

  • 全プロセスで共有するSystemGlobalArea(SGA)と接続単位に使用するローカルメモリProgramGlobalArea(PGA)がある
  • SGAは共有プール、ログバッファ、バッファキャッシュなどがある
  • SGA全体のサイズのみを指定して、内部の領域は自動的に行うことをおすすめする
  • バッファキャッシュはテーブル、インデックスなどのデータをキャッシュする
  • 大きな領域を確保してある
  • 共有プールはオブジェクトの構成をキャッシュするディクショナリキャッシュ、SQL分の実行結果を保存するリザルトキャッシュなどから構成される
  • ログバッファはトランザクションの情報を一時的んキャッシュする
  • PGASQL分を実行するために確保するローカルメモリ領域
    • 必要なときに必要なだけ確保される

Postgre

  • 共有バッファは構成情報、テーブルのデータなどが格納される
  • WAlバッファはトランザクションの更新情報を格納する(WriteAheadLog)
  • ソート処理などはバックエンドプロセスのローカルメモリで行う
    • メモリが足りない場合は一時ファイルを作るので、パフォーマンスが悪化する

MySQL

  • 単一のプロセスなので共有メモリは使わない
  • 全体で管理するメモリをグローバルバッファ、各セッションが利用するメモリ領域がスレッドバッファ
  • グローバルバッファはバッファプール、ログバッファに分類される
  • バッファプールはテーブルの情報をキャッシュする
  • トランザクション情報を一時的に保存するログバッファ
  • ソート処理などはスレッドバッファを利用する。メモリが足りないとストレージ上で実行される

SQLServer

  • ローカルメモリのみ
  • 構成は最大と最小のメモリを定義するだけ

ストレージ構成

  • 永続化とパフォーマンス維持のため、トランザクションログとデータ両方に書きこみをする
  • テーブルやインデックス内のデ ータを保存する領域と、更新トランザクションによる差分データ(トランザクションログ)を保存するストレージ 領域を持つ
  • 更新が確定(コミット)するとトランザクションログとメモリの情報を同期的に更新する
  • データ領域は古いままだが、チェックポイントという機能によりメモリとデータ領域が同期される
  • トランザクションログは障害のときに最新にするために使われる

Oracle

  • ストレージ領域はファイルシステムを使うこともできるが、最近ではストレージ管理専用のインスタンス(ASM インスタンス)が流行り
  • テーブルやインデックスなどの永続データは表領域(TABLESPACE)と呼ばれるオ ブジェクトに保存する
  • トランザクションログ(REDOログ)は複数のグループから構成される
  • サイズとパスは管理者が決定し変更するためにはグループの再作成が必要

Postgre

  • ストレージ領域はファイルシステムと密に結合している
  • ファイルシステムの階層構造をそのままデータベースの構造に利用している
  • Oracle Database や MySQLでは、レコードが更新されると更新前のレコードはブロック単位にロールバックセグメントに退避される
  • Postgreはレコードが更新されると更新前のレコードはそのまま保持され、更新後のレコードは同じブロックに追記される
    • VACUUM処理により更新前のブロックは削除される
  • すべてのデータはデータベースクラスタと呼ばれるファイルシステム上の単一ディレクトリに保存される
  • テーブルやインデックスなどのオブジェクトはそれぞれ個別のファイルで管理する
    • ファイル名はオブジェクトを示す一意なoid
  • トランザクションファイルはWALファイルと呼ぶ
    • ファイル名は自動的に決められる
    • すべてのファイルは一定のサイズで、基本16Mで一度作成すると変更ができない
    • 原則バックエンドプロセスが書き込む
    • 順番に書き込まれいっぱいになったら次のファイルに名前を変えて書き込まれる

MySQL

  • 複数のストレージエンジンを使えるのが特徴
  • 古いのはMyISAMが使われていたが、最近はInnoDB
  • ストレージはデータディレクトリに保存される
  • ファイル名やディレクトリは設定で自由に変えられる
  • デフォルトでデータベース名と同じ名前のディレクトリができる
  • トランザクションログはバイナリログとInnoDBログがある
  • バイナリログにはレプリケーションに使用する変更イベントが格納される
  • InnoDB ログはトランザクションの完了と同期して書き込みが行われる
  • InnoDBOracleのように予め大きなサイズのDBを作る方法と、テーブルごとに作る方法がある

SQL Server

  • 他と比べるとシンプル
  • データベース単位にデータファイル を作成する
  • トランザクションログは大規模な一つのファイル

SQL を比べる

  • SQL 文は標準化の対象にならなかった分野に微妙な差異がある
  • ISOやJISの標準化により多くの構文が同じ動きをする
  • 固有の構文ができており差別化の要因になっている

関数や演算子の違い

  • NULLを変換する関数名がRDBMSによって違う
  • 文字列の長さの定義が微妙に異なる
  • Oracleは文字の数と定義する
  • Postgreは文字数だが、終端の空白は無視する
  • MySQLはバイト数と定義する
  • MysQL以外は0による割り算を行うと実行時エラーになる
  • MySQLは0による割り算はNULLになる
  • Oracleの時刻関数はマイクロ秒まではかれる。日付と時刻を返す

構文と動作の違い

  • トランザクションの分離レベルは4つある
  • 分離レベ ルが強いほど RDBMS としての整合性が高いが、SQL 文の同時実行性が悪化する

実践Scala

lit-elementでTypeScriptを試す

lit-elementというWeb Componentsを作るライブラリの公式にTypeScriptでの書き方が書いてあったので試してみる。

lit-element.polymer-project.org

package.json

  "devDependencies": {
    "ts-loader": "^6.0.4",
    "typescript": "^3.5.3",
    "lit-element": "^2.1.0",
    "webpack": "^4.31.0",
    "webpack-cli": "^3.3.2",
    "webpack-dev-server": "^3.3.1"
  }

tsconfig.json

lit-element.polymer-project.org

lit-elementのサイトにはmoduleはES2017と書かれていたが、どうやらtypescriptのmoduleはES2017を指定できないのでes2015を指定している(typescriptあまり詳しくないのでもしかしたら指定できるのかも?)

www.typescriptlang.org

Decoratorを使うため、experimentalDecoratorstrueで。

{
  "compilerOptions": {
    "target": "ES2017",
    "module": "es2015",
    "moduleResolution": "node",
    "lib": ["ES2017", "DOM"],
    "experimentalDecorators": true
  }
}

webpack.config.js

lit-elementだからといって特別な指定はなし。

const path = require('path');

module.exports = {
  entry: {
    raw: './src/js/raw.js',
    lit: './src/js/lit.js',
    ts: './src/js/ts.js'
  },
  output: {
    path: path.join(__dirname,'dist'),
    filename: '[name].js'
  },
  resolve: {
    extensions:['.ts', '.js']
  },
  devServer: {
    contentBase: path.join(__dirname,'dist')
  },
  module: {
    rules: [
      {
        test:/\.ts$/,
        loader:'ts-loader'
      }
    ]
  }
};

ts-my-element.ts

そもそもあんまりtypescriptを学んでないが、lit-elementのみで書く場合の差はcustomElements.defineとpropertyの指定の仕方くらい。

ちなみに、attributeで型の違うものを渡しても(下の例だとprop2に文字列)コンパイラがエラーを吐いたりしはしない。

普通にlit-elementで書くより行数は減る。

import { LitElement, html, customElement, css, property } from 'lit-element';

@customElement('ts-my-element')
export class MyElement extends LitElement {
    @property({type : String})  prop1 = 'Hello World';
    @property({type : Number})  prop2 = 5;
    @property({type : Boolean}) prop3 = true;
    @property({type : Array})   prop4 = [1,2,3];
    @property({type : Object})  prop5 = { subprop1: 'hi', thing: 'fasdfsf' };

    static get styles() {
        return css`
            p {
                display: block; 
                padding: 10px;
                border: 1px solid #e5e5e5;
            }
        `;
    }
    
    render() {
        return html`
          <p>prop1: ${this.prop1}</p>
          <p>prop2: ${this.prop2}</p>
          <p>prop3: ${this.prop3}</p>
    
          <p>prop4: ${this.prop4.map((item, index) =>
            html`<span>[${index}]:${item}&nbsp;</span>`)}
          </p>
    
          <p>prop5:
            ${Object.keys(this.prop5).map(item =>
            html`<span>${item}: ${this.prop5[item]}&nbsp;</span>`)}
          </p>
        `;
    }
}

typescriptをそもそもそんなに学んでいないので、ピンときていない・・・。

一応成果物

lit-element-sample.netlify.com

Nuxt.js + Netlify、Nuxt.js + Firebase Hostingでリリース

Netlify

➜  nuxt-sample git:(master) netlify init
? What would you like to do? +  Create & configure a new site
Choose a site name or leave blank for a random name. You can update later.
? Site name (optional): tiwu-nuxt-sample
? Account: tiwu official's team  (personal)

Site Created

? Your build command (hugo build/yarn run build/etc): npm run generate
? Directory to deploy (blank for current dir): dist
? No netlify.toml detected. Would you like to create one with these build settings? Yes

netlify init叩いて、新しいNetlifyのSiteを作って、npm run generatedistを指定して終了。

楽ちんすぎた。

tiwu-nuxt-sample.netlify.com

PWAをオンにしてたから、Auditsも満点。

f:id:tiwu:20190715161912p:plain

Firebase Hosting

  nuxt-sample git:(master) firebase init

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

/nuxt-sample

? Which Firebase CLI features do you want to setup for this folder? Press Space to select features, then Enter to confirm your choices. Hosting: Configure and deploy Firebase Hosting
 sites

=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we'll just set up a default project.

? Select a default Firebase project for this directory: [create a new project]

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build's output directory.

? What do you want to use as your public directory? dist
? Configure as a single-page app (rewrite all urls to /index.html)? Yes
✔  Wrote dist/index.html

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...

✔  Firebase initialization complete!

Project creation is only available from the Firebase Console
Please visit https://console.firebase.google.com to create a new project, then run firebase use --add

What do you want to use as your public directory?dist

Configure as a single-page app (rewrite all urls to /index.html)?Yes

毎回コマンド叩くときにPJ作っておくの忘れる。

netlifyはinit時に作ってくれるんだけどな・・・。

yarn generate
firebase deploy

ビルドもnetlifyと比べると面倒くさい。

tiwu-nuxt-sample.firebaseapp.com

余談

とりあえず何か新しいの覚えたときにリリースまでできないと不安でしょうがない・・・。