+ JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net
このくらい小規模な開発だと
要件定義含めて客とのやり取りと
客に説明するためのドキュメント作りがコストの大半だからな
それを理解しない客は避けるに越したことがない >>463
単純なCRUDアプリであれば、
整合性のある要求仕様を提出しなくても
ある程度のクオリティが上がってくるものだとおもっていました。
こちらは私の完全な落ち度ですね。
ただ、この場合制作会社が
「仕様書がなかったから、或いは具体的な指示がなかったから50,000行を一気に表示しても良いと思った」
として50,000行を一気に表示するようなものを作った、みたいなことはよくあることなのでしょうか?
自分の業界であれば素人のクライアントには合理的な解決法をアドバイスするかなと思います。後で自分が地雷撤去で困ることもあるし、次の仕事がほしいので。 >>466
>単純なCRUDアプリであれば、
>整合性のある要求仕様を提出しなくても
>ある程度のクオリティが上がってくるものだとおもっていました。
アホすぎるww 提案内容が気に入らないなら望ましいと思う内容に変更してもらえばいいだけなのになぜそれができないんだろう?
そこに問題の本質がありそう >>468
日本語の堪能なアメリカ人なんですけど
正しいから直す必要がないの一点張りなんですよね。 >>469
下らない嘘までついて隠さなきゃいけない裏事情があることだけはよく分かった 金もそうだろうけど
どう変更したいかを一切書かないあたりもかなり怪しいわな 契約解除するのがいい
そもそもできない奴に仕事振ってるほうがおかしい 納品まで大詰めで、並行して別の会社を探しており移行に入ります。
ただしミスや納品の遅れを指摘すると、仕事自体を降りるだの、ストアに上がっているガワだけできているバージョンを下すだのと、すぐに感情的になってしまうので対応に苦慮しております。大分気を遣ってるんですけどね。 >>476
2行目から何を言ってるのかわからん
主語は誰だよ 納品まで大詰めでUIのラフを初めてレビューする・・・ガチキチクライアントw 言い訳が幼稚過ぎて笑う
全部自分の能力不足が原因なのにそれに気がついてないのか
それとも気がついていて他人に責任を擦り付けようとしてるのか >>460
>他者のコードを使うと、クオリティの担保ができない
コードを少し見て、自分で似たようなものを作れるはず
>>466
>指示がないから、5万行を一気に表示しても良い
こんな言い訳は詐欺だろ
やらない言い訳ばかりする香具師は、時間の無駄。
結論は出来ないに決まっているから
単なる詐欺。素人をだますのはよくある。
作り逃げも多い。動かなくなっても逃げてしまう
だから、コンサルタントみたいな判定する人が重要。
知り合いから評判を聞くとか、良い人を推薦してもらうとか
それと名前欄に、最初の投稿時の番号をいれて下さい!
どの書き込みが質問者か分からないので >>476
ストアに上がっているガワだけできているバージョンを下ろされると困るとか
成果物の管理方法が杜撰すぎてしゃれにならんな
杜撰な管理方法でも事前に書面による了承を取っていればセーフかもしれんが
取ってないならクライアントから訴えられたら確実に負ける >>480
ご指摘ありがとうございます!
これから名前欄を446で進めさせていただきます。 selectに入るものが何万件にもなるって
伝えていたのか否か、だけじゃろ?
伝えていたなら、そのまま
伝えていなかったら、謝って金払って
作り直して貰えばいいだけじゃん?
みんなそんなに罵倒したりなんだりしなくても… 文句言ってる間にも全件対応すればいいじゃん
なんでやらないの? >>486
私が対応しろということでしょうか?
私的には知り合いのエンジニアに頼んで
TamperMonkeyでウェブを書き換えて最低限の修正をしました。 >>487
お前の立ち位置がわからんし主語がないから登場人物が誰で誰について言ってるのかもわかんねえんだわ
まあそんなんだからコミュ力ないお前の責任なんだろうが >>483
伝えていたか否かが問題じゃないんだよね
伝えてたとしてもUIが自分の欲しいものになってるかどうかはわからないわけで
欲しいものじゃなければ変更してもらえばいいだけなのに
なぜかそれが出来ないというところが問題
普通の契約をしてれば変更してもらえないなんてことはあり得ないでしょ?
叩かれてるのは加害者が都合の悪い情報を隠して被害者かのように振る舞ってるから >>489
会社自体は日本人の社長の会社ですが
担当がアメリカ人なのです。
言語の壁はないということで概ねペラペラなのですが
すぐに感情的になります。
繰り返しですが、そのアメリカ人がこの程度の変更要求をしても
「問題ない」の一点張りで更に食い下がると「プロジェクトを降りる」「アプリをストアから下げる」と度々発言しており、仮に彼が実行したら裁判でしょうが
アプリを完成させるために反論をせずになるべく平穏に収めようとしています。
都合の悪い情報を隠したりはしていませんが
具体的な内容の全てを話せないのは確かにあります。
なお本業でもディレクターなので揉めそうな事件が起きたとしても
度々火消しをして収めていますが、こんな簡単なことで突っかかられたことがないので
ここで質問をしています。 経験がある人は最初の投稿だけでどっちに非があるのかすぐ分かる
技術的な問題じゃないから経験がないとすぐには分からない >>491
一担当者の問題ならその会社に対処してもらえばいいだけじゃん
彼がプロジェクトを降りるかどうかは相手の会社内部の問題
請負契約なら誰が担当しようが途中で交代しようが
契約で求めた成果物を出しさえすれば何の問題もないよ
アプリをストアから下げることの何が問題なのかわからない
ストア管理を含めて契約をしてるなら契約不履行
誰か書いてたけどそれで納品ができなくなるようなら
それは君の会社の落ち度 >>490
お前しかいねえだろ
javascriptスレにプログラマー以外が来るのか?
お前が実装できないとかほざいてるんだろが クライアント(日本人社長とアメリカ人担当者)
446が素人プログラマー アプリ開発のクライアント → 日本人社長とアメリカ人担当者)
446 →上のクライアントから受注してアプリを開発してるプログラマー
外野 → 知り合いのエンジニア >>491
もうちょっと論理的に事実と主観を分けて書こうね
相手の人格否定で自分を正当化しようとしてもいろいろ透けて見えてるから誰も好意的に見てくれないよ
普段からそんな感じだとしたら相手のアメリカ人も相当鬱憤が溜まってたんじゃないだろうか >>495,496
[商流]
顧客企業 → 446の会社 → モバイルとWebのアプリ開発会社
でしょ? >>493
仰る通り、究極的には契約書上は制作会社側の契約不履行になります。
問題の箇所だけにフォーカスを当てると、
「Aで定義したデータをBに紐づける」「Aの数は万人を超える」事は要件定義しておりますが、
「(Aの数は万人を超えるので探しやすい様に)検索機能をつけて紐づける様にして欲しい」と話していませんでしたのでその点は落ち度なのだと思います。
しかし、その指定を怠ると
「Aの数は万人を超える」のを理解しておきながらプルダウンで目視して「Aで定義したデータをBに紐づける」という結果になってしまうのが理解できないのです。
プルダウン機能は当然こちらは要求していません。
ですので、「この仕様で万件の中から1件を目視で探すのは無茶ですよね」と指摘されたら「確かにそうですね、作り直します」で終わる話なのではないかと思います。
この様なことがアプリ本体でも多々あり、その度に担当さんが感情的になってしまうので困ってしまい質問をしています。 >>497
あなたと対立したいわけでないので
もう少し教えていただけますか?
アメリカ人の人格を否定したのではなく
「ただアメリカ人に直してくれ言えばいいじゃん、他に言えない理由があるんだろ」と言われたので「理由は彼がすぐカッとなるから」が答えで、それを正直に答えたまでです。
これは悪かったでしょうか? >>498
違う
アメリカ人基地クライアント → 446ディレクター → エンジニアと知り合いのエンジニア なお私は
>>452
で書いている通り、別業界におりプログラマーではありません。 ここはjavascriptのスレッド
javascriptの質問をどうぞ >>494
私はプログラマーではないし、
あなたの文章にも主語がないですよね
対立はしたくないですが、これは事実なので申し訳ないです。 >>499
まーた都合のいいところだけ答えようとするよなぁ
>>493が書いてる通り1担当者が指示を効かないという問題なら
相手の会社の責任者に言って対応してもらえばいいじゃない?
なんでそれをしないの? マジでこいつ救いようがないな
担当者がアメリカ人だとかすぐ感情的になる(と君が感じてる)だとか全く関係ないじゃん
自分のマネジメント能力の欠如が一番の問題なのにそれを自覚してるようにすら見えない
自分の責任は放棄しておいて開発会社の担当者に責任転嫁して自己正当化しようとしてる
挙句の果てに俺はWeb制作ならマネジメント経験あるんだぜみたいなどうしようもないアピールまでしちゃう
はぁ〜 >>507
最終的にはしますよ。
その前段階の話をしています。 >>508
何度も言いますが自分の落ち度は認めています。
またアピールをしたつもりはありません。 >>508
「俺はWeb制作ならマネジメント経験あるんだぜ」
どこで言ってます? >>508
あなたには全く関係ない様に見えても私には大いにありますね。
ただし、そういう事情は質問の内容とは関係ないので最初は話していません。
「なぜ制作会社に『直してくれ』が言えないのか?」という内容の質問に理由を答えたまでです。 >>499
>「Aで定義したデータをBに紐づける」「Aの数は万人を超える」事は要件定義しておりますが
こういうのは要望の羅列であって要件定義したとは言わないんだが
それはいいとしてAで定義したデータをBに紐づけるのならブルダウン以前に
Bの新規登録画面でAを選択させるというのは依存関係的に間違い
>「この仕様で万件の中から1件を目視で探すのは無茶ですよね」
数文字タイプすればいいだけだから無茶ではない
それを許容できるかどうかは非機能要件次第
定義してないなら愚痴以上の何ものでもない
>「確かにそうですね、作り直します」で終わる話なのではないかと思います。
どう作り直して欲しいのか具体的な指示なしにそうはならない
具体的な修正指示は出した?
指示に従わないならこんなところで愚痴らず会社対会社で対応するだけだと思う >>507
あなたが思う、私が答えていない都合の悪いところはどこですか?
508さんも私が「自己を正当化」していると指摘していますが、
匿名の掲示板で不特定多数に「私は間違っていない」と主張したところで
何も解決しないですし、何なら自分の立場を良く見える様に作り変えることだってできると思いますがそれをしたところで何の意味もありません。
あなたに自分の主張を通したいと思っていません。
またそのために不都合な部分を隠す、捏造するようなことはしていません。
質問をしているだけです。 >>509
なんで「最終的には」なんだよ すぐやれよw
マネジメント能力が欠如してるのはそういうところだぞ
その前段階の話て「担当者が言うこと聞いてくれないんです〜どうしたら言うこと聞いてくれますかね〜〜」とか5chでウダウダやってるだけだろ
しかもJavaScriptスレで >>513
ご指摘ありがとうございます!
>Bの新規登録画面でAを選択させるというのは依存関係的に間違い
どうするのが正しいでしょうか?
もしよろしければ今後のためにご教授願いたいです。
>数文字タイプすればいいだけだから無茶ではない
制作会社ではAの項目に入力されたデータ(ユーザーのメアドになります。)
をBでプルダウンで表示し、そこから目視で選択せねばならない仕様でした。
それが非合理ではないかという私の指摘に対し制作会社が「そうは思わない」と
主張し平行線になっています。
そこで知り合いのエンジニアに頼んで、TamperMonkeyを入れてスクリプトを入れてBのプルダウン機能を外し、文字入力に切り替えオートコンプリートにして
数文字タイプすればいいようにしました。
>具体的な修正指示は出した?
知り合いのエンジニアがささっと作ってくれたプロトタイプの動画切り出しを送り、
「今はサンプルで登録されている20-30人のメアドで見ているのでプルダウン形式で良さそうだが、実際には前から話している様に万人規模の管理になるのでプルダウンで目視で探すよりも、このサンプル動画のようなオートコンプリート機能、または検索機能が良いのではないか?」と提案しました。
そうしたところ、「他人のスクリプトを入れるのはクオリティの担保ができないし危険」との事です。
別にそのものを使えとは言っていないのですが「提案を取り入れる」というよりも「今のままでいいので拒絶する」というスタンスになってしまっています。 >>516
あなたのマネジメント論ではそうかもしれませんが、
数社が参加しているプロジェクトなので穏便に済ます必要があり
私は「トップに話して即解決する」という選択肢を選んでいません。
ですので出来るだけ波風を立てず、技術的な解決をするためにここで質問を書き込んでいます。
その過程で技術面からは外れた質問を投げかけられたので質問にそのまま答えています。
私は自己の問題解決のために寄せられた質問に対してより正しい回答が返ってくるのであればという思いで答えているだけです。
その点に関して不快に思ったのならば謝りますが何卒ご容赦ください。 結局どうしたいんだ?
そのアメリカ人を我々が説得すればいいのか? >>519
・アメリカ人が主張する「数万件をプルダウンで目視するという機能が一般的である」ということが客観的にみて正しいと言えるのかというご判断がいただきたいです。
・私は非合理であるという立場ですが、もし皆様の中に「非合理である」という判断をしてくださった場合、現状が非合理であるとする客観的な証明をご教授いただきたいです。
・また代替案のスクリプト処理の方法のアドバイスを伺いたいです。
前述の通り、ここでの質問と並行で進めてくれていた知り合いのエンジニアによって当座は問題は解決しましたが管理画面そのものは私の私感では「良くない」ものであるという判断です。
アメリカ人は直す必要がないし直すなら追加予算をくれと言っております。
お金が無い訳ではないですが、知り合いのエンジニアの方が明らかに合理的な解決をしてくれたので、追加予算を支払ったところで劇的に改善は見込めないので揉めずにお仕事をしていただいた分のフィーを支払い、次期に向け別の会社を探そうと思います。その際にどの様にすると良いのかアドバイスをいただきたいのです。 素のhtmlのselectの子要素のoptionを数百以上も表示するのは一般的ではない
なぜなら
・画面操作が重くなる
・スマホを使う場合、iPhoneとAndroidではそれぞれ独自のコンボボックスUIになる
・データベースへ無制限selectはアンチパターン
・データベースでメモリリークを起こす可能性がある
・ネットワークの転送効率が悪くなる データベースに大量の行となるselectはアプリ側で必ずページネーション処理を行うことが一般的
・ページネーションとは、1回のクエリを1000件ずつのように小分けにしてデータを取得すること
・データベースの効率化とメモリとネットワークの転送効率のため
・UIは2パターン
1. 検索ウインドウとデータテーブル
2. 仮想スクロールによる独自コンボボックス >>448
モザイク処理をしているけど、おそらくこれは「メールアドレスと名前」のプルダウンになっているのだと思うが、これを「参照」または「リファレンス」というデータベースで関連づけをするためのプルダウンなのだろう
そうすると余計に検索ウインドウを使うのが一般的な設計になる
メールアドレスまたは名前でlike検索をすると候補が出てくる
そして候補の中から1つ選択する
参照対象を全てプルダウンに表示するなんて、世界中みてもそんなクソ設計はあり得ない 数万件を表示するなど、あり得ない。
普通は分割するとか、page nation を使う
こういう要望を聞いたら、おかしいと大激論になるはず。
数万件は無理だから、設計のやり直しになる
双方で議論すべき。
議論しなかったら後でもめる TamperMonkeyのスクリプト納品したらウケるな
数万件のプルダウンに負けず劣らず非常識 つまり見解の相違でしょ。
何の仕事でも、こういう事は起こる
例えば演劇で、その演技はおかしいから変更してと言っても、相手が突っぱねる。
普通は従わなければ首で良い。
ところが首にできないというだけの話でしょ
従わない香具師は一杯いる。
だから、こういう香具師に引っ掛からないようにするために、調査費用を掛ける
技術力のない香具師が従うわけない。
できないから無理でしょ
そいつらは技術者じゃない。
技術者なら徹底的に議論して、方法を考えるはず
感性が合わないとか、仕事ができない香具師とは、一緒に仕事なんてできない。
典型的なGoogle が採用しない人。
言い訳ばかりして、何もできない香具師 >>520
相手の国籍この話に関係ある?
海外に発注してたりして文化や商習慣や法律の違いが明らかに影響する話ならともかくそうじゃないところでアメリカ人アメリカ人と連呼するのは差別主義的な行為だよ >>518
相手の会社のプロジェクト体制は作業担当者の上が会社トップなの?
であれば担当者間で解決できない話はそのトップに通すしかないでしょ
常識的なプロジェクト管理をやっていれば
プロジェクト開始前にプロジェクトの体制図を作って
指揮命令系統や権限や役割分担を明確にして
公式なコミュケーション方法やエスカレーション方法が事前に定義する
UIレビューには誰が参加して誰の承認が必要なのか?
意見が対立したときの最終意思決定者は誰になるのか?
レビュー結果としての正式な修正依頼はどういう方法で行うのか?
↑これらも事前に明確になってる
今回の件で「プルダウンじゃだめだから〇〇に変更してください」という修正依頼を
相手の会社の責任者や自分の上長やその他の関係者にも見える形の
公式なコミュニケーション方法を使って本当に実施したのかな?
それに対して正当な理由なく「今のままでいいので修正は拒絶する」という回答を
同じように公式なコミュニケーション方法を通して得たのかな?
であれば事前に定義されたエスカレーション方法に則って解決を測ればいいだけ
普通のプロジェクトならどっちもメール1通+打ち合わせ1回とかで済む話 (続き)
正直なところ関係者全員が見てる中で
正当な理由なく「今のままでいいので修正は拒絶する」と回答するとは到底思えないから
それまでの段階でこっちが想定している前提と異なる一般的ではない状況があるのだと推測してる
>>517を読むとしきりに「提案」という言葉を使ってるのが気になる
まるで開発会社のほうに意思決定権があるように聞こえる
もちろん数万件のプルダウンによるUIの使いにくさや性能問題を解決しようとすると
プロジェクトとしてそれよりも優先すべき要件(性能・セキュリティ・品質などの非機能要件や、予算や納期)を満たせなくなるという正当な理由があるなら拒否されるのも道理だけど
その拒否自体が承認するかどうかはお金を出してる顧客側が判断することのはず
開発を受注した相手方の担当者一人と発注側から君一人しか登場人物が出てこないのもおかしいし
UIレビューを納品まで大詰めになった段階で一人でやってるのもおかしいし
実際にWebアプリを使うエンドの顧客がレビューしてる様子がないのもおかしい
数万件のプルダウン以上に不自然なことだらけ
そもそも5chに相談する前に上司には相談した?
したのであれば上司はどう対応しろって言ったの? >>520
>その際にどの様にすると良いのかアドバイスをいただきたいのです。
要件定義とプロジェクト管理をきちんとやりましょう
あなたの会社にできる人がいないのであればできる人を雇いましょう
あなたの会社に要件定義がきちんと行われているかどうかを
適切に精査できる人がいるのであれば
要件定義については設計・実装を行うシステム開発会社に任せるのも選択肢の一つです >>528
上で説明したかと思いますが、
「アメリカ」を差別している訳でなく(むしろ好きなので積極的にこの制作会社を選んだポイントでもあります。)
日本語の会話は全く問題ないと説明を受けたのに局面で私の意図を理解してもらえないところです。
それが人間そのものの意見の相違なのかもしれないし、日本語が通じていないのかもしれないということです。
また彼が英語圏の方であるためデータベースの人名が
例えば 山田太郎 佐々木花子というユーザーはラフで
太郎山田 花子佐々木 というように表記されていました。
アメリカ人の彼の部下には日本人スタッフもいるのにこれがチェックを経ているはずなのに
こちらへ提出されるのに違和感を感じました。
もしも日本人同士で仕事をしていたらこういうことは起こり得ないと思ったので
「日本人以外」という意味で説明しています。
この話の流れで人種差別という議題を脇道に逸らすようなことをする合理性がないのはご理解いただきたいです。 >>521-524
アドバイスありがとうございました。
私の知識不足で一部理解できない箇所がありましたが
知り合いのエンジニアに聞いて理解できました。
今後の参考にさせていただきます。
貴重なお時間をいただき本当に助かりました。
重ね重ねありがとうございました! >>526
おっしゃる通りです。
こちらとしてはリリースまでは小さな波は仕方ないにしても大きな波乱は起こせないのです。
私の知り合いなので完全に客観的な判断ではないかもしれないですが
知り合いのエンジニア2名に見てもらったところ技術的に優れているとは到底言えないという評価でした。
その知り合いの一人がスクリプトでその場しのぎで使用できる様に作り変えてくれたのです。 >>521
>・スマホを使う場合、iPhoneとAndroidではそれぞれ独自のコンボボックスUIになる
コンボボックスにはならないよ
むしろコンボボックスになってくれるなら自由に入力ができて助かるじゃないか
>・データベースへ無制限selectはアンチパターン
ドロップダウンリストに表示する要素は件数がほぼ固定なので全件SELECTが使われることも多々ある
全くアンチパターンではない
数十件から数万件のようびに大きく数が増加する項目をドロップダウンリストにするのが間違い
>・データベースでメモリリークを起こす可能性がある
さすがにそれはない >要件定義とプロジェクト管理をきちんとやりましょう
コレに尽きるね >>529
最終的には話そうと思っておりますが、
制作会社の身バレを防ぐために詳細は割愛させていただきますが、
制作会社トップと担当者のトップの関係がややこしいようです。
状況を自分なりに理解してなるべく波風を立てずに内部で解決をしたかったのですが
叶わない様ですのであなたや他のみなさんの仰る様に
双方の立場が複数人いる場所で状況を説明すれば(私の主観ですが、一般的には)
数万桁をプルダウンで検索する方法は適切ではないので
ご理解いただけると思っています。
>普通のプロジェクトならどっちもメール1通+打ち合わせ1回とかで済む話
本当におっしゃる通りです。 なんかもう言い訳ばっかだな
自分の落ち度だということを理解してるようには全く見えん >>530
実際に登場人物は双方合わせて15人程です。
530さんが不思議に感じている、開発会社側に意思決定があるように見えるとする点ですが
BTOBのマッチングサイトで弊社提示予算で応募してきた会社さんの中から決めました。
この会社にはとても感謝しているのですが、本質問内容以外にも諸々問題が生じており、その度に「あなたのプロジェクトに共感して安く作ってやっているんだから細かいことは言うな」というスタンスで強気なのです。
こちらが提案しても前述の通りpjtを放棄しようとしたり、感情的になってしまいその度に両者の関係にも良くないですし、私自身もまあまあ心労です。
私はアプリ開発には明るくないのですが、本領域では受発注どちらも担当しているので双方の立場の気持ちがわかるので、「安く作ってくれている」のは嬉しいですが美声を持ったミュージシャンであったり、球界屈指の豪速球を投げるピッチャーだったり、彼自身の成果を見るに唯一無二の存在とは思えませんでした。
そこで「あなたでなくてもいい」とは口が裂けても言えないので波風を立てずに制作者の機嫌を損ねずに及第点のものを作ろうとしているのです。
ただこれは技術的な問題の外であるために説明していませんでした。 学生がサークルの延長でやってるみたい
こりゃ仕事を降りると言うほうが正常 横だが
>>511
> 「俺はWeb制作ならマネジメント経験あるんだぜ」
> どこで言ってます?
は
> なお本業でもディレクターなので揉めそうな事件が起きたとしても
> 度々火消しをして収めていますが、こんな簡単なことで突っかかられたことがないので
> ここで質問をしています。 (>>491)
と
> また自分は普段別の領域で制作業務を行なっており
> アプリに関して無知ですが制作系はそこそこのクライアントをこなしています。(>>452)
だと思うよ。
ただ俺も「制作系」って何ぞ?このスレだからWeb制作=Webサイトは作れるがアプリを作った事がないから発注した、
だからプログラマではあるのだろう、とは推測したが、
> 別業界におりプログラマーではありません。(>>502)
なら、普段はどんな事を管理してるの?
そしてプログラミング/ITの事を何も知らないのに何故今回のマネジメントが出来てるつもりなの?
>>520
> その際にどの様にすると良いのか
無能な「バッテリー女」型ディレクター()の446を即刻クビにしてマトモにマネジメント出来る奴に託す事、だね
プロジェクトを止めてるのは自分自身だとも自覚出来てないようだし
つか、何度も言われてるが、進める気なら、
追加費用+追加期間で再発注する、受けてもらえないなら他を探す、以外になくて、
早ければ早いほどいいから今すぐやれ、でしかない
ここでいくらウダウダやってても何も解決しないし、時間を浪費するだけ
(技術的な問題としては要件定義すら出来ない=発注能力のない446が発注してる事であり、446がいる限り解決しない)
てかお前らが割と抑制的なのにびっくりだわ、多少はジジイになって丸くなった感じか? >常識的なプロジェクト管理をやっていれば
>プロジェクト開始前にプロジェクトの体制図を作って
>指揮命令系統や権限や役割分担を明確にして
>公式なコミュケーション方法やエスカレーション方法が事前に定義する
>
>UIレビューには誰が参加して誰の承認が必要なのか?
>意見が対立したときの最終意思決定者は誰になるのか?
>レビュー結果としての正式な修正依頼はどういう方法で行うのか?
これらを総スルーしてるところを見ると何一つやってないっぽいね
開発の素人がマッチングサイトで拾った格安の会社と何も決めずにやれば
そら失敗しないほうが奇跡だわ >UIレビューを納品まで大詰めになった段階で一人でやってるのもおかしいし
>実際にWebアプリを使うエンドの顧客がレビューしてる様子がないのもおかしい
>数万件のプルダウン以上に不自然なことだらけ
>
>そもそも5chに相談する前に上司には相談した?
この辺も当たり前にやるべきことを全くやってなさそうだよね
5chに相談する前に上司に相談しろは全くもってその通りだと思う >>541
>「バッテリー女」型ディレクター
なるほどな
誰とも話が噛み合ってないようにみえる正体はこれだったか >>541
なるほどであれば推測ですので
そんなことは言っていませんね。
事実とは異なります。 >>545
そうだとして、なら何故このスレなのか?ということと、
マネージメント出来てるつもりな本業とはどの分野なの?という話
ただ、多分その本業でも他の誰かが細かくフォローしてくれてるのに気づけず、(※)
自分では勝手に出来てると勘違いしてるだけで、実際はまるで出来てないと思うよ
IT業界だけマネージメントが特殊というわけではないので
(シビアではあるけども)
俺も>>498だと思って、
てっきりそのアプリのバックエンドをJava等で開発してる連中が、
管理ツールのフロントエンドだけ他会社に発注したのかと思いきや、まるでそうではないし
(まあJavaの連中なら要件定義はWeb系とは比較出来ないほどガチガチにやるはずだが)
無能が仕切るから失敗した、という典型的で一番マヌケな失敗パターンをやってるだけ
要件定義すら出来ないのだから、最低限BtoCの業者を探すか、その手間まで含めて発注するべきだった
BtoBならプロ同士だし、当然ある程度仕事の進め方をお互いに知ってる前提だから、
素人がデタラメやったので当然のようにキレられてるだけ
(※)
余談だが個人的に昔からアニメ好きで今でもよく見てるのだが、
最近「追い出され系」が増えてるのが(悪い意味で)少し気になってる
直近で見たのは「真の仲間じゃないと勇者のパーティーを追い出されたので、辺境でスローライフすることにしました」で、
内容は「実力不足として追い出されたが実は調整役としてすさまじく有能で、居なくなってからパーティーはすぐ機能不全になりました」なのだが、
こういうアニメが作られる=需要がある=共感出来る奴が増えてる、って事が少し病的だよと
そして(※)の職場でもこういう忸怩たる思いを持ってる奴が多分居るはず 制作もディレクターもWebとは関係なかったんだな
道理で制作という用語の使い方が独特だったわけだ
開発業務を外注する際に常識的にやるべきことを
ことごとくやってないにも関わらず
我関せずな態度なのも少し合点がいった >>546
自分の憶測が間違ってて長文で憶測の言い訳しててワロタ
自分語りゴクローサンwww そうかぁ?
俺は446のはひたすら言い訳に聞こえるけど
546のは言い訳には聞こえない
追い出され系?の話は微笑ましく読ませてもらったが ここの住人はケチくさい
誰もアドバイスしてくれず批判ばっか めっちゃアドバイスしてくれてるじゃんw
アドバイスとして受け取れない狭量さをまずどうにかしないと やるべき仕事を全然やってないのに
俺はやってるアイツが悪いんだという無責任傲慢体質だから
聞く耳を持っておらずアドバイスにも気付けないんだろう
正しいから直す必要がないの一点張り
ブーメランだな せっかく非プログラマーが質問してきたんだから優しくアドバイスしてあげたらどうだ?
なぜそんなに排他的なのだ
これだからプログラマーはと言われて困るのはキミたちだぞ >>551
初手>>450-451から大正解ですやん
その後も妥当なアドバイス多数だし。ほぼ無視されてるだけで
知り合いのエンジニアとやらにこの顛末を読んで貰って妥当性を判断して貰うのがいいよ
>>554
> 優しくアドバイスしてあげたらどうだ?
ではお前がどうぞ
> これだからプログラマーはと言われて困るのはキミたちだぞ
多分これは風向きが変わりつつある
東証は富士通しか受けてくれなくなってようやくだが気づいてきてる
.> 15年前の記者会見はシステム障害そのものよりも「事件」だった。システム障害の当日、まだ原因も究明されていないのに、東証の出席者が「富士通に対する損害賠償請求も辞さない」と言い放ったのである。
> 翻って今回のシステム障害では、当日の記者会見で宮原幸一郎社長が「市場運営全体の責任は我々にあり、富士通への損害賠償の請求は現在考えていない」と明言している。
> ttps://xtech.nikkei.com/atcl/nxt/column/18/00148/100800140/
グリコとデロイトトーマツが潰れれば面白くなってくる
> 語弊を恐れず言えば、発注元の企業は発注先のシステム開発会社を“下”に見る傾向があり、プロジェクトの途中で当初取り決めた仕様の変更を求めてきながら費用の増額は認めないということはザラにある。
> ttps://biz-journal.jp/company/post_380797.html
ただWeb系はこいつらなんて死んでどうぞで全く関係ないと思うが
広告と課金ではあるが、なんだかんだでも自前で稼いでいるのは強い
446のような零細キチガイ地雷クライアントには関わるだけ無駄だし >>553
傲慢というより傲岸不遜かな
>>554
すごく優しくアドバイスされてると思うよ
今回の質問者は自分に否があるにも関わらず相手の技術者を必要以上に見下してバカにしてる
このスレの人達に対しても同じで技術者に対する敬意が1ミリも感じられない
それに元々技術的な質問がしたいのではなく担当者を説き伏せる材料として
自分の意見に同意してくれるレスが欲しいだけ
「私的に知り合いのエンジニア5〜6人に聞いてみたんですけど、
数万件のプルダウンで目視による選択はありえないって全員言ってましたよ」
などど言うんじゃないか
こういう相手に対して一連のレスはすごく優しい
俺のレスもなぜ相手が反発するのかを”丁寧に寄り添って”教えてあげてるのでものすごく優しい >>555
グリコまだ続いてたのか
ここまでの酷いシステム障害は記憶にないな >>556
>すごく優しくアドバイスされてると思うよ
どこどこ?? 446はとても誠実で質問も主張も一環しているだろ
なのにこのスレの住人たちは単に446の揚げ足取りばかり終始して解決策の提案すらしない
技術者たちへの敬意の前にディレクターへの敬意はないのか? なんか既視感あると思ったらこいつだな
ttps://egg.5ch.net/test/read.cgi/mac/1538778915/358
>>560
いやもうそういうのいいよ
つまらない >>560
良いディレクターがいることは否定せんが
ディレクターという総体に関しては
まあろくなもんじゃないのは
みんな知ってるからじゃろ >>539
>安く作ってやっているんだから細かいことは言うな
お金をもらう方として、生意気すぎる!
こんな香具師は首!
>「あなたでなくてもいい」とは口が裂けても言えない
決定権がある人と話し合うしかない
要するに、仕事のやり方・決定権の質問ですね。
JavaScript とは関係ない >>561
マルチか。さもありなん
人格に問題があるのはアメリカ人ではなく446なのは見えてたが
しかしこれ、クレジット/銀行がやってる信用情報DBが必要とされてるのだろうね
乱立気味のマッチング系もこの方向で淘汰が進むといいが
(使った事無いが)メルカリがヤフオク倒したのはこの辺の違いだと聞くし >>557
正直さっぱり分からんがな
遅延しても金は払っているので、グリコが「金さえ払えばいいんだろ」のノリで仕様変更を繰り返した可能性はある
しかしどのみちテスト/切り換えはデロイトが仕切ってるはずで、こちらも相当酷い
切り換え前に並立してテストはしてるはずで、当然機材も残ってるのだから、戻す事すら出来ないって何よと
SAPは一時期無駄に単価が高かったが、これだと3位か
//www.devjobsscanner.com/blog/top-10-highest-paid-programming-languages/
ただその理由が「あんな糞言語二度と使いたくない」だったし、wikiでさらっと見る限りCOBOLに近いから、
インメモリDB+JSの何かが出てくればSAPもブチ殺せるのかもね >>556
446の要求に50000桁のプルダウンを作る開発会社
446の質問にアニメの思い出で返す香具師
それを
>すごく優しくアドバイスされてると思うよ
と理解するやつ
3人は気が合うだろうな 実務経験がないルビーくんが何をいっても虚しいだけだぞ >>566
50000桁ww
どういう間違いだよwww >>566
日常の業務も碌にこなせていないだろうな >>556
>446は傲岸不遜
>俺のレスもなぜ相手が反発するのかを”丁寧に寄り添って”教えてあげてるのでものすごく優しい
このことを傲慢というんだ 見下してるとか傲慢だから質問者はだめなんだって言いたいやつは
実社会で上司なり発注先に鬱憤が溜まってるだけやろ
446は褒められたものじゃないがそこまでの情報はあいつの文からは読み取れんだろ ちなSAP、以下らしい(上2つの中身が非常に分かりやすい、一番下は出所)
//x.com/JapanTank/status/1782434284432982065
//x.com/atrzdflw/status/1782987835047628807
> //agora-web.jp/archives/240425021511.html
つかこれ、かなり詰んでるし、
JSでSAPに代わる物を作れたらSAP/COBOL/Javaまとめて殺せそうな気もするが、
誰かやってないんかね?
そもそも基幹システムをJSで組もうという勇者が出てくるかという話はあるが
でもTSなら技術的な「安全性」はJavaとも大して変わらないとも思うし >>571
>このことを傲慢というんだ
ネタに反応してくれてありがとう() >>572
> そこまでの情報はあいつの文からは読み取れんだろ
それはお前もコミュ障が過ぎる >>573
何もわかってなくてワロタ
普通のアホレベルですらjsで代用なんて発想にはならんのに笑 >>446
結局君は何業界なの?
アバウトでいいから答えてもらえればお互いに非常に有益なのだが
君は俺達を気に入らない。俺達も君とは仕事したくない
なら、住み分ければいいだけだ
特定したいわけではないので、かなりアバウトで十分だ
例えば俺らIT従事者は日本に大体100万~150万人居ると言われている
全労働者における割合としては1/40~1/60程度となり、クラスに1人、のイメージになる
JSerはその内の1/10~1/3程度だから、学年に1人、程度になる
この程度なら特定は無理だろ
だから同程度の、クラスに1人程度のアバウトさでよいので、君の業界を含んだ範囲で答えてもらえれば非常に助かる
仮にそれが1/30の範囲なら、俺らは1/30の潜在顧客を失うが、君と遭遇する可能性をゼロに出来る
君は俺らみたいなくそったれな連中を最初から相手にする必要がなくなる
お互いに非常に有益だと思うが、どうだろう? >>569
10^5,000はなかなかに天文学的だなあ
ロマンがある Youtubeの動画でも制作してるんでしょ
ディレクターのマネジメント能力が皆無でも
ゆるい要望を渡すだけで制作物ができあがってくる業界 >>577
君とか俺とかよくわかんないが
俺は君と同業者だが一緒にされたくないなあ
分母が大きいんよ このコミュ障 >>580
今回の質問者は自分に否があるにも関わらず相手の技術者を必要以上に見下してバカにしてる
このスレの人達に対しても同じで技術者に対する敬意が1ミリも感じられない >>581
ならお前が助けてやれば解決だよ
で、お前の書き込みはどれなん?
見たところ446派なのはルビキチと自演?っぽい奴だけだが 俺は446と仕事で会いたくないからどの業界にいるか教えろ
…って教えるバカいますかね >>582
匿名掲示板での煽りとかは別にいいんだよ
仕事でマネジメントしなきゃ人間がマネジメントされる人間を必要以上に見下してバカにしてるのに
相手に反発されて困るとか相手が動かなくて困るとか戯けたこと言うなよって指摘してるだけだぞ
本人はそれが相手には伝わらないようにうまくやってるつもりっぽいけど
ここに書いた文章であれだけにじみ出てれば絶対相手にも伝わってる
拒否られたのはそれまでの経緯によるところが大きいんだろうけど
そこはひた隠しにしてるから本当の真相はわからない >>586
お前の〜に違いない
〜に決まってる
はよくわかんない
ここのみんなもそう思ってるに決まってる 仕事でマネジメントしなきゃ人間をそんなにバカにすんなよ
かわいそ人間じゃーん 50000桁に匹敵するバカさ
煽りで誤字はやっちゃいかん >>586
>匿名掲示板での煽りとかは別にいいんだよ
なら446の細かいことも別にいいだろw
逆にこんなにしつこく絡む理由が知りてーわ
お前が446は開発会社をバカにしてると感じるのはお前の勝手
それで446に当たるのもお前の勝手
ただし「俺たち」っていうのは止めろ >>593
うるせーな!
また今の状況を漫画で例えるぞ! >>585
居るだろ。俺もそうだし
てか多分な、考え方が根本的に違うんだよ
ストーカーに付きまとわれない為の方策は?と聞かれたとき、
俺なら、「適度に嫌われる事だ」と返す
メチャメチャ嫌われたら、ストーキングされて殺される。この前の新宿タマワン頂き系女子がこれ
メチャメチャ好かれたら、ストーキングされてこれまた下手すると殺される。小金井ストーカー殺人未遂事件がこれ
だから、相手からの好感度も調整して、喧嘩はしてないけど何となく疎遠、という適度な距離を保つんだよ
これを、ひたすら貢ぎたくはなるが、全然好いてもらえない、という距離に設定すれば頂きりりちゃんになるわけ
好かれようとしても誰からも好かれないコミュ障には到底無理な話だが、
多分普通にコミュ上手な連中はこの手の調整はしてるよ
そして人類に対しての永遠の頂き系がネコなわけ
違う例で言うと、DQNが河原でBBQしてたら距離を取るだろ、これと同じ
そして今回の場合はお互いが相手にとってのDQNなんだよ
だからお互いに距離を取るのが妥当な平和的解決手法であり、
446に「プログラミング案件発注するな」はさすがに無理筋なので、
せめて避ける為の指標を提示してくれればこちらが避ける、と言っているわけ
そして最も分かりやすいのが446の業界だから、広めでいいからよろしく、というわけ
ヒントを教えてくれれば、446と合わない連中は避けるし、
>>560,>>581のような446派の連中は積極的に446を助けやすくなる。だからこれは446に取っても利益だ
今回のはBtoBではあり得ない話だが、
BtoCでマネジメントを放棄すると100%に近い確率で発生する典型的な失敗パターンなので、
この意味ではBtoCのノウハウを持ってる奴にとっては対処出来る範囲のはずだから、連中に任せとけばいいんだよ
BtoB専用機が出張る必要なんて無い。俺なら446もいけるぜ!と思う奴だけが挙手すれば済む話
無知なのか背伸びしたのか知らんが、BtoBで選ぶからおかしな事になる
だから446は初手から間違ってる(その後も色々酷いのだとも思うけど) 揉め事は置いといて
5万件のメアドからひとつを選ぶUIは
どんなのがベストなのかね?
10件ずつ羅列してページングも
5,000ページは使い物にならなさそうだし
文字列検索するにしても
文字数が少ないうちは万単位で返ってくるし
先頭のアルファベット・数字でわけても
50,000÷36で1400弱あるし
わりと難しそうな気がする >>595
>ストーカーに付きまとわれない為の方策は?と聞かれたとき、
>俺なら、「適度に嫌われる事だ」と返す
じゃあこういう奴には近づかない方がいいな >>597
だから避ける為のヒントをくれと言ってるんだよ
お互いに不幸になるのを未然に防げるから
そして実際、適度に嫌われる程度には叩いてるだろ
でも恨まれるほどでもないだろ
(とはいえ匿名掲示板でどれだけ叩いても大して問題なく、
逆に実名、特に仕事場ではかなり気を使うべきだと思うし、実際446はヤバイレベルだと思うよ
その「アメリカ人」に刺されても、自業自得かも?と思える程度には酷い) >>595
聞いたこともない漫画で例えてくれよ
前みたいにさw
たとえが下手すぎw >>596
それについては色々思うところがあるが、
これまで既にそこそこ妥当だと思える提案も投稿されているし、
また俺自身の見解は446を利する事になるので今は投稿しない
投稿するなら446のプロジェクトが確実にポシャった後、具体的には半年後以降にする
俺は今現在周りをウロチョロしてる「煽って情報を出させようとする奴」は積極的に殺すべきだと考えているので、
この方法で殺す
なので気になったら半年後以降に声をかけてくれ
もっとも、俺が半年後以降にこのスレにいるかは不明だが
ただまあ、勿体ぶって何だが、上記の俺の「見解」も所詮はデタラメな推測での提案であり、
実際の446の案件とは異なるので、仮に今開示したとしても糞ッタレな見解でしかない可能性が高いから、
446派の方々も大して気にする必要はない
結局の所、中身の詳細が分からない事には最適解なんて分からないし、
推測合戦したところで多分実にはならないよ
それでもやるのはどうぞご自由にだが、俺は上記の通り参戦はしない
ただ、その「アメリカ人」は全部見た上で判断してる
で、446よりは「アメリカ人」の方がマトモだから、彼を信じるとして、彼の言うとおり「これが正しいんだ!」となるパターンは、あるとは思うよ
それを選択する奴が居てもおかしくない、という程度で
だからデータ処理手法について議論したいのなら、非446案件を持ってきてくれ
それならつき合ってもいい
とはいえ、今だと446がさらっと混ぜてくる可能性もあるので、現実的はこれも半年後以降だな >>595
>人類に対しての永遠の頂き系がネコなわけ
イヌに決まってる!!!ふざけるな!!!! >>604
とても参考になる意見なので
後でまとめて見たいので
ID表示してもらえませんかね? >>604
>そこそこ妥当だと思える提案
フン、失礼な
そこそこで悪かったな >>596
5万件のメアドから正しいメアドを
メアドだけを頼りに選ぶという業務プロセス自体に問題がある
メアドにだけ依存してると見間違いやタイプミスが必ず発生する
発生したら他人のメールアドレスに紐づけることになるので致命的
UIを考える前に業務プロセス考えましょうといういい例 土日の寂しいおまえらにぴったりだな
446に感謝しなさい 鬱憤溜まってる系は↓こういうやつだから
ここの住民でそれっぽいのはいないので心配なし
ttps://mevius.5ch.net/test/read.cgi/tech/1708677472/982
どんぐり導入されてから過疎ったけど
常時即レス罵倒返ししてたようなやつが激減して平和 >UIを考える前に業務プロセス考えましょうといういい例
これだけじゃ伝わらないかもしれないから一応書いておくと
業務プロセスを考えてそれを要求仕様としてまとめてから
開発者に伝えるのは基本的に開発を発注する側の仕事だからね
業務プロセス設計を含めてやってもらいたかったら
一般的にはコンサル契約で別途それなりの費用を払う必要がある プルダウンとドロップダウンってどっちも同じ意味で使う人もいるけど元来は微妙に違うものだよね? >>610
一応釣られておくとな、
見解の相違は推定の違いから生じてるから、
そいつから見れば俺の提案も「そこそこ妥当」程度で、それ以上白黒つけようもないんだよ
だから大してやる気もないわけ
ただまあ、数年前と比べてお前らがすげえマトモになってるので驚いてる
どんぐり効果なのかもしれんが(>>616) 周りのノイズに乗せられてどんどん446に憎悪をつのらせていってるのが狂気で震えんなw
なんで発注がクソで殺傷事件になんねんw 俺の推測だとアメリカ人ってのは嘘だと思うぞ
咄嗟に作った嘘設定
急に取ってつけた様にでてきた
なんか後ろめたい隠したいことがあるんだろう ttps://egg.5ch.net/test/read.cgi/mac/1538778915/358
>制作会社にアプリの制作を依頼しています。
>アプリ内で使用するID(メールアドレス)とパスワードを忘れた場合の対処ができていなかったのでお願いしたところ、
>「メールを配信することになるので、Sendgridみたいなメール配信サービスの登録が必要。」
>という返事が返ってきました。
>他に方法はないのでしょうか?
これ読むと開発担当者はすごくまとも
対して446は・・・ >>613
いや、別にメアドに拘らなくてもいいのでは?
5万件の何かから
ひとつ選ぶUIよ >>624
あれはまんさん特有の謎マウント、真意は
「アメリカ人」
(と仕事してる私すごいでしょ!ホラ見て見て!
でもこんな事になるのなら「アメリカ人」なんて選ばなければよかった…可哀想な私…)
だと思うぞ
・446は究極の他責タイプ=何であれ自分は一ミリも悪くなく、全ての問題は他の誰かが悪いもん!
だから、他者に責任転嫁する為に何らかの理由を探してきただけで、
今回たまたま「アメリカ人」だっただけのこと
仮に日本人なら、例えば
・「関西人」ってこうなのでしょうか?
・「田舎者」だから話が通じなくて…
とか、何でもいいから理由を探してきて他責するだけ
そしてまんさんは奇妙なところでマメにマウント合戦する事が多いので、
彼女的に「自慢出来て他責出来て一石二鳥」だから「アメリカ人」がいきなり出てきてる
…なんだが、思うに職場で事故る場合って、この手の因子が重なった時だと思うんだよね
・446は無限要求エスカレーター=際限なく要求をつり上げていくタイプ
でもありそうなので、一度折れたら永遠の隷属と服従を要求される可能性があり、
これを突っぱねられない奴にあてがった場合に自殺とかの事故になると思ってる
(まあ今回は突っぱねてきてるので対応としては正しい)
だから446は絶対にマネージャーにしてはいけない人間で、
これまでも全部他責にして下請けを泣かせてきただけであり、マネジメント出来てた訳ではないのだが、
見る目がない奴には「剛腕」=強引ではあるが仕事を進めて有能、と捉えられる事がある
けどこんなクソ精神論なんてIT現場ではまるで通用しない、というだけ あらーアメリカ人を人種差別だ!って怒ってた人が
それを関西人や田舎者に置き換えて説明しちゃうのか >>627
もうすこし抽象化思考を身につけようか
別にメアドに限った話ではなく
間違いがあまり許容できない状況で
1項目だけに依存してたらダメだよということ
そしてUIを考える前に
業務プロセスや業務ルールを考えましょうということ BTOBのマッチングサイトと言うのも実体はランサーズとかのクラウドソーシング
それを言いたくないから不必要な嘘で嘘を隠そうとする >>626
446は
・必要な業務フローを事前に考えてない
・重要な要件をあとから追加する
・Sendgridの月額数千円すら払いたくない!!
・他に方法がないのか担当者や関係者に聞かず5chに聞く
地雷が過ぎる >>631-632
> 不必要な嘘で嘘を隠そうとする
俺はこれは許容するべきだと思うよ
(「アメリカ人」が本当は「カナダ人」であっても誤差だし)
実際にキチガイは存在するから、特定されるのは危険であり、色々ぼかす必要は『常に』ある
ただしぼかした分、得られる情報の精度は確実に落ちる
だから今回の件も、俺らが全体設計の妥当性を詰める事は全く不可能だし、
仮にここで議論した結果を持ち帰られても、実際は全く使い物にならない
(ただ446や煽って情報を出させようとしてる馬鹿共はこの危険性すら理解出来ていないので、
なら逆手にとって、デタラメな提案をさも全会一致のように見せかければ、
446はそれをそのまま自分の手柄として「アメリカ人」に提案し、さらにプロジェクトをぶっ壊す事が予想される
これは攻殻機動隊で言う攻性防壁として機能するから、『5ch流攻性防壁』を試してみたい人はどうぞ
俺は能動的な破壊工作はやらない主義なので参加はしないが、見殺しにはする主義なので邪魔もしない
まあこの辺も結局は、「嘘を嘘と(ry」なんだな
意図的であれ、単なる読み違いや勘違いであれ、間違った情報も垂れ流されてしまう場所なので)
で、話を戻すと、特定を防ぐ為にどこまでぼかし、
精度を高めて自分の利益とする為にどこまで開示するかは、投稿者の責任だと思うのよ
んで、「業界」程度なら特定不可能だと思うから、広めでいいからよろしく、
利益は446と合わない奴が最初から自動的に除去される、という話
しなければ次回以降も446は(446にとっての)「地雷エンジニア」にこれまでと同じ確率で遭遇する
ただこの場合の「地雷エンジニア」遭遇率はBtoBだと100%だから最低限BtoCから探せや、とは思うが
つか割とマジでルビキチに発注すればいいんじゃね?
見解は一致してるようなので、「地雷エンジニア」でない事は保証されている しつこすぎを通り超えてキモすぎる
どっちが性格難あるんだよ >>631
俺も思ってた
個人がクラウドソーシングで個人に依頼した案件として見ると
446が書いてる内容のおかしな点がほとんどなくなるからね
「提案」という言葉もいかにもランサーズっぽい
別にそれならそれでいいと思うんだけど
案件情報を検索されたくなかったんだろう 吉野家にて
アメリカ人︰オー、ココガ"ハヤイノ・ウマイノ・ヤスイノ"ヨシノヤデスカ
446:いらっしゃいませー
アメリカ人︰ギュウドンクダサーイ
ワタシハ"ヴィーガン"ナノデ、ニクハイレナイデクダサーイ
446︰牛丼食べに来て、肉食わないだと?!
おかしいでしょうが!くぁwせdrftgyふじこlp
調理スタッフ:"ソイミート"ならどう?
446:うちのスタッフも、あのように申していますのでどうですか?
アメリカ人:ノーセンキュー!!
446:ドラえもーん😭 >>636
おらんのやから本人にはノーダメや
遠慮せずに吐き出してええんやで >>637
>446が書いてる内容のおかしな点がほとんどなくなるからね
ほんまやな
日本人社長ってランサーズの社長の話やったんかw
自分の上司も相手の上司も出てこんわけや 職場を破壊する「他人の悪い噂や秘密をべらべらしゃべる人」の罪
> つづく「どの会社にもいる「他人を見下し、自己保身に走る」職場を腐らせる人たちの正体」では、
> ttps://gendai.media/articles/-/124988
ttp://asahi.5ch.net/test/read.cgi/c/newsplus/1716760256/ [商流]
446(個人) → ランサーズ等 → アメリカ人(仮)
これが正解だったってことか
確かにこれだと>>542,543あたりの疑問は全部解消される
Tampermonkey対応も納得
そうするとアメリカ人の言い分もかなり歪曲されてそうだな >>643
> 納品まで大詰めで、並行して別の会社を探しており移行に入ります。 (>>476)
と書いてますがな。つまり納品先と発注先があるのだから、
> 顧客企業 → 446の会社 → モバイルとWebのアプリ開発会社 (>>498)
の通りでしょ
発注にランサーズ使ってるかもしれんが、今回そこは問題ではない
>>548 ごときに騙されてるのならお前が馬鹿すぎる
その後も意図的に間違った解釈を吹聴してる輩が突然大量に沸いてるだろ
よくある火消しの手法だから、こちらはマジでランサーズ投入かもしれん
(要は脱線させてそれ以上本筋の議論で分が悪くならないようにしつつ、
脱線先の議論を有利に展開して見た目論破したように見せかける、或いは何の話してたっけ?で引き分けっぽく見える状況に持ち込む
ひろゆきがよくやる論点のすり替えもこの類)
ならそんな奴は無視して、どんどん話を進めて行くに限るし、みんなそうしてるでしょ
(基本的には議論rootを目ざし続ける。今回なら446-449を常に念頭に置く)
まあ、
> どう論破したら良いでしょう? (>>446)
の希望通り、こう論破すればいいのだ、とスレ民が実演して見せただけではあるが
フラグ回収といわれればそうだ ね
446のシナリオとしては、「全部『アメリカ人』が悪い」だから、間違いなく歪曲はされてる >>644
納品まで大詰めと書いてるのはアメリカ人(仮)から446への納品じゃないかな
意図的にぼかしてるんだと思うけど顧客企業に納品するとは書いてない
それに446の話の中に顧客が一切でてこないのも偶然ではないと思う
顧客企業への納品するものだと仮定するとありえないことばっかりで
逆に>>643だと仮定して納得できることばっかりなんだよ
そもそも納品大詰めで顧客にUIの確認すらとってないなんてありえる? まだやってんのかよしつけえな
スレ違いだから専用スレつくってそっちでやれよ >>645
> 納品まで大詰めと書いてるのはアメリカ人(仮)から446への納品じゃないかな
この方向でぼかしているのはあり得る
> そもそも納品大詰めで顧客にUIの確認すらとってないなんてありえる?
常識的にはあり得ない
ただこれは「プログラマの常識」であって、「一般人の常識」ではない
俺は634の通り、好きなだけぼかせばいいが、その責任は本人に、と考えるので、
まずは言われた事を信じて、出来るだけ推定は少なくする
(結果的にデタラメ言いまくった分だけ間違ったアドバイスが与えられて公平だ)
よって、言われたとおりで合致するパターンはあるか?と探す事になる
多くの人は自分が正しいと仮定して、「相手のどこが間違ってるか(どこをぼかしているか)」を探すが、これとは真逆で、
言ってる事は、少なくともその本人にとっては正しいと仮定して、「相手がどこに立てばそう見えるのか」を探すわけ で、俺の推定は、以下だ
α:プログラミング経験無し、或いは1000時間未満
β:プログラミング経験1000~3000時間。出荷経験無し。(CS/EEの大卒新入社員相当)
γ:プログラミング経験5000時間超、出荷経験あり。(職業プログラマ3年目以降相当)
(出荷経験=不備があった場合に賠償責任がある成果物を出荷した事があるか)
BtoBは基本的にγtoγであり、このスレの連中も暗黙の大前提として今回もそうだと思いこんでる
しかし実際の446はαなので、プログラマの常識がまるで通じない
(ついでに言うと「知り合いのエンジニア」もβレベルのヘボだからγの常識が通じない)
ただこれは、ネット+マッチングサイトの発達で、
αがアプリを発注する時代に突入した、ということ
446が超絶糞なのは間違いないが、これは時代の流れであり、止める事は出来ない
今回の446がどうなれ、第二の446が今後いくらでも出てくる
だから俺は「お前の業界ってどこよ?」と、そいつらをまとめて回避する術を求めてる
(どうせ隣接業界も糞なのは間違いないし)
とはいえこれは、WordPressで個人商店とかのHPを請け負ってる連中がよくブー垂れてる事でしかない
相手が素人過ぎて、その要求が「すごく簡単」なのか、「とんでもなく無理」な事かが判断出来ず、
あり得ない事をしれっと色々言われて困る、という奴だ
それでも連中はこの手の「BtoCにおける介護プレイ」を結果的にある程度こなしてきてるので、
連中に任せればヨシッ!
そもそも448ってJSすら不要でP...いやここはRubyだね!!!とも思うし、
またWP+jQueryに毛が生えた程度の連中で十分だし適任だ
この場合、JSよりも「BtoCにおける介護プレイ」の腕前の方が重要なわけでね
もっとも、この推定が当たってる根拠なんて無いがね
この推定でも矛盾してる部分はないだろ、程度だね
実際は嘘つきまくってるかもしれんし 昼食べたラーメンがクソ不味かったからもう二度と食べない
チャーハンも麻婆豆腐も食べない >>648
一応突っ込んでおくと
BtoCは事業者が一般消費者と直接取引をするビジネスモデルのことだから
個人商店だろうが取引相手が一般消費者ではなく事業者であればBtoB
事業規模が違うだけ
便宜的にBtoCと呼ぶところがないわけじゃないけど一般的には通じないよ
素人度合いや零細度合いの高い相手と仕事をするには
それ用のスキルというのはよく分かる >>649
>>446は最初からRuby案件としてルビキチに発注すれば今回の事態は免れた >>585
もっと適切な例があった
車の「初心者マーク」だ
コミュスキルの観点から言うと、
「初心者マーク」は「意図的に自分を嫌って貰う為に敢えて目立つマークを付ける」事だ
周りの車は、基本的に距離を取り、挙動をよくよく確認しながらやり過ごすしかなくなる
そしてこれがまた、イキって付けたがらない馬鹿も結構いるという点でも類似してる
446もこれだ
いやお前、付けるだけでトラブル遭遇率をぐっと減らせるのに、無駄にイキって事故った単なる馬鹿だよね、って話 >>651
それは関係ないね、俺の「BtoC」は定義を問題にしてない
=どちらの定義を取ってる奴にも通じるように書かれている
ただすさまじく簡単に言うと、
BtoB:要件定義は必須であり、全員知っている前提。要件にない項目を要求すると裁判に負ける
(請負側は介護プレイをする必要はない。介護用員が必要なら『発注側が』確保する必要がある)
BtoC:消費者には専門知識はない前提で、
IT開発においては要件定義が必要なんだという所から説明してないと裁判に負ける(可能性がある)
(請負側は全員、介護プレイが出来る前提。
専門知識を利用して消費者を追い込んだら問題になるが、親分はこんにゃくゼリー庁なので実際どうなるのかは不明)
自分は事業者なのでBtoBだとか、国語審議会のような事を言わず、
自分の専門知識レベルは0なのでBtoCから選ぶという、意味論的判断をしてれば、回避出来た話
むしろBtoCに事業者が来たら(脱税する気のない大多数には)歓迎されるはずだし >>557
戸籍システムで障害3カ月、全国で影響 職員が電話で穴埋め
ttp://asahi.5ch.net/test/read.cgi/newsplus/1717108078/
俺も初耳だったが
> 戸籍の広域交付初日から法務省のシステムで不具合、市区町村の現場運用を想定しきれず
>
> 市区町村の職員は、住民から申請のあった特定の戸籍情報を取得するために、「氏名」「生年月日」などを入力して検索する。
> この際に、法務省は検索負荷がかかりにくい「生年月日」を入力する想定でシステムを設計していたが、
> 実際には戸籍筆頭者や本人などの氏名で検索するケースが多かった。
> 生年月日を指定せずに氏名などで検索をするとデータベースの検索範囲が広くなりシステム負荷は高まる。
> タイムアウトし、結果的に証明書発行ができないケースが増えたという。
> ttps://xtech.nikkei.com/atcl/nxt/column/18/01157/040900107/
名前にインデックス張れば終わりのような気もするが、本職の連中が知らないはずもなく、
何か他にも色々あるんだろう 検索項目入力欄の並び順
もしかしたら氏名が一番上にあったとか? 確かにUIの並び順で誘導出来るかもしれんが、
直感的には、名前で検索して生年月日で確認だし、実際そうだったんだろ
ただそれ以前にDBでインデックス済み(B木)なら名前(String)でも生年月日(Int32)でも検索の重さはほぼ変わらん
旧字体云々の場合は検索用カラム(20種類くらいあるらしい斉藤の斉は全部「斉」で登録しておく)で対応可能だし
てな事は本職の連中も当然知ってるので、
まあいつも通り、出てくるのは断片的な情報だけで、全体が全く見えないね
(これに関しては446も同様で、発言のちぐはぐさを気にしてもあまり意味無いとは思う) 質問です
普通のブラウザでYouTubeを開いた時、動画を全画面表示させるにはプレーヤー右下□(f)をクリックしますが
これをJavaScriptを使ってクリックさせるにはどうしたら良いでしょうか? >>665
クリックするだけならボタンの要素取得して.click()すればいいだけなんだけど
そこから呼ばれるフルスクリーンAPIがブラクラ等の対策のためユーザーの操作を伴わないといけないので自動化は無理 >>665
あなたの業界を教えてください
まずはそれからです
まぁ結局結論はださないんだけどね >>667
446乙
結論は最初から出てて>>450-451 >>666
その要素名が難しくてよくわからないんです
ユーザー操作が必須なので自動化は無理、というのは本当でしょうか?
>>667
業界は普通のIT系業務委託会社です
お客さんにYoutube全画面ですぐ見たいと要望されました >>669
要素名が難しくてわからないってなんだ?
英語の文字列が難しいってこと?
視覚が正常なら難しいとかの問題じゃないだろ 調べたい部分で右クリックメニューから、
F12 開発者ツールで要素を調べれば?
他人が作ったサイトの規格も知らないのに、
それを調査してプログラミングするのが難しい。
自分が作ったサイトではないから
手間のほとんどが、その調査コスト >>669
>その要素名が難しくてよくわからないんです
そのレベルなら諦めろ!
と言いたいところだけどインスペクターで調べればすぐわかるでしょ
>ユーザー操作が必須なので自動化は無理、というのは本当でしょうか?
ブラウザによっては非公式設定でuser initiated eventじゃなくてもfull screenにすることが可能
セキュリティ的に問題が出ても構わないかつ非公式だから突然使えなくなっても構わないなら選択肢としてはあり
あとはmacOSのUI AutomationのJavaScriptのように
ブラウザを外から操るようなJavaScriptなら可能 >>669
IT系でそのスキルはあり得ん
初心者よりも知識ないじゃん
客が可哀想 皆さんありがとうございました 今年入社の新米ですが何とか自力解決できました
いつも要素名を調べる時は右クリから調査を選んでインスペクタを開くのですが
今回は全画面(f)上で右クリするとYouTubeプレーヤーのメニューが開いてしまい
インスペクタが開けなかったのです シアターモード(t)と全画面(f)間を右クリしたら
なんとか調査を含む普通の右クリメニューが出てきて要素名までたどり着きました
なお、上記要素名はEDG(WebView2)のNavigationCompletedイベント内で
クリックしましたが、イベント発生直後にはクリックが効かず、0.8秒ほどウェイト待ちした
あとクリックしたらちゃんと全画面モードになりました ブラクラ対策のためユーザー操作が
必須という情報は、今回は当てはまらないような気がします >>675
> 今年入社の新米ですが何とか自力解決できました
いや上司に聞けよマジで ここで聞いて答え貰っておきながら自力で解決って言えるメンタル ちな同時多発デロイト
グリコに加えユニ・チャームでもシステム障害 外資系は見栄え良いがプロジェクトは上手くいかない事がある [PARADISE★]
ttp://asahi.5ch.net/test/read.cgi/newsplus/1717318028/
> 「国内ベンダの場合、契約うんぬんに関係なく、顧客側のタスクであっても気になる点や懸念点などがあると
> 『これって大丈夫ですかね』などと言ってくるケースが多い。
> それがベンダと発注元の役割分担や責任の線引きを曖昧にしてしまったり、
> 契約で定めた以上のボリュームの作業をベンダがやらされてしまうというマイナス面を生むことがある一方、
> 結果的に“穴を埋めて”トラブル回避につながるという面もある。
> 一方、外資系ベンダ・コンサルは『自分たちの担当範囲はここまで』とドライに線引きをしてくるし、
> 顧客側の事情で問題が生じた場合は『ではプロジェクトを中止します』『追加費用がかかります』と言ってくるので、
> 発注する側の企業にもそれ相応の高いスキルが必要となる。
> ttps://biz-journal.jp/company/post_381357.html
>>446、理解しとけよ、介護が必要なんだから、介護してくれる奴を選ぶか、別に介護人を確保する必要がある 最近の子はWebView2も普通のブラウザと言うんだね
おじさんびっくり そういう問題ちゃうやろ
右クリックからしかインスペクター使えないってのがアカンよ 右クリ→調査からインスペクター開くとその要素に直行するから便利だろ
開発ツールからインスペクター開くといちいち上から要素を探すのが面倒 >いちいち上から要素を探すのが面倒
マジかぁ
開発ツールのツールバーにある□と↖が組み合わさったようなアイコンクリックしてみ >>685
いや、さすがに俺もそれは知ってるよ
右クリ→調査しか使わない初心者の気持ちになってカキコしただけ
本当にここの人は文章を読み取って書き手の真意を想像することが苦手だな?w 俺くらいになると
デベロッパツールのためだけにモニタ1枚使ってるからね デベロッパツールにモニタ1枚使ったところで>>684じゃ生産性低すぎて話にならんやろ >>688
やっぱそれもアリなのか
俺はメインモニタの2/3をテキストエディタ
1/3を開発ツールにしてて、あらかた満足なんだけど
開発ツールって縦長ウィンドウにすると
ElementsタブとNetworkタブが
ちょっと使いにくいんだよね
週末だし安いモニタ漁るか
でもアームが高えんだよな… >>690
俺どっちもやる派だな
そこまで面倒だと感じたことはないかも