3月7日に表参道スパイラルホールで開催されたFigmaJapan社主催のイベント「スケーラブルなデザインシステム構築の実践」というイベントに縁があって参加してきました

https://designsystem102.splashthat.com/TW

デザインシステム。
フロントエンドの世界を主戦場としているわけではないのですが、言葉自体は把握していて、主には mozaic.fm というPodcastでよく話に上がっているので気になっていました。

デザインが特に意識されるのはToCの分野が多い認識でToBに関してはあまり必要性が認識されていない事が多い。
前職でもよくあったのが、画面にできるだけ情報を詰め込むような形。

結局これは、もともと使っていた画面や紙がそれだけの情報量を一目で見ることができ、それを用いた業務にユーザが最適化していることに起因していると思う。
画面を分割したりスクロールやタブが発生すると業務効率が落ちるというクレームが入る。

ただ、その流れは確実に変わってきていると思っていて、それは何よりもユーザがスマホやタブレット端末を日常使いするようになり、デザイン要素を取り込んだアプリケーションに慣れてきたという側面が強いのではないかと思っている。

そんなわけで、これからアプリケーション開発を行っていくうえでデザインシステムの構築みたいなものというのは、どういうシーンで必要で強みになり、どういうシーンでは逆に不要となるのだろうか？というのが自分の中での問いになった。

そんなモヤモヤしながらもしっかりと学習していない中でたまたまFigmaJapan社の方とメールする機会あり、本イベントを紹介いただいたのでホイホイと参加してみた。

こちらのイベントは後ほどYoutubeへ公開されるということなので、興味がある方はFigmaJapanさんの公式Xを追っていると出てくると思う。

実践編ということだけあって、登壇されたYahoo!社もHonda社も少し規模が違いすぎる感覚だった。
そもそも、自社プロダクトを持っているわけでもない立ち位置での話なので、デザインシステムの構築をお手伝いする立場？請負でそれを適用する？？
そもそもデザインシステムを作ったこともないのに？？

自分の立ち位置にツッコミどころ満載である。

うーん、面白そうで大事そうではあるけれど、やはりちゃんと理解して腹落ちするところから進めないとダメだろうな、、、ということでこちらのYoutubeを一旦見ておこう。
そのうえで公開されるであろう今回のイベントを見返してみたいと思う。

Obsidian の Self-hosted LiveSync をFly.ioで作ろうとしたものの、App作成スクリプトの使い方を誤っていたようで、作り直す必要が生じてしまった。

基本的にFly.ioはCLIからの操作になるのだが、削除自体はDashboardからできるようだった

ログインすると、登録されているAppが表示されている。
Obsidian用に1GBのDBが構築されているのがわかる

Appを選択して、左下の「Settings」を選択する

「Delete app」を選択すれば削除ができる。

アプリケーションの削除が設定ページにあるという発送に思いつかず、結構探し回ってしまった。

これで削除が完了して、余計なインスタンスを維持する必要もなくなって安心。安心。

Qiitaから定期的に好評記事の一覧がメールされてくるわけですが、パラパラっと見ていたら面白い記事が

ウォーターフォールの反省とアジャイルの成功に必要なもの #SIer – Qiita

わかる。

実際に私自身、前職では自社パッケージの開発を行っていて、現在は準委任や請負両方とも関わっていたりするので、言わんとしていることはよく分かる。
そして、携わっていた準委任で参画しているスクラムの案件がそれなりに終りを迎えつつあって、色々と思うところがあったので多少乱雑ではあるけれど書いてみた。
あくまで個人の感想ではあります。

請負で契約に縛られるのは誰なのか

記事では、「問題の原因は請負開発」とあって、そのインセンティブ構造だとかに対して触れられている。

ベンダー側の立場で利益を案件単位での利益を最大化するのであれば、当初契約締結時の仕様を最低限満たすものを、最小の労力で作り上げる事になる。
作りながら「この機能はこういうケースも対応できたほうがいいのでは？」ということに気づいても、当初見積もりからずれる行為であれば事前の要件として明記されていない限りは基本実施しない。
それは、怠慢とかそういうことではなくて、見積もりの前提が崩れ、その見積もりを下に作られているスケジュールからずれ、納期に影響を与える可能性がある。
言い方は悪いが「余計なものを作っていたら間に合いませんでした」って話になりかねないのだ。

残念なところはユーザー側の立場からも話が出ることはある。
RFPのような形で契約を進めていく場合、そのRFP記載内容からズレたことを行おうとした場合にはユーザー側でも承認プロセスを巻き直す必要がある事が多い。
きっちりかっちりした企業・プロジェクトであればなおのこと、「仕様書にかかれているかどうか」を担当者も判断基準にしている。

このあたり、システムに対して明るくない担当者であるケースも多いのでしょうがないところではある。
ユーザー企業側でシステム全てに詳しい人を割り当てることができるのか？とか考え始めると大変だなぁと思うわけです。

請負におけるベンダー側のインセンティブ

すべての開発者がそうだというような性善説を唱えるわけではないけれど、開発者は基本的に良いものを作りたいと考えていると思う（作れるかは別として）。
お蔵入りするためのものを開発なんてしたくないし、大きいシステムや影響の強いシステムを稼働させるのに臆病になることはあっても、やるからにはいいものを作りたい。

先に書いたように、営利企業である限り利益を生まなければならない以上限界はある。
ただ、最低限請負開発を回していると、要件的に問題がなければそれはいいのだが、ユーザ企業側に不満が残る最低限開発だとリピートされるかが怪しい

請負をする以上、案件を取ってくると言うことが必要になるうえで、顧客満足度を高めて、多少高くてもリピートされることをインセンティブにするという考え方になるのかなぁ、と思う。
サスティナブル的な感じだろうか。

内製か外注かの選択

記事でも書かれている、内製化の流れというのは何となく分かる。

一方で、書かれているようにエンジニアを抱える以上、それに付随した組織改革とエンジニアを（数とスキルの両面で）維持する必要が生じてくる。
ベンダーであれば、様々なプロジェクトを通して色々な経験ができる可能性はあるけれど、ユーザ企業の場合は必ずしもそういう環境を提供できる企業ばかりではないと思っている。
このあたりは、ユーザ企業含めて業界の構造がどうなっていくのかは楽しみだ
自社で内製化のために雇用した人材が維持できず、結局は会社対会社でその部分を担保しようとしているのが今だと思っている。

記事では要件が固まっている場合には内製で行うメリットがないとしているが、これに関しては違和感を感じる。

内製でするべきかどうかは、その作るシステムが自社にとって競争優位を生み出すものかどうかなのではないかな、と。
作り上げる時点で何を作るのかの要件が定まっていたとしても、今後、そのシステムを元に戦っていくのであれば自社で抑えておく必要はあるし、その部分を他社に任せてしまうのは良くない。

「要件が固まっている」が”今後変わることがない”という意味であれば別だけど、変わることのないシステムなんてあるのだろうか？と思ってしまうのはエンジニアサイドの視点なのかもしれない。

一方で、要件が固まっていて特に自社の競争優位に大きな影響を与えないシステムに関しては外注を・・・と思ったけれど、よほどのニッチな領域でない限り、パッケージ導入やAI、ローコードツールによる簡易的なものづくりを内製で・・・ってなっていくんだろう。

数年で取り巻く環境は目まぐるしく変わっていくので、身の振り方は常に考えておかないといけないところですね。

いつも楽しみにしているfukabori.fmが更新。
今回は来年二予定されているEMコンフに関しての紹介

122. EMConf JP 2025 w/ dora_e_m | fukabori.fm

ちなみに、11/14現在ではEM Conf JP 2025 のチケット購入は Coming Soon 状態
開催日は2/27ということでまだ結構時間がありますね
平日ということなので仕事を休めれば、行ってみたいところ。

EM。
難しい肩書だと思っています。

プロジェクト、ビジネスのマネジメントではなくエンジニアリングのマネジメントという位置づけ？
多分組織によってどこまでそれが許されるんだろうか？ということとか、そもそもジョブ定義として共通化なんてされていないんだろう。

そもそもの話として、そこまで多い人数のいない組織の場合、そのあたりの区別は曖昧で結局全てをマネジメントしないといけない状態になる認識でいる。
しっかりと役割として分担できるほどの人的にも金銭的にも余裕なんざないのである。

それでも学びは多いはずだし、そういう状態に持っていくことができればいいとは思うので、やさぐれていないで話を聞きに行きたいと思うところ。

スタッフの応募はすでに締め切られてしまっているのであくまで一参加者として。
楽しみであります

忙しいとしか言ってない気がするが、ここのところ忙しい。

忙しい中でもランニングだけは欠かすまいとしているので、必然的に疲れてしまったりなんだりで気が乗らず、自己研鑽として掲げているAWSの勉強がすっかり止まってしまっている。

うーん、SAA資格の有効期限。切れちゃうな。

とはいえ、このままではいけないのでなんとか切り替えなければ、と外部の情報を物色し始めました

Github Universe

GitHub Universe 2024

Githubが主催しているカンファレンスでVirtualであればFreeで参加することができます。
今年はやっぱりAI関連ですかね。

Universe 2024 – Curated Agenda (rainfocus.com)

Githubのカンファレンスは参加したことがありませんでしたが、もしかしたらコードも付いてくるかも？と思うと、テック系としては良い学びになりそうな予感がします。

来週からなので、楽しみです

5-Day Generative AI Intensive

Home (rsvp.withgoogle.com)

Googleが主催しているAI開発向けの5日間のコース。
5日間と言っても、1日あたりは2~3時間を想定しているそうな。

こちらも無料で受講が可能なので、レベル感はちょっとわからないですけれど申し込むだけ申し込んでみようかな？と。

ここのところ怠け気味なので、なんとか奮い立たせてやっていきたいところです

久しぶりにVBAをせこせこと書いているわけですが、関数の概略とかそういうのを全部自力で書くというのは骨の折れるもので、なんとなくの内容をClaudeに教えて関数を作ってもらいます。

当然、そのままでは動くわけもないのでエラーをつぶしていくわけですが、ぱっと見で何が誤っているのかがよくわからないエラーにぶつかりました

Dim tableNames(5)
For i = 1 to 5
    If i > 2 And tableNames(i) <> tableNames(i - 1) Then

ちょっと内容は端折りますが、2つの条件式があった場合に、一般的なプログラミング言語であれば一つ目の条件式評価の結果、以降の条件式を評価する必要がない場合はそもそも評価が実行されないのですよね。

これによって、Nullチェックや配列のインデックス範囲外アクセスを防いだりします。
ところがVBAでは、すべての条件式が評価されるようです。

初めて知りました。。。

何というか、やっぱりVBAは独特だなぁ。。。と