回答編集履歴

3

fix

2023/04/09 03:07

投稿

退会済みユーザー
test CHANGED
@@ -7,10 +7,8 @@
7
7
 
8
8
  ユーザーが自分の仕事をちょっと便利にしたいときに使うおもちゃみたいなものです。
9
9
 
10
- 同じ予約システムでも、社内の人しか使わないものみたいな、コケても損失が出ないリスクが少ないものに限定すべき。
10
+ 同じ予約システムでも、社内の人しか使わないものみたいな、コケても損失が少ないものに限定すべきでは
11
11
 
12
- 価値を生むシステムを稼働させたいなら、ちゃんとお金をかけて外部の本職の人に頼むか、自分で作りたいっていうなら、おなじくお金をかけて勉強頑張りましょう。
12
+ 価値を生むシステムを稼働させたいなら、ちゃんとお金をかけて外部の本職の人に頼むか、自分で作りたいっていうなら、おなじくお金と時間をかけて勉強頑張りましょう。
13
-
14
- プロジェクトを挫折させ、利用者に迷惑をかけて謝るor逃げるというような経験を積みたいならどうぞgasをご自由に使えばよろしい、と思いますがね。
15
13
 
16
14
  #タダほど高いものはない

2

fix

2023/04/09 03:05

投稿

退会済みユーザー
test CHANGED
@@ -1,15 +1,15 @@
1
1
  GAS一見超簡単ですが複雑な業務要件(他の複数の外部利用者を束ねるようなシステム)をつくろうとするのは絶対やめた方がいいです。
2
2
 
3
3
  理由
4
- ・できることが少ない
4
+ ・できることが少ない(やたら制限が多い)
5
5
  ・きちんとしたサポートがない
6
6
  ・しょっちゅうapiの仕様が変わる(昨日まで動いてた公式の関数が動かなくなったりドキュメントどおりの結果を吐かなくなったりする)
7
7
 
8
8
  ユーザーが自分の仕事をちょっと便利にしたいときに使うおもちゃみたいなものです。
9
9
 
10
- 同じ予約システムでも、社内の人しか使わないアンートとかリスクが少ないものに限定すべき。
10
+ 同じ予約システムでも、社内の人しか使わないものみたいない、コても損失が出ないリスクが少ないものに限定すべき。
11
11
 
12
- 価値を生むシステムを作りたいなら、ちゃんとお金をかけて実用的フレームワーク使いましょう。
12
+ 価値を生むシステムを稼働させたいなら、ちゃんとお金をかけて外部の本職の人に頼むか、自分で作りたいっていうら、Mおなじくお金かけて勉強頑張りましょう。
13
13
 
14
14
  プロジェクトを挫折させ、利用者に迷惑をかけて謝るor逃げるというような経験を積みたいならどうぞgasをご自由に使えばよろしい、と思いますがね。
15
15
 

1

誤字修正

2023/04/09 02:58

投稿

退会済みユーザー
test CHANGED
@@ -9,8 +9,8 @@
9
9
 
10
10
  同じ予約システムでも、社内の人しか使わないアンケートとかリスクが少ないものに限定すべき。
11
11
 
12
- 価値を生むシステムを作りたいな、ちゃんとお金をかけて実用的なフレームワークを使いましょう。
12
+ 価値を生むシステムを作りたいな、ちゃんとお金をかけて実用的なフレームワークを使いましょう。
13
13
 
14
- プロジェクトを挫折させ、利用者に迷惑をかけて謝るor逃げるというような経験を積みたいならどうぞgasをご自由に使えってください、と思いますがね。
14
+ プロジェクトを挫折させ、利用者に迷惑をかけて謝るor逃げるというような経験を積みたいならどうぞgasをご自由に使えばよろしい、と思いますがね。
15
15
 
16
16
  #タダほど高いものはない