Murga

個人的に言いたいコト・主張・気持ち。

「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

以前、「プログラマが知るべき97のこと」という書籍を読んだ。その内容は以下のウェブサイトでも全文読める。

今回は「ソフトウェアアーキテクトが知るべき97のこと」を、ウェブサイトで読んだ。

どうも書き写した際の誤字が多いのだが、注意して読めば分かるレベル。

個人的に参考になったところを引用する。他が参考にならなかったというワケではなく、これまでの自分の知識をベースに、僕にとって新しい発見があったかどうかで選んだ。

  • No. 2 : "付随的な複雑さ"
  • No. 4 : "長ったらしいWord文書などは書かないことです。Visioのようなツールで簡単な図を書いて、考えを伝えるのです。どうせ頻繁に書き換えることが最初から見えているのですから、図もシンプル・イズ・ベストです。" "長ったらしいWord文書よりも、まずはアイデアを浸透させることに力を入れてください。アーキテクチャーについての細かい決定事項を記録するなんてことは、後で考えればよいことです。"
  • No. 6 : "「契約交渉よりも共同作業」というアジャイルの精神に従えば、アプローチは見つかります。具体的には、顧客のニーズを聞くことを目的とするワークショップやミーティングを聞くのです。そこでは「なぜ」という問いに答えやすくなるよう、顧客を誘導しましょう。"
  • No. 7 : "アイデアは「売り込む」必要があり、そのためには効果的なコミュニケーションがなくてはならない" "複数の相手に自分の考えを説明するときには、いつでも立って話をしなさい"
  • No. 9 : "それは交渉だということに気付け" "私たちは3台目、4台目のサーバーなどいらないことはわかっています。これは、スポンサーを次の話題に進ませるための交渉術です。すでにあなたが危険で崖から落ちそうなギリギリところを、かろうじて走っているのだということを示して、交渉のハードルを引き上げているのです。もしこれで本当にサーバーを手に入れることができたら、3台目は本番システムと同じ環境でテストするために使い、残りはビルド用にすればいいのです。"
  • No. 12 : "「常識」というよりも「場の感覚」といったほうが正確だろう。つまり、特定の場で意味を持つ知恵ということである。"
  • No. 18 : "汎用性よりも単純性" "後から考えると、単純な解の方が実は汎用性が高かったということは、十分あり得ることです。たとえそうではなくて、必要だとわかったものに書き換えることになっても、単純なものを書き換える方が、汎用的だとは言い難い「一般的な」ものを書き換えるよりも簡単なはずです。" "汎用性がまるまる役に立つことはありません。普通は特定の状況があり、役に立つのはその状況を解決してくれるものです。"
  • No. 19 : "アーキテクトはビジネスと技術チームのインターフェイスです。" "アーキテクトは、飛行機の機長に似ています。いつも忙しく立ち働いているという感じには見えなくても、数十年の経験を活かして状況を絶えず監視し、異常に気付いたらすぐに行動を起こさなければなりません。プロジェクトマネージャー(副操縦士)は、日常的な管理を行う人です。ありふれた仕事や人員の管理のためにアーキテクトが忙殺されないように、アーキテクトを助けます。"
  • No. 40 : "優れたシステム仕様は、応答時間そのものだけでなく、作業時間も規定します。作業時間とは、特定の仕事を終わらせるまでに必要な時間のことで、人がシステムの操作のために使っている時間を含みます"
  • No. 43 : "何よりも大切なのは状況で、シンプルはそのために必要なものだということです。実際的な言葉で言えば、アーキテクチャー上の決定を下すときに、シンプルよりも優先すべきものは状況だけだということです。"
  • No. 47 : "長ったらしい1次元的な「プロセス」に機能をまとめればプログラムしやすく、多くのデベロッパーにはより「論理的」に見えるかもしれませんが、ユーザーはそのようなものではなく、同時に多くの機能にアクセスできるユーザーインターフェイスを好みます。ユーザーは、プログラムのフロー制御をコールスタックに任せるのではなく、自ら介入しようとするのです。" "古き良き予測可能なコールスタック・アーキテクチャーには、もうさよならしましょう。必要に応じてコンテキストを回復しながら、いつでもどんな順序でもイベントに応答できるようにするのです。" "想像以上に恐ろしい世界でしょうか?しかし、現実の世界は、ずっと前から同じ問題に取り組んできているのです。遅れた手紙、破られた約束、行き違いになったメッセージ、間違った口座への支払いなど、例を挙げればきりがありません。"
  • No. 52 : "理由を書き留めよ" "形式がどうであれ、ドキュメントは、「決定の内容は何か」、「なぜそのような決定をしたか」という基本的な問いに答えるものでなければなりません。副次的な問いですが、「他にどのようなソリューションを検討し、なぜ、選ばなかったか」、つまり「なぜ私の案ではいけないのか」についても、記述しなければならない場合がよくあります。ドキュメントは、検索可能にして、必要なときに簡単に見つかるようにすべきです。"
  • No. 53 : "暗黙の仮定は、すべての立ち往生の母だ" "仮定する(assume)のは、u(you)とmeをばかにする(ass)ことだ"
  • No. 56 : "ビジネスサイドの顧客たちが、提案されたシステムよりもメタファーを気に入ってしまうと、もっとも明るい解釈が共有されてしまって、現実の制約が見えなくなってしまう。" "開発チームが、実際のビジネス問題よりもメタファーの方が大切なように錯覚し出す。メタファーに振り回されておかしな判断をおかしいと思わないようになってくる"
  • No. 62 : "頭の中で考えたメリットや要件を組み込んだソリューションを正しいと考えたくなることはよくあります。しかし、覚えておきましょう。将来必要になることを推測しても、50%の確率で間違い、49%の確率で大きく間違うのです。" "今日のところは、今日の問題を解決しましょう。"
  • No. 66 : "解決策が1つしか思いつかないなら、何か問題がある"
  • No. 69 : "今の近道、後で大損"
  • No. 77 : "問題がかちっとしていると、解決されたときにはほとんど永遠に解決される"
  • No. 80 : "クレバーなソフトウェアは、高くつきメンテナンスしにくく、もろいものです。クレバーになってはいけません。できる限り愚直になり、しかも適切な設計を作ることです。適切な設計にはクレバーという印象は生まれません。クレバーな部分がどうしても必要に思えるのなら、問題の立て方が間違っています。愚直に取り組めるようになるまで、問題を立て直しましょう。"
  • No. 88 : "アーキテクトとデベロッパーは、すぐに問題解決モードに入るように教育されています。しかし、最良の解決は解決しないことだという場合があります。多くのソフトウェア問題は、一切解決しなくてよいのです。それらが問題のように見えるのは、ただ現象だけを見ているからです。"
  • No. 92 : "新しい言語を学べ"
  • No. 95 : "ソフトウェアのバグや実装し忘れた要件の多くは、暖昧で意味が漠然としている言葉に端を発しています。顧客、デベロッパー、アナリスト、ユーザーに、彼らが退屈して眠くなるくらい同じことを繰り返し質問しましょう。アリバイのほころびを探す検察官のように、質問のしかたを変えて、新しい事実、相違点、矛盾などを引っ張り出しましょう。繰り返しろ過するのです。"
  • No. 100 : "ビジネス要求もシステム要求も津然一体で暖昧模糊とした要求を「要求」、整理しおえたシステム要求を「要件」と呼ぶなんて、おかしな話です。わざわざ分かりにくい言葉で区別せず、もっと分かりやすく何に対する要求なのか言い表せばいいではないですか。こうした不思議な用語を作ることこそ、要求に対する取り組みを分かりにくくしている典型的な例ですね。"
  • No. 102 : "ソフトウェア開発の完全な自動化は目指すべきではありません。"
  • No. 103 : "ウェブから集めてきた情報を吸収し続ける毎日。でも、何か不安が残ります。最新の技術情報には精通しているはずなのに、圧縮アーカイバ、検索エンジン、3Dグラフィックスエンジン……、そんなかつて憧れた魅力的なソフトウェアを、いつになっても作れる気がしない。作れるようになったのは、スクリプト言語とデータベースを使ったウェブアプリケーション。それなら1時間もあれば思ったものは作れるのだが。" "なぜか。ウェブに溢れる情報は、そのほとんどが、手段的で陳腐化しやすい知識だからです。「こうしたらこうなる」なんてノウハウ的な知識ばかりが増えても、背景にある理論の理解を必要とするソフトウェアを作ることはできません。圧縮、検索、3Dグラフィックス、それぞれの実現にはしっかりとした理論体系があります。" "また、ノウハウは次々と新しいものが見出されますから、すぐに陳腐化してしまいます。次から次へと新しいことを覚えて、それがどんどん陳腐化していく。さながらゼロサムゲームの様相です。" "日々の開発のために手段を学び、躍進のために本質的な技術を、バランス良く学びましょう。前者はウェブや書籍で、後者は教科書や論文で。何だって、どちらにも偏らない中庸こそがベストです。"
  • No. 105 : "アーキテクトがデザインすべきなのはコミュニケーションです。システムはコミュニケーションを実現するための手段に過ぎません。" "書籍ユーザなんていない。いるのは、リーダーです。サーフボードユーザなんていない。いるのは、サーファーです。最終的なゴールは、「ユーザ」と呼ばれる存在のいない経験の総体をデザインすることだ。"
  • No. 107 : "一般的にいって、「受動的」アーキテクトはなるべくお客様から大きな注文をいただこうと高機能かつ高品質を指向し、「能動的」アーキテクトはなるべく最小限の投資から収益を上げようとシンプルかつアジャイルな開発を指向します。"

アーキテクトって仕事が未だによく分かっていないが、少しはイメージが付いてきた感じ。

ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと

  • 作者: 鈴木雄介,Richard Monson-Haefel,長尾高弘
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2009/10/05
  • メディア: 単行本(ソフトカバー)
  • 購入: 17人 クリック: 362回
  • この商品を含むブログ (82件) を見る

脳内垂れ流し

本当はもう書きたいことなんかなくなってきているのだけど、何かを書く。

書いたら気が済んだ

このブログでは、僕が仕事で不満に思ったことをベースに、「こうしたらいいのに」という希望を多く書いてきた。最近はそうした愚痴も湧かなくなってきた。周りが良くなったワケではなく、自分が諦められるようになってきたからだ。このブログで一度書いたら溜飲が下がって、「何で出来ないんだ!」という解決できない怒りから、「どうせ一生お前らは出来ないんだろうな、俺は出来るけど」という突き放した見方で処理できるようになる。

世間的に良いとされているモノ、有名な原理原則などはもう大概見尽くした。先人の知恵は活用しやすい形でまとまっていて、一見新しい話が出てきても、「コレも結局はあの原理原則に基づいた考え方ってことね」と理解できてしまう。そろそろ自分が新たに知る知恵というモノは少なくなってきて、あとはいかにこうした原理原則を現場で上手く適用していくか、といったところに終止する。

それ自体は、僕じゃなくても、同じ知識を持っている人なら出来ることだし、大抵は現場は良くならない。みんな正しさではなく、多数派に従うからだ。

だからもう最近は「どうしてこんなことになってるんだ…」などと考えないようにした。「いつもどおりメチャクチャだね」と流すことにした。

オリジナリティなんか要らない

僕は自分のやることに関してオリジナリティや個性を欠片も感じたことがなくて、「誰かが言ってたあの原則を適用しているだけ」「過去にどこかがやっていた手法を取り入れただけ」で、同じ知識があれば僕でなくても出来ることしかやってきていないと思う。オリジナルの開発言語でコーディングしているワケでもないし、技術的な知識に関しても、他の誰かと代替できる存在だと思う。

職業エンジニアとしてはそれで良いと思っていて、オンリーワンの尖った人材なんて扱いづらくて用途がないに等しいと思うから、逆に「僕らしさ」が出ていない成果になっている方が嬉しく感じる。

オリジナリティなんか出さなくていいと思っているけど、だったら何でこのブログで「俺はこうした方がいいと思う」とか言ってるんだ?その知識すらオリジナルの話ではないし、どこかで語られていた理想論だ。

技術ブログを書くのは簡単

なまじ「人間」という要素が入ってくるから、チーム開発とか、プロジェクトマネジメントみたいな話題は、「俺が思う理想」みたいな「個」が見え隠れする。自分としては「個」の主張を薄めたいのに、それを実現するための理想論を適用するために「俺はこう思う」とか言い出しちゃう。妙に矛盾を感じるし、人間という要素が入ると何をどうしても上手くいかないし、逆に何もしなくてもやっぱり上手くいかない。

それと比べて、技術ブログというのは、「知恵」や「自分で考えること」は、ほとんど要らない。既に存在する情報を仕入れてきて、一応自分でも試してみて、上手くいった方法をまとめるだけだ。

例えば、自分は最近になって ES2015 の Promise というモノを知り、それを記事にまとめたりしたが、その概念を自分が生み出したワケでもないし、自分が知るより前から Promise という記法は存在していて、それについて語られている文献も多くあった。Promise を使うとどういうことが出来る、とか、こういうことをしたい時にこう書いたら実現できる、というのは Promise の仕様書から読み取れるワケで、そういう意味で、自分が新たに作り出した概念や情報はない、と思っている。 しかしそれも、企業が運営するゲーム攻略サイトが出来たり、どんな情報も Wikipedia にあって、個人サイトで発信する必要性がないと感じ始めると、次第に熱が入らなくなってしまった。サイトを作って何になるんだ?と。

ありものをこねくりまわしているだけなので、技術ブログを書くこと自体は容易い。何ら新しいことをやっている気分にはならない。

プログラミング、エンジニアという職業に飽きた?

自分は飽き性だと思う。幼い頃はミニ四駆、ポケモンカードなんかにハマったが、「これ以上金や労力をつぎ込んでも勝てない相手がいる」と分かると冷めてしまったし、ゲームもある程度やり込むと「まぁこんなもんだろう」と分かった気になって、次第に飽きてしまうのだ。

ゲームに関しては、飽きるまでの寿命を伸ばすために、裏技や改造コードを駆使して、元々設計されていた「限界」を超えることで、自分なりに遊び方の幅を広げた。ネット対戦系に関しては、こうした裏技が使えないし、「自分には敵わないプレイヤーがいる」「それに対して努力して勝ちたいとまでは思わない」という理由で、全くやってこなかった。

小さい頃からウェブサイトを作っていたのは、なんとかゲームやアニメなんかに興味があって、パソコンで何かを作るのが楽しかったからだと思う。自分が知ったこと、作ったモノを発信する場として作っていたワケだ。

技術ブログに関しては、転職するために自分のスキルが低いと思っていたから始めたけど、この数年である程度のスキルレベルに達せたと思っていて、今後はコレまでほど「(自分にとって) 新しいこと」には出会わないんだろうなぁとか思ってきて、飽きだしている。

エンジニアという職業も、表面的な技術は様々あるが、結局は何かのデータを送受信して、現場都合に合わせてこねくり回して永続化するだけ。同じことの繰り返しで、チーム開発の効率は転職しても別に良くならない。技術的なスキルなんかどうでも良くて、人間的なスキル、ビジネススキルはどこもそう変わらないし、毎回同じようなことが問題になるんだなぁと思う。

30歳を前に色々と飽き始めちゃっていて、「えっこれから定年まであと30年はあるけど?」と自分でも驚いている。大体のことはやり尽くされていて、新しいことも変わったことも別にない。楽しくない。楽しいと感じられない。人生に飽きた?

よく分からなくなってきている

ミドルエイジ・クライシスにはまだ早いと思うが、なんかこう、テコ入れが必要そうだね。自分に対して。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

  • 作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2018/09/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る