とあるSEの適当日記(仮)

その時のプロジェクトで必要になって調べた技術や読んだ書籍についてメモしていく場です。誰かの役にたったらいいなくらいのものです。最近の関心事は、「スクラム」「アジャイル」です。

「創発デザイン」と「最適デザイン」

先日、「ふくおかスクラム vol.4」で教えてもらった「創発的設計」についてもう少し深堀りしてみました。
junhiguchi.hatenablog.jp


創発的設計」で調べてもあまり情報でてこなくって、
いろいろ調べてるうちに、「創発デザイン」という言葉で使われていることに気づきました。

そんで、↓の本がなんか割とわかりやすそうでした。

創発デザインの概念

創発デザインの概念

Amazonで無料部分で読めるページが参考になりました。


創発デザイン」とは、

自律的にふるまう要素(部分)間および環境との間の局所的な相互作用が大域的な秩序(全体)を発現し(ボトムアップ),他方,そのように生じた秩序(全体)が個体(部分)のふるまいを拘束する(トップダウン)という双方向の動的過程により,新しい機能,形質,行動が獲得されること

自然界における例として上がられていたのが、↓の鳥の行動特性
f:id:jun_higuchi:20191112044420p:plain


一方で、「最適デザイン」とは、現在わかっている情報の中での全体構成を最適解でデザインしてから、部分構成をデザインするといったトップダウン型のデザインのようです。

以下も参考になりました。
https://www.jstage.jst.go.jp/article/jssd/56/0/56_0_A11/_pdf
https://www.jstage.jst.go.jp/article/jssd/55/0/55_0_13/_pdf


開発方法論の話で置き換えると、、

ウォーターフォールのような予め秩序(ルール)を定めた上で、開発を進めていくやり方が「最適デザイン」で、
スクラムアジャイルのような経験主義に基づいてやりながら秩序(ルール)を作り上げて行くやり方が「創発デザイン」なのかなぁと、

コーディングの話で置き換えると、、

これは、「ふくおかスクラム vol.4」で教えてもらった通りで、

初めにデザインパターンのような拡張の予測を立てた上で重厚設計をしてから部分を開発していくやり方が「最適デザイン」で、
重厚な設計はせずに、作りながら、リファクタで秩序を組み上げていくやり方が「創発デザイン」なのかなと。

まとめ

予め明らかに情報が揃っている場合には「最適デザイン」が向くのでしょうが、
不確実性の高い世の中においては「創発デザイン」が重要視されるのだと思います。

会社の構造でも同じような事が言えますね。
創発デザイン」というのは、社員1人1人が自律的に動いて、その相互作用から課、部、会社全体としての秩序を作り上げていく、、みたいな感じでしょうね。

ただし、「創発デザイン」でも初めから何もルールが無いわけではなく、「やっちゃいけないこと」だけは予め定めておくべきなのかと思いました。(前の記事のコーディングのリファクタで書いた、「Code smell(臭うコード)」のような…)

「ふくおかスクラム vol.4」に参加してきました。

昨日は、「ふくおかスクラム vol.4」に参加してきましたー。

fukuoka-scrum.connpass.com

場所はYahooさんの会議室。初めて行ったー


今回は、開発面におけることを学んだ気がします。

はじめから重厚な設計(デザインパターンなど)することは後々の負債となる

具体的に、ブラジルの首都ブラジリアを例としてあげてました。

Google Mapのキャプチャですが、ナスカの地上絵の如く美しい区画整備がなされています。

f:id:jun_higuchi:20191109044026p:plain
ブラジリア[全体]

ブラジリアの都市計画では、区画をきっちり分けて、その区画単位で生活のために必要となる建物を全て準備し、区画間で行き来の必要が無く、生活できるという空間を作ったそうです。

f:id:jun_higuchi:20191109044147p:plain
ブラジリア[詳細]

ところが、実際、人が住んでみてしばらく経つと、そう思い通りの状況とならなかったようで、↑の地図の大きな信号もないハイウェイと芝生を挟んでるとこを人が行き来するもんだから、芝生にはその移動軌跡がついてしまってるそうです。

そして、そのせいで、後からあったら便利だとわかった区画間の移動手段を作ろうとしても、作り難いという状況になってしまっている。ということをお話されてました。

はじめから重厚な設計(デザインパターンなど)することは後々の負債となってしまう事も多々あるという事でした。

設計は後から考える。創発的であるべきだ

創発」という言葉は、

創発(そうはつ、英語:emergence)とは、部分の性質の単純な総和にとどまらない性質が、全体として現れることである。局所的な複数の相互作用が複雑に組織化することで、個別の要素の振る舞いからは予測できないようなシステムが構成される。
・・・

参考:創発 - Wikipedia

なんか改めて読んでみると、マイクロサービスみたいな事言ってますねぇ。。
つまりは、1つのフレームワークに載せて拡張していくのでは無く、1つ1つが単純な追加により、それが群となり、1つのものに進化していくなる。みたいな感じだと思います。

TDDの考え方と合わせると。

・まずは、テストを作成
・単純でよいのでそれを満たすコードを作成し、テストが通る状態にする
リファクタリング(※ここで設計する)

創発的設計」とは、「初めの設計よりもリファクタによる再設計を重視する」という考え方のようです。

リファクタリングは「Code smell」に対する対応のみでよい

だからといって、リファクタリングで気合い入れて再設計で重厚な枠組みを作ってしまったら、それはそれで拡張できなくなってしまいます。
リファクタリングは、「Code smell(臭うコード)」のみを対象に直すのが良いみたいです。
「Code smell(臭うコード)」というのは、例えば「長過ぎるクラス名やメソッド名」とか、「可読性の悪いコード」とか、、ですが、開発メンバー全員でその基準を決めるのがいいとのことでした。

まとめ

創発的設計」というのは初めて聞くキーワードでした。
もう少し調べてその言葉を使いこなせるようになりたいと思います。

今回も勉強になりましたー。

今更ですが、「もしドラ」を見てみました

もしドラ」って知ってますかね?

もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」というタイトルの略称です。原作がこれ↓

なぜ今更これを見てみようと思ったかと言うと、
スクラムアジャイルの世界ではチームビルディングが大事だと言われていて、そのやり方として、「ドラッカー風エクササイズ」ってのがあるのですが、その名前の由来は、「ドラッカーさん言いそうな感じの問いを使ったエクササイズ」だからのようで、、その影響でドラッカーさんの「マネジメント」がちょっと気になったってだけですw

ちなみに「ドラッカー風エクササイズ」ってのはこちら
tech.pepabo.com



そこで、↑の本読んでも良かったのですが、
↓の映画がAmazonプライムで配信されてたこともあって、そっちを見てみました。

ドラッカーの「マネジメント」に基づいた流れと感想

ドラッカー「わかりきった答えが正しいことはほとんどない」

作中、繰り返し出てきた言葉です。これはとても心に響きます。

マネージャーの資質

ドラッカー「マネージャーにできなければならないことは、そのほとんどが教わらなくとも学ぶことができる」

ドラッカー「しかし、学ぶことのできない資質、始めから身につけたいなければならない資質が1つだけある」

ドラッカー「才能ではない」

ドラッカー「『真摯さ』である」
(※真摯=まじめで、ひたむきなようす。)

ふむ。。知識としては教わる必要なく独学で学べるものなので、
「真摯さ」を自分で身につけようと頑張れってことかいな。

ドラッカー「あらゆる組織において、共通のものの見方」
ドラッカー「理解、方向づけ、努力を実現するには」

ドラッカー「『われわれの事業は何か。何であるべきか』を定義することが不可欠である」

これを高校野球に置き換えてみると、、、↓

まず、
高校野球にとって顧客 = 高校野球に関わる人(野球部員、保護者、学校、高校野球連盟など)

野球部員はお金が目的では無いのになぜ野球をやるのか?=野球が好きだから

高校野球の何が好きなのか?なぜ顧客は集まるのか?」 つまり、「高校野球にとっての顧客は何を求めているのか?」
=それは「感動」を求めている

野球部の定義 = 「感動」を与える事=「つまり、甲子園に行くこと」

  • -

つぎは、「マーケティング(市場調査)」
→皆が部に対して思っている事を聞き出す。そうすればもっと真面目に練習をしてくれる方法が見つかるかも

これにより、皆それぞれ、想いがあったのに、周りに語れていない現状が浮き彫りになる。

試合の負けから、ピッチャーを攻めるチームメンバーに対して監督が一喝「わざとファーボールを出すピッチャーなんてこのチームには居ない!必死に頑張った結果だ!」と

これをキッカケにチームメンバーも練習に参加しだし、ちょっとまとまり始める。

ドラッカー「人は最大の資産である」

練習試合にはほとんど負けなしになった。

んー。今まで練習まともにやって来なかった連中が、こんなちょっとのキッカケでほとんど負け無しになるものなのか、、
まぁ、それ置いておいて、「マーケティング(市場調査)」として利害関係から情報を引き出すのが大事だってことですね。

イノベーション(革新):組織の外にもたらす変化。古い常識を打ち壊し、新しい価値を想像することで常識を変える

野球部ではなく、高校野球の方を変える。
古い常識を打ち壊し、新しい野球を想像することで、高校野球会の常識を変える。
古いもの死につつあるもの陳腐化したものは計画的かつ体系的に捨てていく。

送りバントとボール球を打たせる投球術を捨てる事をしてみてはどうか?


ドラッカー:「専門家にはマネージャーが必要である。彼らは理解してもらってこそ、初めて有効な存在となる」


限られた時間の中で成果を出すためには、
何かに集中し、何かを捨てる必要がある。

監督とマネージャーで、攻撃と守備についてそれぞれ集中すべきポイントを決めた。
それ以外は全部捨て、それだけに集中する。

【攻撃】
集中すること=ストライクとボール球を見極める。
捨てること=送りバント

【守備】
集中すること=全球ストライク球で勝負する。守備側は打たれることを前提に強化する
捨てること=わざとボールを打者に打たせる投球術や、わざとファーボールを出して特定の打者との勝負から逃げること
→「ノーバント、ノーボール作戦(全球ストライク球で勝負する)」を実施

他の様々な部と協力して、合同練習しだす。

ドラッカー「組織の外に与える変化と影響」=まさにイノベーション

これらの作戦が功を奏し、夏の大会でも勝ち進むようになる。

夏の大会、順当に勝ち進み、とうとう決勝戦まで進む
ここで、野球部の元マネージャーだった女生徒が亡くなる。この女性は、主人公の幼馴染でマネージャーやるきっかけになった親友でした。

マネージャーと野球部は、そのショックを乗り切り、最後の決勝戦に勝利する

といったお話でした。

まぁ、全体として、野球部でドラッカーさんの「マネジメント」を適用したからといって、こんなに上手く甲子園まで行けるものでもないだろうと。。
あと、「マネジメント」の本で書いてることはこれが全てでは無いのではないかなっと。

やっぱ、ちゃんとドラッカーさんの「マネジメント」を読んだ方がいいのかなぁと思いました。

マネジメント[エッセンシャル版] - 基本と原則

マネジメント[エッセンシャル版] - 基本と原則

「信用」と「信頼」

どもです。

「信用」と「信頼」って似た言葉ですが、全く意味が異なるんですねー

「信用」・・・過去の実績をベースに(証拠によって)、今後の実績を信じる行為
「信頼」・・・過去の実績は抜きにして、人柄や仕事ぶりから判断した信じるという行為。未来に対して無条件に行う事

のようです。

つまりは、
「信用」できる人だからといって、「信頼」できる人では無いかもしれない。
なぜなら、その人がデキル人だからといって、自分の為に何かをやってくれるとは限らないわけですよ。

また、逆に、、
「信頼」できる人だからといって、「信用」して良いとは限らない。
その人が自分のために頑張ってくれる人だからといって、上手くいくとは限らないわけだ。


ふむふむ。なるほどー。

10/8にワークショップ祭に参加してきました

先週の話ではあるのですが、東京で開催されていた「SCRUM実験室」のワークショップ祭に参加してきましたー。

scrum-jikken.connpass.com

別件で東京に出張に来ておりまして、ついでにこのイベントに参加してきました。

元々、3つに別れてワークショップを行う予定だったようなのですが、結局、Alanさん主体で2つのワークショップを参加者全員で取り組む形となりました。
3つのワークショップをやりましたが、いずれも抑圧者、被抑圧者がテーマのようです。

1つ目のワークショップ「2人1組 操作する方される方(※正確な名前は不明)」

2人1組にでパートナーを作り、まず片方が、もう片方の顔の前に手を広げた状態で出し、その手を動かしたら、手を出されている方は顔をその手から一定の距離を保ったまま顔や身体を動かしてついていかなければならないというものでした。
つまりは、手を出している方が「操作する方」、手を顔に出されている方が「操作される方」となります。
「操作する方」は調子に乗って、無茶のところに手を持っていったり、左右だけでなく、上下にもあちこちに手を持っていくので、「操作される方」はそれについていくのが大変です。
数分後、「操作する方」と「操作される方」の役が交代になり、同じことをやります。

このワークショップで言えることは、「操作する方」=抑圧者、「操作される方」=被抑圧者となり、「操作される方」は被抑圧者として、ストレスを受けていたにも関わらず、立場が逆転すると、同じことやそれ以上の事を相手にやってしまい、抑圧者ー被抑圧者の関係は止まることが無いという事を表すのだそうです(たぶん、そんな感じの事を説明してたと思いますw)。

2つ目のワークショップ「ゾンビ?(※正確な名前は不明)」

歩く際、片方の足のつま先に、もう片方の足のかかとを付けて歩き、必ず首を曲げ俯いて、全員ゾンビのように歩きます。
初めのゾンビ役はAlanさんのみ、ゾンビに手を牙に見立てて、噛まれたら、その人もゾンビになる。そのとき唸り声を上げて、一般人と同様にまたあるき出す。そのゾンビも同様に手を牙に見立てて、噛んでよい。といったゲームです。
これを10分くらいやってみて、一般人のとき、そしてそこからゾンビになった人がどういう感じ方を持つのかを検証してみるようなものでした。

まとめとして、
一般人のときは、ゾンビにならないようにちょっと怖い感覚を持ちゾンビから逃げたり、誰かがゾンビになった唸り声を聞いたら、その唸り声から離れるような動きをする。
一方で、ゾンビになった人は、今度は「他の人を襲ってやるぜ」といった気持ちでエキサイティングな感情になるそうです。

これはつまり、ゾンビ=抑圧者、一般人=被抑圧者と見立て、
被抑圧者(一般人)でも、抑圧できる立場であるゾンビになった際には、その立場を利用して、抑圧者としての権利を行使したくなってしまうのだそうです。これにより、1つ目のワークショップと同様に、抑圧者ー被抑圧者の関係は止まることが無いという事を表すのだそうです。

3つ目のワークショップ「被抑圧者の演劇」

皆で、今までに業務で強い支配を受けた不幸エピソードを募り、その中で最も不幸だと思えるエピソードを「演劇」という形で再現してみるというワークショップでした。
普通の演劇とは違い、面白いのが、演者と観覧者という関係性ではなく、その場その場で、「もっと上手く演じれる」と思った観覧者が手を挙げ、演者と入れ替わり、その役をやり、観覧者に変わってしまった人もまた手を挙げて演者になってもよいというものでした。
まずは、強い支配(抑圧)を演じる形で何度かの演劇を行い、その場その場でもっと強い支配を演じれる自信のある人が変わっていくというものでした。
途中からコンセプトが代わり、この強い支配(抑圧)をどうすれば、いい方向に解決できるのか、を演じる形にシフトしてました。

この「被抑圧者の演劇」というワークショップは、演じて見せたり、見せられたりすることにより、強い支配に対してどうすれば解決できるのか?をシミュレーションしながら議論を行うためのツールとのことです。

後で調べてみましたが、割と有名なようです。
kimochi-pose.jimdo.com

感想とか

今回のワークショップでは、「抑圧者と被抑圧者」がテーマでした。
思い返してみたら、我々のソフトウェア開発業界でも、「抑圧者」からストレスを浴びせられていた「被抑圧者」でも、出世して権利を持ったとたんに「抑圧者」になってしまっているという人も多く居ます。悲しみの連鎖ですね。。
私はそうはなりたくないという気持ちを常に持っていたいです。

それにしても、東京ではこういった勉強会やワークショップなんかが多々行われているようで羨ましいですねぇ。
また出張とかで東京行く機会があったら、何か参加してみようかなって思います^^

最近、DockerとAWSの勉強はじめました。

ども、ひぐちぇです(゜д゜)ノ
なんか、久しぶりにこれ書く気がしますw


というのは、最近、プロジェクトで使っているインフラ系の知識に疎いなぁ、、っと、
この辺、開発チームのメンバーも不得意だし、この知識があればもっと、チームをサポートできる。
とか考え、、

プロジェクトで実際に使っている。
DockerとAWSの勉強はじめておりました。

Dockerで開発環境を作れるようになる

これは、今のプロジェクトで、開発環境として使っています。
Dockerというのは、コンテナという技術を用いて、PC上に仮想環境を作り上げる感じです。
詳しくはこちら
qiita.com

これが使いこなせると何が嬉しいかというと、
開発環境をテキスト(コード)化しておけるので、配布して他の人の環境で開発環境作成する作業が超楽ちん!になるのです。

私のプロジェクトでは、Docker Compose(複数のサーバをまとめて管理するやつ)を使っています。
いろんなベンダーで、Dockerイメージを配布しているので、それらを使って、組み合わせて、サーバ起動させ、Tomcatサーバに作ったアプリを載せて、テストしてるのです。

この技術抑えておくことで、今後のスクラムの現場でも開発環境的な支援がし易くなると思い、頑張ってます。

AWSでCI/CD環境を作れるようになる

AWSについては最早、書くまでも無いですよね。
我々のプロジェクトでは、CI/CD環境(継続的なインテグレーション、継続的なデプロイ、デリバリー)として使っておます。
これ抑えておくことで、今後のスクラムの現場でのCI及びCDのスピードが出やすくなるだろうと思い、勉強することにしました。

何か目標あったほうがいいので、AWSについては、AWS認定資格を目指しながら勉強することにしました。
f:id:jun_higuchi:20191004031617p:plain

まずは、プラクティショナーから、、そのあと、アソシエイトのアーキテクトとデベロッパー辺りを取れたらなぁっとか考えてます。
最近、プラクティショナーの本を↓1冊を読み終えたところでした。

AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー

AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー

そんで、Udemyで模擬試験を1つやってみたのですが、全然だめww 6割くらいしか取れてないw
https://www.udemy.com/course/aws-4260/

ってなわけで、勉強やり直し中だったのです。


Microsoft AzureやGCPGoogleクラウド)も勉強したいとかも少し思っているので、先は長いなぁ・・・


といった具合で、今は、直近業務で使うDockerを勉強しながら色々試してみつつ、さらに、AWSの試験勉強中なのです。
進展あったら、またレポ書いておきます。

「カイゼン・ジャーニー」を読み終えたので感想を。。

ひっそりコツコツと読んでた「カイゼン・ジャーニー」を読み終えたので、感想書いておきます。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

簡単に書くと、
開発の範囲の「境界」を越えること(つまりは「越境」すること)で、コミュニケーションが活性化し、仕事をスムーズに終えることが出来たという話です。
物語形式になっており、いろんな場面において「境界」を感じ、その都度、様々なプラクティス(やり方)を使いこなしながら「越境」をしていくという構成となっており、そのプラクティスはとても参考になるものでした。

ここで、私が参考になったなーって思った、いくつかのプラクティスを紹介しておきます。

Working Agreement

チームで決めたルールの事です。チームメンバー全員が必ず参加し、互いの価値観をぶつけあいながら、生産性の上がるルールを決め、それを守りながら仕事を進めるというものになります。これは、ふりかえりの中でより良い形にアップデートしていくものとのことです。

ドラッガー風エクササイズ

メンバーそれぞれが、「①何が得意か?」「②どうやって貢献するか?」「③大切に思う価値」「④メンバーは自分にどんなことを期待しているか?」の4質問に答えていき、付箋などで大きく張り出し、互いの相互理解を深めていくというものです。
この4質問に全員が答えたうえで、⑤の質問として、「④メンバーは自分にどんなことを期待しているか?」の答えが認識合っているか?のフィードバックを全員から貰うというものです。それにより、期待のズレを修正していくというものになります。

ファイブフィンガー

今の状態を「せーの」で一斉にメンバー全員がそれぞれ5本の指で示し合います。5本「とっても上手くやれている」、4本「うまくやれている感触あり」、3本「可もなく不可もなく」、2本「不安は少しある」、1本「全然ダメで絶望的」を意味します。
手を上げるか下げるかだと、二者択一の多数決のような状態となってしまいますが、5本の指で示すことでもう少し状態を詳しく示すことができるというものです。互いに出し合ったうえで、コミュニケーションを取り、不安要素などを共有し合うというやり方になります。

CCPM(Critical Chain Project Management)

バッファの持ち方の話で、タスクごとの個別にバッファを持つやり方ではなく、全体としてバッファを持ってプロジェクトを管理する方法のことです。その全体バッファの求め方は、全タスクの見積もり工数合計の半分として足し合わせます。
これにより、各タスクについて担当者がグズグズと作業を先延ばしにしてしまうというリスクを回避できるそうです。
なるほど。。

むきなおり

むきなおりとは、進むべき先を捉えて現在と正すことです。
つまりは、期限を意識した上で、重要度の高いものを整理し、どこまでやるのかを明確化して、どのようにやっていくのかを再度検討して実行に移していくというものです。

仮説キャンバス

↓のSlideShareが分かりやすいです。このキャンバスの項目を埋める形で情報を整理するというものです。

前ページも見てください。この「仮説」を元にして、ユーザーインタビューやユーザーストリーマッピングを作成することで「検証」していくのだそうです。

ハンバーフライト

ハンガーフライトというのは、プロジェクトの枠を越えて、いろんな人と集まり、技術やコミュニケーションなどについての雑談をすることで新たな学びを得ようという試みです。
ハンガー(Hangar)というの、飛行機の格納庫のことだそうで、昔、天候が悪くて飛行機が飛ばせないときに、天候が良くなるまでパイロット達でハンバー(格納庫)に集まって、航空技術の経験談を語り合ったそうです。



以上、気になった点をまとめてみました。
なお、私が元々知っていた事はフィルタリングされてしまっているので、ここでは紹介されない形となっているため、興味ある方はちゃんと読むことをおすすめします。


いやぁ、この本は、アジャイルスクラムに関係なく、新人からシニア層まで読んで価値あるものだと思いますよ。
今後、うちの会社の同僚にもオススメしていきたいものです。

プライバシーポリシー お問い合わせ