IBM BobでWebアプリを作成してみた

前提

昨年の年末あたりにIBM Bobを使えるようになったので、実際に使ってみました。
本記事は、使ってみた体験談的な内容となっております。

Webアプリの開発をしてみましたが、本人はきちんとした開発経験がありません。
そのため、実際に開発されている方が見るとつっこみたくなる内容もあるかと思います。

基本的にBobに依頼だけ丸投げして中身は殆ど確認していませんので、実際の利用とは乖離がある部分もあります。

アプリ作成のきっかけ

ざっくり言うとサーバーを管理するアプリを作りました。

検証環境としてPowerサーバーがあるのですが、使えるツールを色々駆使して利用予約の管理をしていました。
Excelやらプロジェクト管理ツールなど色々なものを組み合わせて管理していました。
それぞれの場所やツールに情報が散らばっていたり、そもそもツールが見づらかったりと不満に思いつつも仕方なく使っている状態でした。

IBM Bobを使えるようになったということで、サーバー利用管理に使えそうなWebアプリを作ってみようと始めたわけです。

実装テクノロジーについて

最終的に以下のような技術スタックで実装しています。
デプロイ先のサーバーが少し古いもののため、OSやイメージのバージョンに古いものも含まれております。
アプリとDBはすべてコンテナ上で動かすようにしています。

フロントエンド

• React 18
• TypeScript

バックエンド

• Node.js - ランタイム
• Express - Webフレームワーク
• TypeScript - 型安全性
• PostgreSQL - データベース

デプロイメント

• コンテナ: Podman
• OS: RHEL 10.0 (ppc64le)
• ベースイメージ: Red Hat Universal Base Image (UBI8)
• PostgreSQL: v13 (コンテナ)
• Node.js: v18.x (コンテナ)

実際にできたもの

ここでは、簡単に見た目だけ紹介させていただきます。
ダッシュボードがあったり、予約管理するページ、ラック図まで表示できるページも作っています。

※ あくまでも一部の人間で使うdedicateな場所でのツールなので、色々好き勝手実装してみています。

UIは、IBMが出している Carbon Design System を使っています。
実際には、carbon-mcpを使ってBobが勝手に Carbon Design System に沿った実装をしてくれたという感じです。

このMCPを使うことで見た目の統一感が出て、それっぽいアプリになっていると思われます。
BobのMCP設定で使用するMCPをオンにしておくことで、毎回実装のタイミングで Carbon Design System に従った仕様で実装してくれました。

あまりにもバグが解決しない時に、この Carbon Design System を回避するような動きをすることがありました。
このあたりはバグが発生している状況の確認と適切なBobへの指示が必要だったのかなと思っています。

どんな流れで実装したか

試行錯誤しながらBobとアプリを作っていったので、その時の心境や実施したことを羅列しておきます。

• 1つのタスクでBob任せにして実装していく
  • とりあえず実装したい事を伝えて1つのタスク内でどんどん機能追加をする
  • Github上に更新したソースをアップロードしつつ、リモートのRHEL on Power上でビルドをしてデプロイする流れを繰り返す
  • ときにはsshコマンドをbobに発行させてデバッグを直接行う
  • このときはコンテナ化せず、RHEL上でそのままデプロイ

• 機能追加をタスクに分けて実行
  • コンテキストの圧縮によってBobの振る舞いがその都度変わったり、挙動が怪しかったため機能をタスクに分けて実装
  • 機能実装ごとにBobの履歴も残って参照しやすくなる
  • タスクごとに異なる実装をしてデバッグで困る

• コンテナ化
  • 本番環境にデプロイすることを考えてコンテナ化実施
    • コンテナ化や起動のスクリプトもBobに作ってもらう
  • コンテナのデプロイ方法をしていなかったために、デプロイのバリエーションが沢山になる

• ソースの更新をmainに直接行わないように変更
  • 自分以外も変更とか出来るようにしたほうがいいと思い始める
  • 機能更新や修正はブランチで切って、プルリクエスト出してからマージするほうが良いと思い始める
  • Bobにブランチの作成からプルリクエストの作成まで実施してもらう

実装を通して感じたこと

仕様は明確にしておくことが大事

依頼事項に対しBob側で解釈して実装をしてくれますが、他部分との整合性が取れなかったりします。わかりやすい例だと、下の図のような状態です。
登録されている機器の詳細を表示するボタンが下のような形で実装されました。

左の実装は目のアイコンがボタンになっていますが、右側は "詳細" ボタンがあります。
実装にはトークンが消費されてしまうので、できるだけ消費されないように事前のドキュメント化やリクエスト時の明示的な指定は必要だと感じました。

機能の実装は細かく、タスクを分けることが大事

一気に複数の実装を進めていくとコンテキストが大きくなりすぎてしまい、コンテキストの圧縮が行われます。
そうすると以下の問題が発生すると感じました。(あくまでも個人の印象ですが)

• コンテキストの圧縮により実装/処理方法がブレる
• トークンの消費量が大きくなる

細かくタスクを分けて実行することで、実装内容のコントロールがしやすくなる印象がありました。

バグやエラーの解消は操作側の知識も大事

バグやエラーに関して、ある程度解決に近づくような情報(ログやデバッグ情報)を渡せるほうが素早く解決できました。
BobがDB操作のコマンド実行や開発環境の起動もしてくれたりするのですが、その時々でBobが提案するデバッグ方法も異なったりします。
ある程度解決に使えそうな情報を提供できるのであれば、早く解決できますし無駄なトークンも使わず済むと思われます。

ドキュメントが大量に作成される

実装内容や指示のドキュメント化は大事であると先に書きましたが、Bobが実装するときに大量のドキュメントをどんどん作成してくれます。
精査をしていないのも悪いのですが、ちょっと実装依頼をするだけでそれに関するドキュメントを新しく作ってしまい、何がなんだかわからなくなりました。
しかも開いているディレクトリにどんどん新しいドキュメントが作られるので、せめてディレクトリ指定をするのが良いと思いました。
Bobのモードは設定の編集が可能なので、そこでドキュメントは documents に保存して と記載しておいてもよさそうです。

Gitの操作をBobに任せると楽

Bobにgit操作を依頼すると、コミットやPush、プルリクエストの作成まで行ってくれます。
コミットの詳細やプルリクエストの記述まで作ってくれるのでだいぶ楽でした。
ブランチを切ってくれたりするので、運用に合わせて指示をしておくのが良いと思いました。

自分は環境の都合上、ブランチを毎回切って新しい実装をしてもらうように依頼しています。
新しいブランチを作成して以下実装してください というような形でチャットの最初に書いておくと、ちゃんと対応してくれます。
また、実装が長くなると途中でコミットを促してくれたりします。
少し前の状態に戻したい場合なども、gitの機能で戻せるのでトークンの消費も抑えられると思います。

以上、BobにWebアプリを作ってもらった感想でした。

今回、Power上のRHEL向けにアプリを作りました。
開発環境はローカルのMac上で行い、完成したらRHEL上で動かしてみるという流れで開発をしていました。
最初にそのような条件で開発することを明示していたためか、特に互換性の問題もなく動かせました。