じぶん Release Notes 0.30.03

7月1日〜31日の間の出来事がリリースされました。

7月の感想

7月は自分の思い通りに行かない日々でした。 目標もOKRを立てたは良いものの、とても学びのあるインプットと深い内容のアウトプットできたと思えてません。やはり業務外で時間をとってやるのはなかなか難しいですね。業務内容に絡めたものが出したい...一回ブログを休むか、仕事を変えるか... モチベーション的にも現時点でうまくいってない1番の理由は仕事で、プログラムやらシステム組んで書いてもっとエンジニアリングがしたいなぁと言う感じです。逆に今やっていることが向いていないことがわかってよかったです。次を考える際の軸にします。

技術・開発関連

  • 特にありません

イベント

  • 特にありません

読んだ本

-特にありません

ブログ

リリースノートを除き、次のエントリを書きました。 (編集中)

PV数

7月は3813でした。

7月の目標結果

  • O: 「趣味ブログ」は今後進みたい「サッカー分野」で認知される
    • KR: 趣味ブログの読者数を10人にする
    • KR: 趣味ブログのPVを月100にする
    • KR: 趣味ブログの週1記事上げる

週一で記事を出すことはできました。 他は未達ですが、今後どうしたら良いか練っていきます。まずは書くための自分なりのフレームワークを作りたいです。

  • O: 「Python/Vue.js/Azure」はこの分野の人って認知される
    • KR: Python/Vue.js/Azureの3分野だけで月100PV取る
    • KR: Python/Vue.js/Azureのどれかに関する記事を週1で上げる

こちらも週一で記事を上げれましたが、良い内容だとは思えないし、どう改善すれば良いか袋小路です。引き続き目標としては設定しておきます。

  • CEMのサイト修正 こちらは未着手でした。

【Python】str()とrepr()の違い

ずっと疑問に思っていたPythonにおけるstr()とrepr()の違いについてまとめた。

共通していること

タイトルに「違い」と書き始めたが、まずはこの2つについて共通していることを簡単に書いておく。 この2つの関数について同じことはオブジェクトの中身を出力する関数であるということだ。更にこの2つはPythonの組み込み関数として用意されていて、すぐに使うことができる。

何が違うか

出力する部分が同じであると書いたが、それ以上細分化する部分と必要性はあるのか疑問に思った。Pythonの公式ドキュメントを眺めてみると、repr()には「公式の (official)」、str()は「非公式の (informal)」という文章が書いてある。

repr() 組み込み関数によって呼び出され、オブジェクトを表す「公式の (official)」文字列を計算します。可能なら、これは (適切な環境が与えられれば) 同じ値のオブジェクトを再生成するのに使える、有効な Python 式のようなものであるべきです。

https://docs.python.org/ja/3/reference/datamodel.html#object.__repr__

オブジェクトの「非公式の (informal)」あるいは表示に適した文字列表現を計算するために、 str(object) と組み込み関数 format(), print() によって呼ばれます。戻り値は string オブジェクトでなければなりません。

https://docs.python.org/ja/3/reference/datamodel.html#object.__str__

この公式と非公式の表現が詳細に書かれていないので、余計混乱する形になった。他の人がどう解釈しているかが気になったので、インターネットで検索したところ「エンドユーザにとって読みやすいか読みやすくないか」と書かれていたのが一番しっくり来た。しかし、Pythonの公式ドキュメントに書かれている事実と、これを読む人は開発者であることを考えると、「エンジニアが開発しているときにデバッグとしてわかりやすいものかわかりにくいものか」と解釈するのが正しいように思う。これは開発者から見るか、利用者から見るかの違いなので大筋では同じことを言っているし、「エンドユーザからみて読みやすいか読みにくいか」を否定するものではない。

どう使われているか

実際にどう使われているかを見ていくと、「エンジニアが開発しているときにデバッグとしてわかりやすいものかわかりにくいものか」がしっくり来ると思う。str()とrepr()の違いについて調べると、よく出てくるサンプルコードをGoogle colab上で実行したものだ。strだと単純に時刻表示だけだが、reprだとどのクラスを使っているかとか詳細な情報が出てくる。これを見ると「エンジニアが開発しているときにデバッグとしてわかりやすいものかわかりにくいものか」がある意味では正しい表現であるんじゃないかと思えてくる。

import datetime
now = datetime.datetime.now()

str(now)
2020-07-31 12:37:54.850396

repr(now)
datetime.datetime(2020, 7, 31, 12, 37, 54, 850396)

now
datetime.datetime(2020, 7, 31, 12, 37, 54, 850396)

また、nowの変数だけ入力した際にデバッグが表示されるのもインタラクティブに開発が行えるPythonの強みが出ていると思う。逆に言えば、.pyファイルで実行した際はreprの変数だけでコードを書いたときに実行されないので、そういったときのためにstrが用意されているのかなと考えた。

【Pandas】df.head と df.head()の違い

サンプルコードを写経していたら、df.head()と打たなければいけないところを、df.headで実行してしまった。それでも実行はできて中身の出力はできたのだけれど、出力内容は違うものが出てきたのでこの2つについて簡単に調べた。表示されているデータは機械学習で有名なタイタニックのデータを出力した。

df.head()はメソッド

df.head()はメソッドです。引数に数値を入れることで、その数の行数分出力できる。 デフォルト引数も5が設定されているので、引数を設定しなくてもそのまま動く。

f:id:yoshitaku_jp:20200726103521p:plain

github.com

df.headはreprが出力

df.head すると10行のデータと詳細な情報が多く出てきた。 タイトルに結論が書いてあるが、これはreprの情報が出ている。 reprはrepresentationの略で表現という意味になる。 df.headを実行しているが、本当はreprの情報が出ているためにデフォルトで5行という制限もなく、様々な情報が出力されている。

f:id:yoshitaku_jp:20200726103417p:plain

【Python】デフォルト引数にリストを使うときの注意点

自分が知らなかったのでメモ

関数のデフォルト引数にリストを設定した時、デフォルト引数のリストの内容は再度実行したタイミングでも前の内容を保持します。

def sample(a, b=[]):
  b.append(a)
  return b

print(sample('test'))

['test']

print(sample('test'))

['test', 'test']

公式ドキュメントを読む

公式ドキュメントを当たると、次のように書いてあります。

デフォルト引数値は関数定義が実行されるときに左から右へ評価されます。 これは、デフォルト引数の式は関数が定義されるときにただ一度だけ評価され、同じ "計算済みの" 値が呼び出しのたびに使用されることを意味します。この仕様を理解しておくことは特に、デフォルト引数値がリストや辞書のようなミュータブルなオブジェクトであるときに重要です: 関数がこのオブジェクトを変更 (例えばリストに要素を追加) すると、このデフォルト値が変更の影響を受けてしまします。一般には、これは意図しない動作です。このような動作を避けるには、デフォルト値として None を使い、この値を関数本体の中で明示的にテストします。例えば以下のようにします:

def whats_on_the_telly(penguin=None):
    if penguin is None:
        penguin = []
    penguin.append("property of the zoo")
    return penguin

ミュータブルなオブジェクトを使う時に注意しなければいけないので、辞書も気をつけなければいけない対象です。 デフォルト値にNoneを使うことでも、この問題を回避できることが書いていました。

デフォルト引数を使うタイミング

そもそもデフォルト引数を使うタイミングがあまり想像できなかったので周りのエンジニアに聞いたところ、既存の関数に引数を追加したい時に使うと教えてもらいました。言われれば、呼び出し元に影響を与えず関数の中を変えられますので当然ですね。

Azureのストレージにおけるデータの冗長性

今回はAzureのストレージにおけるデータの冗長性についてまとめた。 Microsoftのドキュメントはとても丁寧に作られていて、こちらも読んでみてほしい。 このドキュメントは丁寧に作られている反面、普段触りなれていない人には内容として少し難しいかもしれない。 そのため、この記事はスッと理解できて説明の場ですぐ使えるようなレベルを目指した。 参考になれば!

docs.microsoft.com

※この記事は2020/07/07時点の情報を元にしています。

Azure Blob Storage とは?

Blob Storageは、Azureで提供されているストレージサービスで、AmazonAWSだとS3が同じサービスに該当する。 RDBサービスやNoSQLサービスのような構造化・半構造化データではなく、テキストや画像データなどの非構造化データを保存することに最適化されている。

Azure Blob StorageはBlobストレージとAzure Data Lake Storage Gen2の2つから選択できる。 この2つの違いについて歴史も交えつつ簡単に説明する。 元々はストレージサービスとして提供されていたのはBlob Storageしかなかった。 ビッグデータを扱えるストレージのニーズが高まり、Azure Data Lake Storageが誕生した。 これにより基本的なクラウドストレージサービスのBlob Storageとビッグデータ利用に最適化されたAzure Data Lake Storageの棲み分けが発生した。 現在はAzure Data Lake Storage Gen2と名称が変更され、Blob StorageとAzure Data Lake Storageが含まれたものになっている。

Azure Blob Storageにおけるデータの冗長性

データ冗長性について考えなければいけないことは3段階ある。 最初は「配置するリージョンでの複製方法」。次に、「ペアリージョンにも複製するか」。最後に、「複製したペアリージョンへのデータと読み取りを許可するか」となる。

配置するリージョンでの複製方法

まず配置するリージョンでの複製方法だが、これは「ローカル冗長ストレージ(LRS)」と「ゾーン冗長ストレージ(ZRS)」から選べる。 「ローカル冗長ストレージ」は1つの場所の中でデータを3回コピーする方法。 架空の話だがイメージとしては、東日本リージョン内の関東の中だけで3回データをコピーすることになる。 「ローカル冗長ストレージ(LRS)」は最もコストが安いがMicrosoftとしては推奨していない。 これは複製したデータが1箇所でしか保持されていないためであり、関東の交通網が大雪で止まってしまい、通勤通学に支障が出ることに似ている。 ローカル冗長ストレージは年間 99.999999999% (イレブン ナイン) 以上の持続性が提供される。

それに対する「ゾーン冗長ストレージ(ZRS)」はリージョン内に用意されているゾーンの間でデータをコピーする方法になる。 こちらも架空の話だが、東日本リージョン内の 北海道 / 東北 / 関東 の中でデータをコピーするイメージとなる。 「ローカル冗長ストレージ(LRS)」と比較すると、関東だけにデータを留めておくよりも広範囲に保存されることになります。 当たり前だが「ローカル冗長ストレージ(LRS)」よりも広範囲にデータが保存されるため冗長性は高くなる。 しかし、先程の関東の大雪よりも広い範囲、要は東日本全体への大雪がきてしまったら通勤通学を始め、飛行機新幹線での出張にも影響が出てしまうことに近い。 ゾーン冗長ストレージは年間 99.9999999999% (トゥエルブ ナイン) 以上の持続性を提供される。

配置するリージョン内での複製方法については以上となる。 じゃあ関東または東日本に大雪がきてしまったときのために、ペアとなっているリージョンにもデータを複製することを考え始めるのが次の項目となる。

ペアリージョンにも複製するか

ペアリージョンにも複製するかだが、これは「geo冗長ストレージ(GRS)」か「geoゾーン冗長ストレージ(GZRS)」から選べる。 「geo冗長ストレージ(GRS)」は「ローカル冗長ストレージ(LRS)」をペアのリージョンでも実施することになる。 先程出した例の延長線でいうと、東日本リージョン内の関東の中だけで3回データをコピーしたあとに、西日本リージョン内の関西の中で3回データをコピーすることに近い。

次に「geoゾーン冗長ストレージ(GZRS)」は各リージョン内に用意されているゾーンの間でデータをコピーする方法です。 東日本リージョン内の 北海道 / 東北 / 関東 の中でデータをコピーした後、西日本リージョン内の 関西 / 中部・四国 / 九州 の中でデータをコピーするイメージになる。

もちろん、ペアリージョンにコピーしているので東日本リージョンが使えなくなってしまった場合に、西日本リージョンのデータを使うことができる。普段から西日本のデータを読み取ることはできないが、いわゆるフェールオーバーが完了すると、西日本リージョンでデータの読み書きが可能となる。

ペアリージョン間のデータの同期ですが、これは非同期的に複製される。 どちらも年間 99.99999999999999% (シックスティーン ナイン) 以上の持続性を提供している。

複製したペアリージョンへのデータと読み取りを許可するか

「geo冗長ストレージ(GRS)」か「geoゾーン冗長ストレージ(GZRS)」はあくまでも、障害からデータを守るために複製する意味を持っている。 そしてペアリージョンでのデータの読み取りをできるのはフェールオーバー後でもあった。 しかし、「読み取りアクセス(RA)」を選択するとフェールオーバーをしなくてもペアリージョンからデータを読み取ることができる。 名称は「読み取りアクセスgeo冗長ストレージ (RA-GRS)」と「読み取りアクセスゾーン冗長ストレージ(RA-GZRS)」になり、増えた接頭辞の「RA」はRead Accessを指す。

まとめ

Azure Storage の冗長性についてまとめた。 「LRS」「ZRS」「GRS」「GZRS」「RA-GRS」「RA-GZRS」と英語が並んでややこしくなったが末尾の「RS」は「Redundancy Storage」のことを指している。 初めにも書いたが、Microsoftのドキュメントを参照するとより詳しいことが書いてあるのでそちらも参照してもらいたい。 ひとまず「L, Z, G, GZ, RA-G, RA-GZ」の部分が何を指しているのかが理解できて、説明できれば大丈夫だと考える。

おわりに

この記事はスッと理解できて説明の場ですぐ使えるようなレベルを目指した と前置きをしたが、自分ならどう説明するかの思考整理と理解整理も兼ねている。 「ナレッジの共有」と言うと聞こえは良いが、実際に組織としてうまく回せていることは少ないし、ファイルをどん!とおいてあるところが大半だと思う。 なので、新人でもとりあえず暗記すれば話せて、そこで成功体験を積め、最終的に技術の深いところに入ってもらうきっかけになればと思いながら筆を走らせた。 具体例を挟むと抽象的な部分は抜け落ちるし難しいと感じる。

何か間違っている部分があればご連絡お願いします。

参考情報

docs.microsoft.com

じぶん Release Notes 0.30.02

6月1日〜30日の間の出来事がリリースされました。

6月の感想

まだまだ警戒すべき段階ではありますが、少しずつ日常が戻ってきて嬉しいです。 仕事は期末ということで、忙しいかと思いきや来期への準備でそこまで忙しくなかったです。 出社して顔を合わせていれば色々会話も弾んだのと想像しますが、リモートということでやり取りも必要最小限でした。

6月は、自分の今までと今後を深く考える月になりました。 「ジャーナル」も初めてみました。 毎月設定している目標も7月に向け、OKRを軸に組み立てやる気にあふれています。 残り半年頑張っていかなきゃなと決意を固める日々です。

技術・開発関連

技術面での取り組みは以下の通りです。

イベント

読んだ本

ブログ

リリースノートを除き、次のエントリを書きました。 Design It輪読会記事は割愛します。

PV数

6月は4128でした。 バズり無しで4000を超えたのは初めてかもしれません。 引き続き頑張っていきます。

6月の目標結果

「西洋美術について学びまとめる」を立てました。 無事に読み終わりました。やはり自分の知らない世界に飛び込むと面白いですね。 感想をまとめることはしませんでしたが、美大出身の方とお話する機会があり盛り上がることができました。 それだけでも自分にはとても価値のあることだったと思います。

7月の目標

  • O: 「趣味ブログ」は今後進みたい「サッカー分野」で認知される
    • KR: 趣味ブログの読者数を10人にする
    • KR: 趣味ブログのPVを月100にする
    • KR: 趣味ブログの週1記事上げる
  • O: 「Python/Vue.js/Azure」はこの分野の人って認知される
    • KR: Python/Vue.js/Azureの3分野だけで月100PV取る
    • KR: Python/Vue.js/Azureのどれかに関する記事を週1で上げる
  • CEMのサイト修正

Design It! 輪読会 12章 アーキテクチャに通知表をつける

12章は「アーキテクチャに通知表をつける」で、今まで作り上げてきたアーキテクチャを評価し、また評価する文化を育むことを教えてくれる章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

当たり前ですが、章のタイトルでもある通知表は学生が学期末に渡される成績のことです。 学校における通知表は、生徒を始め保護者にとって重要なフィードバックとなっています。 このフィードバックをもとに、その学年・学期ごとの勉強が順調かを見極め、少し遅れている箇所に対策などを行うことができます。 このような考え方をアーキテクチャの評価にも取り入れようという趣旨の話から始まりました。

アーキテクチャ評価は、アーキテクチャが目的を満たしている程度について確認するプロセスです。 筆者は、一般的に設計段階の最後の段階に1回だけアーキテクチャ評価をすることは間違っていると警鐘を鳴らしています。 そもそもアーキテクチャが大きくなればなるほど、アーキテクチャを1回に見きれなくなると同時に評価をすることもできません。

アーキテクチャ評価の中で学ぶ必要があることは、「アーキテクチャはどの程度いいか」「アーキテクチャはどのようにいいか」です。 この2つの質問に答えるため、アーキテクチャ上重要な要求(ASR)についてわかっていることを使っていきます。 アーキテクチャ上重要な要求(ASR)を満たしていればいるほど、アーキテクチャとしての目的も満たしていると言えるからです。

まずは設計をテストするために、評価するものを作らなければなりません。 本の中で繰り返し使われているタンジブルにする必要があるということです。 評価する物自体は、コードであったりホワイトボードスケッチでもなんでも良いようです。 前章の内容からの内容を引っ張ってくると、共有と変更が難しい形での評価物は後のことを考えると辛いと思いました。

次に、デザインルーブリックを定義する手順がおこなわれます。 デザインルーブリックは、アーキテクチャの適合性を判断するときにレビューアが採用する基準を定義するものです。 ルーブリックは「観点」と「尺度」から構成され、観点は設計成果物を評価するために使用する特性を定め、尺度は特性を評価する段階を定めます。 ルーブリックは表の形を取ることが多いです。

他にも評価するためのワークショップを開こうと行った内容もありました。 この辺りは実施するときに参考とすればいいので、頭の中にインデックスを張る程度に留めました。

アーキテクチャ評価を継続的に行っていくためのtipsも書かれていました。 例えば評価ピラミッドを使うですが、すぐにチェックできる部分はスコープが狭いので頻繁におこない、逆に深い評価はスコープも広いのでASRと見比べてじっくりとおこなうといったバランスを取るような考え方です。 アーキテクチャ評価と言われると非常に重苦しい思いを持ちますが、このように書かれると小さなところからでもおこなって良いんだという風に好感が持てます。 他にも、アーキテクチャ評価という場を仰々しく始めるのではなく、手軽なホワイトボードジャムの最後に「どこか問題はありそうかな?」と問題定義をすることでチームとして評価する雰囲気をさり気なく初め、習慣づける方法も書かれていました。

Design It! 輪読会 11章 アーキテクチャを記述する

11章は「アーキテクチャを記述する」章で、ソフトウェアアーキテクチャの文章化を上手におこなって、見る人の関心事に着目したアーキテクチャ記述を学ぶ章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

まずはアーキテクチャの文章化のメリットデメリットについて述べられています。 デメリットは、アーキテクチャを文章化している分コードを書く時間が減ることや、メンテナンスされずに実物と文章がこなるアーキテクチャになることが挙げられていました。 もちろんメリットもあり、ビジョンが伝わり一貫性を保ちやすくなったり、設計計画を立てやすくなることがあります。

メリットとデメリットはわかりましたが、それを踏まえて必要な理由は何でしょうか。 それはコンポネント同士の結びつきや振る舞いを整理することや、ステークホルダー間の共通語を確立できるためです。 自分はこの共通語というところがDDDにおけるユビキタス言語に近しい文脈のように感じました。 仕様書通りに作ることはもちろん大切ですが、ステークホルダーが置き去りになることなく共に作り上げるニュアンスが含まれていると感じました。

様々なシチュエーションで必要になってくるため、それに応じた記述方法を選ばなくてはなりません。 本の中では、変更が「簡単」「難しい」か、共有が「簡単」「難しい」の2軸で考えることを勧めていました。 この部分でも気に入ったものがあり、それは変更が難しく、共有も難しい「無駄な方法」と述べられていた部分です。 その方法はスライドによるアーキテクチャ記述で、スライドだけでは独立できないこと(=共有が難しい)と、スライドの位置や参照を調整するのが大変といったこと(=変更が難しい)の2つを挙げられていました。 ついついスライド作成ツールを使って見栄えを良くしたほうがいい感覚になりますが、上記で述べられているようなことを感じ最近は使用していません。 アイデアの共有だけだったらまずはマークダウンファイルで良いわけですし、このなかでもリストや強調と行ったことを駆使して表現できます。 またテキストファイルなのでツールや環境にも大きく左右されません。

他には聴衆に配慮するといったことが述べられていますが、要は受け手を意識して共有しようということです。 我々エンジニアは日々難しい用語などを正しく使おうとしています。 コレ自体は全く悪くないことですが、やはり普段ITに携わらない人からすると理解がしにくいものです。 なので、なるべくステークホルダーと同じ言葉を使い専門用語を避けたり、背景知識が必要なものも簡単に定義したりしましょうということです。 また図や表を使う場合も凡例を使い理解しやすいように努めましょうということが述べられていました。

最後に個人的に良かったと思うところは、判断の論理的根拠を説明するです。 設計の根拠が伝わることでアーキテクチャの一貫性が保たれるという当たり前のことが書かれていましたが、自分に響いたのは次の文脈でした。 それは、選ばなかった案についても言語化するということです。 この部分を言語化しておくと、設計判断に耐え地会えなかった人にも納得感が与えられるのと、不要な議論を避けられるのが挙げられていました。 ドキュメント化するときには、自分たちが通ってきた道ばかりを残してしまいそうですが、分かれ道で選ばなかった方も「なぜ選ばなかったか」を記述しておくと、他の人の共有も楽になることを学べました。

Design It! 輪読会 10章 設計判断を可視化する

10章は「設計判断を可視化する」章で、アイデアを共有するためにアーキテクチャを触れられる形(=可視化)にする方法を述べた章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

アーキテクチャを可視化する方法は様々あるが、大切なのは誰に見せるのかを意識するということでした。 誰というのはつまりステークホルダーになりますが、このステークホルダーによって必要で欲しい情報は異なるために、適切な可視化の方法を選びましょうという話でした。 本の中で語られている「要素責務ビュー」と「絞り込みビュー」はシステムアーキテクチャを表現するにはとてもわかりやすいし便利です。 しかし、なぜここで分けて紹介されているのかがわからないといった疑問が輪読会の中であがりました。 ここで自分が持った回答は、このビューを見せるステークホルダの相手が欲しがっているものが違うから、記述される詳細度が違うのではないかということを回答しました。 要素責務ビューは、機能がビジネス側に対して何を提供しているものなのかを語るものであり、ビジネスサイドのステークホルダーに対して提供するものです。 それに対して絞り込みビューは、機能が何のモジュールによって構成されていて、またモジュール同士の関係はどうなっているかと言うエンジニアサイドが欲しがる情報を提供しています。 このようにステークホルダーが何を欲しがっているかを考えると、なぜこのビューがほしいのかが整理されると思いました。

後半の「素晴らしい図を描く」部分では、図の書き方について述べられている章でした。 相手にわかりやすく伝えるため、何をどのように載せるべきか、また各機能の並べ方など、忘れがちなことが書かれていました。 個人的な感想としては、そこまで書き方について色々言うならまず業界標準的なものがほしいなと思っていたところ、コラムにそのような情報が載っていました。 それは「アーキテクチャ記述言語」と呼ばれるものです。

アーキテクチャ記述言語(Architecture Description Language、ADL)とは、ソフトウェアアーキテクチャやシステムアーキテクチャを記述するためのコンピュータ言語または概念モデルである。ソフトウェア開発者がアーキテクチャについてやり取りする場合や、開発者と発注元との認識あわせに使う。またエンタープライズモデリングでも使われる。

ja.wikipedia.org

アーキテクチャ記述言語 SysML , AADL(前編)システム全体の記述に適したアーキテクチャ記述言語 「SysML」|オブジェクトの広場

アーキテクチャ記述言語 SysML , AADL(後編)非機能的側面に適したアーキテクチャ記述言語 「AADL」|オブジェクトの広場

コラムには続きがあり、アーキテクチャ記述言語は設計の表現力を制限したり常に仕事を楽にしてくれるわけではないと書かれており、本当に使いたい場合だけ使うべきだと書いてありました。 現在の自分の仕事が会社内での標準を作成するようなものであり、デザイン表現について標準がないのかと気になっていました。 しかし、デザインに関しては標準などが定められてしまうことによって表現力が遮られてしまうことがあり、良くないことがわかりました。 このあたりも標準を作成して効率を上げることよりも、可視化し相手に伝えるための存在しているツールだから、このような結論になっているのかと考えました。

Design It! 輪読会 9章 アーキテクチャデザインスタジオを開く

9章は「アーキテクチャデザインスタジオを開く」と表現された章で、参加者を集めアーキテクチャに関するワークショップを開く方法を学ぶ章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

まずはアーキテクチャという言葉の後ろにある「デザインスタジオ」について歴史的な経緯が語られており、このあたりの期限は19世紀のフランスまで遡るそうです。 19世紀のフランスの考えから現代なりの解釈を加え、ユーザエクスペリエンスコミュニティがデザインスタジオとして普及させました。 このように言葉の起源をしっかり明記してくれると頭にもすんなり入ってきて嬉しいです。

章の構成としては、アーキテクチャデザインスタジオを計画して実践していく方法について述べられています。 ワークショップの大きな流れとしては「作成」「共有」「批評」を繰り返していくものです。 本の中ではワークショップの流れの参考用にタイムスケジュールと、そのときにどんなことをすれば良いのか、またその目的は何なのかと言ったことが書かれています。 この部分に関して言えば、実際にチームメンバーとアーキテクチャに関する座談会を開くフェーズになったときに参考にすると良いと思います。

またワークショップデザインスタジオを開く準備段階で注意することに関しても明記されています。 「適切な参加者を招く」の章ですが、ワークショップをおこなう際の人数に注意するとか、フロントエンドの人ばかりが集まらないように多様性をもたせるとか、忘れてしまいそうなことが書かれていました。 他にも主催するファシリテーターとして、参加してくれたメンバが会の中に馴染めていないようであればコミュニケーションを円滑に進めるようにするために注意しなければならないことが書かれていました。

ここまではワークショップの流れと準備でしたが、実際におこなっている際の管理の視点も述べられています。 この中で書かれている「開始前に期待を設定する」というのはワークショップ以外にも使える視点で、自分が人に物事を説明する際にも意識する点です。 これから到達したい頂上の点がどこなのかを解説し、そこまでの道のりを確認し登っていくためです。 ゴールが明確となっていない長距離を走らされるのと、42.195knとわかっていてマラソンを走るのでは感覚的に大きく違うようなことです。

今回の輪読会では自分が9章を担当しましたが、現在のご時世を考慮して最後の「リモートチームと実施する」部分を重点的に話してみました。 この輪読会も普段からzoomやGoogle ハングアウトを使っておこなっていますが、他にも便利なツールを紹介しあってより生産性を向上させてみたい意図があったからです。 まずはJamBoardです。これはGoogleが提供しているホワイトボードアプリで、大人数で同時に編集することができます。 これは輪読会の資料を今回紹介する意図も含めてJamBoradで作成したものになります。

jamboard.google.com

次に面白いと思ったのは、紹介してもらったspatial.chatです。

spatial.chat

オンラインミーティングをするツールなのでやれることはzoomやGoogleハングアウトと同じなのです。 しかし、このアプリのすごいところは、ユーザのアイコンの距離感で話し声が大きくなったり小さくなったりすることです。 アイコンが近いユーザの声は大きく、アイコンが遠いユーザの声は小さくなり、普段の会議や飲み会のような体験が得られます。 zoomなどですと、全員に同じ音量で届きますからね。 他にもYoutubeの動画を貼れたりもして、非常に便利なツールであると思いました。

note.com