+ JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。 Viteの使い方がやっとわかりました！
ファイル名が変わるのは許容します
これから少しずつ学んでいきます
みなさんアドバイスありがとうございました 実際にサイトをサーバーに公開することになったらファイル名のうしろにつくハッシュ値の恩恵がわかると思うよ
キャッシュのこと気にしなくていいからね アプリで登録されたユーザー情報をWEBアプリで管理するということで
制作会社から管理画面のラフが送られてきたのですが、
ある箇所で、アプリで登録したユーザーのメアドをプルダウンで選択するんだそうです。 続き
「今はテストなので登録数は20-30件ですが、仮に50,000人とかになったら？」
と尋ねたら「プルダウンされた50,000行の中から目視で探す」んだそうで
それが正しいやり方だと言い張って平行線です。
どう論破したら良いでしょう？ 長文の投稿ができなかったので分割にて投稿させていただきました。
何卒よろしくお願いいたします。 論破もくそもねーわ
変更したいなら変更すればいいじゃん
これ100％発注側の問題だからな まあそうだわな
客あるあるだけど
欲しいもの、必要なものをちゃんと説明できないのは
本当によくあることで
だいたいの不幸や不具合はそこが起点になるんだ
作る側もそれはわかってるから
出来るだけ真意を聞き出そうとはするんだけど
で、平行線になってるってことは
説明不足のまま、もう作っちゃったからでしょ
ちゃんと追加料金払って変更してもらいなさいな 今後のために教えてください。
「アプリで登録されたユーザー情報」を「WEBアプリで管理したい」
という話し合いはしていましたがプルダウンにする/しないという
話し合いは確かにしていませんでした。
また自分は普段別の領域で制作業務を行なっており
アプリに関して無知ですが制作系はそこそこのクライアントをこなしています。
アプリの業界では特に話し合いを詰めないと
この様な非常識な仕様がポンと出てくるものなのでしょうか？
自分がいる業界ならば二度と仕事は振られないと思います。
（考えれば使いづらいのは話し合うまでもなくわかるでしょう、それがわからないのなら次はない、という感じ） >>452
>「アプリで登録されたユーザー情報」を「WEBアプリで管理したい」という話し合い
いやいやざっくりすぎやろｗ
項目すら詰めてないとか非常識にもほどがあるんだけど >この様な非常識な仕様がポンと出てくるものなのでしょうか？
どういう会社にどういう条件でいくら支払うか次第
海外とかにユルユルな発注を低予算でやるとそれなりによくあること
さすがに5万件になったら使いづらいというのは受注側も百も承知
それが理解できないような人間には出会ったことがない
お金の問題かスケジュールの問題か人不足か
いずれにしろ仕様変更の影響度が大きすぎるから今の条件では対応できないということ
ぶっちゃけ言えば君から二度と仕事を振られなくても別に困らないということでもある 非常識な業者は多い。
だから優秀な社員、又はアドバイザーみたいな第三者を雇う。
例えば家の売買なら、直接売買せずに宅建業者を通すのと同じ
後はキャンセルして、裁判して金を取り返す。
そんな業者と付き合っても損するだけ
詐欺みたいなもの >>452
>アプリに関して無知ですが
無知な人が関わっちゃったのが
問題の根っこなのはさて置き
データ件数とかは設計時に検討した？のかな？
自分も死ぬほど経験しているけど
ウェブ制作会社のディレクターって
ウェブのこと全然知らないじゃん？
あんまり関わらない方がいいよ
自分でも作れるけどやらないだけ、くらいになるまでは 登録済みユーザーを一覧できる画面とか存在しないのかな？
負荷を無視して単に使い勝手を改善したいならデータリストに変更すれば解決 独自のプルダウンを開発すれば5万件いける
無限スクロールすればいい 質問者です。
知り合いのエンジニアさんが助けてくれて
解決できる機能のソースコードは持っていて、
自由に使って良いですよ、と言われているのですが
提案したらクオリティの担保ができないから断られました。
まあわかるんですが、クオリティが低いから問題になっているのですが、、という感じです。 その開発会社思ったよりはまともそうでよかったじゃんｗ 書けば書くほど墓穴を掘っていくな
君が第一にやるべきはソースコードを渡すことじゃなくて
どう修正して欲しいかを含めて整合性のある要求仕様としてまとめて提示することだぞ
単純なCRUDアプリなんだから要求仕様さえきちんとまとまっていればこんな問題は起きない モバイルアプリで登録済みのユーザー情報を管理するためのWebアプリなら
普通は検索画面、一覧画面、ユーザー単位の詳細画面があって
一覧画面や詳細画面からユーザー単位の編集画面へリンクされるので
編集画面でそのユーザーのメールアドレスをドロップダウンから選ぶ必要はない
あるユーザーと別のユーザーを手作業で紐づける機能が必要ということであれば
ユーザー単位の編集画面から紐づける機能を起動して検索画面 -> 一覧画面 -> 詳細画面と辿る
この場合は紐づけ処理中かどうかで一覧画面や詳細画面の内容を変える必要があるから画面数の扱いとしては別画面 このくらい小規模な開発だと
要件定義含めて客とのやり取りと
客に説明するためのドキュメント作りがコストの大半だからな
それを理解しない客は避けるに越したことがない >>463
単純なCRUDアプリであれば、
整合性のある要求仕様を提出しなくても
ある程度のクオリティが上がってくるものだとおもっていました。
こちらは私の完全な落ち度ですね。
ただ、この場合制作会社が
「仕様書がなかったから、或いは具体的な指示がなかったから50,000行を一気に表示しても良いと思った」
として50,000行を一気に表示するようなものを作った、みたいなことはよくあることなのでしょうか？
自分の業界であれば素人のクライアントには合理的な解決法をアドバイスするかなと思います。後で自分が地雷撤去で困ることもあるし、次の仕事がほしいので。 >>466
>単純なCRUDアプリであれば、
>整合性のある要求仕様を提出しなくても
>ある程度のクオリティが上がってくるものだとおもっていました。
アホすぎるｗｗ 提案内容が気に入らないなら望ましいと思う内容に変更してもらえばいいだけなのになぜそれができないんだろう？
そこに問題の本質がありそう >>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
なんで「最終的には」なんだよ すぐやれよｗ
マネジメント能力が欠如してるのはそういうところだぞ
その前段階の話て「担当者が言うこと聞いてくれないんです〜どうしたら言うこと聞いてくれますかね〜〜」とか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に相談する前に上司に相談しろは全くもってその通りだと思う 
