Effort Tree の中の人

Effort Tree公式アカウント
企画・運営：株式会社プラムザ

以下のアカウントでサンプルデータがご覧いただけます。
メールアドレス：[email protected]
パスワード：demo2026

[Effort Tree の中の人 @effort32296]

Effort Tree、プレオープンしています。
https://t.co/815x59EN5j
こちらから新規登録可能です！
Backlogをプロジェクト管理に使っている開発チームの皆さん、ぜひ使ってみてください。
弊社でも実際に使っていますが、開発途中の消費コストが把握できて、非常に便利です。

[Effort Tree の中の人 @effort32296]

10:40 復旧しました！

[Effort Tree の中の人 @effort32296]

ただいま、サーバーの緊急メンテナンスを行なっております。復旧は10:45を予定しています。
ご迷惑をおかけし、申し訳ありません。

[Effort Tree の中の人 @effort32296]

請求・入金管理の上に前受金・売上充当の概念をプラスしています。昔なら仕様検討だけで3日はかかっていたことですが、1時間足らずで終わりました。しかも精度が高い。
もちろんここに辿り着くまでには「実現できることと直感的にわかりやすいUIがあることは違う」「売上と負債は分けなくてはいけない」「そこは参照専用画面だけど入力させても違和感はないか」とか、ケンケンガクガク議論しています。

[Effort Tree の中の人 @effort32296]

「しかしこの状態でこのボタンが押せるのがおかしいですよね？」

[よっぴー @yoppy_cyber]

障害の原因はシステムじゃなくてユーザーの誤操作だと証明されたぞ！

[Effort Tree の中の人 @effort32296]

一定のクオリティが担保されることを確認したら、モデルをコロコロ変えずに使い倒すことだと思います。
多少切れない部分があっても、慣れ親しんだハサミに敵いません。大事な部分は道具ではなく自分の中にあるからです。

[炎鎮🔥 - ₿onochin - @super_bonochin]

Opus 4.8 、基本的には良いモデルだと思うんだけど、これは Claude 全般に言えることだけど、コンテキストが積み重なると一気に理解の解像度が落ちる。
社内の人間とお客さんを混同したりし始める。
柔軟な一方で、理解が大雑把。
GPT-5.5 よりもはるかに「ありえない勘違い」の頻度が高い。
一方で。GPTはカッチリで正確だけど、ちょっと近視眼的だったりする。
自分の中では、自分の進め方に自信のあるタスクならGPTに、なんかよくわかんねぇから一旦雰囲気で進めるか、みたいなのは Claude でやってる。

[Effort Tree の中の人 @effort32296]

@IT_BOYAKI おおむね、同意です。
職業プログラマーならという前提ですが、プログラムはビジネスの現場で役立たなければ意味がありません。

[Effort Tree の中の人 @effort32296]

もちろん、古めかしいウォーターフォールの多重請負構造の開発を引き摺ってたら、それはAIを使おうが何を使おうが、良いものを作るのは無理です。

[Effort Tree の中の人 @effort32296]

人間がコーディングして100人月規模の基幹業務システムの開発を、AIを駆使してやってますが、そういう感想は持たないですね。
要件定義もAIによって無茶苦茶効率化され、要件定義段階で精緻な画面作成までもやれてしまい、顧客との認識のズレが抑えられます。

[木村岳史(東葛人)×極言暴論 @toukatsujin]

コーディングエージェントによる開発を前提にした場合、そこそこの規模のシステムでは要件定義が間違いなくボトルネックとなる。生成AIは「合理の塊」だから、要件定義→設計→開発を通じて要件の解像度を高めていくといった日本的流儀は通用せず、要件定義の段階から完璧なものが必要になる。だけど日本企業には、組織の慣習などといった「謎の要件」が多数あり、合理の塊のAIに理解不能。そのくせ、それらしきコードを吐き出したりするから始末に負えなくなる。

[Effort Tree の中の人 @effort32296]

作業時間計測機能の軽微な不具合を修正しました。
ストップウォッチをスタートしていないのに、それが残ってしまうのが1ヶ月に1回くらいうざかったです。

[Effort Tree の中の人 @effort32296]

よく「既存のシステムにちょっと機能を付け加えてもらえればいいから安くやって」と言われますが、そういうのが一番つらいです。既存システムには設計者の世界観があり、まずはそれを吸収しなければなりません。
こちらより優れた設計者の世界観なら頑張ってついて行けますが、「うわ、こんなことやっちゃってる」というような場合、それを引き継ぐのは難しいものですね。
しかし、それを発注者の方は理解できず、リスクと難しさにコストをかけてもらいにくいです。

[Effort Tree の中の人 @effort32296]

そうです。責任感あるエンジニアは「絶対」という言葉を使いませんが、責任感ある顧客担当は使わなければいけない時があります。

[ヤマダ @yamada_sier]

良い悪いはさておき、「心にきた」という意味で、29くらいの時にお客様の情シス部長に飲み会で言われた言葉。

「ヤマダさんはね、物凄く真面目にやってくれてる。それは有難いの。でもね、僕らは『もっと気持ちよく騙されたい』って事は知っといてほしいんだよね」

[Effort Tree の中の人 @effort32296]

世の中には「形は綺麗だけど扱いにくい」と言うDB設計があります。
今回のcontractsテーブルのようなものは「こいつ何のために存在してんだよ？」と毎回イラつくことになりますね。
設計者と実装者の両方の立場で考えた時、意見が対立することがあります。

[Effort Tree の中の人 @effort32296]

今日も朝からAIと楽しい会話ができて嬉しかったです。

「はい、そうですね。私も請求（予定）テーブルを作った時の「元になったデータ」をどうするかを考えていたのです。 レッスンの請求は契約を元にして作成されるが、演奏の請求は演奏案件を元にして作成されるというのが歪です。金銭周りは基本的に請求予定テーブル、請求テーブル、入金テーブルあたりで全て共通化しますが、契約まで含めて共通化すべきなのか、そこは別でいいのか、で悩んでいます。」

『3. 「契約テーブル共通化」はやりすぎになりやすい
共通 contracts テーブルを作る案もあります。
contracts
- id
- contract_type: lesson / performance
ただし、これは途中で苦しくなる可能性が高いです。
（中略）
共通契約テーブルを作ると、結局、
contracts
lesson_contract_details
performance_contract_details
のようになり、contracts が薄い親テーブルになります。』

30年選手のSEが直感的に思っていることを言語化してくれるの何なん😇

[Effort Tree の中の人 @effort32296]

興味深いテーマでしたが、「場合による」の一言。その状態とそうなった経緯をどれだけ重視するかによると思います。
例えばメッセージの「既読フラグ」。これは誰のアクションかといえば送られた本人に決まっているし、使うのは本人の表示にしか使いません。大事なのは読んだのかまだ読んでないのかだけの話であって、いつの時刻にそうなったかはどうでもいいです。
その程度の状態管理を別テーブルにするのは、コストに見合いませんね。
発想は面白いと思いましたが柔軟さが必要です。

[farstep @farstep_]

https://t.co/fLIm4rlzco

[Effort Tree の中の人 @effort32296]

今はデモなので入れて無いのでしょうが実用化する際にはフェイルセーフの概念は必須ですね。現場では誤作動するよりは動かない方がいいです。

[Effort Tree の中の人 @effort32296]

実はメルマガ配信してます。

お役立ちメルマガ vol. 16『「業界外の会社でもAIを使えばシステムができる」は本当か？』

最近、AIを使ったシステム開発の話をよく聞くようになりました。

特にClaude Codeのようなツールを使うと、プログラムの専門知識がなくても、自然言語でかなりのことを指示できます。

「こういう画面を作ってください」
「この項目を登録できるようにしてください」
「ログイン機能を付けてください」
「サーバーにデプロイ（アップロードして公開すること）してください」
このように指示すると、AIがコードを書き、必要な設定まで進めてくれることがあります。以前なら難しかったDNSの設定やサーバーへの反映も、AIに聞きながら進めれば、ある程度までは到達できるようになっています。
では、業界外の会社でも、AIを使えばシステムを作れるのでしょうか。
結論から言えば、簡単なシステムであれば可能です。

たとえば、次のようなものです。

社内だけで使う簡単な資産管理のシステム

問い合わせ受付フォームとメッセージの履歴管理

小規模な予約フォームやメール配信システム

単純な商品紹介サイトとシンプルなアクセス解析
一時的に使う業務補助ツール
このくらいであれば、AIを使って自社で作ることは十分現実的になってきました。
「AIでシステム開発なんて無理」と決めつけることはできません。
ただし、注意しなければならないことがあります。
それは、「動くものができること」と「業務で安全に使えること」は別物だということです。

たとえば、個人情報を扱うシステムになると、急に難易度が上がります。

顧客情報、会員情報、住所、電話番号、メールアドレス、ログイン情報、決済情報などを扱う場合、単に画面が動けばよいという話ではありません。

他人の情報が見えてしまわないか

管理者以外が重要な操作をできてしまわないか

パスワードは安全に扱われているか

退職者や外部スタッフの権限を止められるか
障害が起きたときに復旧できるか
画面上は普通に動いていても、内部では危ない作りになっていることがあります。
さらに、システムが一定以上複雑になると、AIだけで作るのはかなり難しくなります。
たとえば、特殊な業界向けのマルチテナント型ECサイトを考えてみます。
複数の会社や店舗が同じシステムを使う場合、単に商品を登録して、カートに入れて、決済できればよいわけではありません。

A社の管理者はA社の情報だけ見える。
B社の担当者はB社の注文だけ処理できる。
本部は全体を確認できる。
顧客は自分の注文だけ見える。

このように、権限設計だけでもかなり複雑になります。

さらに、請求金額の計算も簡単ではありません。

商品価格、送料、手数料、割引、キャンペーン、消費税、月締め請求、返品・キャンセル、テナントごとの料率。
こうした条件が重なると、「AIに自然言語で指示すれば何とかなる」という範囲を超えてきます。
もちろん、AIに一つひとつ指示すれば、それらしいシステムが出来上がります。
しかし問題は、個別の機能を作ることではありません。

本当に難しいのは、全体として矛盾しない構造を作ることです。

どの情報をマスタとして持つのか。
どのタイミングで注文を確定するのか。
請求金額はどの時点で固定するのか。
権限はどの単位で管理するのか。
例外処理をシステムに入れるのか、運用で吸収するのか。

こうした判断は、個別のプログラムを書く力とは別のものです。

ここを見誤ると、最初は順調に見えても、途中から苦しくなります。

画面ごとに仕様がバラバラになる

データの持ち方が途中で合わなくなる

権限管理が後付けになってぐちゃぐちゃになる

請求計算が例外だらけになる
修正するたびに別の場所が壊れる
最初は小さなシステムだったはずが、業務に合わせて機能を追加していくうちに、だんだん手に負えなくなっていくのです。
ここで大事なのは、
「少しずつ作ってブラッシュアップしていけば、いつか大きなシステムになる」わけではない
ということです。
小さな材木をいくつか組み合わせても、大規模な建築物は作れません。

犬小屋を作る考え方で、ビルは建てられません。

もちろん、小さく始めることは大事です。
ただし、小さく始める場合でも、将来どの方向に広がるのかをある程度見越しておく必要があります。

AIは、部品を作るのは非常に得意です。
画面を作る。
入力フォームを作る。
一覧画面を作る。
簡単な登録処理を作る。
エラーを直す。
こうした作業では、AIは大きな力を発揮します。
一方で、業務全体をどう分解するか、どこに境界線を引くか、どのデータを正本にするか、将来の変更にどう備えるかは、人間側が考えなければなりません。
つまり、これからのシステム開発では、
AIを使うか使わないか
ではなく、
AIに何を任せ、人間が何を判断するか
が重要になります。
AIを使えば、システム開発のハードルは確実に下がります。

ただし、何でも作れる魔法の道具ではありません。
「なんとなく動くものはできた」
「でも、このまま拡張してよいのか不安」
「権限や請求の整理が難しくなってきた」
「個人情報を扱うのでセキュリティが心配」
このように感じたら、そこが一つの分岐点です。

プラムザでは、AIを使った小さな開発から、業務システム全体の整理まで、お客様の状況に合わせてご相談をお受けしています。

「全部を外注してください」という話ではありません。

まずは自社で作ってみる。
できるところまではAIを活用する。
ただし、難しくなってきたところで一緒に整理する。
そのような関わり方もできます。

AIで作り始めたシステムが少し複雑になってきたと感じたら、早めにご相談ください。
作り直しになる前に、どこを整理すべきか、一緒に考えることができます。

[Toru SHIMADA @plumsa0]

上流工程をやっている開発会社としては思ったほどAIによって仕事を奪われない実感があるな。
これまで実現できなかったUIや複雑な仕様が低予算で実現できて提案の幅が広がっている。会計や法務など定型的な仕事は厳しいかもしれない。

[Effort Tree の中の人 @effort32296]

弊社はそれが嫌で大手の下請けは受けないようにしていましたし、仕様書も必要最低限（やや不足がち）にしてましたが、それがAIによって大きく変わりました。
「本来あるべき開発スタイルになった」と言っていいと思います。

[Effort Tree の中の人 @effort32296]

こういう仕様書、昔なら状態遷移を必死で考えて半日がかりだったけど、今は10秒で書いてくれます。
「ここがおかしい」とか「複雑すぎる」とか指摘すればいいのでとっても楽です。
そして仕様書がプログラムの正義となるのは当たり前のことなんですが、これまではなかなか実現できなかったことです。

[Effort Tree の中の人 @effort32296]

これまでも大手のSIerでは仕様書ファーストで作ってることが多かったですが、嘘も矛盾も多かったですし、そのメンテが大変なのでちょっとした修正に何週間もかかり、コストもバカでかくなりがちでした。
不毛なドキュメントメンテはエンジニアの士気を下げるということもよくありました。