これからの時代、こんな話が、もっと増えていくような気がします。

AI で、だいたい作れてしまう

データを集めて、加工して、グラフにする。この一連の処理は、以前なら専門の知識が要りました。でも今は、AI に聞きながら書けば、それらしいものが動いてしまいます。知識が無くても、そこそこのデータ処理が組める。いい時代です。

ただ、ここに落とし穴があります。「作れる」と「続けられる」は、まったく別の話だからです。

日曜大工の家は、なぜ雨漏りするのか

AI に手伝ってもらって作ったデータ処理は、たいてい日曜大工的になります。とりあえず今の要件では動く。でも、次のような課題が付きまとうことになります。

• どういう順序で組み立てたのか、本人しかわからない
• 元データの形が少し変わると、静かに壊れる
• 直そうにも、どこをいじれば何が起きるか読めない

こうして、半年後には「触れない仕組み」ができあがります。作った本人が異動すれば、もう誰も直せない。結局 Excel の手集計に戻る、というのはありがちな光景です。

家に例えるなら、日曜大工で建てた小屋のようなものです。建てるだけなら建つ。でも、雨風に何年も耐える構造にするには、やっぱり基礎と設計の知識が要る。データ基盤も同じです。

「作る」より「続ける」が難しい

データ基盤の本質は、実は作ることではなく、続けることにあります。

数字は、集めただけでは使えません。生のデータを、順序立てて整え、積み上げていく。この土台をきちんと組めているかどうかで、後の運用が天と地ほど変わります。土台が雑だと、少しの変化で崩れ、更新が止まり、いつのまにか誰も見なくなる。

そして厄介なことに、この「土台をきちんと組む」部分こそ、いちばん専門知識が要るところなのです。AI で省けるのは、むしろ表面の作業のほう。基礎工事は、そう簡単には省けません。

道具の問題ではなく、人の問題

ここまで書くと、「じゃあ、いい BI ツールを入れればいい?」と思うかもしれません。でも、たぶん違います。

高機能なツールを入れても、それを使いこなして土台を整え、壊れたら直し、要望に応えて育てていく。その作り手がいなければ、結局また止まります。専任のデータ分析チームを何人も抱えられる会社なら話は別ですが、多くの会社にとって、それは現実的な選択ではありません。

つまりこれは、道具の問題というより、人の問題です。小さくてもいいから、続けられる作り手がそばにいること。そこが効きます。

そんな問題意識から作りました

この「作り手をどう用意するか」という問いに、自分たちなりに答えを出したのが、今回リリースした BI SaaS「Nugget BI」です。

ツールを渡して終わり、ではありません。データを整える土台づくりから、グラフの作り込み、その後の手入れまで、運営チームが引き受けます。いわば、小さな専属のデータ分析チームを、月額で持てるサービスです。もちろん、慣れた方がご自分で作り込むこともできます。

日曜大工で崩れる前に。あるいは、崩れてしまった後からでも。データ活用の土台づくりで困っている方は、気軽にご相談ください。

Nugget BI について詳しくは、こちらから、お問合せください。

The post AI で「動くデータ基盤」は作れる時代。それでも壊れるのは、なぜか first appeared on 株式会社Altus-Five.

1. 情報・認識のズレ
   • 前提や論点が揃わないまま進むことで、手戻りや炎上が起きる
     • グループ相互作用分析（R.F. Bales）（社会心理学）
     • Group Interaction / Group Communication 研究（社会心理学・組織行動論）
2. 依存関係の未管理
   • 誰が誰を待っているかが見えず、ボトルネックが発生する
     • Coordination Theory（Malone & Crowston）（情報システム研究・組織理論）
     • チーム・ダイナミックス研究（社会心理学・組織行動論）
3. 不確実性の前での行動停止
   • 分からない状態で初動が取れず、学習や前進が止まる
     • 成人学習理論・学習する組織（P.センゲ ほか）（教育学・教育心理学・組織開発）

チームリーダーは、この3点が起きていないかをチェックしてあげるとよいかと。

参考書籍
・The Cambridge Handbook of Group Interaction Analysis
・Group Communication（Routledge）
・The Emerald Handbook of Group and Team Communication
・『グループ・ダイナミックス』（釘原直樹）
・『チーム・ダイナミックスの行動科学』（山口裕幸 編）
・『学習する組織』（ピーター・センゲ）

これは、評価制度について、AI と壁打ちして勉強されてもらいました。たった3点で網羅(※)されるんだ！と驚きました。それ以上に、私ごときは、参考書籍にある本を読むことはないし、異なる学術分野の知識を組み合わせるのも並はずた知能レベルだから、私だったら、この答えにはたどり着けない。
これぞ、AIならではの使い方だな・・・と思いました。

※ 完全な網羅ではなく、「初期フェーズで破綻を見逃さないための最小集合」という位置づけらしいが。

The post 仕事・学習が破綻する「最小セット」 first appeared on 株式会社Altus-Five.

また、同じく Anthropic 関連で、NewsPicks の動画で言っていたことを掻い摘んで紹介します。
コーディングのAIエージェント分野では、Claude Code が相変わらず評価が高いということで、Claude の AI モデルがコーディング方面では特に優れているというのもあるだろうけど、この CLI も高度なのだろうと思います。
そして、とうとう Claude Code を作った開発者本人は、自分ではコードを書かなくなったそうです。
この流れは、システム開発の全般で、じわじわと波及していくと思いますが、コードは AI が書くようになるから、どのように AI を動かすか、オーケストレーションとマネジメントが、人の役割として求められるようになると言ってます。

私の解釈も含めて、もう少し説明を加えると、オーケストレーションとは、例えば、AI を並列化してコードを書いた方が効率がよいわけで、それをぶつからないように配置することや、どの分野をどの AI で書かせるか采配すること、AI 間の統制をどう図るのかを設計すること、AI の出力をどのように統合していくか、などのことです。
マネジメントは、例えば、AIがダウンしてコードが作られなくなったら、それに依存する AI タスクに迂回指示するとか、難易度の高い機能部分がボトルネックになって全体の進捗が芳しくないときに、どのようにテコ入れするか指示することなどです。
今の SI の中でのマネジメントと、ここでいうマネジメントは、少し違うので、そのうち、新しい役職名で呼ばれるようになると思います。
おそらく、AIでのシステム開発方法論のようなものも、誰かが体系化し始めると思います。それもAIで書いちゃうのかな。

Anthropic では、すでに、その未来像に向かって進んでいて、この役割は、1つのことに深い知識を持つスペシャリストよりも、広い知識を持つジェネラリストが適しているので、新規の採用のすべてをジェネラリストの採用に振り切ってるそうです。

ジェネラリストとは何か？AIと壁打ちしてみました。

• オーケストレーション力
  • AIという『最強の武器』を与えられたとき、一人で何人分の役割を演じようとするだろうか？
    • 1人分の作業を楽にするために使う人（→ オペレーター止まり）
    • 1人で企画から開発、マーケまでやろうとする人（→ これこそがジェネラリスト）
• 独学の「型」と「執着心」
  • AI時代、知識の賞味期限は極端に短くなります。学校で習ったことではなく、「未知のものを自力でどう攻略したか」というプロセスが重要になります。
  • 知識の深さよりも、「学習の高速道路を自分で作る力」が大事。
• 「越境」への抵抗感のなさ
  • ジェネラリストは、「自分はエンジニアだからデザインは関係ない」とは言いません。AIという万能な助手がいるからこそ、領域をまたぐことを「楽しい」と思えることが重要です。
  • 「多趣味」や「飽き性だけど色々手を出している」は、この時代、ポジティブです。
• 言語化能力と構造化思考
  • プロンプトエンジニアリングが示す通り、AIを使いこなすには「頭の中のイメージを正確に言葉にする力」が必要です。これは、「論理的に物事を分解する力」と言い換えられます。
  • 「結論から話す」以上の「概念を噛み砕く力」が大事。
• AIを「体の一部」にしているか
  • 「AIが流行っているから使う」のではなく、息を吸うようにAIを道具として使い倒している「AIネイティブ」な感覚を持っているかです。
  • AIとの対話のログ（試行錯誤の跡）を誇らしげに語れる人は、まさにジェネラリスト候補です。

当面は、レビューをするのが人の役目と言われていたけど、オーケストレーションとマネジメントが、エンジニアの仕事になって、ジェネラリストの方が活躍できるという未来像、なんだかシックリきます。

The post AI時代はジェネラリストの時代 first appeared on 株式会社Altus-Five.

GraphQL Federation によって、マイクロサービスをより細かい単位で構成することができます。
サービスを小さくできるということは、多様なシステムに組み込みやすくなります。
小さいということは、ロジックも、複雑にならずに済みます。
複雑じゃないということは、バグも少なくなるし、開発効率も高くできます。
良いこと尽くめだけど、性能についてはやや気になります。

ここまでは、サーバーサイドの話です。

フロントエンドは、どうなるかというと、通常は、1つのアプリとして実装されます。
SPAとして構築する場合は、React や Vue、Angularの1種類を選択して開発することになります。
サーバーサイドのようにマイクロに分割するのが難しいです。
難しいというか、webpack などで、1つにパッケージングしてリリースするのが一般的で、静的に統合buildするというのが定石となっています。
1つのモジュールを小さくできたときのメリットは、上記のサーバーサイドのそれと同じなので、なんとかしたいものです。

そんな悩みを解決してくれそうなのが、マイクロフロントエンド です。

フロントエンドも、マイクロに分割独立させようというものです。
webpack などがそれを実現するモジュールフェデレーションという機能を提供していて、主要ブラウザもサポートしているので、安心して舵を取ることができます。

面白いのは、React、Vue、Angularが混在して使えるという点です。
例えば、ユーザー管理マイクロサービスと対になる形でユーザー管理フロントエンドをReactで開発していて、リソース管理も対になる形でフロントエンドをVueで開発して、それを1つの画面にガッチャンコできるということ。
まぁ、大規模な開発で複数チームが混在する場合はあるだろうけど、小中規模では、あまりそこまで極端な開発をすることはないとは思います。

モジュールフェデレーションでは、ホスト側とリモート側という表現をしますが、ホストはブラウザが最初に読み込むメインの画面のことで、リモートは、include されるマイクロ化されたフロントモジュールです。
include と言ってるのは、静的にパッケージするのではなく、動的 include です。内部的には、 `<script src=”https://micro.example.com/user-service/v1.0/bundle.js“></script>` このようなコードが動的に生成されるみたいです。

ホスト側では、リモートのモジュールで発生したイベントをフックすることができるので、インターセプターのようなことができます。つまり、マイクロフロントエンドも、プラグインによる機能への介入ができるということになります。再利用性と拡張性が高くなります。

設計パターンとしては、マイクロサービスとマイクロフロントエンドとが必ずしも対になるわけではなく、おそらく、マイクロ化するモジュール単位は、サーバーサイドとフロントエンドでは異なると思います。それをうまく統合するのが、 GraphQL Federation ですが、このインターフェース設計は、とても重要で要になるのだろうと思います。

サーバーサイドもフロントエンドも小さく小さく開発できそうなことが、見えてきました。
システム構成をうまく考えると、ちょっとしたプラットフォームにもなりそうです。

The post マイクロフロントエンド first appeared on 株式会社Altus-Five.

マイクロサービスでAPIが供給されているとして、異なるマイクロサービスが複数あるときに、まるでテーブル結合するかのように、マージしてくれるもの。
クエリーだけじゃなくて、更新系もうまいこと、処理してくれる。

主要なプロダクト

Apollo Federation と WunderGraph Cosmo、GraphQL Fusion などがある。
Apollo が GraphQL Federation のデファクトスタンダートで一番導入実績があり、WunderGraph Cosmoは、最近の導入実績が急激に増えているものらしい。
Apolloは、有料版じゃないと使えない機能があったりするが、Cosmoは、全機能が利用可能で、且つ、Apolloと互換性のあるI/F仕様になっているという安心感が、その理由のようだ。
さらに、Cosmo は AWS Lambda 用に最適化されたコンポーネントがありサーバーレス化が可能なので、小規模なサービスには、持ってこいである。

マイクロサービスアーキテクチャとの親和性

マイクロサービスでは、サービスを超えてDBを共有することはせずに、専用のDBで設計する。
会員管理はRDBを使い、予約管理は DynamoDBを使うということも可能になる。

GraphQL Federation を使って、複数サービスをマージするとして、1つ1つのマイクロサービスは、小さくてシンプルなので、開発しやすい。
その一方で、フロンエンドの実装は、やや、面倒そうではある。

自社プロジェクトでの検証

自社プロダクトである「貸会議室予約管理システム」は、当初は、モノリシックに構築しようと思ったが、マイクロサービス化を推し進めることにした。
懸念されることは、マイクロサービスとして切り出したり、マイクロサービス間の整合性に頭を使わないといけないので、生産性が低下しそうなこと。
だが、それ以上に、マイクロサービスでシステムを構成することのノウハウは、AI時代だからこそ財産になると思うので、学びを優先することにした。

貸会議室の予約管理システムをマイクロサービスにすると、ユーザー管理、会員管理、リソース管理、予約管理、各種通知、・・・、単純に考えても、これだけのマイクロサービスが切り出せる。
これは、再利用できるアセットのバリエーションが増えるということでもある。
モノリシックに作り込んでしまうと、「貸会議室予約管理システム」がたった1つのアセットなので、例えば、「営業支援システム」のような開発をするときにも、「貸会議室予約管理システム」からユーザー管理機能だけを抜き出すのが面倒で、またもや「営業支援システム」用のユーザー管理機能を作り込んでしまう。ほとんど同じなのに。
それが、マイクロサービスになっていると、ユーザー管理マイクロサービスがDockerコンテナで動く状態なので、ユーザー管理機能を新たに作るという動機は起こらず、そのまま再利用する流れになる。

システムを細かくマイクロサービスで設計するときの切り札となるのが、複数サービスの Federation なので、まずは、WunderGraph Cosmo で開発を進めながら、同時に検証してみようと思う。最終的に、やっぱり Apollo に落ち着いたということになるかもしれないが。

The post GraphQL Federation とマイクロサービス first appeared on 株式会社Altus-Five.

そもそも、DB探しをしたのは、なぜかというと、エクセルで進捗管理していて、バーンダウンチャートをグラフ表示するために、数式を山ほど仕込んで、数式の意味が、どんどんわからなっていって、メンテナンス不能になったというのが、キッカケです。
いっそ、DBで管理して、エクセルからは、データソースとして DB を検索集計して、グラフ化したらよいんじゃないかと考えて、でも、DB をインストールするサーバーがないので、何かよい方法はないだろうかと、WEBを検索したのでした。

SQLite

いまさらですが、誰もが知ってる SQLite です。
ただ、これだと、チーム内の全員で共有するには、どうしたらよいんだろう・・・と、さらに検索してみると、「Lambda + EFS で SQLite をストレージに使う」という記事をよく見かけました。
そもそも、AWS使えないので却下なのだけど、この構成だと、同時アクセスがあったときに、ファイルオープンが競合して、エラーになりそうだよね。マネしない方がよいなと、読み飛ばしました。

同じく、ファイルサーバーで共有するのも、ダメなのは、言うまでもありません。

rqlite

SQLite をクラスター化してくれるツール
https://github.com/rqlite

チーム内の全員が SQLite をインストールして、rqlite でクラスター化すると同期されるから、良いんじゃないかと思ったのだけど、リーダーノード（マスターノード）を決めて、それに対して、SQLを投げないといけないので、リーダーノードのPCが起動してないと使えないという、風邪引いてもPCだけは起動しなくてはいけない不自由さで、不採用としました。

PostgreSQL

人気 NO.1 DB は、MySQLかと思いきや、今は、PostgreSQL  が一番人気なんですね。
https://www.sbbit.jp/article/cont1/155196

さらに、psql は mysql よりも、いろいろ高機能化してることを、知りました。

• 全文検索の機能がある
  • これはmysqlにもあるが。
• マテリアライズドビュー
  • ずっと何年も前から実装されてたのね、MySQLにこの機能があったらいいのに・・・と思ったことが何度あったことか。
• ベクトルDB
  • LLMには欠かせない

psql だけでも、さまざまなシステムの構築ができそうですね。

今回の用途には、使えないのは、rqlite と同じく、常に起動してないといけないからです。

見つけたら教えてください

他にも OrbitDB や、YugabyteDB なども調べてみましたが、用途には合わず、この日は、結局、最適なものを見つけられずに、終わりました。

p2pで動いてSQLが使える軽いDBがあったら、ぜひ、教えてください。

The post ちかごろの DB アレコレ first appeared on 株式会社Altus-Five.

ガリレオは 新宿三丁目駅C4出口直結、徒歩0分 という抜群のアクセスが魅力です。
雨の日でも濡れずにお越しいただけます。

会議室は30名収容可能で、リノベーションされたばかりのビル内にあり、とても清潔で快適な空間です。天井はコンクリート打ちっぱなしのデザインで、シンプルながらもスタイリッシュな雰囲気を演出しています。

さらに、プロジェクターやWi-Fiをはじめ、会議やセミナーに必要な設備を完備。大切な打ち合わせや研修、勉強会など、さまざまな用途にご利用いただけます。

当社はこれまでシステム開発を中心に事業を展開してきましたが、新たな挑戦として貸会議室事業に踏み出しました。ガリレオを通じて、地域の皆さまや企業活動に貢献できる場を提供してまいります。

新宿での会議やイベントには、ぜひ「ガリレオ」をご活用ください。

ご利用方法は、以下で紹介しています。

The post 貸会議室「ガリレオ」オープンのお知らせ first appeared on 株式会社Altus-Five.

ラウンドロビン設計は、3人以上がいる開発で、何かを設計するときに、いったん、全員が各々でラフスケッチをするところから始めて、スケッチを隣の人に回して1回転させて、自分の案との違いを確認し、そこに追加で自分のアイデアを書き加えて、さらに、1回転させて・・・・といくことを繰り返す設計手法です。

自分のアイデアと他の人のアイデアが組み合わさって、1人では考えつかなった設計に変化していって、短時間で洗練させられるようです。
原典なのかは不明だけと、「Design It! ―プログラマーのためのアーキテクティング入門」の第9章”アーキテクチャデザインスタジオを開く”で紹介されています。
この本によると、ワークショップ形式で全員で取り組んで90分で完成させると書かれてます。時間制限を設けることも大事なようです。
90分で終わるなら、普段の開発の中でも、取り入れてもいいかな。
設計レビューも不要だし、チーム内に新人の人が居ると教育にもなるし、良さそうです。
ただ、アイデアが発散したときに収束させるのが厄介かもしれないけど。

ラウンドロビンレビューは、レビューを複数名で、役割分担するのだけど、例えば以下のような役割で分担するとします。

• 仕様面が正しく実装されているかをレビューする役割
• テスタビリティをチェックする役割
• メンテナンス性をチェックする役割
• SOLID原則などの実装合理性や実装デザイン性をチェックする役割

役割をさらに、細かくして、1人複数の役割を分担してもよいと思います。
仕様面のチェックは、DB観点と画面観点で分けても良いし、SOLID原則は、それこそ、S/O/L/I/Dで分けても良いという具合に。
これのよいところは、大きいプルリク全体をマルっとレビューするときの気持ち的な負担が軽くなるように思います。
ただし、レビュー指摘が錯綜する可能性がありそうなので、それは、デメリットの1つかもしれないです。
本来、このラウンドロビンレビューは、役割を強制的に割り当てるので、メンバーのレベルが同程度のときに有効とされるのだけど、レベルが違う人が入っても、2～3回転させるルールにすると、弱いパートが補完されるし、教育観点が加わるので、それアリかもと思いました。
こちらは、WEBで記事を漁っていて見つけたものです。

アイデア出しのフレームワークにブレインライティングというのがありますが、ぐるぐる回すというところが、ちょっと似てるなと思いました。
ブレインライティングもやってみると、ちょっと面白いので、アイデアを量産しないといけない場面があったら、WEBでやり方を検索してみてください。

モブプロもラウンドロビンだし、他にも普段の仕事の中で、”ラウンドロビン○○” してみると良いかもです。

腕を胸の前で糸巻きするように回しながら、「ぐるぐる戦法」と言ってみるのも良いと思います。

The post ぐるぐる戦法 first appeared on 株式会社Altus-Five.

チームのメンバー構成とメンバーのスキルレベルによって、アウトプットできる成果物の量は異なります。 ベテラン1人とキャリア1年目、キャリア3年目の人のチームが目指すべき生産性を、定量的な絶対値で目標設定する場合、 ベテラン3人構成でのアウトプット量を “そうあるべきライン” として目指さないといけないのだろうか？ でも、その目標をクリアできるのは、キャリアの浅い人の成長を待つことになるので、何年か掛かります。 チーム構成は時と場合によって、さまざまなので、絶対的な指標は、あまり機能しないことは、想像に易いと思います。 そもそも絶対値の求め方というか計算式をどうするのかも難解です。

そこで、相対的なベロシティの方が有効となるわけです。 ベテラン1人とキャリア1年目、キャリア3年目で、現在のベロシティは 35 ポイントと出ているなら、 それを維持するか、少し上回るように、目標設定すると、達成感も得られるようになります。

気を付けないといけないのは、ストーリーポイントの見積でのブレでしょうか。 ついつい甘い見積になってしまう傾向のあるチームでも、常に甘い見積を出している場合には、相対的なベロシティは指標となり得ます。 しかし、甘かったり、辛かったりと、毎回見積がブレる場合には、ベロシティもブレるので、見積精度の観測も同時にやった方がよいのだろうと思います。

さて、ベロシティというとスクラムじゃないと使えないと思ってる人はいないだろうか？ 実は、私は、そう思ってました。 でも、どうやら、スクラムじゃなくても、ストーリーポイントでの見積とベロシティで生産性を計測できるようです。 イテレーションで期間を区切ってない開発の場合、計測時点で、タスクが完了していないこともあります。 その場合には、ストーリーポイントを、ベロシティ計測時点の進捗率で、換算します。 タスクA のストーリーポイントが 8 ポイントだとして、計測期間終了時の進捗率が 50% だとしたら、4ポイントのタスクに取り組んだことにして、 ベロシティを計算するということです。

スクラム以外でも、ベロシティを生産性指標に活用にしてみてはいかがでしょうか？

※今回の記事には、こちらの記事を参考にしました。 → アジャイル開発でストーリーポイントを見積もる手順

The post アジャイル開発（アジャイル風も含む）での生産性の計測 first appeared on 株式会社Altus-Five.

9時に起床して10時に仕事を始めると、12時には、ゴールデンタイムが終わるってことか、なんだか、もったいない。 10時に起床して即仕事を始めたら、ゴールデンタイムの1時間を昼休みで消費してしまってることになる。

どっちにしても、だいたいの人は、午前中いっぱいはゴールデンタイムなのだと思うけど、その時間に朝会とかをやってるのは、どうなんだろう？ 朝会じゃなくて夕会をやる方がいいのかもしれない。

脳の回復に関することを少し、紹介します。

• パワーナップ昼寝ですね。20分くらいの仮眠をとると、そのあとの効率がずいぶんと回復するようだ。 実際、昼寝すると、頭がスッキリした気になるので、効果はあるのだろう。
• マイクロナップ1分間、目をつぶる。 脳が処理してる情報の8割が視覚によるもので、それを遮ることで、脳は、ずいぶんと休憩できるのだそうだ。 会議に入る直前の1分間でマイクロナップすると、会議中の居眠りを予防できるとあった。

時間管理術を、少し紹介します。

• ポモドーロテクニック25分集中して、5分休憩するのを繰り返すのだけど、ポモドーロテクニックでも、休憩の5分は、寝るのが一番よいとあった。
• フロータイムテクニックポモドーロをアレンジしたもので、25分と5分という刻みを自分にあった時間でやるというもの。
  自分のちょうどよい時間を見つけるために、実際に作業を始めて集中できなくなるまでの時間と、休憩して再びやる気が戻って再開するまでの時間を記録して、自分のちょうどよい時間を把握するというやり方。

私は、6時頃に起きてるので、9時頃になるとゴールデンタイムが終わるってことか、確かにこの3時間は、集中できてる気がする。 そして、10時になると、いくつかのプロジェクトの朝会をハシゴして午前中が終わるのだけど、あぁ、もう10時かと、寂しさが過るのは、ゴールデンタイムが終わったからなのかもしれない。 会議や雑多なことに追われると、仕事が手につかなくなることがあるが、あれも、脳が疲れて機能しなくなった状態か。

パワーナップとマイクロナップを試してみようと思います。

みなさんも、脳の疲れを回復させながら効率よく仕事していきましょう！

The post 朝の3時間は脳のゴールデンタイム first appeared on 株式会社Altus-Five.