エンジニア小噺

この夏にキーボードで遊ぶこと

この夏にやりたいと言うかマスターしたいもの、したいこと。キーボードを作れるだけ作る Dvorak / DvorakJP を使えるようにする最近、頭の中は「キーボード」のことでいっぱいです。TypeScript にもっと向き合わないといけないと思いつつも、Arduino を始めとする電子機器、ハードウェアに意識が向いています。キーボードの配列や、キーキャップ、キースイッチのことばかり寝る前に考え込んでしまって寝られない日々です。人生に心配がない感じもしますが、ふつ

エンジニアスキルに対するオブザーバビリティの重要性

ある程度の年齢や、職位となっているにも関わらず、話の通じないエンジニアが散見されます。ITのエンジニアとして押さえておくべき基本というものがあり、これらが欠如していると、会話になりません。同じ言葉を使っているにも関わらず、定義が異なっていたり、そもそも通じなかったり、個社特有の謎の言葉で煙に巻かれたりします。わたし的には、同世代であれば 80%程度は話が通じて欲しいと考えています。それは、自分の内面にこのような劣等感を持っていることによるのではと考えています。とは

目指すITアーキテクト像は「話せるエンジニア」

わたしが目指すITアーキテクト像は「話せるエンジニア」です。ITアーキテクトは言ってしまえば、お客様にとって都合の良いエンジニアそのものだと考えてます。以前にも、某CTOから有難い言葉を言われて、次のような記事を書いています。 ITアーキテクトにとって必要なスキルは広範です。コミュニケーションスキルテクニカルスキルアーキテクトスキルアーキテクトは、お客様の困りごとを正しく理解して、それを解決するためのソリューションを作り上げることが目的です。そのためのコミ

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

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

[ISP] オープンサーキットを2年弱使ってみて

オープンサーキットさんへ移行してから約2年が経過しました。2年間付き合ってみた結果をちょっとまとめます。移行した頃のお話は、こちらからどうぞ😘 さて、この2年使ってみての感想です。インターネット接続の品質に関して、事実と感覚でまとめてみます。回線速度この2年間、速度に関して低下したり、不足したと感じたことは一切ありませんでした。娘が膨大なゲームデータをダウンロードしたり、膨大なWindows Updateを繰り返しても、わたしには一切の影響がありませんでした。一人

もうすぐSalesforceで7年。Salesforceのしょっさんが板についてきたようです。

先日、大阪で初めてあったSEの方から「入社前にハッカソンで解説をしているしょっさんを初めて見て、わたしにとってのSalesforceの顔です」とありがたいことをおっしゃっていただいたしょっさんです。ここでいうハッカソンは、約1年前の一昨年、年末にSalesforceが初めて主催して開催したハッカソンです。わたしはここで、解説者として、リモートで観覧されている方向けに各チームの作ったアプリを解説するという大義を頂いてました。とは言っても、私に台本など言ったものはなく

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

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

「エンジニアのための図解思考再入門講座」を読んで、今すぐシステムを自分で作り上げろ

花粉症の薬だけではもたない世界線の日本、しょっさんです。コロナ騒ぎで、わたしの周りからはライブが一掃されてしまっていて、楽しみが失われた状況下にあります。ただ、それ以外は面倒な予定ごとが減ったり、なぜか仕事が忙しかったりで、思った以上に変化のない世の中だったりします。たまたまライブのない時期だと思えば、余計なことのない過ごしやすい日々だとも。さて、そんな連休の間の読書で、良い本があったので紹介です。 10年前の本です。9年前に購入しました。ある程度読んでいたのですが

note 有料記事の勘所がわからない

天気悪いと、せっかく良くなった調子も下降気味、しょっさんです。なんで書き出しに一言入れないとものが書けなくなったのか、理由が分かりません。教えて下さい。さて、note では有料記事が作れます。わたしも技術書展で出版した自分の担当部分を有料記事にしています。みんなが思っている以上に良記事なんで、200円払って読んでいただけると嬉しいです。ところで、この有料記事について使い所がわかってません。結局、誰かが買ってコピペしちゃったりできるじゃんとか、あまりみんなに見ら

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

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

老害のスタート地点

ようやく、ランニングできる程度の体調が良くなってきたしょっさんです、おめでとう自分。一時は尊敬してた先輩エンジニアも、今や老害、みたいなことってあると思うんです。わたしがどう思われてるかは、よー知らんので、そこは置いといて。それでも「あの人も年取ったな」というよりかは、なんかちがうように感じて、その違和感をよくよく考えてみたんです。もしかして「老害」って、ただ口が悪いだけなんじゃないかと。昔からよく考えたら、わいの先輩たちには口の悪い人が多かったのです。声がでかい

エンジニアが視点を変えるということ

日が変わりそうなタイミングになって、慌てて書き始めるしょっさんです、こんばんわ。インフラエンジニアだった頃とプラットフォームエンジニアの今ずーっとインフラのエンジニアをやってきていたので、オンプレと IaaS くらいしか考える脳を持ってなかった時代がしばらくありました。その当時からPaaSやSaaSも存在してましたけど、あの側にいると「楽だけどなんか違う」みたいな、ちょーカスタマイズ脳でした。細部まで構成を制御できない = 素人が触るのにちょうどいい。に近い考え方でもあり

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

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

話せるエンジニアになりたい

とある会社のCTOから「話せるエンジニアですね」と言われ、とても嬉しかったのでそのことを記しておきます。話のわかるエンジニアですねという文脈ではなく、対話やうまく説明のできる、という文意での「話せるエンジニア」というように言われました。本人としては、どの程度の気持ちでいったかまではわかりませんが、私自身としては最上の褒め言葉です。わたしの目指すエンジニア像は、エヴァンジェリストにずいぶんと近い立場です。ただ、特定固有のサービスを伝導することを目的としているのではなく、

フォローしませんか？