はてなキーワード: 仕様書とは
https://b.hatena.ne.jp/entry/s/smart-flash.jp/sociopolitics/277057/1/1/
大阪府の入札結果
https://www.pref.osaka.lg.jp/keiyaku_2/e-nyuusatsu/e-kekka.html
府からの案件は万博公園ばかりで、学生招待業務で旅行会社を呼ばれてたぐらい。
(万博公園の資料デジタル化の入札が0.7千万と5千万の2社なの大丈夫かしら)
大阪市の入札結果
https://www2.keiyaku.city.osaka.lg.jp/OsakaCity-PPI/index.html
コンサルでは、交通需要3.5千万、鶴見との連携2千万、花飾り企画0.7千万とか。
物品では、ロゴ入りの色々が買われてるけど、推進局設置は一社入札でよかったんか。
工事では、上がってこない。委託では推進局の害獣駆除。花飾りや諸外国からのファムトリップツアー業務は入札中止になってる。
(花飾り委託がR5/8、コンサルがR5/11なので不調後の予算見直しのため?)
https://www.expo2025.or.jp/bidding/
は応答遅すぎで開かないのでまた今度(土日が無理?)。
あくまで使用権単体の話ならば行使できるようにするのも1つの戦略なのでアリだと思う。
問題は作品の完成に向けた仕様書・発注書の性質を持つ契約においてである。
ここな。著作権者が同一性保持権を行使する構えであるとき、じゃあ検収してくださいって契約になる場合がある。
これは元々法人向けのひな型にはあるもので、先方のブランドを守るための手続きのテンプレ。
これを個人の著作権者がスルーして契約するととんでもないことになる。
とか確認作業が一気に発生する。たまにアニメ化で忙しくなってる作家などいるが、このタイプの契約が多い
別に本人がやる気なら全然いいし、時間作れるならOKなんだけど、その準備のないまま契約するとえらいことになる。
いやブランド守るために監修しなきゃいけないでしょ、って人もいる
なんで契約する前にまず編集とどういうスタンスで向き合うかをよくすり合わせる必要がある。
某大手通信業者に勤めててソフトウェアエンジニアやってるんだけど
会社にも申請して副業フリーランスしていてそっちの収入の方が断然多くてどっちが副業なんだか分からない状態になってる
副業やってると分かるんだけど巷のソフトウェアエンジニアって大半が低スキルで年収もせいぜい500万とかで
高スキル者だと年収1000万越えは普通、2000万クラスもザラっていう感じ
で、自分は高スキル者側にいるので副業フリーランスの方はいろんな依頼も来るしそこそこのプロダクトを作ったりしてるんだが
そこそこ給料貰ってるんだから全然やりますよ、と伝えても、そもそも仕事が来ない
たまに来る依頼はほぼ秒殺できるような内容だったり
依頼内容が意味不明な上に会話しようとしてもコミュニケーションエラーになるような仕事ばっかりなんだよね
基本的にウォーターフォール開発なので仕様書・設計書を最初にゴリゴリ作るような文化で
ソフトウェアエンジニアに対する依頼は設計書渡して「お願いします」って感じ
大抵の場合は設計書の段階でクソコードになっていたりセキュリティ上の問題があったりするので
その辺の指摘をしてみるとコミュニケーションエラー起こして大問題になる
設計書に至までにいろんな会議を通していろんな偉い人が承認してることになってるから
それをひっくり返すのはいろんな人のメンツを潰したり会議に再付議とかなってクッソ時間がかかる
そもそもの組織構造がウォーターフォール前提に作られているのでこのあたりを効率化するのはほぼ不可能に近いし
組織に長く居る人ほどウォーターフォールじゃないと業務出来ない人が多い
高スキル者ってプログラミングに関する知識もそうだけどウォーターフォールでいうところの上から下まで全部やるので
組織構造としてウォーターフォールになってる会社とは全然合わないんだな、とは思っている
例えばうちのCTOにあたる人ってバズワードとか業界動向、社内事情とゴルフについてはめちゃくちゃ詳しいし、そういう人じゃ無いと務まらない
なのでその地位を目指す管理職はそっちの知識を付けようとするし評価もそっちに流れていく
CHR$(143)
プレイ時間 88時間(全ステージクリアしたばかりの現在の時間)
全クリして達成感に満ちあふれているが、この気持ちが収まる前に感想を書くぜー!
しかし、タイトル名の読み方がよくわからん。「キャラクターズ・ワン・フォー・スリー」でいいのか? ちなみに、ゲームのタイトル画面では『Project CHR$(143)』表記となっている。
タイトル名の『CHR$(143)』だが、Amstradというイギリスのメーカーから1984年に販売されたCPC464というホームコンピューター(パソコン?)のキャラクターコード143に四角形が割り振られていることが元ネタのようだ。レトロなコンピューターを元ネタにしてるだけあって、ゲーム画面全体もレトロな雰囲気に仕上がっているのも好きだ。
ゲームのジャンルとしてはパズルゲームでいいはずだ。ちなみに、Steamでのジャンルは「インディー, シミュレーション」となっている。
Steamのストアページの類似品として、『Baba Is You』(説明不要の有名パズルゲーム)に、『Factorio』・『shapez』といった工場建設系シミュレーションに、カイロソフトのレトロ調シミュレーションゲームに、変態パズルゲームメーカー(誉め言葉)で知られるZachtronics社の『SHENZHEN I/O』などが並んでいる。
『CHR$(143)』の紹介文をSteamストアより引用する。
リッチでやりがいのある物理ベースのパズル/ロジック/建設/プログラミングゲーム!弾道学、流体力学、熱力学、化学反応、核反応をマスターし、オートメーションレンガを使い、構造物、機械、乗り物を作り、電力を生産し、パズルを解き、霧を突き破り、CHR$を倒そう!
https://store.steampowered.com/app/1695620/CHR143/
パズルゲームやレトロ調ゲームが好きな私としては『CHR$(143)』のトレイラー動画や上記の紹介文に心惹かれてプレイした次第だ。これがやっぱり面白かった。上記に挙げた他の類似品に匹敵する、あるいは凌駕するほどに面白かった。
ゲーム内容としては、箱庭系というよりもステージ攻略型のパズルである。ゲーム内では各ステージはレベルと表記されているので、この感想文でもレベルと表記する。
パズルの難易度としてはかなり高い。それでも、チュートリアルなどの導入はしっかりしてるし理不尽さもないので、私にとっては時間をかけて考えれば自力でクリアできる難易度だった。とはいえ、悩みに悩んで、日をまたいでようやくクリアしたレベルもある。
ちなみに最終レベルクリアのSteamグローバル実績は1.6%である。これで難易度の高さが伝わるだろうか。
各レベルの主な流れとしては、ブロックを作ったり掘ったり操作したりして目的を達成(レベルクリア)していくことにある。ブロックの一つ一つが物理演算する様は『Noita』らしさを感じた。レベルクリアについてだが、解法がガチガチに決まっているわけではない。時間制限があって急いで操作しなければいけないレベルもあり、レベルによってはアクション性が高かったり、シューティングゲーム要素があったりするのも楽しかった。
レトロゲームは昨今のゲームと比べてジャンルという枠組みにとらわれていない印象があるが、この『CHR$(143)』も同様だ。
ブロックを組み合わせたギミックはとても面白いが、その中でも特に好きなのは蒸気タービンによる発電だ。
ただ過熱蒸気をタービンに送るだけでは発電できず、冷却用の水も同時に必要となっている。タービンで熱交換されて、過熱蒸気はただの蒸気となり、水は温水になる。発電を継続させるためには、蒸気を常に加熱する仕組みと、温水を冷却塔で常に冷却する仕組みを構築する必要がある。蒸気よりも過熱蒸気の方が密度が小さいので上の方に行き、水よりも温水の方が密度が小さいので上の方に行く。こうしたブロック毎の密度の違いを利用してタービン発電を実装していく必要があるのだ。
このように、流体力学や熱力学を反映したシミュレーションになっているのが、『CHR$(143)』の面白いところだ。
非常に頭を悩ませながらも面白かったのがプログラミングだ。AND・OR・NOTなどのブロックで論理回路を実現できるだけではなく、CPUブロックも存在する。そしてCPUに対して、このゲーム専用(たぶん)のプログラミング言語で命令をプログラムできるのだ。この言語がとても低レベル(低水準・低レイヤの意味で、決して侮蔑表現ではない)なのが面白い。逆ポーランド記法で数式を記述したり、goto文で条件分岐したりといった具合だ。言語の仕様は大量にあり、pdfファイルでまとめられているほどの徹底ぶりだ。しかも、ゲーム中でも詳細はpdfファイルを参照するようにと求められるのだ。パズルゲームで、まさかプログラミング言語の仕様書を読まされるとは思わなかった!
とはいえ、言語仕様を全て理解する必要はないし、プログラミングもゼロからコーディングする必要もない。プログラムはサンプルとしてすでに作られた物をコピペで流用して必要な個所だけを書き加えたり修正したりすればいいし、仕様書も必要なところだけを読めばいいのだ。それはそれで、ある意味リアルなプログラミングともいえるのだが……。
説明するのを忘れていたが、ゲーム全般は日本語対応しているものの機械翻訳なので翻訳はガバガバだ。とはいえキー操作一つで英語表記に戻せるのでそんなに問題は無いし、翻訳のガバガバっぷりはそれはそれで味があっていいものだ。しかし、プログラミング言語仕様が描かれているpdfファイルは英語オンリーなので、読み解くのに苦労した。とはいえ、言語仕様を調べようとして英語の説明しかなくて苦労するというのにも、これはまたリアルなプログラミングだなぁと感じたものだ。
好きなレベルについても述べたいので、まずはレベルがどのように構成されているかから説明する。
チュートリアル的なレベルでギミックの説明から始まり、レベルを経る毎にギミックを応用させた解法が求められる。さらにレベルを経るとこれまでの集大成的なレベルが登場して、それをクリアしたらまたチュートリアル的なレベルで新たなギミックが登場する。この繰り返しが『CHR$(143)』の大きな流れだ。
その中で私が好きなのは、やはり集大成的なレベルだ。集大成的なレベルは視界が狭まっており、一体何があるのだろうかと周囲を探索しながら進んでいくのが楽しかった。こうしたレベルはクリアがSteam実績解除の対象となっており、それにふさわしい達成感も与えてくれる。
そして最終レベルをクリアしたのが、つい最近のことだ。この達成感を味わったことを書き残したくて、今この文章を書いているところだが、それももう終わりのようだ。
ソースを見る限り、仕様書がポイントだ。複数のソースでこの点がぶれている。
というか記事、文中でDMMはワンテーブルと関係ないと書いておきながら、タイトルで釣るのはやめてほしいな。
中核の仕様書を、委託契約等の仕様書作成に当該事業者が関与することは問題あり
という説があるが、そもそも自治体で作れないのであれば、もとから研究している企業が落札できないととんでもないことになる。
よって仕様書を作ることに裏で関与していることは当然ありうる。しかしDMMの関連企業が書いているとは一言も書いていない。あくまでワンテーブルなんだけどな。
2023/03/07 福島・国見町 救急車リース事業の公募型プロポーサル方式で委託事業者を募る際に作成した仕様書において、競合他社排除する項目 業者と自治体が確認か
ここがあいまい。人や記事によって書いていることが違う。競合他社を直接排除する事項なんて書いていない。だからこの記事はバカで中途半端にDMMを落としてめているだけで危ないな。
要は直接優遇するのではなく、規格や仕様がベルリンク社のみと読み取れるという程度でしかない。こんな「DMMがまずいことをやっている」というのはどこからもかけないわけだが。
大平伸一
@ohira_shinichi
問題はやはり国見町の仕様書です。河北新報の報道では亘理町の仕様書と酷似しているうえ、ベルリング製の既存車両に使われている寸法や内容が示されているようです。この仕様書の作成過程を調べるためにも、国見町議会が百条委員会を立ち上げることを期待します。
https://twitter.com/ohira_shinichi/status/1650478689203916802
さらに貸し出せないと困るから仕様書が同じになるのもやむを得ない。これも馬鹿なの?
というかやっぱりバカなんだな。
https://scenariohouse.hatenablog.jp/entry/2023/09/06/025535
意見書ではまず救急車事業が、4億円を超える事業でありながら、監査委員が町側に説明を求めたところ「事業計画書が作成されていませんでした」と明かし、議会に対する説明も「すべて口頭のみで行った」と、町側のずさんな事業計画を暴露。「
次に研究開発について、「同じ仕様書で、12台も製造する必要があったのか」と疑問を呈し、「研究開発事業の名称を掲げている以上、」「例えば、A仕様で4台、B仕様で4台、C仕様で4台とすれば、採用枠も広がるし、幅広く意見を求めることができます」と、ていねいに具体例を挙げて町側の研究開発方針の矛盾を指摘。
「1回意見を聞いて、6台作り、1年使用していただいて、さらに2回目の意見を聞いて、6台作れば、1回目より2回目は良いものを作れる可能性があり、より質の高い開発が期待できるのではないか」と、町側の考えが浅いとばかりにたたみ掛けています。
そんな複数仕様書を作るほど、救急車に規格はないと思われる。全然具体的ではない。これがきっかけならあほかっつーの。
事業計画?救急車の開発の事業計画を自治体が作れるわけがないだろう。まあコンサルに頼むとかしたほうがいいけどな。
あと生産能力も問われるわけで、それいうんだったら12台作って翌年24台作れればいいといえる。監査委員はバカなの?無理げーなら馬鹿でも書けるよ。
貸与して回収するって書いてあるの読めないのかな?
「行政機能ぶん取る」 自治体連携巡りワンテーブル社長発言 録音データで判明
https://kahoku.news/articles/20230320khn000033.html
https://www.youtube.com/watch?v=l3wUxUUKrYw
それに、こう考えているのは企業版ふるさと納税のだいたい全部でしょ。公金チューチュースキーム企業版かな。でも救急車の性能が良ければいいけど、だれも救急車の性能を評価しない。だからダメ。
かっちりとした設計書を作ることは少なくなったが土台となる仕様書やソフトのマニュアルとかは未だに存在するが、まぁ読まない。酷いと帳票のデザインから仕様を読み取ってプログラム組んで後で間違いと気づいて質問してきたりする。
仕様書が正で帳票デザインが間違いなのでそれを直せば良いだけなのに見比べるとかしない。
技術書や公式ハンズオンを最後までやらない。ググって赤の他人のQiitaの内容で理解した気になる。だから想定外の時に何も検索条件を出せない
確かに技術書でHello, world!出すのは達成感は無いし仕事の何に役に立つんだって思うけど大半の技術書はその分野の土台を網羅しているのでその後の詳細な知識の吸収には圧倒的に有利になる。なのに3章までもやらすに分かった気になって開発に勤しむ。でコピペコードでソースレビューで説明できず勝手に機嫌悪くなる。誰も粗探しもしていないのに。
確かにベンダー系の資格は高いし更新にも金かかる。IPAの資格は時代遅れ感半端ない。でもシステムに勤しんでいて無勉で受けて合格する人は半分も居ないだろう。難易度が高くなればさらに減る。
あほくさい勉強だけど実力はつくし自信と箔もつく。転職でも評価はされる。資格取らなくても勉強してアウトプットしているのなら良いけどそれもしない。
そんな感じなので検索のワードの粒度が荒いので問題解決に時間がかかる。おまけに英語が嫌いなので海外の情報はシャットアウト。最近はChatGPTに聞きまくるがそれでも意味不明な物を作ったりする。
軽く指摘するとはてなブックマークで未経験なのにChatGPTでサービス作った人の記事を教えてきたが、たぶんこの人は技術書を最後までやり切れる人だからすぐ飽きて出来もしない上を目指す君にはChatGPTも匙投げるよと言いたかったけど「凄いねー」で済ませた。
仕事だから嫌々やっている事も出来ない人材が年々増えている。好きな物はChatGPTとキントーンとセールスフォースな感じの
ついでに未来の話を聞きたい。よろしければ。
クレヨンとかでコンセプト画を描く。
下っ端が実図面に起こす。
ザハ・ハディドなんかはトンカチ一つ持ったことがないから、下っ端に完全おんぶにだっこ。
日本人は、そういうセンセイの立場になるまでに下積みなしということはまずないので、
これはもちろん例えで、
コンセプト・構造・意匠を統合して立体構築する頭脳労働=プログラ厶の設計
ということになろうかと思うが、
建築の場合やっぱり下から全部やった人がクレヨン握らないといいものができない。
ザハ・ハディドなんかはどっかの独裁国に馬鹿げた「作品」作っただけで先進国ではついに通用しなかった。
プログラミングはどうなのかな。
仕様書を作ってないシステムの概要を資料にまとめて欲しいと言う依頼
その程度であればと思い受けて、数時間でできる程度の資料を作って送る
結局、
あれも教えて欲しい、これも追記して欲しいと工数以上の事を要求される
「何でこんなお粗末な資料を寄越すの?」って言われても、DB設計書も指示書もまとまってないんだから多めに見てくれよ、この程度の工数でやる気なんて出ねえよ
「何でそのままDBのカラム名をプログラムで使わないの?」って言われても、パスカルケースとキャメルケースとスネークケースが混ざっているし、日本語ローマ字だらけのカラム名をそのまま使えるわけねえだろ
と部屋で一人愚痴りながら書き上げて送る
叩き台作らされた上に、修正で手を動かす側にさせられるのは損だなと思いつつ