組織を舞台にした野望を持ちたい

最近、同僚とよく会社のビジョンの話をしている。背景については割愛するが、要は会社にビジョンを求めているのである。 会社としてビジョンを掲げてくれないと自分たちがどう動いていくべきなのかがわからない、ということだ。

とはいえ、「個人的なビジョン」も必要だよなぁとぼんやりと考えていた。

そんな中で個人的に好きな三大漫画の一つであるアオアシが完結目前ということもあり1巻から読み直しているのだが、第1話から琴線に触れるセリフがあった。 東京シティ・エスペリオンFC監督の福田達也が主人公の青井葦人をユースへ勧誘する時のセリフだ。

「 俺には野望がある。俺の作り上げたクラブで、世界を掌中に収める。世界への踏み台じゃない。我がクラブこそが世界だと。バルサもマドリーもマンチェスターも、ミランも、叩きつぶす。その野望のすべてを担うもの、育成<ユース>だ。」

小林有吾『アオアシ』（小学館）第1話「ファーストタッチ」

なかなかに響いた。これは福田達也個人の野望であり、エスペリオンというチーム自体に世界一を目指すという話は出てこない（はず）。 しかし、そんな野望を持って育成に力を注いでいる福田達也のもとには、サッカー選手として大成しようとする優秀な若者たちが集まる。 中には福田達也と同じように世界で戦うことを前提としたユース生もいる。 福田達也は自らの野望を果たすためにチームを率いているが、そのための行動がチームのためになっているし、ユース生個人のためにもなっている。 ユース生も自分のための行動がチームのためになるし、福田達也個人のためにもなっている。ここには明確に正のフィードバックループがある。

対して自分はどうだろうか。会社が、もしくは会社の経営陣がビジョンを掲げたとしてそこに個人のビジョンを重ねることができるだろうか。 相互作用関係を作り出すことはできるのだろうか。このセリフを読んで個人のビジョンを掲げていく必要があると感じた。

ただ「ビジョン」というと綺麗すぎる感じがあるので「野望」が今の気持ちによくハマる。

そんなこんなで@iwashi86さんの講演を思い出した。 これも熱くなる講演だった。見たのはYouTubeの動画だけど...

なかなか現実味を持って「日本」を主語にした野望を持つことはできないが、「会社」くらいなら可能かもしれない。 いや野望というくらいなのだから「札幌」とか「北海道」とかもっと大きく出てみてもいいのかも。

そんなことを考えている。

アオアシ（１） (ビッグコミックス)

視点・視野・視座を捉え直す

はじめに

今更ながらアオアシを元にしたビジネス書を読んでいる。 第1章「観察」の中で書かれていた視点・視野・視座の考え方がものすごく腹落ちしたので、自分の言葉で思考をまとめてみる。

視点・視野・視座とは

視点：何を見ているか

視点は通常、「何を見ているか」と「どこから見ているか」の2つの意味を持っているが、 2つの意味を持ったままにしておくと話が混乱しやすいので「何を見ているか」を視野と定義し、「どこから見ているか」を後述する視座と定義する。

同じソフトウェア開発の話をしていても視点が「品質」にあるのか「売上」にあるのかなど、見ているものが違うと意見も違ってくる。 対話を試みる際にはまず同じものを見ているかを確認する必要がある。

視野：どれくらい見えているか

視野の定義においてブレが発生することはほぼないと思う。 同じものを見ていてもその周辺にあるものがどれくらい見えているかは人それぞれ違う。

視野が狭いと見えているものが少なくなる＝情報が少なくなるので選択肢を持ちにくくなってしまう。 選択肢が少ない状況では良い成果を得ることも難しくなる。

注意しなければいけないのは、視野が広ければいいわけではないということ。 視野が広すぎると選択肢が多すぎて選びきれなくなったり、情報が多すぎて疲れてしまったりする。

視座：どこから見ているか

視座は2つの考え方で捉えることができる。 1つ目は「どの方向から見ているか」という捉え方だ。 「開発者」と「営業」では同じ「プロダクト」を見ていても感じ方が違う。 「開発者」の視座では内部品質も見えるので開発のスピードを落としてでもリファクタリングを行うべきと考えることもあるが、「営業」の視座では顧客満足度や売上を高めるために開発のスピードを落とすべきではないと意見が対立するような感じだ。

2つ目は「どれくらい離れてみているか」という捉え方だ。 これは地図の縮尺のような考え方が理解しやすい。 縮尺が大きいと見える範囲が狭いが細かいところが見えやすい。 縮尺が小さいと細かいところは見えなくなるがより広い範囲が見えるようになる。

同じように視座を離すと全体像が把握しやすくなり、視座を近付けると詳細が把握しやすくなる。 たまに「視座を高く持とう」というような言説を目にするが高ければ良いというものでもないし、高低というメタファーは「高い方が良い」と感じやすそうなので距離のメタファーを用いて離す・近付けると表現するようにしたい。

視差について

今まで知らなかった概念として「視差」が出てきた。同じものを見ている時の「見え方の違い」という意味らしいのだが、 ここで気付いたことがある。それは、視差とは情報の非対称性と一致する概念だということだ。 そして視点・視野・視座は情報の非対称性を構成する要素となる。

見ているものが違えば当然、意思疎通はうまくいかないし、見える範囲が違えば導き出される答えは異なる。 そして見ている場所が違えば同じものを見ていても見え方は違うし、見える範囲も変わってくる。

まとめ

視点・視野・視座は人それぞれ異なる。完璧に揃えることはできないことを前提としてできる限り視点・視野・視座を共有しながら対話を進めることで、不確実性を低減させていくことができるだろう。

AI時代になぜ「結合度」と「凝集度」なのか

はじめに

最近、「結合度」と「凝集度」に関する簡単なブログを書きました。 これからアウトプットをしていくための練習としての意味合いが強いのですが、なぜテーマに「結合度」と「凝集度」を選んだのかについて簡単にまとめたいと思います。

「結合度」と「凝集度」を選んだわけ

AIが急速に進化しています。ソフトウェア開発で使わない日はないくらいです。 まだチャットUIで実装方法について相談するだけという人もいるみたいですが、世の中を見ると Cursor や Claude Code といったコーディングエージェントを使って実装を行う人が増えています。 さらに Devin や OpenAI の Codex、Microsoft の GitHub Copilot Coding Agent のような IDE/エディター外で動作するコーディングエージェントも増えてきています。

IDE/エディター上で動くにせよ、そうでないにせよ、コードを書く仕事がソフトウェア開発者の手を離れていくことは間違いありません。 例えば我々は、機械語やアセンブラを理解しなくてもソフトウェア開発ができます。 それと同じように、プログラミング言語を理解しなくてもソフトウェア開発ができるようになるでしょう。 今すぐではないと思いますが、そう遠くない未来でしょう。

そう考えた時に、ソフトウェア開発でどんな変化が起こるのでしょうか。 その1つが「設計」の重要度が今以上に高まることです。

AIは恐ろしいほど高速に実装を進めます。どんな優秀なプログラマーでも速度では敵わないでしょう。 しかし、コードの品質が人間と比べて圧倒的に良いとは言えません。それどころか、実製品には到底使いたくないようなコードを生成してくることも珍しくありません。 AIがコードを生成する速度で製品にコードを反映していれば、あっという間に保守が困難になってしまいます。

ところが、AIの実装速度を考慮すると今まで通りのコードの品質を求めることが最良かというと、そうではないとも感じます。 AIが十分に理解できる大きさで疎結合・高凝集なモジュール設計を行っていれば、仕様書やテストコードをコンテキストとして入力してモジュールごと作り直す、ということが可能になるからです。 モジュールに対するテストさえあれば、丸ごと作り直すという選択肢を取ることができるのです。AI時代のリファクタリングと言ってもいいでしょう。

もっと先の未来ではモジュールではなく、システムごと作り直すという選択肢もあるでしょう。 しかし、連続的な変化の先にある未来では、それは非常にコストがかかってくる行為となるはずです。

だからこそ、結合度と凝集度といった設計の基礎を学び直し、AIを使った新しい時代のプログラミングスキルを身につけることが、これからのソフトウェア開発者の技術力になるのです。

凝集度をザックリ理解する

はじめに

ソフトウェア開発における重要な概念である凝集度について、ポイントを絞って解説する。 この記事では、結合度をさらに深掘りするための土台となる知識を身につけることを目指す。

凝集度とは

凝集度(Cohesion)は、モジュール内に必要な機能が十分に集まっているかを示す概念であり「ぎょうしゅうど」と読む。 凝集度は高いほど望ましいとされており、以下の2つの観点で評価することができる。

• モジュール内に必要な機能が集まっているかどうか
• 含まれている機能が関係性の高い機能であるかどうか

プログラミングにおける「単一責任の原則」と非常に似ている。

凝集度が影響するソフトウェアの品質特性

凝集度が高い場合、多くのソフトウェアの品質特性によい影響を与える。 代表的なものを記す。

修正容易性

修正すべきコードが1つのモジュールに集まっているので修正箇所が特定しやすく、他のモジュールへの影響が少ないためコードの修正が行いやすくなる。

理解容易性

関係性の高いコードのみで構成されているため目的が明確になりやすく、コードの理解が進みやすい。 特定のコードを探すときもモジュール内に必要な機能がまとまっているため見つけやすくなる。

再利用性

1つのモジュールに必要な機能がまとまっているため、他の箇所から呼び出しやすくなる。

凝集度を高める取り組み

凝集度を高めるには適切な設計やリファクタリングを行っていく必要があるが、似たようなロジックを集めるだけでは達成できないので、以下の指標を基準に実際のコードと比較しながらモジュールを形作っていく必要がある。全てのコードが機能的凝集であることが理想だが、現実には難しいのでソースコードの規模や複雑さを加味しながらできる限り高い凝集レベルを目指していくことになる。

凝集のレベル

数字が大きくなるほど凝集度が高くなるように並べると以下のようになる。

レベル1 偶発的凝集

関係のないコードがたまたま同じモジュール内に存在している状態

レベル2 論理的凝集

似てはいるが別の目的を持つコードが同じモジュール内に存在している状態

レベル3 時間的凝集

同じタイミングで実行されるコードがモジュール内に集まった状態

レベル4 手順的凝集

特定の目的を果たすための手順を実行する複数の機能がモジュール内に集まった状態

レベル5 通信的凝集

同じ入力、もしくは出力（またはその両方）を扱う複数の機能が1つのモジュールに集まった状態

レベル6 逐次的凝集

前の処理の出力が次の処理の入力になる複数の機能がモジュール内に集まった状態

レベル7 機能的凝集

モジュールが1つの機能を完成させるコードのみで構成されている状態

まとめ

• 凝集度はモジュール内に必要な機能だけが集まっているかを示す
• 凝集度はソフトウェアの品質特性に影響を及ぼす
• 全てのモジュールを機能的凝集にするのは難しいので、規模やドメイン特性に配慮しつつ、可能な限り凝集度が高い状態を目指す

結合度をザックリ理解する

はじめに

ソフトウェア開発における重要な概念 である結合度 について、ポイントを絞って解説する。
この記事では、結合度をさらに深掘りするための土台となる知識を身につけることを目指す。

結合度(Coupling)とは

複数のモジュール間における依存の強さを示す概念のことであり、結合度が低い状態のことを疎結合という。 疎結合なモジュールは独立性が高く、良い状態とされる。

結合度が影響するソフトウェアの品質特性

修正容易性

結合度が高いと、あるモジュールの修正が他のモジュールへの影響を及ぼしやすくなり、バグの発生や修正時間の増加につながる。

理解容易性

結合度が高いと一度にたくさんのコードを把握しなければいけないため認知負荷が高まり、理解容易性が低下する。 モジュール間の繋がりを見落とす可能性が高まり、バグの増加に影響を及ぼす。

再利用性

結合度が高いと再利用する際にモジュール周辺のコードを改めて実装する必要があるため、再利用が難しくなる。 多くの場合はコピペをすることによってコードの重複が発生する原因となる。

結合度を下げるための取り組み

結合度を下げるためリファクタリングを中心とした取り組みが重要である。 常に意識しておくべき手法を以下にまとめる。

抽出

関数やクラスなどのモジュールとして抽出する。 特に関数の抽出は手軽にできる上に引数という形で外部との依存関係が可視化できるためリファクタリングの一歩目として取り組みやすい。

抽象化

抽象化によって詳細を隠蔽し、インターフェースと実装を切り離せる。 これにより実装を切り替えても呼び出し側の修正を不要にすることが可能となる。

テストコードを書く

結合度の高いモジュールは利用するために必要なコードが多いため、テストでもそれを再現する必要がありテストがしにくい。 テストが書きやすい設計を目指すことで、結合度が低いモジュールを作ることにつながる。

まとめ

• 結合度はモジュール間の依存性を表す
• 結合度が低い状態を疎結合という
• 結合度はソフトウェアの品質特性に影響を及ぼす
• 結合度を低くするにはリファクタリングが重要

Macでcmd+tab実行時のアプリ切り替え表示を全てのディスプレイで表示する方法

結論

以下のコマンドを実行してログインしなおす。

defaults write com.apple.dock appswitcher-all-displays -bool true

これで思ってたのと違う画面に切り替え表示が出力されているという現象を防ぐことができる。

参考

osx mavericks - Cmd+Tab App Switcher is on the wrong monitor - Super User

読書感想文『そろそろはじめるテスト駆動開発』

はじめに

Software Design 2022年3月号の特集『そろそろはじめるテスト駆動開発』を読んだので覚えておきたいなと思ったことをまとめます。

今回は自動テスト編です。

特集のおおまかな内容

著者は日本におけるテスト駆動開発の第一人者、和田卓人さん。「テスト書いてないとかお前それ@t_wadaの前でも同じこと言えんの？」というライオンのアスキーアートでお馴染み方です。

前半では自動テスト、テストファースト、テスト駆動開発がそれぞれどのようなもので、どのような違いがあるのかについて解説している。後半ではテスト駆動開発をするにはどのような手順踏めばよいのか、どのように考えると良いのかをJavaScriptの実際のコードをベース解説している。

今回はその中から自動テストについて書かれている部分について覚えておきたいと思ったことをまとめていきます。

自動テストとは

テストもコードで書いて、そのコードを実行することでテストの実施を自動で行っていく取り組みのこと

自動テストに必須の特性

自動テストで効果をあげるために必須となる性質

自己検証可能

テストの結果を人が見て判断しなくても成功か失敗かがわかること。つまりコードの実行結果が期待しているものかどうかの判断をコンピュータが行える状態。Pass/Failedをアサーションなどで判別して行うのが一般的。

繰り返し可能

テストがいつでもどの環境でも同じように動くこと。ローカル環境、開発環境、CI環境それぞれで同じように動き、テスト後の後処理なども人間が行う必要がない状態

必須ではないが強く推奨される特性

独立していること

テストを行う順番や並列実行による影響を受けないこと。どんな順番でどのタイミングに実行されても変わらない結果が得られる状態

高速であること

コードが自分の考えた通りに動いているかを判断するため、できる限り高速に動く必要がある。実行に時間がかかってしまうようだとテストが億劫になって実行頻度が下がり、コードが壊れたことに気付くのが遅れてしまう。

自動テストのメリット

根拠のある自信

開発しているシステムが想定通り動いていることで自信が生まれるようになります。これが根拠のある自信であり、著者が自動テストの最大の効果であると述べています。自動テストが整備されていれば既存のコードを壊してしまうかもしれないという心理的負担を感じずにリファクタリングを行うことができる。この安心感が継続的な変更と改善を支える。

デバッグを大幅に軽減できる

自動テストは既存のコードを壊してしまってもすぐに気づくことができる回帰テスト（リグレッションテスト）としての効果があります。バグの混入にいち早く気付けるようになることで、デバッグの時間を大幅に削減できます。

詳細なドキュメントになる

実際のソフトウェアと用意されたドキュメントに乖離しているという状態は誰しも経験があると思います。自動テストはもし乖離が起きてもテストが失敗することで乖離に気付くことができます。テストコードはよりコードに近い、詳細なドキュメントとしても活かすことができます。

自動テストの注意点

学習コストがかかる

過去のさまざまな事例からテストを書くコストはデバッグの時間の軽減などで相殺され、むしろ黒字になるのでテストを書き慣れているプログラマーはテストを書いたほうが早く開発を進められる。しかし、テストを描き慣れていないプログラマーはテストの書き方を学びながら開発を進める必要があるので、より時間がかかってしまう。

メンテナンスコストがかかる

自動テストは設計変更の影響を受けるため、テストコードの可読性や変更容易性も意識しないとメンテナンスコストが高くなってしまう。そのため、テストコードも定期的にリファクタリングを行なって適切な状態を保っていく必要がある。

品質保証としてはもの足りない

自動テストによって欠陥を減らし品質を高めることができるが、それによって品質が保証されているというわけではない。自動テストとは別に、コードレビューやペアプログラミングなど、品質を高める施策を行なっていく必要がある。

感想

自動テストのメリットは品質や開発効率という面にあると思っていたので、1番の利点が心理的なものであるというのは意外でした。言われてみると確かに自動テストがあることでリファクタリングを行うときにも、既存の機能にバグを生み出してしまうかもしれないといった恐怖感を低減できる。それによって品質や開発効率の向上という効果が生まれる、というのは納得ができます。メリットを活かすためにも、十分なカバー範囲を持ったテストを実装する必要がありますし、個人でなくチームレベルで自動テストの文化を作っていくためにも、今後は自動テストの手法について学んでいこうとおもいます。