プログラマ低能自慢「○時間で作った！」

1 ：2013/08/11 〜 最終レス ：2013/09/24

調査、設計、プロトタイプ作成などなど除いてだけどなｗ

2 ：

予定工数に収まっていればなんでもいい

3 ：

本当は調査とか技術検証とか
そういう所に時間がかかるんだよね。
何もかもすんで、材料揃った所で
○時間で作ったとか言っても、
それただ書いただけですからｗ

4 ：

「○時間で作った！」
↑動かねえぞコラ

5 ：

プログラマってやたら開発時間自慢をするよねｗ
出来たの見ると、おもちゃレベル
そんなものより実用レベルの
品質にすることのほうが重要なんだが。
そこまで開発時間に含めなさい。

6 ：

「○○キロライン書いた！」
↑動かねえぞコラ

7 ：

◯日で作れ
↓
無理です
↓
作れ
↓
作る→バグだらけ→なんでこんなの作った
作れない→なんで作れない

8 ：

DB接続してＳＱＬ結果をＥＸＣＥＬシートに書き出し合否判定を行うプログラムを２時間でつくった。
単体テストで全部つぶして結合・統合テストでバグなし。

9 ：

>>8
試験密度が低いね。強化試験しなさい。

10 ：

>>9
手厳しい。
まあ、問題ないよ。
低能自慢だからね。

11 ：

「○時間で作った！」じゃなくて
「○時間で作れるツールを作った」ならかなり有能なんだけどね。

12 ：

「○時間で「○時間で作れるツール」を作った」

13 ：

大量のsetter/getterを１本指打法で入力して
「○○時間かかった。いや〜大変だったわ」
と残業時間とステップ数自慢するおっさん
間違いだらけの修正にさらに○○時間
開発ツールの機能使って一撃で出せよ

14 ：

そういえば各フィールドごとにアクセサ書くのってなんか無駄な気がするよな。だいたい等価じゃん。そこがなんとなく気に入らんクラスオリエンタル

15 ：

短時間で成果物を作り上げられる目標達成能力があるんだから普通に凄いことじゃん。
自慢というか自己アピールして全然構わないと思うけど。
ここの皆さんはそれがなぜか気に食わなくて
短時間ではゴミしか作れない前提で語ってるようだけど。

16 ：

>>15
たしかになw

17 ：

java限定だが
>>14
beanは糞だからな
最近はpublicフィールド結構使うようになってきたけどね
自動生成してくれるframeworkとかもあるし
javaもCSとかActionScriptとかみたいに、必要なとこだけ別個でgetter/setter実装するってスタイルの機能つけてほしいわ…

18 ：

>>17
ツールじゃなくて、クラスというのが嫌い

19 ：

>>14
そうだね。全く同感。だから、アクセサは特に必要なものにしか書いてない。
通常publicにしてる。Javaじゃないけど。

20 ：

そうやって書いたpublicフィールドから
外部インターフェースを変えずに
アクセサに変えられるのが
C#やVB.NETやVB6なんかのpropertyなんだよね。

21 ：

PMが「昔は○○時間で○○を組んだ」とか毎日小一時間自慢話
個人的な気分転換や自尊心の為に工数使うってのはPMとして失格じゃないか

22 ：

鳴らせるほどの腕がある技術畑上がりのPMってことは
工数管理もよくわかってるはずだから
その工数に余裕も含まれてるんじゃない？
いざとなれば一番面倒な部分を作ってくれたりとか。

23 ：

時間が短い自慢か、時間が長い自慢かによって方向性が違ってくるな

作ったよりも、○○までテストしたから○○までの動きは完璧、
という方が引き継ぐ方としては嬉しい

24 ：

開発時間とガチなテストは別の話じゃん？
まあ開発が速ければ総体的にも速くなるだろうけど
システム規模でバグひとつ無い完璧なプログラムなんてそうそうありはしないけど
開発が早い人は開発に必要な知識や経験が確かで設計もしっかりしてるから早い
だからバグ率も相当低い、初版で出るバグと言ったら仕様相違のバグくらいだろう
遅い人は知識も経験も圧倒的に不足してるから、初心者にありがちな稚拙バグが目立つ
と現場では実感してるけど

25 ：

完成までが早い糞コードよりも、多少かかっても意図が読み取れ見通しがよいコードであってほしい
早く作業が終わったのなら、UTとリファクタリングに力を注いでほしい

26 ：

>>25
>>15

27 ：

早く作れない低能連中の言い訳スレという見方もできるわけだな。

28 ：

自分を磨いてベテランに追いつこうと考えるのではなく
自分の技量不足や経験不足を誤魔化すために
ベテランを蹴落とすことを真っ先に考える人種だからな
物作る才能もなく技量も経験も乏しいのに上流にシフトして
35才定年説の元凶を作るわ、物作りもまともにできない奴が
何を設計し何を管理するのか、結果的に現場をデスマに変えるわ
素人に汚染されまくりだよ今のIT業界は

29 ：

>>22
部長なってしまったBさんはそういう人だった
けどAさんは・・・
ちなみに工数の余裕はありません
「厳しい案件ばかり担当させられる」　←　仕様策定ミスの言い訳
「会社の奴らは何もしてくれないけど俺はやってきた」　←　無茶な指示の言い訳
「腹黒いBより仕事速かったのに評価されなかった」　←　いい歳して昇進しない不満
勘弁してほしい・・・

30 ：

>>29
要するにAの開発時間云々は口からデマカセで、本当は技量も才能も無い奴なの？
そんな藤四郎と大ベテランを混同してるの君は？

31 ：

>>21はAさんのこと、余裕がなくていつも大変
>>22で書かれてるような人ならBさん
>>29の「」内は全てAさんの発言
ID出ないことを考慮して書くべきでした。自分の発言はこの3つ
これで混同なくなった？

32 ：

あっすまん>>22は自分の発言じゃない、レスのツリーがその3つと書くつもりでした
グダグダですまん

33 ：

>>31
いやAとBを混同してるって意味じゃなくてさ、
時間自慢をしているAと、時間自慢をしている世間の大ベテランの両者を、君は混同してるのかってこと。
>>30に書いた通り、君の言うAは、世間の大ベテランとは程遠いホラ吹きの無能ってことでしょ？
そんなのとベテランを同一視されたら迷惑

34 ：

ご心配なく、きちんと区別してるから大ベテランのBさんのことは尊敬してるよ
スレタイには「低能自慢」とあるから、区別したうえでダメなほうへの愚痴を言うスレかと

35 ：

一人目・・・バグを良く混入させる奴だが、一時間で作るなど、スピードは速い
二人目・・・仕事は丁寧だが、仕上がりが遅く、同じソフトを十時間かける
三人目・・・仕事自体を面倒くさがる奴で、「ネット検索三時間」で「コーティング二時間」。
　　　　　　ネットでフリーのソース探しが早いが、仕上がりの質は元のコード次第でバラつきあり。
四人目・・・一ヶ月かけても完成させられないが、鬼テスターとしての能力は完璧
五人目・・・数十分で完成させる天才だが、病弱で、仕事場から早退が良くあり。能力が
　　　　　　高いので、会社も解雇できず。
六人目・・・三時間で完成させられるのに、その後の一時間は、自作のExcelマクロのゲームで
　　　　　　遊んでいる怠け者。バグはほとんどない。
おまいらなら、誰に仕事を頼むんだよ?w　　　　

36 ：

>>26
速度だけが重要じゃないって話だよ
遅くて糞いのは問題外で話題にする内容でもないし、早くて完成度が高いのも、別にあえて言及する必要ないでしょ
早くて糞いのと遅くて完成度が高いの2択で考えたら、後者のほうがテストや以降の保守で楽できて以降の作業が早くなる
巷に蔓延るうんコードの保守をやってると、速度なんて完成度高いコードが書ける程度になってから重視すべき部分だと感じてしまうわ

37 ：

1. UTが不足しているのに完成したと言っているだけの無能
2. 丁寧の定義が曖昧なので評価しづらいが、開発速度は慣れだから今後期待出来る可能性はある
3. コピペコーダー、チェンジ
4. コーディングに興味が無いなら、テストの請負専門でやってるような所に行くべき
5. 出勤が不要な出来高でのみ評価されるような国外の企業とかじゃないとこの先辛そうだな
6. バグの作り込みがないなら、スキルはあるし怠け者ではなさそう
>>35 「仕事」の要件が曖昧で中身が伝わらない。情報が曖昧。糞営業。

38 ：

巧遅は拙速に如かずと言うことわざがありまして。

特に出来上がるものが想像してたものと違うのが当たり前のソフトウェア開発
だといかに早く作って、フィードバックしてというのが大事なのか分からない人が
多いよね。 それが大事だと分かった人が増えてきたからアジャイルとかいう
開発プロセスが注目を集めてるわけだし。

39 ：

アジャイルは、工程を守らないための方便の意味で使うバカが
多いおかけで、どんどん否定されて、下手すりゃアジャイルでやりたい
といったとたん契約が飛ぶなんてことも起きかねない状況だけどね。

40 ：

>>38
5の調子が良さそうなら、5に頼んで、
調子が悪そうなら6に頼む。
他は論外だろ。

41 ：

5と6の「マ」に、人気が集中しているな。

42 ：

>>40に同意。５に頼む。
最近かなり増えた在宅とかで本領発揮するタイプに多いから
病気は気にしなくてもハイクォリティで、かつ納期は人の数倍から数十倍は早く仕上げてくれる。
どうしても頼めない状況なら６だな。他は論外。

43 ：

>>36
早くて糞いって一体どんな糞？
早いからこそ出る糞？
そもそも速度が重要じゃないなら早いとか遅いとか言っちゃってる時点で矛盾じゃん？

44 ：

誰が作ったってバグは必ずあると思ってるから
人の数倍、数十倍で作る能力があるなら断然早さを選ぶ
バグってのは後で直せばいいんだよ、開発ってのはそういうもんなんだから
最大手のテスト的に言えば、むしろバグが見つからない方が恐い

45 ：

そしてテストをやる人間（開発者本人では無意味、テスターやサポート、運用に近い人間）が
運用開始前にバグを見つけられなければ、テストが不完全（適当）ということになるのでテストをした人間の責任になる
最近、プログラマに全て任せきりでロクにテストもせずに運用始ようとする馬鹿な会社が増えたが
品質低下の根底にはプログラマに全てを押し付けてる経験の浅いド素人なクソ企業体制にある

46 ：

なんかこうテストのレベルが違うな
そういう一昔前の開発手法じゃ、昨今のニーズに堪えるには工数的に厳しいと思うぞ
まだその辺りで前進出来ないとこは多いけどな
早く終わらせてから多いバグを取るって考え、間違いじゃないけど
実際はUTによる一通りのバグ取り、リファクタリングが終わった時点が本当の終わりじゃん
今日日、「実装してからテストする」みたいなやり方で考えてるわけじゃないっしょｗ

47 ：

＞そういう一昔前の開発手法じゃ、昨今のニーズに堪えるには工数的に厳しいと思うぞ
昔でも何でもない。
どんな客層を想定した極小規模かは知らんが、無テストで運用開始とか基地外にも程がある。
＞早く終わらせてから多いバグを取るって考え、間違いじゃないけど
多いバグとは書いてない。
バグ数はゼロではないが、開発が遅い奴より桁違いで少ない。
開発が早い奴ってのは、手探りの遅い奴より開発に関する知識も経験も遥かに上で正確、
各種チェック機能や起こりうる問題回避のための機能付けもかなり高水準で抜かりがない。
（開発が遅い奴のコードを見ると、このあたりの対応がスッカスカでゴミデータを素通ししたり
脆弱性を平気で作ったりしてる奴が多い）
テスト自体も半端なく早くこなすから、コーディングミスなどは一般の水準よりも遥かに少ない。

48 ：

開発が早い奴が出すバグといえば、
プログラマ本人が想定していない仕様策定段階のミスや、基本設計の不適正が原因の論理バグ。
つまり開発着手前に要求をまとめて設計する人間が、どれだけ手を抜かずシステムをしっかり練ったかで左右するバグだ。
あとは仕様変更などの指示が杜撰で発生する他所非対応問題や（よほど関連性が明確でない限り指示のあった箇所だけ対応する）
プログラマの想定を越えた運用時に発覚する問題（バグに限らず）。
発生を想定するのがこれだけならテストも割と簡単だ。
誰が書いても一度は起こす問題（外部サービスやブラウザ依存のバグ等）は開発が早くても遅くても出る。
ここは過去にその問題を経験したかどうかでしか回避できない。
運用前に発覚しない問題（非バグ、想定外のアクセス数で重いとか）こそ、運用後に必要に応じてリファクタリングすれば良い話。

49 ：

バグはプログラマの周りの人間が原因で発生する場合が多い。
プログラマ個人のバグの発生率を確かめるなら、最初から最後まで一人で開発した
それなりの規模のシステムやプログラムがあれば判りやすいな。
他にも個人開発したプログラムなどがあれば（フリーソフトやスマホアプリなど）
その更新履歴などを見れば一目瞭然。

50 ：

その昔、パソコンショップでも売られていた、超有名なビジネスソフト。
「支離滅裂な動作をする」とユーザーからのクレームで、詳しく調査したら、
原因が判明した。
Cで、最後に「ヌル文字列」を確保するのを忘れたために発生したバグ。
テスト段階では、同じヌル文字での破壊だったために、表には出なかった。
だが、購入ユーザーが大量のデータを利用し、違う文字での破壊だった
ため、それでバグが明らかになった。
有名なパソコンソフトと言えども、こんなことが実在する。
世の中、所詮、そんなもの。売りまくった企業の勝ちとも言える。
マやテスターの、良心的な苦労も実を結びつらい。

51 ：

>>46
PG/PTみたいな意味のない作業区分を作ってる会社にありがち。
業務系のWEB開発メインでやってた連中が多いと、そういう方向になりやすいように感じる。

52 ：

CIを前提にしたプロジェクトなら受け入れや改修のリグレッションなんかで
無駄な工数を割くことがかなりなくなるけど、新規案件でもそういうのを導入出来てないのは多いしな。
技術者のスキル不足が顕著に出てるなって感じ。

53 ：

せせこましいチンケな開発しかしてない会社だけでなく
パッケージ系やゲームメーカー、金融・証券など大金が動く業界でも働いてみるべきだな

54 ：

>>53
一生なんて短いから、
そういう、あちこちちょっとだけ摘まんでみましたみたいのは無理があると思う。

55 ：

>>52
そもそも銀の弾丸なんてないし、万能なツールなんて存在しない。
ツールを使うことで浮いた時間を別の価値のある仕事に割り当てる、創り出す
ためだけのものだからな。あと外部のツールだと、アップデートの時間が早いと
自分とこの環境を同じ速度でアップデートできないことの方が多いからタコツボ化
していくんだよね。

56 ：

「工場のラインの組み込みの場合、仮に製品を100万個作る事を、客から
要求されたら、一億個にも耐えられるテストデータを作れ」
と言われたな。

57 ：

>>56
ソフトウェアは1個つくるのも
100万個作るのも1億個作るのも
手間は変わらないから全く参考にならないな。

58 ：

>>57
どう読んだらそういうレスが出てくるの？

59 ：

工場のラインがメモリリークで酷い目にあったとなったら、相手が賢い場合、
下手すれば損害賠償モノでは？
途中から、すべて半製品になりかねないし。
100万個を作るラインなら、うちなら10億個まで耐えられるように作りたい。
組み込み系は、バージョンアップは出来ないし。

60 ：

組み込み系でもバージョンアップできるぞ？

61 ：

>「工場のラインの組み込みの場合、仮に製品を100万個作る事を、客から
> 要求されたら、一億個にも耐えられるテストデータを作れ」
は、見当違いな素人の意見
100万レコードを扱えるシステムを想定したら、客から1億レコードにも耐えられるシステムを作れ
と言われたなら、それはまっとうな要望と言える。
勿論、その分だけコストがはずむけど。

62 ：

>工場のラインがメモリリークで酷い目にあったとなったら、相手が賢い場合、
>下手すれば損害賠償モノでは？
100万個作れるシステムの時点で、メモリリークするような設計してることはないだろう。
そのシステムはそのまま1億個作れると想定する方が自然だと思う。

63 ：

コピーコマンドでいくつでも同じものを作れるのに100万個とか1億個とかいう
単位でソフトウェアを計測しようとする人がおかしいって言ってるんだろ。
100万レコードと1億レコードといういいかえも、DBなら単純にキーの桁数に
なるわけで、プログラム上で意識する必要はそんなにない。ただ、データ数は
ハードウェアの構成に直結するものだから、扱うことのないでかいデータを
想定して作るのはただのバカだよ。

64 ：

100万個の製品作りの場合でも、データ的に、多少の余裕を持たせないと。

65 ：

>100万レコードと1億レコードといういいかえも、DBなら単純にキーの桁数に
>なるわけで、プログラム上で意識する必要はそんなにない。
ほ、本気で言ってるの？

66 ：

低能自慢だからスレタイ通り

67 ：

システムのことが分からないプログラマなのか、
仕様書通りにつくることしか出来ない末端のプログラマなのか…
１年の保守機関が過ぎたらあとは知りません、
つまり、１年持てばいいですって考えの方がいるようだな。
そりゃ、客もキレるよ。

68 ：

保守機関じゃなくて、瑕疵担保機関か。

69 ：

>>67
よくわからんがサポート契約切れたら知ったこっちゃないだろ普通
どこの乞食だよ

70 ：

>>67
なんとも言えない部分もあるが、普通は、仕様通りに作れば、後は
問題はないのでは？
「一年、持てば良い」と言われても、「五年間、使い続けて問題が出た」
と文句を言ってくる客も、いないわけではないからなあ。どこまで配慮
するものなのか、マジで知りたいところだ。
「最初から、五年、使い続ける」と言ってくれれば、それ相応に仕上げる
ものだと思う。それにもっとも近いのは、Windowsだからね。

71 ：

あのさ、ハードウェア的な問題じゃなく、
ソフトウェアの仕様的に経時的理由でまともに動作しなくなるってのがダメだって話なんだけど、
少し前のレスから読んでみて意味わからないのなら、
まぁ、そういうシステムばっか作ってきた人なんだろうな。
だから逆に案件だけは継続的に発生するわけだ。
出会うクライアントがどんどん不信感を募らせているのも説明がつくな。

72 ：

>>70に言ったわけではないからね。
>>70みたいな配慮をしているかどうかの問題だから。

73 ：

経年劣化するソフトウェアってどんなんなんだろ？

74 ：

誰かが弄って劣化させる以外考えられないわな

75 ：

メモリ食い過ぎ＋データの蓄積で重くなってく感じ？

76 ：

>>75
数年かけてメモリ食いつぶすとかは、割りとよく出来たソフトウェアだろ。
普通だったらすぐに見つかるだろうし、長時間かかるなら再起動で対応
出来るだろうし。 データの蓄積に関して言えば、それを予測できなかった
発注側の問題だろ。要不要を取捨選択するのは作る側が勝手に判断
していいものでもないし。

77 ：

生産性として重要だと思うのだが

78 ：

皆様、スケジュールに従えと強要されたら、刑法223条 強要罪で刑事Rするよう、お願い申し上げます。

79 ：

客先では、「設備投資する資金が厳しくて、『本当なら、三年前に破棄する
はずだったシステム』を、いまだに使い続けている・・・」
などという事は、良くあることだと思うよ。それを作る側で、どこまで
配慮するかという事になるのだが。
マイクロソフトだって、いまだにXpを現役で使っている連中が、
これだけ多いのは、考えてもみなかったかもしれないし。

80 ：

>>79
客の人間性と金払いによる
ケチな会社でしかも担当者がクズだった場合は、瑕疵担保期間以降のことは一切考慮しない

81 ：

ソフトウェアが想像以上に長く使われるのは、他の設備と違って経年劣化しないから。
だから、時間が経つに連れて使えなくなるとか言ってる奴とはそもそもの基本的な
考えから違っているからどうしようもない。 だいたい減価償却というのがあるの
だから使えなくなって当たり前位の考えを持ってないとダメだろ。

82 ：

機能的な劣化はしなくても、作りや構造的な部分に相対的な劣化はあるけどね

83 ：

劣化はしない、周りが常に進化してるだけ
進化の必要がなければいつまでも使われ続ける

84 ：

>>81
システムに関して、完全な素人が発注責任の経営者だと、
その辺の考えを、まったく理解できない場合もありうるからな。
「いつまでも使える」ものだと、頭の中で、勝手に変換して
しまうらしいから。

85 ：

正論の綺麗事で偉そうに出来ない理由を並べて製造拒否したところで、
評価が上がる訳もなく「ハイハイ、アンタには無理なんだね」って思われて終わりだろ
正論の綺麗事なんて教科書に載っているような内容なんだから、
大抵の奴は分かっている
できる奴を求めているところに、できない奴がきて
できない理由をベラベラ喋りはじめても
鼻っからお前みたいな奴はお呼びじゃないんだよってなると思うけどな

86 ：

自分らの力量を理解して、不可能、可能を説明できるだけでも十分有能。
その上で現実的な案を出して説得できるなら、さらに有能。
理想そのまま合わせる理由がどこにあるんだよ。
そんな馬鹿に営業やらせてたら、間違いなくデスマになる。

87 ：

先のことを考えて色々と汎用的に使えそうな関数なりオブジェクトを作っても
案外使われなかったりするのに似ている。 他の物と比べてもソフトウェアってのは
色々なものとのトレードオフが必要になってくる。
トレードオフ？なにそれ美味しいの？とかいう人はR貰いたいとは常々
思っている。

88 ：

>>87
やり方が間違ってるんだよ。
先のことをいろいろ考えて、
拡張するルートを確保して開発すればいい。
最初からゴールを作るのではなく、
ゴールまでの道があるかどうかを
考えればいいだけ。

89 ：

マウスで作動させる「簡易計算機」のソフトを、一日かけて
作っていた奴は、「遅い」と、後から怒られたらしい。
「一時間で作れ！」という感じでな。

90 ：

それは自慢ではないな。

91 ：

仕様と言語によるが
四則演算ならJavaならギリギリ1時間、Eclipse使って30分
jsなら20分ぐらいでできそう

92 ：

VCやC#でも10〜20分で作れるな
という時間の話をこのスレの人達は嫌うんだったな

93 ：

私は10万で出来るけど、80万で売ってます。

94 ：

>>93
あまりぼったくるなよw

95 ：

皆様、遅く作るようお願い申し上げます。
IT経営者の利益競争
技術者に早く作らせて、
技術者を早く捨てる。

96 ：

早さと書きなぐりやすさだけしか見てないでExcel方眼紙仕様書を作ろうとする奴らと同じにおいがする感じ

97 ：

>>94
ぼったくってないだろ。
買う人がいるなら商売は成り立つんだから。
どうしてもプログラマを人月にしたい奴がいるな。

98 ：

マの評価基準は、普通、人月じゃないのか。

99 ：

人月が評価？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

生活保護ﾌﾟﾛｸﾞﾗﾏｰでｵｰﾌﾟﾝｿｰｽしようぜ！ (355)
tokuhirom応援振興協議会 (183)
「夜の」を付けて卑猥な感じにするスレinマ板 (132)
VB6システム、未だリプレイスせず拡張中 (268)
HTS ハイテクシステム 002 (123)
プログラミングの上手い奴の特徴　0x02 (236)
--log9.info------------------
【ブラビンス】名フィル＆セントラル愛知【齊藤】 (256)
【Bartok】バルトークについて語ろう！Sz. 5 (619)
◆◇◆セルゲイ・ラフマニノフ 第11楽章◆◇◆ (439)
仲道郁代☆日本ピアノ界の女神サマ　2 (574)
諏訪内晶子について語ろう 4 [所得隠し 重加算税] (934)
Amazon,HMV,タワレコ…etc 出荷準備中42日目 (826)
京都市交響楽団 5 (752)
ホルストの惑星の中で火星・木星以外の曲が好きな奴 (178)
死ぬ前に最後に聴きたい曲は？ (392)
【ひの饅】痛いレビューを晒すスレ７!玉座【自演】 (256)
M田さんを見かけたら逐一報告するスレ (959)
トスカニーニ　１１ (269)
【巨匠】小澤征爾Seiji Ozawa第１５演目目【復活】 (640)
ベートーヴェン交響曲第３番変ホ長調「英雄」 (850)
オレ様★高嶋ちさ子　怒濤の三発目 (608)
【ﾜﾙﾃｨ話】関西ＣＤレコード店情報part13【禁止？】 (285)
--log55.com------------------
ワーキングチェア総合（ステマ禁止、ハーマンミラー社、関家具の扱うイス全般エルゴヒューマンを除く）
【ぐっすり】ベッド総合53【眠りたい】
【羽賀淳一】オフィスチェア全般【奇行種避け】
電気通信大学非常勤講師羽賀淳一先生に挨拶するスレ
新旧アーロンチェアとエルゴヒューマンのステマ戦略を糾弾、ハーマンミラー社、庄文堂、関家具に問う！
ワーキングチェア総合（家具業界でステマ販促が有名なアーロンチェアやエルゴヒューマンのステマ厳禁）
Makita マキタの電動工具
【安くて高品質】SPF材で何作る？11【可能性無限】