00:07
10月10日、月曜日ですね。
中国朝9時、10分もありました。
すみません。
昨日は、大学の同期との飲み会があってですね、楽しかったんですけど、
ちょっとね、場所が遠かったので、夜帰るのも遅かったんですよね。
で、寝坊してしまいました。
はい、おはようございます。ひめみのきーすことくわはらです。
では、本日も朝活を始めていきます。
はい、本日はですね、何をいろいろ探してたんですけど、
僕がいつも情報を取るというと言い方がですね、
情報収集するときに利用させていただいている
Weekly Frontend Roundup from Tokyoというサイトがあるんですけど、
そこの記事を10個更新されてたので、その10個のやつからいくつかピックアップしたんですけど、
今回はあまりちょっとIT系とかいう話ではなく、
どっちかというとチームビルディングとか、
そういうソフトスキルを使うような記事ばっかりがピックアップされたので、
まあいいやと思ってそれを読んでいこうと思います。
1つ目はQuality is Systematic。
2つ目がブレインストーミングの改善的なところですね。
3つ目がHow to work with design constraintsですね。
の3つを読んでいこうと思います。
どれもこれもちょっと短めの記事なので、
もしかしたら標準に全部読めるかもしれないなとは思っていますね。
では早速入っていきましょう。
まず1つ目、Quality is Systematicからですね。
はい、おはようございます。
お参加いただきありがとうございます。
今日もちょっとダラダラと読んでいこうと思います。
では行きましょう。
しかもシステマチックじゃなくてQuality is Systemicですね。
はい、行きます。
ここでソフトウェア品質に関するホットな話題を紹介します。
ソフトウェアの品質とは、
品質を生み出すように設計されたシステムの結果であり、
個人のパフォーマンスによるものではありません。
つまり平凡なプログラマーの集団が、
品質を生み出すように設計された構造で働くと、
他の目標で設計されたシステムで働く素晴らしいプログラマーの集団よりも、
実はいいソフトウェアを生み出すということです。
品質のために設計されたシステムってどういう意味でしょうかと。
次のようなことを話そうと思っています。
いくつか、1、2、3、4、5個ありますね。
1つ目は、テストを書きやすくするためによく設計されたテストハーネスと、
優れたテストを書くことを奨励し、
エンジニアにそのための時間とスペースを与えるチーム・企業文化というのがあります。
というのが1つ目でした。
2つ目に、使いやすく忠実の高い開発環境とステージング環境、
そして十分に証明される前に、
本番環境に行動を押し込むプレッシャーのない企業文化ということですね。
3つ目は、ドキュメント化され、リファクタリングされ、
十分にコメントされたコードベース。
これは、これらの活動に十分な時間を割くことができる開発ケーデンスの結果でもありますよということですね。
4つ目、行き詰まったときに気軽に助けを求められるような
心理的安全性の高い職場であること。
最後5つ目ですね。
失敗しても咎めることなく反省し、
03:01
二度と同じような失敗をしないようにシステムを改善するというような文化ですね。
以上5つの文化だったりチームというところができていればいいよというお話をしていました。
話してた、読んでた感じ、その通りだなという感じがしますね。
続きます。
システム品質には技術的な要因と人的な要因があって、
これらの要因というのは相互に影響し合っています。
最良のケースでは好循環を形成しますと。
その好循環のところもまた5個ピックアップされていますね。
1つ目としては優れたテストというのは問題になる前にエラーを検出しますが、
そのテストは魔法のように存在するわけではなく、
テストを書くための時間と空間というのを提供する構造というのがやっぱり必要です。
2つ目に、そのためにはテストを書くための時間と空間を確保する仕組みが必要です。
この仕組みがうまく機能するのは、
エンジニアがテストを正しく行うために十分な時間が必要なときに、
必要なときに気軽に発言できるからです。
エンジニアが発言しやすいのは心理的安全性が高い環境で働いているからです。
このような環境があるのは、
生産の失敗がシステム的な失敗とみなされ、
個人が罰せられ、非難され、
恥ずかしめられることがないことを知っているからです。
あとはストップとか停電とかいろんなものがありますけど、
システム的なものとして扱われるのはそのほとんどがそうだからです。
それはテストのやり方が非常に優れているため、
個々のミスが影響力のある失敗になるずっと前に発見されるからですよということですね。
ミスに関しての寛容性もありますが、
そもそもミスを事前に検知するというところの仕組みもあったりするというのは良い話ですね。
とかけシステムがダウンしたりとか障害が起きたときって、
結局は誰かのミスになる可能性は高いですけど、
問題が起きたときに犯人探しをしてしまうというのはよくある話なので、
それはあまり避けたいよねというのはありますよね。
結局その人に責任を負わすわけではもちろんないし、
チームでやったことなので、
コードレビューをチームでやっているはずだと思いますし、
他の人たちが検知できなかったので責任はチーム全体にあると思いますね。
とはいえ最後の最後、キックをした本人も責任を感じるとは思いますけど、
それは別に否定することもないし、
その反省、責任感があるというのはすごく良い話ではあるんですけど、
でも自分一人で抱え込まないようにチームとしてはバックアップしたいなと思いますよね。
このことは広範囲の意味を持っていて、
2つだけ簡単に紹介します。
もしあなたのチームが欠陥のあるコードを作っているとしたら、
それは彼らがみんな仕事ができないからではないかもしれないと考えてみてください。
それはおそらく質の高いソフトウェアを作るための環境が整っていないからです。
農業か時間とか品質とかの話が長かったりとか、
制約がかなり多かったりして、今回仕方なくそうなったというのはあるかもしれないですね、背景に。
もう一つ、優秀な人材しか採用できないと考えて、
採用に膨大な時間と労力を費やすのではなく、
より幅広い個人のパフォーマンスから素晴らしい結果を目指すシステムというのを構築することに、
その労力の一部を向けるのです。
06:00
もちろん優秀な人が採用できるのはそれに越したことはないですけど、
でもチームを形成するのは、
そんなに簡単に人だけパッと集めて入るチームですというわけではないですよね。
本当のチームというのは、時間をかけて醸成させていくというのが必要ですからね。
一応他の記事として、
ダブル・エドワーズ・デミングという方の赤いビーズの実験みたいな別の記事があるので、
それも見てみてくださいということでした。
というわけで一つ目の記事、クオリティーズ・システミックというのはこれで以上にしたいと思います。
結構短かったし、一つの考え方なのだと思いましたけど、
クオリティ・品質というのは設計であったりとかシステムの話ばっかりではなくて、
そもそもチームとか企業文化というのがあって初めて生み出されるという、
その一個俯瞰した目線というのがご意見でしたね。
参考になるというか、確かにそうだなと思う面もありましたので。
面白かったなと思います。
続いての記事は、
この記事はタイトルがないな。タイトルはないんですけど、
およゆるブレインストーミングの色を加えてみようみたいな記事だったと思いますけど、
では早速読んでいきましょう。
会話デザイナー、カンバセッションデザイナーですね。
会話デザイナーの皆さんこんにちは。
私はコーチとしてブレインストーミングについて多くの人に教えてきました。
会話デザイナーって専門の人いるかは知らないですけど、
ある意味で会話する人たちみんなが会話デザイナーだという捉え方をすると、
僕らはみんな会話デザイナーかもですね。
いろいろ教えてきましたよ。
しかしその際私は通常次のような質問から始めてますと、
良いブレインストーミングとはどのようなものでしょうか?
良いブレインストーミングとは2つのアイディアなのかそれとも二重のアイディアなのか?
あー確かにね、2つしかなかったら良いブレインストーミングではないか?
って言われたらそれはまた違うようなと思いますね。
何人の人をこの部屋に招待するのか?
一緒に過ごせる時間は?とか、
一人あたりの発話時間とはどれくらいありますか?とか
ブレインストーミングっていうのはしばしばアイディアを生み出したり問題を解決したりするための自発的な集まりというふうに定義をされます。
次が不当人になってますね。
しかしブレインストーミングは無計画のままにしておくにはあまりにも重要だと思います。
会話はデザインしましょう。
またブレインストーミングのルールっていうのは、
1950年代に広告代理店の重役であるアレックス・オズボーンが提唱した基本ルール以来、実はあまり進化していないようです。
私はこれらのルールは再検討し、再構築する価値があるというふうに思います。
IDEA OUのブレインストーミングのルールっていうのは比較のためにオズボーンのルールと一緒に紹介をしています。
IDEA OUっていう会社が作っているブレインストーミングルールっていうのを一覧化したわけですね。
この次の記事とか、この読んでいくと比較が出てくるのかな。一応読んでみましょう。
もし出てこなかったら後で画像を見てみますね。
はい、じゃあ行きます。
判断を先延ばしにする、ワイルドなアイデアを奨励するといった基本的なルールっていうのは、
09:03
モチベーションの低い合理的なひねくれ者の集団のような厳しい集団に使うのは本当に難しいと言っています。
私はブレインストーミングを乗り越えて変革へと導くために3つの質問について書きました。
詳しくはこっち見てくださいって別の記事に書かれてますね。
何が入っていて何が入っていないのか。
つまり私たちは何について話し何について話すつもりはないのか。
誰が参加し誰が参加しないのか。
私たちはみんなちゃんと中にいるのかという問いもしっかり見ていこうと。
私たちの中心で側面がないものは何か。
つまり私たちが一緒に解決したいと思っている最も中心的な問題は何なのかっていうですね。
私たちはどのようにして可能性の縁で踊ることができるんだろうか。
私たちが何を話しているのか。
そして私たちの最も中心的な問いがわかったらこの課題を解決するためにどうすれば可能なことを見出すことができるだろうかと。
本当にいろんな問いを投げるわけですね。
続いて。
あれか。
まさに今比較をしているんですね。
次がですね。
これらは結構ハードな質問ですというふうに述べられています。
ファーストスピーカー症候群というのは辞退します。
グループで共有する前に常に無言のアイディア出しを醸成しましょうというふうに言っていますね。
1個目ですね。
1個目はアイディアというのは必ず書き留めましょうと。
会話のインターフェースは重要です。
シンプルなアイディアやテンプレートというのはこのプロセスを容易にするのに役立ちます。
それぞれのアイディアの基本的なフー・ワット・ホワイ・ハウ・マッチですね。
誰が何をなぜいくらでもで容易に役に立ちますよと言っています。
なるほどね。
フー・ワット・ホワイ・ハウ・マッチなんですね。
マッチか。
第1つ目。
続いて。
スケッチをしましょうと。
実際ブレインストーミングの代わりにスケッチストーミングというのも実行しましょうと。
スケッチストーミングというのがあるんですね。
続いて。
物事をスローダウンさせると言いますね。
ピザチームというやつですね。
ピザ2枚のルールというのを守っているグループでもアイディアの生成、優先順位付け、批評、修正、選定というのを30分で行うのはまあ無理でしょう。
正しく行うには90分かかるかもしれませんと言っています。
続いて。
おズボーンの批評をしないというルールに従わないこと。
批評してもいいと言っているんですねこの人は。
そのアイディオという会社のディファージャッチメントというのは少しいい話だと言っています。
さらにいいのはブレインストーミングのプロセスに判断を焼き付けることで全てのアイディアが同じように判断されるようにすることです。
確かに出したら出しっぱで一回受け入れるというのはすごくいい話ではあるんですけど、
でもそれに対して批評しないというのは果たしてどうなのというところは僕もありますね。
実際にしてみたらむしろいろいろ見えてきて面白いかもしれないですね。
最後。
私はそのアイディオのワイルドアイディアというルールは使っていません。
悪いアイディアを出してもらいそれを良いアイディアに変えてもらうんです。
その方がずっとうまくいきます。
12:01
ワイルドアイディアルールっていうのは使わない。
いわゆる何でもいいとかどんなものでもルール出していいよっていうのではなくて、
まず悪いアイディアをガッと出してもってそれをブラッシュアップする方に変える。
やるんですね。
で、そっちの方が実はうまくいくっていう風に言っていると。
いやー確かにやったことないけどこれはこれで面白いですね。
あなたのお気に入りのブレインストーミングのルール。
そしてブレインストーミングの段階を乗り越えるためのルールは何でしょうか。
変身をして私に教えてくださいみたいな。
また私からの連絡がかなり少なくなりそうです。
ファシリテーションマスタークラスの最後のコースなのかもしれないというほげほげと言って、
ここからはいわゆる宣伝でこの話は終了するよという感じでした。
はい、なるほどでしたね。
以上ブレインストーミングのお話でした。
なるほどですね。
一応さっきのオズボーンとアイデオユーのブレインストーミングのルールですね。
ちょっとこの画像が荒いので、
本記事が見たいんですけどちょっと貼られてなさそうでしたね。
というところで読んでみますね。
一応アイデオユーだけは文章が短いので読めなくはないなという感じですね。
一つ目はディファージャッジメント。
二つ目はエンカレッジワイルドアイデアスですね。
三つ目はイネーブルドアザ。
四つ目はステイタッチドオンザ。
次がワンカンバセンションアザチーム。
アトアチームですね。
六つ目は読めないですね。
七つ目はゴーフォークワンティティですね。
質に持っていくってところですね。
この記事の後でリンク共有しますので見てみてくださいということです。
まあ確かにですね、アイデア出しのところに最後の二つですね。
批評するっていうのと悪いアイデアからブラッシュアップするって
この二つだけでもブレインストーミング今までやったことなかったので
これは面白いですね。
別にチームでやるだけじゃなくて自分自身の中でもアイデア出しする中で
一回それをやるのは全然。
じゃあラスト三つ目ですね。
How to work with design constraintsの記事を読んで終了しようと思います。
かなり短いんですけどねこれもね。
この方はAppleのデザインを今回参考にされているのかな?
話に値段にしてるっぽいですね。
はい、いきます。
古いことわざに人生からレモンをもらったらレモネードを作れというのがあります。
When life gives you lemons, make lemonadesって書いてますね。
そういう一応ことわざがあるんですね。
すみません、僕は知りませんでした。
多くのデザイナーはその制約をレモンとみなしますが
優れたデザイナーは制約からレモネードを作るのです。
制約をレモンとみなして優れたデザイナーは制約からレモネードを作る。
AppleがiPhoneに搭載した新しいDynamic Islandsっていうのはそのいい例です。
Dynamic Islandsの核となる制約とは
カメラやセンサーのハードウェアをディスプレイと同じ面に配置しなければならないということです。
ディスプレイはできるだけ大きくしたいが
カメラとセンサーには広いスペースが必要であるという緊張関係があります。
15:00
カメラやセンサーの使用を妨げずにスクリーンを覆うことができる新しい技術が登場するまでは
スクリーンにノッチを開けるという解決策がとられます。
これによってカメラやセンサーの境界を確保しつつ
画面の大きさを最大化することができます。
欠点はそれは見にくいということです。
いわゆるパンチ穴のサイズや配置をいろいろと変えてみることができても
結局ディスプレイに穴が開いているというのは穴が全くないよりも悪いのです。
じゃあどうしたらいいでしょうかというところですね。
まあ確かに美しさを犠牲にするのは果たしてどのというのはありますよね。
どうするかというとダイナミックアイランドの登場です。
ダイナミックアイランドというのはiPhoneの画面上部にある穴の見にくさを
最小限に抑えるのではなくてむしろそれを受け入れて便利なものにしようとしています。
iPhoneの画面上部にある穴というのは目障りな存在であることを説明するのではなく
製品の重要な特徴になるのというふうに言っています。
Appleは以前にもこのようなことを言っています。
iPodがAppleのベストセラー製品だった2005年ですね。
同社は人気の音楽プレイヤーの新しいエントリーモデルというのを発表しました。
このモデルは画面を搭載しないことで実現して
しかも安価で小さな製品になりました。
このモデルは画面がないため聴きたい曲を選ぶのが難しい。
1曲ずつめくるのが精一杯。
これは他のMP3プレイヤーと比較すると大きな欠点と確かに言えます。
しかしApple社はその懸念を払拭するどころか
この制約を受け入れ製品のアイデンティティの中心に据えたのです。
このiPodは自分のコレクションからランダムに音楽を再生して
驚かせることができるとアピールしました。
いわゆるiPodシャッフルという名前を付けました。
iPodシャッフルか。
なるほどですね。
という名前も付けました。
確かにいきなり画面がなくなったというのは
逆に大きくなりました。
発想が面白かったですね。
iPodシャッフルというのは製品の欠点を特徴に変えました。
スクリーンがないことで悩むのではなく
それを楽しむことでより良い製品になりました。
ダイナミックアイランドのようにレモンからレモネードを作ったのです。
あなたはどうですか?
どんな制約を利手に変えることができるでしょうか?
という一つのなぎかけをして終了します。
はい。短いですが良い例でしたね。
なるほどでした。
iPodシャッフルというのは
画面がパンチ穴があってどうだろうならば
むしろ画面を無くしてしまえという
すごい発想でしたね。
でも結果として
現代のSpotifyと同じ体験になりますよね。
自分の中にある好きな音楽たちの中から
ランダムで勝手に選ばれるというのは
なかなか面白いと思いますけど
Spotifyは結局ランダムにいろんな曲を
インターネットの海から探してきて
この曲って次々に流してくれますからね。
体験としては結構似ているものだと思いますし
ここを2005年の時からやってきた
Appleってやっぱり革新的だなと
改めて感じさせられますね。
レモンからレモネードを作るというのは
本当に良いことわざだなと思いましたね。
歴史の偉人はうまいこと言ったもんだと思いつつですけど。
18:02
はい。では今回は3つの記事を読んだのですが
ちょっと短く早めに終わってしまいましたね。
今日は開始がちょっと遅かったので
実は10分から開始したんですけど
今日は20分で3記事読んだんですけど
この辺で朝勝田終了しようかなと思います。
そうですね。ちょっと技術的な記事も読みたいんですけど
ちょっと設計にどうしても僕は注目したりとか
ちなみにOCMビルディングの話がやっぱり好きなので
そっちの記事ばっかり読んでしまいがちなんですけど
ちゃんと技術の勉強もしてみたいなと思いますので
なるべく記事探してみます。
というところで今日の朝勝田はここで終了したいと思います。
3連休3日目ですね。
今日はラストですけど10月10日。
ゆっくり休んでまた明日から頑張っていけたらなと思います。
それでは終了します。お疲れ様でした。
