  |
はてなキーワード: 仕様書とは
なんか最近「オブジェクト指向」関係の記事や書籍紹介を目にするような気がするのは、新学期が始まったせいなのかな。
オブジェクト指向がよくわかんない、という人は、いったんオブジェクト指向を忘れて、「システム」とはなんぞやという基本の基本を確認することをおすすめする。
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）の図（https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:System_boundary.svg）を見てほしい。
外部環境（Surroundings)において境界（Boundary)が定義されるその内部がシステム（System)なのである。
境界こそがシステムを具現化するものであり、要するにシステムの内部はおいといて、境界を通じてシステムの内部と外部でどのような入出力（インターフェース）があるかのを定義するのがシステム定義なのである。
これが決まってはじめて内部をどのように構築するのか、サブシステム（コンポーネント）間の連携をどうするのか、という話になる。
英語版のページにはしっかりとこう記載されている。
We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside – part of the environment.
日本語版の項にはなぜか訳されてないが、これが本質的な定義であり、システムときいたら即「境界」と思い浮かべるべきである。
そんなの当たり前じゃんと思われるかもしれないが、たぶんシステム関係に携わっている多くの人が、「システムって何？」ときかれたら、
「システムはいくつかの要素によって構成されるもので、その全ての要素は、他の要素に影響を与え・・」
と、いきなりシステム内部の機能的な説明を始めると思う。まず境界やインターフェースの話から始める人はむしろ少数だろう。
そうでなければ、世の中に数多あるシステムの「要件定義」「システム設計」「機能仕様書」などトップレベルでの記述はもっと明確かつトップダウンになってなければおかしい・・・
話をオブジェクト指向に戻すと、
最近話題になっている記事などは、なるほどよく噛み砕いているなあ、とは思うんだけれども、言語・実装・モデルといったものにひきずられてしまって、本来は広い分野や局面における「システム構築の手段」の広い概念であるはずのオブジェクト指向、実装例や用語から再度説明するという堂々巡りをしているという感じがする。
システムの本来の意味が身についたら、オブジェクト指向で説明されているあれやこれやが、このシステムを実現するため手段にすぎず、効率的にシステムを構築し、サブシステムの再利用を容易にするための仕組みや方法論をあるていどまとめて総称したものであることが自然に理解できると思う。
なんか最近「オブジェクト指向」関係の記事や書籍紹介を目にするような気がするのは、新学期が始まったせいなのかな。
オブジェクト指向がよくわかんない、という人は、いったんオブジェクト指向を忘れて、「システム」とはなんぞやという基本の基本を確認することをおすすめする。
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）の図（https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:System_boundary.svg）を見てほしい。
外部環境（Surroundings)において境界（Boundary)が定義されるその内部がシステム（System)なのである。
境界こそがシステムを具現化するものであり、要するにシステムの内部はおいといて、境界を通じてシステムの内部と外部でどのような入出力（インターフェース）があるかのを定義するのがシステム定義なのである。
これが決まってはじめて内部をどのように構築するのか、サブシステム（コンポーネント）間の連携をどうするのか、という話になる。
英語版のページにはしっかりとこう記載されている。
We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside – part of the environment.
日本語版の項にはなぜか訳されてないが、これが本質的な定義であり、システムときいたら即「境界」と思い浮かべるの
そんなの当たり前じゃんと思われるかもしれないが、たぶんシステム関係に携わっている多くの人が、「システムって何？」ときかれたら、
「システムはいくつかの要素によって構成されるもので、その全ての要素は、他の要素に影響を与え・・」
と、いきなりシステム内部の機能的な説明を始めると思う。まず境界やインターフェースの話から始める人はむしろ少数だろう。
世の中に数多ある、システムの「要件定義」「システム設計」「機能仕様書」などで、トップレベルでの記述でまず境界と外部とのインターフェース明確にして、
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）にもそう書いている。
それそれで正しいんだけど、それ以前に重要なのは「境界」であり、
話題になっている記事は、なるほどよく噛み砕いているなあ、とは思うんだけれども、言語・実装・モデルといったものにひきずられてしまって、本来は広い分野や局面における「システム構築の手段」の広い概念であるはずのオブジェクト指向、実装例や用語から説明するという堂々巡りをしているという感じがする。
乱暴に言いきってしまうと、「システム」の本来の意味を理解すればオブジェクト指向にまつわるあれやこれやは自然にわかってくるはずだ。
日記だしおもってることをつれづれなるままに。
「～です。」とか、「～ます。」て文章は読んでほしくて媚びてる。
「～だ。」って文章は上から目線。
って思う
読ませたくない（読んでいただかなくて結構ですが？）
って雰囲気のヤツあるんだけど
諸事情により、とあるプロジェクトの統括みたいのをやっているのだが
遅刻したり簡単なミスをした時、わざわざ私の席まで来て謝罪していくのをやめて欲しい。
簡単なミスもそう。
君が謝っても何一つ事態は良くならないから。
ぶっちゃけ謝罪って、その本人の気持ちを軽くするためだけの作業だと思うんだよね。
それ自体は別に責めないけど、それに私をつきあわせないでほしい。
君の謝罪１分聞いてる間に、仕様書１枚読めるから、おにぎり食えるから。
失敗したら反省はして欲しいけど、謝罪とかは全然して欲しくない。
謝罪をたくさんする奴に限って反省できてなくて再発させたりするし。
前々からこういう事思っていたから、この間おなじようなことしてきた人に
「私に謝罪とかしなくていいんで」
って言ったら、なんか周りに人非人みたいな扱いされるし。
オブラートに包んで言えばいいのか？
もう、まじほんと謝罪やめて欲しい。
どうしたら良いんだ。
とある社内でホームページの作成、運用を担当してきた。綺麗な言い方をすれば全てのホームページの作成が終了したので、退社が決まった。俺の方はお金に困らない生活ができて良かった旨を知り合いに言ったら、「お前は周りに合わせないから行けない」「言われた事をやるのが態度に出るから首になる」と散々注意を頂いた。まあやる事やってりゃいいだろ、違う会社に行く為の腰掛けと言う態度が表にでるから失敗する事もある。尤も風俗でHする為等のお金が欲しいから働いてるのが現状だ。さて今日はこんなダメ人間街道まっしぐらな自分の6ヶ月間のハイライトを話していこう。
まずA部署ではwordpress系のホームページを作って来た。基本的にホームページ制作の流れは、企画を設計書に落とし込み、設計書の各パーツをPhotoshopのスライスと言う機能で切り出し、各部分にはめ込んでいく。このように仕様通りに作るというテクニックが要求される事が多い。どうしてこういう流れを踏む必要があるか？それは仕様書をあらかじめ作っておき予定立てをすることで、全体の進捗の管理をしやすくし、効率よく回しやすくするためだ。
システムの世界で言うアジャイル開発に代表されるように、昨今では状況の変化に対応しやすいようPDCAサイクル((ある事業の計画→実践→検証→改善までの))を短く回せるような開発手法が注目を浴びている。
最もこのプロジェクト程度ではそこまでやる必要も無い規模だったのもあって、
2.wordpressで実装
4.公開、運用
の流れで作業を行っていった。自分は1〜2の流れを短いスパンで繰り返し完成に持っていった。思い返せば商品を見せる？タイプのサイトだったのか、3.では画像の修正が一番多かった記憶がある。とりあえず見た目の良いページが出来上がった。このうち個人的に反省した点は1の構想の段階で、「誰にみてもらうのか？」「何の為にこのサイトを作るのか？」を明確にしなかった点だ。前の会社でもこの点はないがしろにされてしまっていたので、shit!と思った所だ。
困ったのは担当がこの手の現場作業に理解が無い面がある点だ。事ある事に「(前の会社で)仕様書通りに作る仕事をやってたんだろ？」、「一からHPを作れるようにしてやっただろ」的な態度なのは...以下業務とはやや関連する、仕様書のあり方について話していく。
まず家を建てるには設計図と言うものが存在し、図面通りに作る事で組み立て作業をやりやすくしているわけだ。設計図に不備があると欠陥住宅になったり、資材を追加発注してイニシャルコストがかかってしまうなどが考えられる。さてHP制作の場合はそこまで厳しくないものの、全体の進捗管理をやりやすくする等の目的で仕様書が存在する。ただ作るだけでなく、何の為の仕様書か？と言う部分を把握する事も仕事のうちだと思っている。
例えば一からホームページを作るんなら、ソフト使えば自分でもできる話。それではできない現場の技術を覚えたい、企業ものを手がけてみたいからみんな入社するのだ。もっとも「仕様書の作り方、仕様書通りに作る技術を覚える＝現場の技術を覚える」な場合もある。以外と現場と個人との差はこういう部分で現れてくる事も多い。
次はB部署で作ったホームページの話をしよう。嬉しかった点、一緒に仕事をさせて頂いて良かった点は冒頭の打ち合わせの段階だ。特にB部署の方から「うちは別の事業がメインなので、とりあえずこんな会社があると言うのを紹介するようなページを作ってほしい。だから簡単で良いですよ」と言ってくれた点。もちろん気が楽なのが2割、結果的に作り過ぎにならないが8割だ。
その為「外回りの営業の人が○○やってると言う事が分かるように、簡単な説明を入れてほしい」「いやそこは○○と言うべき所だ」とどんどん実のある話が飛び交ってくるのが嬉しい。ともかく意見を言いやすい雰囲気で、会社側の意向に合わせてどんどん改修などもしやすい限りだ。何より会社の体面でなく、客の方を向いているのが本当に良かった。
ここで個人的に社内SEなどの部署は、基本的に社内の意見を反映しやすい物を作るために存在すると考えている。今回の案件を担当して思ったのが、営業だとか他部署の人間の仕事を円滑に進めるためのホームページがあっても良い訳だ。アクセス状況を無視して、営業の人がiPadで話すためのネタをホームページに仕込んでしまってもいい。1.で話した通り所詮はお金の為と言え、もしお金を度外視するならできる限り相手の立場で仕事をしたい所だ。
その他嬉しかった事が2つあって、1つ目は上司が業界の仕組みを教えてくれた事だ。帰り際に「○○の業態は全体の△△%のキャパシテイを埋めれば、利益が回収できるような仕組みなんだ」と業界の仕組みなどを教えてくれるのもありがたかった。2つ目は俺に合わせた冗談を言ってくれたことかな？「10分女と話して10分仕事して...」の一言には、俺のこれまで全てを言いくるめられたような気持ちとなった。加え「温泉街に風俗だのスナックだのは必要だよな」と俺の後押しをしてくれ、気を合わせてくれたのが最高だった。辞める事になったものの、こんな会社に出会えて本当によかったってものだぜ!。
場合によっては「アダルトの仕事なんて何やってるんだって気になるよね」って言う奴も居て、こういう奴のいるような会社はことごとく去って来た。こんな事を言われるたびに「うるせー。こういう男の下心で金が動いてんだよ！」と黙って反抗し続けたものだ。やっぱ女に騙されるようなバカで居たいし、それを笑ってくれるような人と働きたいものだ。ホント2週間に1回Hができれば、もうちょいクビになるタイミングをのばせたかもしれない。セックスはクビ防止に多いに役に立つに違いない(笑)。
最後にこんな文章をお読みいただきありがとうございました。社内で目立った存在なんで、協調性が無いの分かると目を付けられやすいんですよ。(違う知人から「お前がいると俺が目立たねえじゃねえかよ！」といじられましたw)。さてこんな俺の愚痴から何か得るものがあれば幸いです。俺の方はとりあえずバイトでもよいので適当に探し、大好きな食事とHをこなし続けていきたいです。
保育士が足りないって話。
保育士になりたい人は多いんだよ。子どもと触れ合って、毎日、楽しい！みたいな希望を持って。
でさ、認可の保育園は結構、書類作成が多いのよ。認可される根拠となる提出物が。そもそも保育士を目指した人って、そういうの苦手だと思うんだよね。
ウチの妻はパートの保育士だけどさ、俺から見ても優秀な保育士だと思うんだよ。雰囲気からして子供に好かれそうだし、常に笑顔だし。社会人になってからも大学の保育に関する講演会みたいなの聞きに行って勉強したり、意識が高い（笑）保育士だと思うよ。
でも、いろんな知り合いから「フルタイムで働かないか？」とお誘いがあるのだけど、全部断ってるんだよね。「フルタイムになると書類作成やらされるから嫌だよ」って。
プログラミングがしたいのに、Excelで表を作ったり、仕様書を作ってる時間が多くなってるみたいな。そんな感じ。
でさ、仕様書とかそういうのをたくさん作らなきゃいけない案件ってさ、国や地方自治体の仕事が多いでしょ？
認可の保育園って、まさに、補助金で儲けてる組織だから、その手の書類作成が結構んだよ。
保育園によっては、経理や総務みたいな仕事も保育士さんがやってるらしいよ（妻の話なので事実かどうか知らないが）。
保育園に赤ちゃんを預けると、国とか自治体とかから補助金が月２０万円くらい、保育園に入ってくるそうな（裏付けソースはない）。これが保育園の収入だ。
それだけの税金がかかってること、みんな知ってるんだろうか。
保育園の料金を、１ヶ月１０万円くらい（俺はそれが妥当だと思うよ）にして、その上で親に子ども手当１０万円（バウチャーでもいいけど）渡せばいいと思う。保育園はある程度のルールさえ満たせば誰でも作れるとすればいいと思う。
そしたら、競争原理で、良い保育園は賑わうだろうし、保育士の処遇も上がっていくだろうし。
以前、自分は海外の会社に勤めていた。ネット経由で仕事するという、最近良くあるスタイルの会社で、今まで二社経験がある(クラウドソーシングとかじゃなくて、れっきとした専属の社員です)。
その二社目にいる時に、日本人の別のソフトウェア技術者が入社したのだけど、その人は半年でクビになってしまった。自分はマーケティング系職務だったので、クビになった技術者が何をしていたのかは知らなかったが、その一ヶ月後に日本の大手IT系企業に入って、その後長くやっているので、技術に問題があった訳じゃないだろう。
自分は二社とも日本人一人の状態で参加していて、そもそも語学は大して上手くない人間なので、「うかうかしてると振り落とされる!」という強迫観念もあり、言われないことでも積極的に提案したりモデルを作ったりして、それなりに評価されていた。なので、会社との合意でない限りやめることはなかった。じゃあ、クビになった人は何が出来なかったか。
ひとつは、先に日本人がいたことで、甘えがあっただろう。要するに、仲良くしていれば自分の立場を守ってくれるという認識がどこかにあったんじゃないだろうか。実際に接していてそう言う印象は受けた。でも、ネット経由で仕事する限りは、そんなものは通じない。ましてや、相手は異国人。そういう人に、期待しても仕方ない。
もう一つは、(結局同じことだけど)自分から積極的に成果をプッシュすることが出来なかったのだろう。別段優れた成果である必要はなくて、ソフトウェアの簡単なバグを直したり、速度の遅い所を改善したり、そんなものでまずは良かったはずだ。だけど彼は、浮かれていてふわふわした印象も受けた。だから、最低限の成果を出すことが出来ず、結局クビになってしまったのだろう。
最近はグローバル人材とかいって海外とコミュニケーション出来る人材がもてはやされるし、ネット経由での仕事も多くなってきた。一方で昔ながらの「外国でビジネスしても上手くいかない」「外国人が思った通り動いてくれない」という嘆きも耐えない。だけど、そんな話を聞くたびに「日本人とコミュニケーションするのと同じルールで接していても上手くいく訳ないじゃん」と感じている。逆に日本人と接していると、「なんでコミュニケーションがそんなに適当なんだ」と思ったりもする。
仕事上で外国人と接する際のポイントは(自分の場合は、いわゆるアメリカ型で、アジア、アフリカ方面は知らないけど)
まあ、要するに、日本人同士なら「それは言い過ぎ」「きっとわかっているはず」と思っていることもしっかり表現しましょうということだ。ただ、これって、普段使わない思考能力を使うために、結構大変。予想よりも訓練が必要。自分の意識下に眠っているものを一生懸命掘り出していく必要がある。例えば、ソフトウェアを作成する際に「この仕様書通り作成して」と伝えると、その仕様書に書いてないことは、ほぼ達成されない。「数字は通常通り桁を合わせる」とか「エラーの出力は普段通り」と思っていても、はっきり書かないと応じてくれない。子供と接するくらいの気持ちの方が却って良いです。日本人だとバカにされてると感じるくらい。
日本人だとNoというと非協力的だと思われがちだけど、海外のきちんとした会社であれば、適切なエビデンスとともにNoということは、「問題を改善する積極性がある」と評価される。
その上で、
http://ayato.hateblo.jp/entry/20140129/1391004860
を読むと、「まあ、相手も悪いけど、この人も説得力のない資料を作ったんだろうな」と思っちゃう。伝えきれなかった方が負けって感じで。さすがにそれは言い過ぎかもしれないけど。
未明の2時間半。一心不乱にコードに集中 ──中島聡流プログラミングの流儀 #OpenGL｜CodeIQ MAGAZINE
──16歳でプログラミングに触れてから、現在までずっとコードを書いているわけでが、その持続力には驚きます。会社に入って数年もするとマネジメントをやるようになって、現場から離れてしまうプログラマも多いと思いますが。
これがまさに僕が一番問題視していることなんです。世界的に活躍しているIT企業、Google、Apple、Microsoft、Facebook……みんなアメリカの会社ですよね。なぜ日本はだめなのか。個々の能力では日本人が劣るところはない。勤勉な性格だし……。
根本の違いは、優秀な技術者がいつまでもプログラムを書いているかどうか、ということなんです。
特に理工系の修士号取得者。日本では大学を出て大手企業に入ると、そこではほとんどプログラムを書かない。仕様書は作り、ドキュメントも書くけど、実際のコードを書くのは子会社や外注やその下請けの人たち。僕はこういうのを「ゼネコンスタイル」と呼んでいます。
それに比べると、アメリカのソフトウェア企業は、バリバリの理系の修士号、博士号の人を採用して、その人たちを一生プログラマとして使い続ける。プログラマとして優秀であれば、ゼネラリストよりも高給を弾んでくれる。生涯プログラマでもリスペクトされる。 マネジメントはそれなりの専門職だから、それが得意な人に任せればいいという考え方。プログラマは一般に人の管理をするより、コードを書いていたほうが幸せだから。
ほんとこの文章を、大手SIerの糞馬鹿社員と、3年前に自分のいたチームの糞リーダーに読ませたい。
仕事を人に振ってばかりで楽していると無能になるぞ、と。周りに聞いてばかりいないで、たまには自分で調べて、考えて仕事しろ、と。
なんで皆管理側を目指すのかねぇ、、って上の記事のまま、使われる側だと評価されない、金くれないからだな。要は、日本は経営者とか幹部クラスが致命的にアホすぎるんだな。
それなりのPVのあるポータルサイトのリニューアルを70万円で請け負った。
ちゃんとした見積を出せば300〜600万円くらいの案件だと思う。
色々未来があり、先方に予算があるから…という理由でそうなったらしい。
もちろんそれなりのサイトなので、競合とのプレゼン大会となった。
結果うちが勝って受注となったわけだが、理由が「安いから」だ。
営業がプレゼンにいって、何の計算もされてないデモデザインを持っていってとってきた。
その後その営業が自らディレクションをしてくれれば問題ないのだが、
自分がやりたくないから、という理由でディレクターの私に案件が降りてきた。
内部を整理するとめちゃくちゃだった。
まず現状だとサーバーの維持費が高いからサーバーを移管したいという先方の考えがあって、
こちらも「じゃあ移管しましょう！」という提案をしているんだが、
元々入ってるプログラムがどういった環境で動いているかを確認していなかった。
それで受注した後にようやく現状のシステム仕様書がやってきた訳だが、
VPSで試してみたtが動かない。
元々のプログラムがクソすぎるわけだ。
この件に関しては一旦放置する。
最悪プログラムの組み直しをシステム部に依頼しなきゃいけないわけだが、
おそらくとんでもないレベルの罵倒を浴びせられることだろう。はぁ、気が重い。
次にリニューアル範囲を決めていなかった。
「とにかく何でもやりますよ！」というスタンスで仕事をとってきているので、
先方としては「これもリニューアル範囲に含まれるよね？」というスタンスで突っ込んでくる。
結局当初はトップページのリニューアルとサーバー移管のみの話だったがの、
全リニューアルとなった。もちろん受注金額は変わらず。
先方の事務所が離れているため、こちらから行こうとすると新幹線を使う事となる。
営業サイドは「安い案件で経費をかけられないから行くな」という指令が下る。
安い案件…？
安く取ってきたのは、どこの誰…？
そんな言葉をぐっとこらえて結局Skype会議がメインとなった。
誰が喋ってるか分からねぇ…議事録まとめられねぇ…という事がありつつ何とか仕様等まとめた。
会議にて要望が当初の倍になり、営業サイドからは「対応して」の一言。
結果、来年3月くらいまで私は数字的に全く会社に貢献できない人になるだろう。
「数字があがってない」と言われるだろうが、
はてブをリングサイドとして、2013年買ってよかったもの合戦が始まった。
後出しのほうが、質は上がっていくだろうから（例えば使っている写真を張るとか）
今あえて最底辺から苦言を呈する。
ブロガーたるもの無知蒙昧な衆愚を啓蒙する高い志を持ってもらいたいからだ。
今よりも高い水準を要求して余りある能力をお持ちだと信ずるからだ。
これはつまり、我儘というやつだ。
アタリマエのことは省いて欲しい
TIPSは血肉があってこそ
「自動車買ったら世界が変わったよ！やっぱレンタカーともタクシーとも違うな！」
どうだろう。
発言した人間との関係性で反応は異なるだろうが、余程でなければ苦笑いだろう。
もちろん、これが電気自動車であるとか、もっと言えば明治時代に馬車から乗換えた元公卿とかなら判らんでもない。
今あえてルンバを出す価値や、MBAを出す価値が有るだろうか。
アタリマエのことの集合体が意味を持つTwitterのさえずりとは違うだろう。
一つ一つのさえずりは小さくとも、バルスの大合唱は世界を揺るがす。
しかし、ブロガーは合唱団の一員ではなく、孤高の演奏家だろう。
大衆に紛れて声を上げる煽動者ではなく、先導者であって欲しい。
余程のことがなければ、それはそっと追記すれば良いだけだ。
そもそもコンナ偉そうなことを書く価値があると感じたのは、このブコメだ。
現物の写真を撮ってるのに他のサイトとかぶってるという指摘すごいなー。独自性を出すためにチョイスを変えるとか本末転倒だし、記事書くためにわざわざ別の何かを買ってくれば満足なのかな。
実に鋭い切り口で本質を見せてくれる。鋭すぎて傷の治りが早そうだ。
オレのリストは他人とかぶってるつまり通り一遍のリストだと婉曲的に表現するときに僕も使いたいと思う。
珍奇なものをワザワザ買ってくれば良いのか？という所が凄い。素晴らしい腕をお持ちだ。
なかなか返す刀で「オレはどうせワザワザ買ってこないと他人と被る普通の感性だよ≒オマエはどうなんだよ」とは言えない。
精進したいと思う。
つまり、買ってよかったものリストというのは、その人間を表すものだ。
なかなか買えない高いものを買ったからレビューしてやろう、というのも人間性だ。
安くてちょっとしたものでも生活が変わったならそれをリストに加えて欲しい。
そうすれば「安くてチョットしてものをリストに加える人」なんだと判る。
他人の本棚を覗くような、その人となりを如実に表すバロメーターだ。
TIZEN特集の雑誌が並んでいようとも、Nokiaの仕様書やMeeGo解説書があればその人への評価を改めるだろう。
高くて良い物を買って高いだけあって良かったと叫ぶのは我々で良い。
2013年を総括する、彼にとってこんな1年だったと示して欲しい。
前半Disったように聞こえると本義ではないため、弁明しておこうと思う。
N-Styles（あれっくすさん）のリストは後半流れるように素晴らしい。
人からモノをプレゼントされる人柄、それに引きづられるように泥縄で増えるグッズ、
さすが老舗、(通称)人間がダメになるソファの写真で如何にもなダメさを魅せつけておいて、
Vitantonio マイボトルブレンダーの写真に、テーブルの角のクッションを映し込む感性。
年会費1万円のアメックスゴールドカードに入っても旧料金法人会員プランがお得なのは、
コレこそがあれっくすさんの2013年を振り返り、2014年を感じさせるリストだと言える。
ルンバが見たいのではない、遅刻しないコツからあれっくすさんを観たいのだ。
「床に物を置かなくなる」みたいなのは、Twitterで我々愚民が呟けば良い。
Amazonのリンクを我々が踏むのは、「まとめ」を見たからではない。
購入を通じてブロガーと一つになりたいという
雨後の筍のごとく2013年買ってよかったものリストがまだ出てくるんだろうが、
取り敢えずで書いたそのリストにはそのブロガーそのものが出るぞ。
心せよ、
最後まで泣くんじゃない。
システム一式○○万円でござい、と出すと「もっと具体的な根拠を出せ！ そんなんで当社の社内決裁通らんわ！」って言われる。言われた。
具体的な根拠（=原価見積もり書的なもの）って何？っていうと、労働集約型産業なので、そのシステム作るのに何人が何ヶ月張り付いたか、に帰結するんだよね。
プログラムコードの行数で原価算出する手法もあったりするんだけど、古い大企業や公的機関といったお固いところほど、人月による詳細内訳が【求められる】。
「発注の前に、プロジェクトのメンバー構成表（各人の実名入り）出して」とかね。開発現場激励という名目の視察チェックが不定期に入ったりとかね。もうね。なんだろうね？
人月計算で見積もり出してプロジェクト動かしてるにも関わらず、システム会社の人間が死んだ魚の眼で一日中キーボードを叩き続けてる理由。
・技術力および経験不足で見積もりミスってる。（および、競争入札で一番安いとこに発注するって言われたから無理なダンピングしてる）
・進行中のプロジェクトにおいて、上流マネジメントの失敗で追加仕様や仕様変更が頻発してる。
・開発メンバーの中に役立たずが混ざってる。
この全てでございます。
最近は裁量労働制がトレンドだから遅くまで煌々と働かせても残業代払わなくていいし、生かさす殺さずで搾り取ろう！ ふぁいと！
なんで大きな開発案件ほど、UI 設計にちゃんとした時間と工数割かずに適当にやっちゃうんだろうね？ 不思議。
設計の最初の段階で【画面仕様書】という名のポンチ絵を書いて、ユーザ承認が降りたらもうあとは動かしたりしないんだけど。
おおむね、システム開発一筋３０年みたいな大ベテランが伝統の技を活かして固定画面でキーボード操作オンリーの前世紀 UI になるか、ロクな経験も無い頭でっかちの若手がドヤ顔で最新トレンドを取り入れてメニューがやたらパカパカ閉じたり開いたりする落ち着きの無い UI 設計になる。なった。
激しく使いづらいと、作ってる側も認識してるけど、その段階ではもうどうしようもない。ゆくみち戻れず。
実現場の利用ユーザには大変申し訳ない限りだけど、これはもうシステム会社まかせにしてても現実問題どうにもならんです。
だって、システム会社は納品済ませれば仕事完了だし。その先毎日１０年に渡ってうんこ UI と延々付き合い続けるのは、あなたがたなのだから。
画面仕様書が提示されたら、懇切丁寧に読み込んでチェック入れて赤字だらけにしたものを「バーカバーカ」って言いながら突き返しましょう。
その手間隙は絶対に惜しんではいけない。
開発会社から「ユーザインタビューの時間を下さい」って言われたときに、日常業務が忙しくて時間が取れないって断るのは自殺行為だ。残業してでもたっぷり時間取れ。
エラーメッセージに意味不明のシステム情報出すのは、システム会社が１００％悪いですね。
さすがにそこまでユーザ側に設計チェックさせろというのも無理筋な話。TCO に密接に関わるんだからおざなりにせず、もっと気合入れて丁寧に案内作りましょう。
全メッセージ「システムに不具合が発生したため処理を中断します。詳しくはシステム担当にお問い合わせ下さい」とかやらないように。約束だよ？
本業の利益ベースでウン億円も稼ぐ苦労に思いをはべらすと、感情的にもなりますわな。日々 100 円単位でコスト削減努力に血道をあげてるっていうのに！
このあたりはシステム会社の営業がちゃんと、ユーザが心から納得できるように丁寧に説明して理解させろ。頑張れ。超頑張れ。
まあこれについては根本、大規模システムにおける競争入札制度の欠陥ってのが何十年も前から指摘されてて、全く改善の目処が立っていない絶望的な今が有るわけです。
ユーザ側企業は「こんなこといいな、できたらいいな。空を自由に飛びたいな。さて、ハウマッチ？」で競争入札を求めてくるし。
システム企業側は「え？ もうちょっと詳しく話を聞かせてくれないとなんとも…あ、とりあえず予算組のために総金額だけ知りたいですか。入札日は２週間後！？ あわわ…えーと、んじゃ、どんぶりで…こんぐらい？」って杜撰な見積出して来るし。
まあそんな適当な入札、勇気を出して見送ればいいんですよ。でもそんな適当入札しかないんですよね世の中。武士は喰わねど高楊枝、なれど妻子は喰わしていかねば。
スタートラインがそんなだから、ボタンの掛け違い一つで開発プロジェクトはいともたやすく炎上するし、末端の開発人員はブラックだし、上層部はいつまで経っても終息しない開発とテストのエンドレスエイトに夜も眠れぬ日々を過ごすし、できあがったシステムはうんこでユーザ側も大変だし。幸せってなんだっけ？
システムの要件定義契約と、実際のシステム開発契約を分ければいいんじゃないって皆が思うのだけれど、まあ現実問題これもなかなかねえ。どうすればいいんでしょうね？
小学生の時に「こんにちはマイコン」を読んだことを除けば、自分がプログラミングに最初に触れたのはWindowsME上で動くHSPだった。
多分友達の家で「なんかパソコンあるし面白いこと出来ないかな」と話していて触ったのだと思う。3日ほどHSPを触っていたが、スプライトが動いてゲームっぽい何かが作れそうな予感がしたところで飽きた。導入としては良かったが、すごい偽物感があった。
次に目に入ったのはDelphiだった。当時、無料で入手でき、やりたいことがそれなりに出来そうで、かつ理解できそうな開発環境がそれしか無かったからだ。AphexTwinやAutechreにあこがれてDSPをやりたかったので、(1)とりあえず何か音を出そうといじくり回していた。
何日か触っていて、ようやくDelphiのGUI上で設置した「Button1」と関係がありそうな場所に、Webで見つけたコードをコピペすると、それが実行されることがわかった。実行された結果、エラーの文字列がIDEに表示されるか、運が良ければ音が出る。文字通りただのノイズがスピーカーから出ただけだが、とても嬉しかった。
さらに試行錯誤を続けているうちに、MSDNからコピペして"="を":="に書き換え頑張っていると、MSDNのサンプルコードのうちのいくつかは実行出来て何らかの音が出ることがわかった。楽しかったが、偽物の開発環境を使わされている感じもしていた。
またしばらくして、Delphiと同じ開発元からC++Builderというものが売られていることを知った。世の中ではpascalよりC++のほうが使われているらしいことは知っていた。なおかつ、(censored)したけどよくわからなかったVisualC++5.0よりDelphiに似ていて、ずっと使いやすそうだった。買った。8000円くらいだったと思う(2)。
C++はまったく意味がわからなかった。仕方ないので図書館に行って関係がありそうな本を片っ端から借りてきた。まったくの勘違いから、本屋で見つけた3000円くらいするDSPボードの解説書を買ってきて、自分が欲しいものとまるで違うとわかって枕を濡らしたりもした。
この頃借りた本の中に、「エキスパートCプログラミング」という本があった。ジョーク過多な原文を無理やり翻訳したような、典型的な翻訳技術書で、読んでいる間は楽しかった。内容は大雑把に言うと「これこれのコンパイラの場合メモリのアドレスがこうやって使われるのでスタックが云々ヒープが云々。あとCの仕様書書いた奴はタヒねアーグヴィーーアーグシーー」というもので、同じ頃図書館で借りたニューロマンサーのほうが100倍わかり易いと思った。
それでもなんとかポインタの操作くらいは出来るようになり、最終的にはBC++上で、wavファイルを読み込んでメモリに展開するプログラムと、コピペしたFFTのコードを元にソノグラムが表示できるプログラムが出来たと覚えている。今、それらのコードは手元には残っていない。
この後、3年ほどプログラミングには触れなかった。生活に忙しかったのと、人として腐っていたのと、あとは単に飽きたのだろう。
腰を痛めてコンビニのバイトが辛くなり、なんとかデスクワークがしたいと思ってテクニカルサポートの派遣業務を始め、紆余曲折、今はWebアプリのエンジニアをしている。普段はおもにPerlとJavaScriptを書いている。
ちょっとした処理をループ書くか再帰で書くか、といった時に、C++を触ってた時の経験がふっと役に立つことがある。
[1]この時にはまったく無意識だったが、新しい環境に飛び込むときに大事なポイントは、凄く低レベルな目標を決めてとりあえず進んで見ることだと思う。
何時の時代の話だよ。
てか、1万倍遅いなんてことが良くあって溜まるかボケが。
アホか書いたコードだってライブラリが勝手にごまかしてくれるし、
えーすが書いたコードだってライブラリにバグがあってどうしたってメモリーリークしたりするだろ。
そこに1万倍も差なんて無いわ。
ライブラリなんて分かんなくても仕様書通りに組み立てりゃいいんだよ。もう、プログラマーってそういうレベルなんだよ。
いつまで神聖視してんだよ。
お前の言ってることは最早、工場でたんぽぽ載せるお仕事をするのに、そのたんぽぽがどこ産で、そのお刺身がどの様な物が載って
どれだけの最終結果になるかきちんと把握しろ、って言ってるのと同じレベルなんだよ。
いい加減理解しろよ、ドアホが。
んな格好良いことしてたいなら、お前もグーグルとか行けばいいだろ。
ソフトを買うときは、原材料とか根拠とか聞きたがるんだ？説明する理由がないだろ。
むしろ、原材料を指定したいなら仕様書書け。その仕様書でいくらか見積もるから。
内部がこういう構造になってて、こういうふうだからこのぐらいかかるなんて、ラーメン屋に原価聞くようなもんだ。ありえない。
醤油ラーメンか、味噌ラーメンかぐらいは指定できるが、どこそこさんの醤油がどうたらこうたらで、一晩寝かせてどうたらこうたら
言うのは自由だが、聞くようなもんじゃないだろ。
秘伝の味に決まってる。教えてもいいようなものなら教えるが、作り方に関わる部分をきくというのはそういうこった。
プログラマーは仕様書に書かれているとおりに作るのが仕事で、意図を仕様書に落とすのは発注側の仕事だ。法律でもすでに明確に定義されている。
よくわからないし、言葉にもしないが、お前が悟ってプログラムを作れは仕事ではない。それは発注元が訴えられて賠償責任を負うべき事態。
もちろん、お金をくれればやるし、その仕事を設計・上流工程というのだが。
それでも書いた仕様書を読んで、サインしたらその時点で発注側の責任。
それでもXXのつもりだった。とか後付はなくならんし、いつもそれで裁判ざたになってるだろ。あれは別にアスペが書いたわけじゃない。
ここ一ヶ月間私は気になって仕方がない。
もう一度言おう。sendとreciveだ。
誰かをお忘れではないですか。
(゚∀゚)ラヴィ!!
reciveから逃亡していたのだった。
ところで、私はSEだ。IT業界の雑用係として名を馳せている。エクセルシートでレポートを書き、エクセルで調査表を作成し、excelで仕様書を修正し、Excelでソースコードを打ち込んでいる。エクセルでチャットに励むのも、エクセルに目覚まし時計を頼むこともエクセルでコーヒーを沸かすことも、、、できる。そんなエクセル戦士たる我が日々戦っているものはなんであろうか。難解なシステムか？不毛なレビュー会議か？睡眠時間か？……いや、どれもそうであるが、どれもそうではない。一番は誤字脱字、二番目は文言の不統一だ。レビューで誤字脱字が一つ見つかると平均して五分時間が伸びる。たった六つで三十分だ。鬼の首でも取った勢いで指摘する人もいれば、淡々と告げる人もいる。だが、これだけは共通している。間違えれば、確実に時間が伸びる。
そこは本質ではない、そこはレビューで確認してほしい点ではないんだ。内心でどう喚こうと、口に出していかに取り繕うと、誤字脱字の指摘にレビュアーは時間を最大限に割く。どいつもこいつもだ。修正は終わるところを知らない。
今いる場所もまぁ似たようなところだ。どこも一緒。だが、IFなんつー物騒なところにアホくさいスペルミス。これはどういうことだ？使用箇所は軽くgrep検索しただけで200行以上。ソースコードのタイムスタンプを見るに八年前はすでにこのフォルダ…ディレクトリ名を使用していた。
これだけ省略形？
今気づいた。
聞いていて、こっちが間違っているような気がした。何でたかが一ディレクトリの名前が違うことに義憤とも私怨ともつかぬものを燃やせばならんのだ。アホらし、アホらし。
その数時間後、仕様変更の連絡違いで30ファイルのエラーログを修正しなければいけないことをレビューで告げられて、闇の炎は再燃することになる。何の因果から、レビュー議事録を送ろうと開いたメールボックスには、TOEIC団体申し込みの最終案内が入っていた。
少なくとも八年前、ディレクトリ名にreciveと名付け、魔のレビュアーの監視を全て逃れて、見事システムに組み込むことに成功した名も無きエンジニアよ。私が今、敬意さえ込めた眼差しで見つめていることをあなた様は知る由もないだろう。人が多ければ多いほどいい。そうすれば、猫は犬に変わり、日本語はJanglishになる。あなた様は確かに、間違いを正しさへ変えたのだ。工数、信用、評価、どれも欠けることなく。
凄いよ、くそったれ。
幼稚で愚かな底辺SEの一人より。
