マガジンのカバー画像

エンジニア小噺

395
本
しょっさんの書いたエンジニア向けのエッセイ集
運営しているクリエイター
しょっさん

#アーキテクチャ

システム構成図の書き方 #2 (配置編)

前回はシステム構成図を準備するための心構えというか、考慮しておくべき事項をまとめました。 今回は「配置」に関してです。システム構成図やネットワーク構成図を記す際、対象となるコンポーネントやモジュール、抽象化された機器などを配置して、相互の関係性を線を使って示すことが多いでしょう。 該当する「箱」とも言うべきコンポーネントの配置の仕方について考えてみましょう。

¥300
しょっさん

システム構成図の書き方 #1

ITアーキテクトが何者だろうかとか、ITアーキテクチャがなんなのかとか、今絶賛まとめている最中です。が、完成されたものを見るステークホルダーや開発者の人は「その構造化された構成図がキレイか、見やすいか、分かりやすいか」にしか興味がないことでしょう。きっと。 完成された美しいシステム構成図やネットワーク構成図などを見た時、それだけで良いシステムだと勘違いします。見た目の麗しさは人をごまかします。 だからといってと言うわけではなく、正しく伝わりやすいシステム構成図と言うものは

¥300
しょっさん

ITアーキテクチャとは何か(前振り)

ITアーキテクトは定義を重んじるんです。学者肌の人が多いのもありますが、まずそもそもエンジニア自体が定義を重んじるべきです。あやふやな単語を分からずに使っていると、お互いの認識に齟齬が発生して、何も伝わりません。 ITアーキテクトとしてスタートラインに立った時、まずはじめに言われたことは「言葉を正しく使うこと」でした。ええ。はい。わかります。おっしゃる通りです。 そんな正論はおいといて、実際には、現場はその実態とはかけ離れています。同じ言葉でも違う使い方をすることがありま

しょっさん

ITアーキテクトは何者か(5)

ITアーキテクトとしての役割は多くあります。果たすべき責任も負います。 その中でも重要な責任として「説明責任(Accountability)」があります。 ここでいう説明責任というのは、アーキテクチャを設計する上での「決定」から生じた結果に対して、その理由を明確にして説明する事です。 なのですが、この設計方針や設計を決定した理由が不明確なままになっているドキュメントが非常に多い。わたしが見せていただく設計書には「決定事項」と「パラメータ」しか記述がありません。設計方針の

¥500
しょっさん

今年こそ充実したプログラミング学習を

#今年学びたいこと と言えば。プログラミングです。 「しょっさんはITアーキテクトだろ」と言われたら、そこまでなんですけれど。今でもプログラム自体は書けますし、今でも嗜んでいるプログラミング言語は数多くあります。でも、そうじゃないんです。 わたしがプログラムを朝から晩まで書いていたころは、手続き型や構造型のプログラミングコードの書き方です。サブルーチンのないBASICや、特定の構造・モジュールをファイル単位で分割する程度のC言語、高速化だけのために分割されたアセンブラのラ

しょっさん

#JapanDreamin 交流のまとめ - Salesforce について何でもこたえるの巻

先日は写真の振り返りだけでしたけれども、今回は私が交流会でお話しした内容をまとめておきます。 わたしが参加したのは 14:25からの交流タイムです。 テーブルが並んでいて、そこにいる名物代表に質問をしながら交流を図るという時間だったようです。 なお、私のいた卓は私が代表として、Team Spirit の社長に見守られながら「Salesforce について何でもこたえる」というお題で交流させていただきました。「給料については答えないからね!!!」とだけ念押ししてはじめたのも

しょっさん

アーキテクチャに影響を及ぼす特性とパースペクティブ

最近のアーキテクチャ関係の書籍をあさっていると「アーキテクチャ特性」という言葉を見かけるようになりました。 この「アーキテクチャ特性」について調べてみた内容をまとめておきます。

¥100
しょっさん

ITアーキテクトとは何者か (1)

御大層に書いていますが、ITアーキテクトとは、一言で申し上げるなら ITアーキテクチャを造る人のコトです。では、その "ITアーキテクチャ" とは何か。実はこの「ITアーキテクチャ」は説明が難しいものです。定義自体はありますが、アーキテクチャの示す言葉の抽象度の高さ同様、あいまいさが漂い残っています。そこで、ITアーキテクトは何を目的に、なにを成し遂げるものなのかが分かれば、 ITアーキテクチャの理解が進むのではと考えています。 ITアーキテクトの目的を理解した上で「"IT

¥300
しょっさん

カオスなシステム整理を自動化する

ちょっとカオスなシステムを整理している時に、Google スライドで手いっぱいになってしまって、どうやって表現しようかと考え込んでいた時に、ふと "PlantUML" の事を思い出しました。 Excel のシステム情報一覧的な資料さえあれば、テキスト化された CSV を吐き出せますので、わいの力なら awk と grep だけで PlantUML の元ネタを自動生成できます。 結果、とても人間がつくれる限度を超えた資料を作成することができました。 ありがとう Plant

しょっさん

[読書メモ] 1からはじめるITアーキテクチャー構築入門 (1章)

ページ数の限定された雑誌の連載をまとめたものなので、具体的な内容や詳細があまり触れられていません。そのため、初学者には難しすぎる内容となっています。 とくにアーキテクト用語が急に定義されずに出てくることや、1つの用語が複数の用語の定義に含まれていたりと揺らぎが多いので、IBM でアーキテクチュラルシンキングを受講していない人には、理解が難しい内容です。 また、多くのドキュメントを示唆していますが、具体的な内容は記載がありません。Ex-IBM のアーキテクトにとってはおさら

¥300
しょっさん

例外を想定したアーキテクチャを考える

アーキテクチャは原理原則とガイドラインを含みますので、原則としてそのルールに従う必要があります。ただ、全てをガチガチに規則を作り、そこからはみ出ないようにしようとすると、どこかでほころびが出てきてしまうことがあります。かと言って、それに対処するように例外対応を行っていくと、もともとのアーキテクチャの思想から外れたシステムが完成します。 きれいなアーキテクチャに限って、それに乗っかることによって何かしらのデメリットが多いケースがあります。メジャーなWeb3層型を矯正するような

しょっさん

勝手に感じるITアーキテクトの２つのタイプ

ITアーキテクトって2つのタイプから成り立ってると感じる昨今。学究(学術)的と実質(実用)的の２つ。 そもそもITアーキテクトって何する人がと言われたら、「アーキテクチャを作る人」なんですが、「アーキテクチャ」が意味不明すぎます。 めでたいことに、これらは定義がなされています。IEEE1471では、アーキテクチャは仕組みだとして次の通り定めています。 私がもっているEnterprise Architectとしての資格である "TOGAF" にも、次のように定められていま

しょっさん

変えないエンジニアと、新しいものだけを使いたいエンジニア

雪が降ったり、雨だったり。急に寒くなりすぎた、東京、しょっさんです。 テクノロジースキルを高めるが故に、手段が目的になることは多々見られます。どのようなアプリケーションにするかどうか、まだ見極められていない状況下で、何故かシステム制約が決まっているようなケースです。OS や、使用するソフトウェア、ミドルウェア、フレームワークが決まっているようなケースです。このあたりは、企業やビジネスとして、全体のアーキテクチャの方針として、全体で最適化された結果であればいいでしょう。しかし

しょっさん

仕事で一番大切にしていること

仕事をする上で、とても大切にしていることは「Accountability」です。 日本語では「説明責任」と言われていて、個人的にはもにょんとするあれです。わたしがITアーキテクト(エンジニアもか)として伝えておきたい "Accountability" は、ある結果の事実に対して、なぜその決断をしたのか、なぜそのアクションを取ったのか、その正当性を証明できること。「責任」ってのが曖昧なのであれですけど、決断について責任をもつことと言われれば、まぁ理解できます。報告義務があると

しょっさん