  |
はてなキーワード: 開発プロセスとは
夢のあるシステムに関わりたい。
いわゆるプログラマをしているが「屑システム」にかかわりたくない。
「屑システム」とは以下だと思ってる。
なお、一応言っておくと、私がかかわっているシステムすべてが以下に当てはまるとは言ってない。
自分が開発にかかわってるが、開発が進んでも自分の利益にならない。他人の懐具合がよくなるだけ。
安月給はもらってるから、それで満足しろということになるわけだが。
その安月給は当然あがることはない。私から見れば立派な「屑システム」だ。
枯れた技術だけが使われ、そのシステムにかかわったことが何の宣伝にもならない。
例えばいまさらsyslogが使えます、とかsnmpが分かります、とか意味なす。
細かいとNoSQLとかクライアントサイドJavascriptとか。
次につながるようなシステム開発がしたい。そういう意味で「屑システム」
「システム」とは、プログラムそのものだけを意味するわけではない。
プログラムを開発する、開発プロセスそのものも「システム」である。
例えば、ある作業をやったら、諸事情で無駄になるようなのが「屑」な開発プロセスだ。
責任者に、リーダシップがないせいだ。あるいは、プログラマに何の権限もないと起こる。
人間だから、全部有効な作業というわけにはいかないが、そんなんばっかりだとやる気にならない。
なお、リーダーシップというのは権限とセットだ。責任とセットなわけではない。
プログラムを作る責任だけあっても、その責任を全うできる権限がない以上
上と被るかも知れないが、一週間に一回も会議を行わないようなのも「屑システム」だ。
確かに会議だけしても意味ないが、しなくても全く情報共有ができず、プログラマは何していいかさっぱりわからない。
また、各作業員の間で信頼関係がないのも、なかなかに屑システムだ。
あとオブジェクト指向とか開発プロセスとか、コードの書き方みたいなやつも。本を1, 2冊読めば合格できるレベルの試験でいいから。
試験に合格してないと開発にはかかわらせないようにして欲しい。
「試験は合格して当たり前だろ」とか言う人いるけど、職業プログラマには合格できないレベルがゴロゴロいるから。
PHPの入門書の一冊も読んだことないだろってレベルの人間がPHPのコードレビューしてるとかギャグのような状況が日常。
で、そういう客観的に見たらどう考えても水準に達してない人に限って自分のレベルの低さを自覚してない。
自覚してないどころか「おれ10年選手だから」みたいに経験年数の長さだけを根拠に、むしろレベル高いと思ってる。
いや、普段の言動をみてると自分のレベルの低さはうすうす感じてるのかもしれない。
「学生時代にかじってた新人は変なクセがついてだめだ。なにも知らないやつのほうが素直で教えやすい」みたいなことをいいがちだけど、これって新人にも自分は負けるって自覚があるからその防衛反応だろうし。
そんなことないよ。シリコンバレーはエンジニアの数も求職数もものすごく多く、裾野がかなり広いので、実力レベルは上から下までさまざま。博士号なんてもってたら給料が高くなるから、雇用側もあえて学士程度を望んだりするケースも多い。すーぱーぷろぐらまーレベルがどうしても必要な会社なんて一握りだし。一部の花形企業以外は、実力はそこそこでいいから$80Kで来てくれますかありがとうみたいなところは多いと思う。
会社のスタンスもさまざまで、純粋にCSでやってきた人じゃなくても、新しいプロダクトを作るセンスがあるとか、HTML/CSSやJavaScriptに強いとか、NginxとかNode.jsを使って仕事したことあるとか、IT土方だけどJavaだけは人並み以上にできるとか、インディー系で携帯ゲーム作ってたとか、アジャイル開発プロセスに明るいとか、色んなタイプの人が評価される。何か得意なこと持ってれば、そういう人を探してる会社は必ずある。シリコンバレーは最先端で尖ってるっていうイメージもあるけど、枯れた技術での固い職ってのも多い。JavaとかPHPの仕事なんていくらでもある。Flashですらいまだに結構ある。ほんとに裾野が広い。多くの人が、それなりの実力でそれなりの仕事をしつつ、家族との時間や自分の時間を大切にして人生楽しんでる。
会社によっては、平均的な日本人の勤勉さを知っていて、そういう面で重宝されるケースもある。世界中から人が集まってるので、勤務態度も様々で、その中では日本人の真面目さは割と有利。まあ、日本人は英語しゃべれないとも思われてるけど。逆にちょっと話せればかなりインパクト強い。
結局、
・大学か高専出てるか（出てないとビザが厳しい）・・・できれば理系、できればCSメジャー
・採用したらすぐ来れるのか
くらいじゃないのかね。
顧客：「お客様向けのシステムが全部止まってるんだけど。なんとかしろ!」
営業：「すみません。原因調査中です。早期復旧を最優先に現在対処中です。」
↓
営業：「はやく、なんとかなんないの？。顧客、怒ってんだけど。」
PM：「すみません。現在、原因調査中、及び復旧優先で動いています。」
↓
PM：「なんか、わかんないだけど、早く復旧して。」
プログラマー：「はい。原因調査中です。（なんか休日だけど・・・）」
プログラマー：「原因分かりました。バグです。こうこうしたら、復旧・・」
PM：「はぁ？お前しかわからないんだから、お前直せよ。で、すぐにリリースな。」
PM：「属人性を排除しないお前が悪いんだろ、ドキュメントもないし。誰も引き継げないだろ。明日までにやっとけよ。」
PM：「お客さん困ってんだよ。やれるだろ？」
旅立つには十分だった。
なんだか話題になってるから書く。
やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。
Haskellが短いコードでプログラムを書けるというのは分かる。
それでやりたい処理のほぼ全てがまかなえるということも実感している。
副作用のない小さな関数を合成して大きな関数を作る利点も分かる。
再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。
ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。
むしろ邪魔なんじゃないかと思う。
ファンクターやモナドの概念が圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。
圏論が必要なのは、Haskellを設計する人であって、使う人ではないと思う。
なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。
Linux上で開発環境整えるのにカーネルのコードを読めって言うぐらい的外れだと思う。
いや、知識として持っとくのはいいだろうけど、役に立たんだろ。
Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語もオブジェクト指向言語とそこまで違いがあるような気がしない。
純粋な言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。
その無名オブジェクトにもっとあれこれデータや関数詰め込めば、いつの間にか普通にJavaやC#で使うようなクラスのできあがり。
その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。
関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。
上級者はデザインパターンをdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。
デザインパターンはオブジェクト指向言語の欠点を補うための苦肉の策じゃないよ。
関数プログラミングの基礎的なパーツだと思う。
だからちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。
関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。
もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。
けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。
役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。
せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。
多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社。
そんな会社だと、プログラムでなるべく解決する（コードが業務プロセスを頑張っちゃう）ために頑張るよりも、
業務プロセス・開発プロセス全体で最適化するよう頑張った方が、
プログラムで頑張ろうとすると、
外注するのに設計しようにも結局学習コストがかかりすぎるとか、
外注が逃げるとか、
引き継ぎ先がいなくて死ぬとか、
そんな余計なことが多かった。
反復性・正確性が求められるものはプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。
ともすればプログラムのスペシャリストでないことに大きなコンプレックスを抱くけど、
生産物が割合ライトで公共性も低い（例えばエンタメ系スマホアプリ）だったら、
身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。
オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して
ライトなフレームワークを選択して、ライトな開発プロセスでやる選択がもっと歓迎されていいと思う。
そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からのボトムアップ的な思想やツールでなく、
マネジメント視点や経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。
元プログラマが経営層になっての話は近年よく聞くけど、非プログラマが経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。
こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。
暇ができたらまとめたいなあ。。
その前に売上UP（白目）
・その人材を適所にあてはめる。
・人々の士気を保つ。
・チームの結束を強め、維持する。
・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。
・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。
・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。
・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。
・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。
・さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。
つまり……
心で指揮をとる。
組織に魂を吹き込む。
くだらないものを嗅ぎ分ける鼻を持つ。
・戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。
・採用には、管理に必要な身体の器官、心臓、魂、鼻、腹をすべて使う（しかし、腹が大部分だ）。
・一人でやろうとするな。二つの腹には、一つの腹の２倍以上の力がある。
・新しく採用した人材には、１回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。
・意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。
・話すより聞け。
・短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
・短期的な効果を約束するものは、いんちきである可能性が高い。
・やる気のある態度を常に引き出そうとしない人物をリスク管理人に任命せよ。
・悪い話が上層部に伝わりやすい経路（匿名性など）を作っておくこと。
・無駄を減らす。
・成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。
・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する（本人たちにその意思があれば）。
・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす。
・プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。
・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。
・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。
・実際の結果と照らし合わせてモデルを調整する。
・病んだ政治はどこにでも、最も健全な組織にも出現する可能性がある。
・病んだ政治の決定的な特徴は、個人の権力と影響力の目標が、組織の自然な目標より優先されることである。これは、病んだ目標が組織の目標と相反する場合でも起こりうる。
・病んだ政治の副作用の一つは、少人数のプロジェクトを抱えることが危険になることである。
・単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい。
・手に入るすべての基本要素（ソフトウェアの数量化可能な特徴）をもとに合成尺度を作成する。
・考古学的データを収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。
・合成尺度の公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。
・過去のデータベースをもとにトレンド・ラインを引き、予想される労力を、合成尺度の値の関数として示す。
・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンド・ラインから予想される労力を割り出す。
・生産性トレンドのノイズのレベルは、予測を立てるときの誤差の目安にする。
・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然な目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。
・形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良の為に費やされた時間を相殺できる可能性は低い。
・プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。
・プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なＣＭＭ等級の引き上げ）は、プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。
・標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。特に、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事（役に立とうが立つまいが）が発生するなら、標準的なプロセスが厳密に守られてしまう。
・デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。
・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
・相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
・一時的なプレッシャーや残業は、人々の商店を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
・管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。
・おそるべき推測：プレッシャーや残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。
・管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる（虐待された子供が自分の子供を虐待するようになるのと同じ）
・管理者が部下を侮辱すると、それが刺激となって部下は自分の仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」である。しかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。使用を明確にする最初の一歩にもならない。
・仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである。
・開発に複数の当事者が関わっている限り、利害の対立は避けられない。
・対立は尊重すべきである。対立はプロらしくない行動のしるしではない。
・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする。
・勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。
・触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても（通常はほかにもいろんなことをするが）、触媒の役割は重要で貴重である。
・仲裁は、触媒の役割の特殊なケースである。仲裁はわずかな投資で学習できる。
・「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。
・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。
・初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。
・このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。
・理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤（プロジェクト期間の最後の６分の１ぐらい）に人数を大幅に増やすというものである。
・おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。儀式は、小規模な会議や無欠点運動など、プロジェクトの目標と理想に目を向けるために使う。
・注意：怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである。
・考察：怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる（これは怒っている人の問題は解決できないが、ほかの人の悩みは軽減できるだろう）。
・病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。
・問題が自然に解決するか、行動するチャンスが来るのを待つしかない場合もある。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。
・それは、組織の自然な目標である繁栄と福祉の精神とは正反対である。
・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。
オレ、東京に住んでる３０歳毒男、職業はＩＴ系なんだ。東京の生活に疲れて来たから、地元に帰ろうかと思うんだが、田舎には有るわけない。
なんだかんだ言って東京は学ぶ環境が発達してるし、ITって勉強会も盛んにある。開発プロセスに関しても会社によっては最先端だ。
横文字使ってはなしたり、「～～感」の様な会話も成り立つ。
けど、田舎帰ったら、業務系のITドカタ系の仕事しかないと思う。
もし、ITドカタ系に就職しても上流工程とかで「仮説が～」なんて言葉を出した瞬間にシカトされそうな気がする。
エクセルの使い方を知らないＣプログラマーが隣でグダグダ馬鹿な事いってそうな気がする。
そして、３０過ぎで地元に帰ると周りの目が ＭＡＸで都落ちめって感じで見てくると思う。
おまけにやはり出会いが無い。田舎で３０過ぎの女はもはや売れ残り以外の何者でもないだろう。
これまで散々遊んできたから田舎の３０過ぎの田舎毒女には多分、納得できないだろう。
こう考えると、次は海外に逃げるかっと思ってしまう。
ちょっと昔の話。今よりも僕はずっとずっと言い訳をするのが好きで、理屈を説明するのが好きだったんです。
でまぁ、当時も今と変わらずデスマーチがへりませんで、
アジャイル信者と飲みながら「いいプログラマがいない、だからデスマーチがへらないんだ」と文句言ってたのです。
進捗報告会議で。
したらまた、このアジャイル信者が「じゃあ、わかった」と言うのです。「今からプロジェクトのやりかたを変えよう」と。
プロジェクトのやり方を変えたことなんかないオレは焦りました。「いや、ちょっと待って」とあわてます。
でもアジャイル信者は、少し遠くで打ち合わせしている2人組のプログラマを指さし、「あそこ行って一緒に検討しようぜ」と言い、席を立ちます。
オレは「いや、向こうも迷惑だし」とか「さすがにうざいっしょ」とか言って止めます。
アジャイル信者は「嫌がられたら戻ってくればいいんだよ」と言ってましたが、オレが動こうとしないので行くのをやめました。
「じゃあ、海外発注して、オフショア開発にしようか？」とアジャイル信者は言います。
「逆にそっちの方が難易度高いだろ」とオレは顔をしかめます。
「でも時間がないんだろ？ だったらやり方を変えるしかないだろ」とアジャイル信者は口調を強めます。
「そうだけど、もっと普通にやりたいっていうか」とオレ。
「なに、普通って？」
「ウォーターフォールとか、Ｖモデルとか、そういう…」とハッキリ言えない自分。
「じゃあ、オレが今からテスト仕様を具体化してきて、それでお前に渡したらいいか？ それも時間の削減だよな」という友達。
「それは…、だけど、ほら、お前もこの前言ってたじゃん。ドキュメント作らないやりがあるとか」
「は？」
「その…」
「…ドキュメントを作らないじゃねぇよ。無駄なドキュメントを作らないだよ」
「あ、そうだったね。…でもオレ、ドキュメント書くの、少し苦手だし。そこまでしてプロジェクトのやり方変えたいってわけでもないし…」
「だせぇ」
と言いました。
彼は言います。
言い訳をして、さも「こういう事情なんだ、だからしょうがないんだ」って言うけれど、
プロセスを変更する勇気もないやつが、時間が無いとか言うんじゃない。
どうせオープンソースのライブラリを使えば「オープンソースは保障がないから怖くて使えない…」って言うし、
スパゲティコードを変更しようとすれば「動いているコードに手を入れるプログラマとは仲良くなれそうにない」とか言うだろうし、
開発プロセスを変更しようと言えば「いや、いままでこのやり方でやってきたし」って何かにつけて言い訳するんだろ？
だったら「自分にはソフトウェアを開発する技術力がないんです」って素直に認めて文句言うんじゃねぇよ。
そっちの方が、よっぽど何かってときに力になりたいってと思うし、
つーか、できない理由並べて、今の開発プロセスやスパゲティコードを変更させずに、バグをなくしてもらおうとするその魂胆がだせぇ、と。
男増田です。今日ショッピングセンターのトイレを利用したところ、そこの男性用小便器のデザインが今まで見たことのない斬新なものでした、というか、率直に言うとものすごく女性器に似ていました。それだけの話なのですが、色々考えるところがあったので文章にまとめます。以降男性用小便器を『それ』、女性器を『あれ』と呼称します。私はトイレ産業の関係者ではありません。他の業界のエンジニアです。部外者の立場で書きました。
普通『それ』のデザインというと、四角いものを思い浮かべる男性が多いと思います。大きさは様々で、例えばホテルのような高級っぽいところだと、厚みがあって重量感があるものが備え付けてあったり、駅とかだとそれほどでもなかったり。丸っぽいものは学校にありました。それらは大抵小ぶりだったような気がします。正直、今日まで『それ』のデザインについては無頓着だったので、思い出しながら上のような例を書いています。
『それ』は工業製品ですから、基本的には素材の体積で値段が決まると考えられます。大型のものは高価なはずで、だとするとそれは高級感を持つのみならず、パフォーマンスも違ってくるのではないか、と予想します。じゃないと、アドバンテージが少なすぎじゃね、って。
そこで『それ』の性能の指標として『尿のユーザー及び環境へのはね返り』が重要であると想像しました。ここではそれが数字化できるものとして扱い、ユーザーと環境（例えば床）は別々のものですが、まとめて『はね返り係数』と呼称することにします。『はね返り係数』が小さい『それ』ほど優れていて、メーカーはそこで技術競争しているに違いありません。先程の『それ』の大きさに戻ると、大型のものほど尿を受ける曲面の設計に自由度を持たせることができ、結果的に『はね返り係数』を向上させることができます。
さて、開発プロセスをイメージしてみましょう。『それ』を利用するユーザーの身長は様々であり、使用時におけるユーザーと『それ』との距離にもばらつきがあります。使用状態も検討しなければなりません。ケータイで話しながら用を足しているかもしれません。設計では、あらゆる状況でまんべんなく『はね返り』係数を最適化させる必要があります。
私、男増田の経験からいうと、モデル体型を数種類用意して、それにモンテカルロシミュレーションを組み合わせているのではないかと予想します。
このあたりがエンジニアリングですね。
私が見た『あれ』の形をした『それ』に戻ります。第一印象は「細！」でした。ボウリングのピンを上下からつぶしたようで、下部はもっと丸みと厚みががあって包み込むような形状、上に行くにしたがって薄くなり、あげくには水を流す部分が突起を形作っていました。こうして書いていると、私がエロエロでひどい欲求不満のようです。皆様に『それ』をお見せできればいいのですが、写真を撮ってくるわけにはいかなかったですし、「小便器 女性器 デザイン」でググっては見ましたが、製品のサイトにはたどり着けませんでした。正直、他の男増田の皆様が同じように『あれ』を想起されるかどうかは分かりません。
しかし私に関しましては、用を足しながらいやらしい想像が浮かんでくるのを抑えることはできませんでした。思い切って書いてしまうと、中にどくどくとたっぷりと注ぎ込んでしまいました。そこで、はっと気付いたのです。これは人類学だと。
ユーザーに『それ』が『あれ』だと思い込ませることができたならば、その時のユーザーの行動をより理解することができ、結果製品のパフォーマンス向上につなげることができます。射精だったら上手に狙ってこぼさずに。つまり『それ』の曲面設計よりも、『それ』のデザインによって『はね返り係数』の最適化が可能になるのです。人類学・民族誌学的アプローチです。
短所としては、『あれ』を想起しない人、特に『はね返り係数』が高そうな子供には何の効果もない、という点が挙げられます。ただ、それ以外の長所として、『あれ』が比較的小さいために洗浄に使う水の量を減らせるということもあると思います。
色々書きましたが、中の人の意見がない限り私の空想に過ぎません。ただ、『あれ』の形をした『それ』との遭遇は、休日の私にちょっとした思考をくれました。
まぁ、年齢からいって近いうちに転職されるのだと思いますが。
今いる世界は今いる世界できちんと色々と見ておくと、転職後に役に立ちますよ。
特に確立された開発プロセスの元での開発経験は、そうでない、開発プロセスなんてものが存在しない現場（大抵そういったとこは「うちはアジャイルでやってます」って掲げてますね）にいった場合に結構役に立ちます。
すぐに転職されないのなら、今の仕事は今の仕事で色々と学ばないと時間がもったいないですしね。両方の世界を見てきたことのある１エンジニアからの提案です。
まぁ、両方見てきた人間としては、COBOLやメインフレームの世界もあれはあれで色々と考察できるというか。
COBOLは結局のところ業務処理用DSLだよなー、とか、やたら一本一本のプログラムが短くてそれらをJCLでつないでデータを流す様はPlaggerでたくさんのプラグインを設定ファイルでつなぐのと似てるよなー、とか。
とはいえプログラマーとして退屈なのは確かにありますね＾＾；
