緊張構造(Structural Tension)をつくる

緊張構造は、ロバート・フリッツのメソッド。

 

自分なりにようやく理解して、体得してきた感じがするので、一度ここで理解していることを書き出してみたいと思った。知っている人向けの記事。

 

少し考えると、やはり、言葉で説明するのは難しい、と悟った。あまりにも単純だから。その難しさはここに書いた

medium.com

 

だから、ここでは、「この記事を書く」ことを緊張構造を利用してやってみて、そのプロセスを記述してみる。

 

ビジョンを描く

まずは、ビジョンを描く。ビジョンは、自分が創り出したいもの、目の前に存在するすることを望むもの。それを現実的に思い描いた。

 

・緊張構造についてのブログ記事(内容はもやっとしている)

・ロバート・フリッツのメソッドを学んだことのある人が読んで、理解と実践の助けになるもの(映像を思い描いた)

 

この時点で、色々な邪魔なものが頭をかすめる。知らない人が読んでも面白くない記事を書くのはどうか、グダグダの記事を書くと評判を落とすのでないか、やっぱり言葉で説明するのは難しいよな。。。多くが自意識の問題。とりあえず横にどかして、目標に集中する。

 

達成しなきゃならない、という強迫観念も捨てる。実現したい未来をドンと置く、というイメージ。

 

ビジョンから現実をみる

次に現実をみてみる。自分は今ここで自分の目に映るものに意識を移してから考え始める。

・記事はできてはいない。

・mediumの記事は書いた。

・新しい知識は不要。現時点での理解を共有すればよい

 

そうこうしているうちに、行動したい衝動が起こる。というより、体が勝手に動き始める。感情の高ぶりはない。坦々と行動しだす。

 

書こうと思うと、アイデアが湧いてくる。

 

言葉で説明するのは本質的に難しい。

だから、主観的体験を共有すればよい。限られた読み手のささやかな助けになることがビジョンだ。

この記事を書くプロセスをそのまま書いてみたら、たぶん助けになるだろう。

 

アクションプラン

 書き始めればよいし、すぐ書き始められる、と分かった。

 

ここまで書いてみて、読み直して確認する。振り返りを書いた方が読む人の助けになる、と思って振り返りを書く。

 

やってみての振り返り

・エネルギーはビジョンと現状をセットアップすると流れ出す。アクションプランはその結果。

・感情の高ぶりは一切なかった。(ある時もあるだろう)

・ビジョンは、描くとき、現状をみるとき、やっているとき、にどんどん形を微妙に変え、明確になっていった。アクションが終わったとき、ビジョンは現実になっている。

・自意識は常に邪魔しに来る。それを脇にのける。

ソフトウェアアーキテクチャとサッカーにおけるプレーモデル

共通イメージ

最近、ワールドカップシーズンのみのにわかサッカーファンとして、色々な動画やら、本やらを読んでいた。

 

youtu.be

 

サッカーの新しい教科書 戦術とは問題を解決する行為である

サッカーの新しい教科書 戦術とは問題を解決する行為である

 

 

本の中で、「プレーモデル」という言葉がでてくる。ようするに、プレーについての監督、選手が共有する、どう戦い、何をすべきかの共通イメージである。複雑系スポーツであるサッカーでは、コンビネーションの秩序を得るためにプレーモデル、という共通イメージが必要ということだ。

 

ここから発想したこと

 

つらつら書いてく

 

ソフトウェアアーキテクチャとは

ソフトウェアアーキテクチャの定義としては、色々IEEEとかの定義があるが、

 

IEEE 1471 - Wikipedia

 

個人的にはあまり、有用と思えない。不正確とも思わないけど、「So What?」な定義になっている。実際に仕事するとき、自分が念頭に置いているのは、マーチン・ファウラーが『エンタープライズアーキテクチャパターン』で記載した、Ralph Jonson(デザインパターンGang Of Four の一人?)の言葉

アーキテクチャとは、主観的要素であり、プロジェクト内の熟練開発者がシステム設計に関して共通して理解していることに過ぎない。

 ファウラーはこれに加えて、「変更しにくい」「重要なもの」という要素を何となく付け加えている。

つまり

アーキテクチャとは

  • 主観的要素であり
  • 熟練の
  • 開発者たちが共通して理解している
  • システム設計についての事柄で
  • 変更しにくく
  • 重要なもの

 である。

個人的には、

「熟練の」というのは不要。古い大規模開発とかだと、プログラマアーキテクチャについての理解を求めない場合もあったかもだけど、現在の規模やプロセスでそれを区別する意味はない。

「変更しにくく」も不要。今のエンジニアリングではほとんどのものが変更容易になっている。もし変更しにくいのは、多くの開発者の「共通して理解」していることだからだとおもう。

「重要なもの」も不要。共通理解が重要である、てこと以上のものはないと思う。

 

また、「システム設計」には当然プログラミングも含む。

 

だから、個人的な定義はアーキテクチャとは

アーキテクチャとは、主観的要素であり、チーム内の開発者が、システム設計/プログラミングに関して共通して理解している事柄

である。

これはサッカーにおけるプレーモデルの概念ととても近いと思う。

 

ソフトウェアアーキテクチャは何のために定義するのか

ソフトウェアアーキテクチャは何のためにあるのか。ここで、サッカーにおけるプレーモデルの概念が参考になる。

 ボール 保持 者 と その 味方 が お互い の こと を 理解 し、「 この 選手 は ここ で ボール を 受け て 壁 パス を したがっ て いる」 という よう に、 味方 の 次 の プレー を わかっ て いれ ば、 動き出し も 早く なる はず です。

この よう に し て 共通 の イメージ を 持つ こと で、 息 の 合っ た コンビネーション プレー が 実現 する の です。 少ない タッチ 数、 特に 1 タッチ での コンビネーション プレー という のは、 どんなに 緻密 に 形成 さ れ た 守備 組織 で あっ ても 突破 する こと が 可能 です。 チーム という のは 選手 の 集まり で 形成 さ れ、 各 選手 は お互い の 性格 や 考え方 を 理解 し て いる 方 が よく 機能 する の です。

坪井 健太郎. サッカーの新しい教科書 戦術とは問題を解決する行為である (Kindle の位置No.179-187). . Kindle 版.

 

つまり、共通イメージをもつことでコンビネーションが促進される。また、意思決定を柔軟に、素早く行う効果もある。

note.mu

 

また、ソフトウェアは開発し始めたばかりのときは、設計の選択肢は無限にある。だから制約を見つけることは開発の障害であるよりは、より考えることを絞り込めるため、開発を促進する。

制約は味方である。G.M.ワインバーグ

 

ソフトウェアアーキテクチャ定義、アーキテクティングとは、変化していく要求に対応して開発を駆動していくために、設計とプログラミングにおけるチーム内での共通理解を作り上げ、維持、変更していく行為なのだと思う。

 

どんなものがソフトウェアアーキテクチャなのか

ソフトウェアアーキテクチャの例として挙げられるのは、論理的に演繹できるもの、というよりは、経験的に、共有していた方がよいとされる認識のあつまり、なのだと思う。

例えば、

 

例えば、RDBのテーブル構造を「技術的詳細」としてアプリケーションから隠ぺいするのか、それとも、アプリのモデルとして扱うのか、といった見立てと判断も含むと思う。

 

これらは文書化されることもあれば、フレームワークやツール上に実装されることもある。文書化されず、文化として保持される場合もあるとは思う。

 

もちろん、これらを共有するためには一定水準の共通知識が必要。スペインのサッカーでは、プレーモデルを実現する前提として、様々な概念、知識(サッカーの教科書)が育成年代からトレーニングを通じてインストールされているという。

 

youtu.be

 

ソフトウェア開発でも同じで、アーキテクチャを理解するための基礎知識は必要なんだろうな。それがあると、個別具体的な状況に合わせた対応ができる。

 

チーム外のステークホルダーアーキテクチャ

伝統的なアーキテクチャの考え方として、チームやプロジェクト外のステークホルダーとの合意が重要とされることがある。自分の定義だとその観点はでてこない。ただ、別に普通のシステムに対する要求事項として扱えばよいと思うので定義を変える必要はない。

どうせ、ステークホルダーがレビューしたり、合意したりする場合はそれ向けのドキュメントなりを提示しなければならない。

 

追記

どんなものがアーキテクチャでないか

  • 開発者に認知されないドキュメント
  • 個別機能の設計やプログラミングを助けない制約
  • 共有する必要のない、一部機能やコンポーネントの詳細

 

追記

フレデリックブルックスのアーキテククチャの定義

  • 利用者に知覚される製品の定義

つまり、そのシステム/ソフトウェアとはなんであるか、のイメージ。アーキテクチャは実装ではない。

 

 

 

Jim Coplien氏の認定スクラムマスター研修に行ってきた

アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。

Jim Coplien - Wikipedia

 

認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。

 

以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。(通訳は提供されてたが、自分は使わなかった。)

また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ!という主張と理解している。

 

  • スクラムアライアンスとスクラムを一緒にするな
  • 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン
  • 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
  • ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
  • JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
  • 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
  • ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
  • 完了は完了(DONE is DONE)。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
  • 信頼を築くには、まず、自分から信頼すること。
  • 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの?信頼が大事。
  • デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
  • チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
  • POが出してきた要求にもチャレンジすることが大事
  • アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。(どこまで強い主張かは不明)
  • スプリント毎の振り返りでは、浅い振り返りになる。年に3日とか使ってしっかりと振り返りをして改革につなげたりする。
  • ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。3スプリント連続で変わったりするなら再考必要

 

前から思っていたけど、POの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ROIを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。

 

講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。

dev.classmethod.jp

 

coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、POが書く立場と思う(開発者も含めたステークホルダー追記できはする)。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。

ロールを全うするには、個人的には、ROIに責任もてない開発者がとやかくいうのではなく、POチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。

 

最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がPOチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。

 

追記①----

  • 多分、スプリントプランニングの時と思うけど、3本指テストでPBIをやり切れるか、の自信を試すといい。

 

追記②----

上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。

とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。

 

でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。

 

 追記③----

coplienさんから回答が来た!

 

以下翻訳。

開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。

 

google翻訳で読んだのかな?もしくはまだ、日本にいるから、誰かに訳してもらったのかも。 

 

追記④----

ユニットテストが無駄である旨の記事

https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

上記記事のからの引用


• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.

回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。


• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.

広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ

(ビジネスルールのアルゴリズムとか?)


• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.

上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。


• Design a test with more care than you design the code.

プロダクトコードをデザインするより注意深くテストをデザインしろ


• Turn most unit tests into assertions.

ほとんどのユニットテストアサーションに変換しろ


• Throw away tests that haven’t failed in a year.

1年間テストして、失敗しなかったテストは捨てろ


• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth

テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。


• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.

もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。


• Be humble about what tests can achieve. Tests don’t improve
quality: developers do. 

テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。

 

 

 

IntelliJ IDEAハンズオン に行ってきた

こちらにいってきた。

samuraism.doorkeeper.jp

 

仕事で使っているわけではなく、個人用に有償版を何年か前から購入させてもらっていたのだけど、使いこなせている感が全くなかったので参加。ツールを追求するのは苦手。。。

仕事ではEclipseだけど、使いこなせている感覚はない。。。

 

当日のカリキュラム

・JetBrains社の紹介
・製品紹介
 ・TeamCity/Upsource/YouTrackなどのチーム開発製品の紹介
 ・各種開発ツール
・ハンズオン

 ・キーマップなどの初期設定

 ・ショートカットと補完機能をフル活用したFizzBizz

 ・デバッグ機能

 ・Git

・クーポンなど
・質疑応答

 

注意点

 

感想その他

・チーム開発のツールは少人数なら無料みたいなので必要なら積極的につかってみたらよさそう。Upsourceがよさそう。

・コード補完機能は、変数の宣言と初期化が「値.var」「変数.if」や条件式.notでコード生成したり、条件式変更してもらえたり、これは、全く知らなかった。。。流れるようにコーディングできて、使いこなすと生産性がかなり変わりそうな印象。

デバッグ機能は、Eclipseでも使いこなしていなかったけど、実際に目の前でデモしてもらうと分かりやすかた。

 ※特定の条件でのみブレークポイントで止まるって機能、Eclipseにあったっけ。。。

・有償のChrononデバッガーがインストール可能なのでそれも使える、とのこと。業務ではまったときとかは使えそう。

Chronon Time Travelling Debugger | Chronon

・Gitの機能もほとんど使ってなかったのでやくだった。一部だけコミットしておくとかって結構使えそう。

 

結論

・時間は金で買える。

・そして、使いこなすのに時間を使うくらいなら、ハンズオン依頼しちゃうのがいいと思った。

 

 

 

コインチェック盗難事件とソフトウェアの複雑性

tweetをまとめる。

事件の経緯

第一報?

news.yahoo.co.jp

 

 

会社と社長について

www.businessinsider.jp

 

自分のtweet

 

記者会見

http://logmi.jp/260622

 

会見読んで

 

そこから考えたこと

 

CEO、どう考えても優秀な人だと思う。こういう未熟さは年の功がないとどうにもできない。わきの甘さは後付けで何とでもいえるけど、周囲のおっさん/おばさんもいいアドバイスができなかったんだと思う。

 

追記

 

追記2

返金する方針らしい。興味を失ったので、続きは書かない。

corporate.coincheck.com

書評『現場で役立つシステム設計の原則』

下記の本のレビュー記事。

 

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

 

 

内容

特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。

基盤となっているのは

あたり

 

感想

最初の雑感

とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、としかいいようがない。本当に使えるノウハウが体系的に整理されている。

教育コンテンツとしても完成度がめちゃめちゃ高い。前提知識をほとんど要求しないので、Javaなどの静的オブジェクト指向言語とデータベースの入門書レベルをしっかり理解している人ならそれなりに理解できるように記述されている。語られている範囲が広いのに、ボリュームも少なく、頭に自然に入ってくる。これは驚異的。相当推敲を繰り返したんではないか。

古い設計理論や開発プロセスも踏まえて語られているので、昔ながらのSIの現場にも伝わる内容になっている。そして、伝統的なやり方がなぜだめなのか、どうすればうまくいくのか、がしっかりと書かれている。あとは現場で考えてね!で逃げないのって本当にすごく難易度が高い。

 

誰向けか

若手~ベテランまで広くお勧め。そして、SIのマネジメント層に読んでほしい。

 

ドメイン駆動設計との関係

エヴァンスドメイン駆動設計にある、Entity(エンティティ)やAggregate(集約)みたいな重要なものが語られていない。これは、実は重要でない、というか、意識して作らなくてもいいんでないか、という主張なのではないか、と自分は思っている。エヴァンズのドメイン駆動設計のアップデート。だから、エヴァドメイン駆動設計を知りたかったら、やっぱり原典に当たったほうが良いかと思う。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 

 

プロセス

アジャイルのような反復開発でどのように開発を進めていくのか、ということも書かれている。重要なところに当たりをつけて部品を作っていって全体をくみ上げるってのがオブジェクト指向開発、とな。。こういうのが明確に語られている本は記憶にないなあ。

そして、これはScrumみたいのを形式的に適用したらオブジェクト指向開発はうまくいかないってことになるんだよね。バックログがPO任せだと、POのやりたいことが順番に降ってくるだけ。ウォーターフォールと大差なくなってしまう。

 

画面とデータベースに真っ向から取り組んでいるのがいい

従来の教科書的なオブジェクト指向設計の話だと画面設計やデータベース設計と絡めて語られることがほとんどなくて、現場で一番苦労するのがそこだったりするので、

オブジェクト指向使えない」

みたいなことになってたような気がする。

この本では、画面とデータベースという、コードを汚くする2大源泉に真っ向から取り組んで、成功しているように思える。そのブレークスルーの源は「ドメインオブジェクトの主役は値オブジェクトのようなスモールオブジェクト」って洞察だと思う。

 

読んでなるほどーと思ったとこ
  • 画面は利用者の関心事(ドメイン)を反映してるって視点。
  • ドメインモデルとデータモデルの本質的なミスマッチ
  • 業務マニュアルを初期から作っていく

なんとなくもやもやしてたけど、明確になった。

 

まだもやもやしているとこ
  • 小さいWebAPI→性能大丈夫か??
  • メッセージ文字列をドメインオブジェクトに直書き→国際化とかは?メッセージ一覧ほしくならないのかな?
書いてないけど、書かなくていいと思っていること
  • フレームワークとか、下回り(Radisとか)の話
  • 非機能面(性能とか)の対処→疎結合、高凝集の構造だと問題起こっても何とかしやすいからね。

 

書いてほしかったこと
  • テスト→多分、ユニットテストの重要性は小さくなっているはず。メンテもつらいし。開発の中でどうテストし、モデルの成長に合わせてメンテしていくのか、って話をちょっとだけでも書いてほしかった。

プログラミング初心者にはGoがいいんではないか、という話

一応、リンク張っとく
 
よいと思う理由
  • 文法が少なく、覚えやすい
  • 実行可能なバイナリをつくるもので、ソフトウェアがどういうものか、って基本が実感できる。
  • 手続き型言語であり、関数、構造体、抽象データ型、ポリモーフィズム(インタフェースによる)という歴史をなぞる形で学んでいくことができる
  • モダンなプログラミングスタイルのいくつかは備えている(クロージャなど)
  • 例外処理が簡潔
  • 標準ライブラリが充実していて、どれも簡潔な記述ですむ素晴らしい設計(Webアプリ、並列処理、DBアクセス)
  • 新しい言語であり、どんな企業いっても知っていて無駄になるってことはない(と思う)
OOPは手続き型の後に出てきたもの。Javaのようにいきなりクラスってのはつらい。Rubyとかもいいと思うけど、コンパイルって概念とか、型の存在とかは最初に知っておいたほうがいいと思う。
 
Javaを教えていて、これ、本質じゃないんだよなあ、って感じるところがさっくり教える必要がなくなっているイメージ。
 
ある程度センスのある人なら、短期間でかなりしっかり身につけられるんじゃないだろうか
プログラミングやアプリケーション開発がどんなものか、って全体像が最短距離で分かると思う。高校や大学で文系がやるんなら絶対にお勧めする
 
初心者向けのいい入門書が待ち望まれる