「開発プロセス」を含む日記 RSS

はてなキーワード: 開発プロセスとは

2020-05-26

anond:20200526002227 情報処理技術者試験なんて簡単で案外役に立ちます

情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。

前提が違う気がしますよ?

まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験危険物取扱者試験などの国家試験とは異なり、

別に持ってなくても実務に従事できるって言う不思議国家試験であること。

なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。

 

じゃあなんで試験なんか受けるの?

情報処理技術者試験は、ちゃん情報処理のこと勉強してますよ!ある程度の知識は修めてますよ!って言うためのものでしょう。

名刺資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。

たこ資格を持っていることで、ちゃん勉強している人間なのか、その指標にもなるのでマネジメント一助になるです。

なので、エンジニア同士の共通言語って位置付けな気がします。

 

そんなにひどい問題が多いの?

ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、

一方で実務以外のコンピュータ技術本質的な設問であったり、法務関係問題もあったりして、

マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識必要になったときには役に立つかと。

 

そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、

まともな設計知識を持っていたら、このくらいの問題は知っていますよね?ってのが技術試験の一面です。

※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと・・・w

 

ちなみに、UMLの基本や、開発手法MPEGなどの標準規格名称なんかを覚えるのは、設計コーディングにおいて「超大事」なことです。

そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、

システムを構築していくソフトウェア開発手法」でやります!みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。

基本情報技術者試験レベルメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。

 

情報処理技術者試験なんて簡単に取得できます

合格率は基本情報技術者試験で3割弱、応用情報技術者試験で2割強となっています

なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから

そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという・・・)

なのに合格率が低いのは、みんな真面目に勉強(暗記)していないからと思われます

試験会場にいくと分かるのですが、まずスタート時点で1割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。

会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。

暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、1~2か月真面目にやればだれでも取得できますよ。

ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。

範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。

 

情報処理技術者試験は案外役に立つ

上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます

合格率2割の国家試験を、通常業務をこなしながら取得してくるだと・・・!?化け物か! みたいな

雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。

 

受験だってそんなに高くないし、そこまで噛みつくような試験でもないと思いますけど。

情報処理技術者試験なんて何の役にも立ちません

情報処理技術者試験資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術無関係ものを含まないということです。

なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります

オブジェクト指向におけるカプセル化説明したものはどれか。

  1. 同じ性質もつ複数オブジェクト抽象化して,整理すること
  2. 基底クラス性質派生クラスに受け継がせること
  3. クラス間に共通する性質抽出し,基底クラスを作ること
  4. データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること

https://www.fe-siken.com/s/kakomon/19_haru/q42.html

こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。

数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。

ひどい問題は挙げればキリがありません。

UML2.0において,オブジェクト間の相互作用時間の経過に注目して記述するものはどれか。

  1. アクティティ
  2. コミュニケーション
  3. シーケンス
  4. ユースケース

https://www.ap-siken.com/s/kakomon/22_haru/q44.html

図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそもUMLなど別に技術者として知っておくべき知識でもありません。

要求分析から実装までの開発プロセスを繰り返しながら,システムを構築していくソフトウェア開発手法はどれか。

  1. ウォータフォールモデル
  2. スパイラルモデル
  3. プロトタイピングモデル
  4. リレーショナルモデル

https://www.fe-siken.com/s/kakomon/23_aki/q50.html

これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題いかに、この試験エンジニアリングプロジェクト管理本質関係いかがよく分かります

極めつけはこれ。

次の画像符号化方式のうち,携帯電話などの低速回線用の動画像の符号化に用いられるものはどれか。

  1. JPEG
  2. MPEG-1
  3. MPEG-2
  4. MPEG-4

https://www.fe-siken.com/s/kakomon/17_haru/q52.html

地方公立中学校定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字語句対応を覚えることが重要だと思っているのでしょうか。

情報処理技術者試験で測れる能力は以下の2つだけです。

  • 内容の理解はともかく、ある用語を「聞いたことがある」かどうか。
  • 150分間、落ち着いて椅子に座っていられるかどうか。

まり、ある種の発達障害ではない意識高い系ポエマー認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。

そもそもコンピュータプロジェクトマネジメントの技術を、資格試験勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。

2020-02-15

anond:20180929221805

そもそもアジャイル開発でやる気がないのだろう

若いエンジニアは「新しい技術・開発手法は優れている」というドグマを、なぜか頭から信じ込んでる場合が多いが、

ウォーターフォールだろうがアジャイルだろうが、ミスなく早く開発できればなんでも良いし、

ウォーターフォールモデルにチームが習熟しているなら、そっちの方が良いに決まってる。

アジャイル真理教宣教師でもあるまいし、金貰ってる仕事なのだから、わざわざ今まで経験したことのない開発プロセスを試して危険を犯す必要がない

可能性としては

1.偉いさんがアジャイルアジャイルうるさいから、なんちゃってアジャイルモデル適当お茶濁しとけと思ってる

2.チーム全体にアジャイル開発の経験値がないので、失敗しないように今回のプロジェクトウォーターフォールでやりつつ、

アジャイルモデルに習熟する時間を稼いでいる。

どっちかだろう

2019-09-29

リーダーの部下に怒りが収まらず悩んでいる

長いので最初にまとめ

愚痴です。

ざっくりいうと、

という話です。詳しく書きすぎて身バレしそう。

これまでの経緯(長い)

私は、昨年とある小さい企業入社し、入社10ヶ月ほどで管理職となった。入社直後の配属先は5名前後の開発チームで、タイトルの「元リーダーの部下」とはそのときにチームリーダーを務めていた人物である

入社先の会社自体設立から10年程度経過しているが、当初は社長のツテなどで社員を雇っていたようで、開発チームにはいわゆるプログラマとして働く人のみで開発のマネジメント経験のある人はひとりもいなかった。ちょうど数年前から事業ちゃん収益化しようとしているところだったが、これまで社長自身の旗振りによって動かしていた開発チームも、社長多忙となり直接見られないことから一応リーダーとして立っていたようだった。

私は前職ではそれなりの規模の企業で、受託案件プロマネを数年間やっていたこともあり、今の会社面接の際はそのマネジメント経験を非常に買ってもらえた。そういう経緯もあり内定をもらい入社したので、最初はやってる業務内容を教えてもらいながらこちらもチーム運営ヒアリングしたりして状況把握につとめた。初っ端、タスク管理方法について聞いてRedmineを見たところ更新されているチケットほとんどなく、営業チームから要求がたまに書かれるだけのものになっていて「おぁ・・・」となったが、そういうところから運用ルールを決めて周知して回して…と地道に進めてきた。

2〜3ヶ月もすると、開発チームのメンバーとしてマネジメント会議に私が参加するようになり、他部署との依頼や業務調整など、すべて私を通してやってくれるようになった(それまでは、営業部門の人が開発メンバー個別に聞きに行く、という形で情報共有もされていなかった)。

それでも、名目上、チームリーダーとしては彼を立ててはいた。もはや彼のリーダーとしての仕事は進捗確認するためにチームメンバー招集すること(進捗確認自体は私がやっていた)と、全社会議で開発チームの進捗をみんなに報告することだけであったが、私が管理職になったことを機にその仕事も私が引き取り、他のプログラマたちと全く同じ立ち位置になった。

話は変わってチーム全体のことだが、開発チームにはさまざまな勤務形態で働く人がいることと、私の前職ではデスマーチ的な働き方が横行していた反省から、チームメンバーには極力割り込み業務をさせない・会社全体の状況はできるだけこまめに共有する・定期的にメンバー個別に話を聞ける時間を作る、などメンバー安心して働ける環境づくりを心がけてきた。また、開発プロセス品質についてそもそも知識がないメンバーもいたので、個人個人能力底上げができるよう、タスクの洗い出し方から設計書の書き方、テスト項目の作り方など教えながら一緒にやってきた。実装インフラ設定などは逆に私よりも知識能力がある人たちだったので、道筋を作ってあげることでこれまで「それなりに動く程度に作って終わり、バグが報告されたら手が空いたときにやる(結局できない)」みたいな感じだったのが徐々に改善されてきたと感じている。

ただ、彼だけは例外だった。最初の数ヶ月で、彼自身ハンドリングさせる仕事を振ってはいけないと分かってはいたため、彼にアサインする仕事は必ず私が最初に介入し、進め方・タスクの洗い出し方・スケジュール…とすべて打ち合わせで明確にし「いつまでに何をする」をきっちり決めて(スケジュールは彼の見積りさらバッファを山積みして)あとはやるだけ…な状態に持っていく。また、彼は誰かにまれごとをするとそちらが最優先になる自分タスク管理をできない人なので、一切他のタスクを振らないようにしていた。それでも期日になると、成果物が出てこないか、終わってないものが出てくるか、そもそもタスクがなかったことになっている。終わったと本人が言っていても、当初やることに合意したはずのもの実装されていなかったり、適当実装だったり。リリースすると客から指摘が来て、それの対処にまた数週間かけるのである(次の開発を開始できないためまた遅延する)。

そんな状態なので、開発工程ど真ん中でも頻繁に介入して立て直しをする必要が出てくる。立て直しをするときにはできるだけ彼の心を折らないよう、「このまま進めても遅延するリスクが大きいので」と伝え、振り返りの体で「ここでもう少し見積りのための調査を詳細にやっておくべきだったね」「次はこうやってみよう」と立て直しのために必要作業を一部実際に自分でやってみせ、他の部分を明日いっぱいぐらいで作ってね、作ったら一緒にレビューしようね、という風に毎回新人教育のような気分になりながら進めるのである。当然私自身が持っている仕事に支障が出るので週末にやるのである

長くなってしまったが、ここまでは日常業務光景であり、組織作りや案件炎上しないための立ち回りなどは私の仕事だと認識しているので努めて冷静に対処しているつもりである。怒鳴ったことは一度もない。

私が怒りを覚えていること

私が怒りを覚えてしまうのは、彼の仕事上での振る舞いである。

発言が、仕事茶化すようなものだったり、自分タスク他人事のように言ったりする。そしてそれは状況がシリアス(彼の能力不足に起因する遅延が発生している状況など)になっても変わらないため、非常に癪に障る

これまでのことをすべて列挙するときりがないが、直近に行った、彼が進めているプロジェクトの仕切り直しのための打ち合わせ(私と彼の一対一)での発言特にひどく、タイトルの通り怒りが収まらない状態が続いている。

  • 遅延しているプロジェクトを立て直すためにタスク課題の再洗い出しを指示すると「それやらないといけないの?」「何日かかるかわかんねえな」「洗い出してちゃんとやろうとすると終わらねえよ」(立て直すためにそれを指示しているのに)
  • 課題なんて実装してみないとわかんねぇだろ」(調査期間にやったことの振り返り時)
  • その立て直しの打ち合わせ(冒頭で、スケジュール見直して仕切り直す旨を伝えた)が終わると、周りのメンバーに「スケジュールが延びた〜」とうれしそうに話す(私が事前に営業さんたちに説明して頭下げて…という話をしたにも関わらず)
  • それを指摘するとヘラヘラと笑いながら「いやいや言葉のあやだから〜」と返事する

よくブチ切れずに済んだなと思いながら、このように調子に乗ったままだと彼は負債再生産を繰り返して会社に害為す存在になることがわかっているため、きっちり〆ておく必要があるのかなとも思う。反射的にそういうアクションをとれない自分が恨めしい。とはいえ過去就業規則全然守らないことに対して説教したときヘラヘラしてたし、金銭的な処分をする権限はないし、自分には彼をどうにかするのは荷が重いな…と迷いに迷っている週末。

人手不足の折、やるべきタスクはたくさんある中で、彼の手もまた人手だと思いながらやってきたけど、私の負担けが増えてモノができないなら思い切って切る判断もあるのかなと思う。結論が出てこないけど、直近指示したことが予定通り出てこないならまたそれに対して立て直しをしないといけないと思うと心が重い。彼を担当から外すにしても今他に空いている人はいないし、彼にさせる仕事も思いつかない。担当から外したら外したで「身軽になった〜」と喜ぶのだろうか。それを想像してしまいまた怒りがこみ上げ無限ループに陥るのやめたい。

2019-08-02

[] 8年間働いた某自動車部品会社退職しました

あらまし

自動車部品会社で8年ほど働きましたが、思うところあって少し前に転職しました。

なお、基本スペック

転職した理由は大まかには以下の通りです。

これらの事は、どんな会社でも規模の大小によらず多かれ少なかれ共通する点でもありますし、私の恨みつらみを知っても楽しくないと思うので(あるいは、本ポストをご覧いただいている方が求めているのはまさにそういう心の闇なのかもしれませんが)、具体的には書かないでおこうと思います。ここではあまり話題にならない自動車業界雰囲気自分が見てきた範囲で書こうと思います

業界全体の雰囲気とここ数年の動向

世間一般でも言われていることですが、ここ数年で自動車業界に他業界(主に、家電ITから転職する人が増えましたし、業界内でも転職する人も増えたように思います。極端な例ですが、全員が転職して部署がなくなったという例や、部署のほぼすべてのメンバーが他社から転職者という例が知る限りでも複数ありました。

車がハッキングされたり、NVIDIA自動車向けの半導体リリースしたり、Teslaが電気自動車販売したり、自動車メーカー各社のプラットフォーム戦略軌道に乗る等、技術面、ビジネス面での変化があり、従来のビジネス手法や開発手法通用しなくなったのも世間の評判通りです。一方、価格競争や、納期対応、カーメーカーを頂点にした厳しいサプライチェーンマネージメント等はあまり変化がないように思います。また、価格競争のために、製品原価を1円~10円下げるために数千万円~数億円の開発費・設備投資費を費やすという取り組みや、車種・グレード固有の個別最適化設計・開発等、自動車業界らしい取り組みもまだ多く残っています

最近トレンド実業務に与えた影響

まずは、実際のところは下っ端~中堅目線でどう変わったかというところを書きたいと思います

いろんな人材自動車業界に入ってくるようになり、いい意味多様性が生まれたように思います。従来の自動車業界は、業界内で少々転職する人がいるぐらいで他業界から転職者は多くはなかったらしいです。

逆に、新しい流れを受け入れることができず、取り残されている人も一定数います。知る限りでは同業他社も同じ状況のようです。そのため、せっかく生まれ多様性をうまく活かせていないようにも感じていました。ただ、これは現在自動車業界で働き盛りの40代の方々が若手のころは自動車業界画一的で発展性がなく、斜陽産業だといわれていたこともあり、解消にはしばらく時間がかかると思います。それに、どこの業界会社にも新しいトレンドになじめない方はいらっしゃるようですので、ある程度は致し方ないかと思います。足の引っ張り合いの末に死屍累々のあり様の携帯端末ビジネスよりはよっぽどましかと

従来の自動車部品メーカーの開発は自動車メーカーが主な関係先でしたが、ITに近い技術が利用されるようになり、開発が自社のみで完結しなくなり、業界外や社外とのかかわりも増えましす。そのため、僕が業界に入った時に蔓延していたお客様の言うことは絶対という雰囲気いくらか軽くなったように思います。また、個人業務では、ソフトウェアベンダーコンサルティング会社欧米ベンチャー企業とかかわることが多かったです。ただ、家電業界斜陽になった当時、景気がいい自動車業界に参入してきた会社が多数ありましたが、ビジネスモデルや開発手法のあまりの違いや、既存ビジネスへの参入の難しさから、多くの企業撤退もしくは苦戦しているというのも現状です。

業界から転職されてきた方に関して言及すると、仕事の進め方や、客先とのかかわり方が他業界とは大きく異なることもあり、年齢・経験によらず苦労されている方や、心が折れてしまった(隠語)方も多数いらっしゃいます

ここからは、国内自動車業界の本当によくないと思う点なのですが、新しいブーム技術が発生した時に、社内の中堅以上の方が、否定的見方をしてしま雰囲気がやはり業界全体に漂っている点があると思います。えてしてそういった考え方や雰囲気は伝染するもので、新しく業界に入った方もそういった考え方に染まってしまったり、現実を嘆いて業界外に転職していってしまうこともあるようです。一方で、家電業界携帯端末業界の衰退・ビジネスの変化を目の当たりにして、新しいトレンドを取り入れる必要があると考える人も年々増えているように思います

やや突っ込んだ話になりますが、最近は新しいトレンドCASE(Connected/Autonomous/Sharing/Electromobilityの略)とまとめて呼ぶことが多いですが、初めに大きな変化を国内自動車業界にもたらしたのはElectromobilityであったように思います2010年代から自動車の電動化により、すべての車がEVもしくはHVに置き換わり、エンジントランスミッションの巨大市場が失われ、モーターやバッテリー、充電コバーターの巨大市場が生まれるといわれていました。ただ、EVの航続距離を延ばす根本的な電池の容量問題への解決策が見えないことや、充電スタンド等のインフラ整備が進まないこと、ハイブリットのみならず、グリーンディーゼルダウンサイジングターボ等により、EVでなくても燃費改善策はあること等の背景もあり、当初思われていたほどEV関係市場が伸びないということが2015年ぐらいから明らかになってきました。逆に、自動ブレーキ代表される、既存のACCや車線逸脱警告、周辺監視等の技術の延長に位置するマーケットは大きく伸びたというのが実際のところです。

そのため、当時EV関連事業に巨額の投資を行った方々の間では新しいトレンドは絵に描いた餅という固定概念が植え付けられおり、なかなか手が出しにくい状況になってしまったという点も、新しいトレンドをなかなか取り入れれない原因になっているように感じられます。また、上に書いたことを否定するような文章になってしまますが、多種多様製品があるため、大半の製品では新しいトレンドとは無関係に従来と変わらない方法技術を用いて開発を進めることも多く、変化は全体から見ればまだまだ小さいため、多くの企業トレンドに乗り遅れていることに対する直接的なデメリットを受けていないという状況のようです。

ワークライフバランス残業健康上のリスク職場雰囲気

次に、働いてみてワークライフバランス等はどうだったかという話をしたいと思います研究・開発職のワークライフバランスは言うほどは悪くないと思いますが、市場不具合対応時や、納期対応時はかなりの残業必要になることは間違いないと思います特に製品リリースの直前には、ストレス睡眠不足から心身の健康を崩す方も度々いらっしゃるようです。営業工場製造部門納期遅れが業績等に直結してくることもあり、工場とお客さんとの往復や、残業対応が迫られていることが多いようです。さらには、中堅以上の層に暴力的な人も多く、部署によっては罵声や怒号が飛び交うという話も実際にあります自身も、初対面の人に打ち合わせ開始5秒で怒鳴られたことがありますし、そのまま数十分にわたり罵声を浴びせられたことも幾度となくあります。ただ、最近世間の風当りがきついことや、容易に転職可能となったこともあり、そういった雰囲気もここ数年で多少はましになったかなと感じます

人材育成に関しては、かつては人材流動性が非常に低い業界であったため、技術方法は先輩や上司から業務を通じて学ぶ、既存技術を知っていて当たり前という雰囲気もかなり蔓延しています。そのため、個別技術に対する系統だった教育プログラムが用意されていなかいという問題もあります。新しく業界に入った方に”そんなことも知らないのか?”という発言をしたり、それを理由攻撃して精神的に追い詰めてしまう人もかなりいます。何にせよ、全体的に人材育成が苦手な業界ではないかと思います特に組み込みソフトウェア関連技術に関しては、かつては客先の要求仕様にのっとってV字開発プロセスを通すことが開発のほぼ全てを占めていたこともあり、C言語の基礎(自動車業界ソフトウェア開発はナビ等の一部を除けばほぼすべてがC言語です)や組み込みソフトウェアの基礎に関する研修はなく、開発プロセスに関する研修ばかりという会社もかなりの数があるようです。そのため、基本が押さえられておらず、基礎設計が悪く、手戻り発生で開発工数が爆発、不具合を垂れ流すというコンボもごくまれに発生している様です。

今後の業界全体の景気や人材採用の動向に関して

ここ数年、自動車業界各社の業績が良かったこともあり、春闘ボーナス満額回答や、ベア過去最高益等の景気のいいニュースが多かったですが、2018年下期から中国市場の減速等により各社が業績の下方修正をする等、景気にやや陰りが見えているのも事実だと思います。まだ、各担当レベル仕事や、給料への影響はそれほどは感じられませんでしたが、このままの状況が続くと数年程度で何らかの影響が出てくるのではないかと思います

一方、人材採用という側面では、根本的な人材不足解消の目途が立っておらず、多少の業績悪化があるとはいえ、しばらくは雇用豊富にある状況は続くと思いますサブプライムショックのような世界的な不景気が発生すると、一旦は雇用が絞られる可能性がありそうですが、その後の景気回復に伴い、数年で回復すると思います。車は数年~15年程度で必ず買い替える消耗品であり、家電製品より高価ということもあり、景気が悪くても最低限の需要市場が生まれ、景気が回復すると需要回復する業界ですし、新興国需要の伸びはこれからなので、中長期的に見れば伸びしろのある業界だと思います。ただ、外資系企業国内市場進出が進んでいることや、業界内の買収・統合事業移管が進んでいることもあり、会社によっては価格競争等に敗れ、売り上げが激減するリスクリストラリスクはありそうです。また、まだ例は少ないですが、国内で救済的買収を行う会社が見当たらず、外資系ファンドの傘下に入った会社も出始めています。ですので、転職先の会社選びが非常に重要になってくるのは間違いなさそうです。

結局自動車業界エンジニアをするのはオススメ??

他の業界の方と一緒に仕事したことはあるものの、他業界仕事したことがないので、何とも言えないですが、自身業界全体の未来不安視されている方が業界をまたいで転職してくるのは十分にありだと思います。また、米中摩擦の今後の動向次第では、自動車業界全体の業績に悪影響を与える影響もありますので、30代で転職を迷っている方は興味があればこのタイミング自動車業界トライするのもいいかもしれません。うまくいかなければ、他の業界転職すればいいと思います。一度は自動車業界に来たものの別の業界転職していった方や、別業界からの出戻りもあるようです。

8年働いてどうだったか

不条理世知辛い業界ではありますが、個人的に携わったテーマは楽しく取り組めたので、自動車業界で働いたのは間違いではなかったかなと思います。緩やかにですが変わっていく業界ではありますので、近い将来に今よりは働きやす業界になると思います。今後の伸びしろもあり、まだまだ楽しむ余地がありそうですので、転職先も自動車業界しました。ただ、国内世界的某大手自動車部品メーカーも受けましたが、面接をしている最中にここも結局は同じか………と感じてしまたこともありましたので、外資系企業しました。

最後

すいません、皆様が知ってるって感じのうんちくを垂れ流しただけで、全然退職エントリーではなかったです。

2018-03-05

いろんな意味やばい開発会社に入った話をしようと思う。+α

とにかくいろんな意味やばいIT系の開発会社に入ったからぜひ話を聞いてほしい。

自分は21歳で2社経験してるけど入った会社全部がやばい会社(いわゆるブラック?)だったりでいろいろ苦労したか

就活生や転職活動してる人の参考になればと思ってこの記事を書いてる。

んで今回はIT系会社についての話。

読むのめんどくせえって人用にまず3行でまとめてみる

1、「うちは今度から完全週休2日制に完全に切り替える」と言われてたった3か月で完全週休2日制が撤廃になった。地獄

2、自分以外の開発メンバーのずさんさがやばい。ゴールが見えない。地獄

3、話合いが全くできないので何一つことが決まらず進まない。以下地

わかりづらかったらマジゴメン

こっから本題

1、「うちは今度から完全週休2日制に完全に切り替える」と言われてたった3か月で完全週休2日制が撤廃になった。地獄

 入社した当初は週休2日制で土曜出勤とかもあったんだけど、つい最近経営者から「よし!うちも完全週休2日制に切り替える!」

と言われて確かに完全週休2日制になったんだけどどうも

法律上、うちは休みが多すぎるって判明したから調整した結果、完全週休2日制は今月いっぱいでなしね」

とかよくわからんこと言い始めて(そもそも法律休みの上限とか聞いたことないけど)たった3か月で撤廃になった。

この事例からアドバイスできるとしたら

ちゃん休日関係確認したほうがいい、完全週休2日制とか謳っておきながら箱の中身を見てみたら嘘だった

なんてこともざらにあるから気を付けてほしい。

あと転職活動何度かしててわかったけどに「休日数1〇〇日以上!!」とか見出しで謳ってるような会社も基本ろくでもない会社が多いって感じたから参考程度に

覚えておいてほしい。

2、自分以外の開発メンバーのずさんさがやばい地獄

 正直今回一番書きたかったのはこの項目。とにかくここが一番やばい

基本的開発プロセスって(例外とかは抜きにした基本的な順序)

1、要件定義 → 2、外部設計 → 3、内部設計 → 4、開発開始 → あとはテストやら公開準備やら……

って感じだと思うんだけどうちの開発者場合

1、開発開始 → 2、要件定義 |(ここでクライアントとか経営者ものすごい怒られる)| → 3、外部設計 → 4、内部設計 |(ここでクライアントとか経営者ものすごい怒られる)| 3、外部設計  ……

これが永遠と繰り返されるんだ。マジで。書いてる自分でも訳がわからなくなっていく、つまりゴールが一生ないってこと。

設計書作らない、新しく入った人に引き継ぎしない、仕様書すら作らない。そんな会社です。

それで今どきの開発会社で手作業バージョン管理してるんだぜ?やばくね?

ようは古いファイル(上書きが必要ファイル)は「ファイル名_20180305(今日の日付)」とかで管理してるんだぜ?地獄じゃね?

だって自分修正したファイルがさ自分が知らないうちにその開発担当者上書き保存されて消えてるんだぜ?

そのくせ「治ってないじゃないか仕事怠慢だ!」とか言われるんだよ。俺にどうしろっちゅうねん

そこでさ、俺さすがにこのままだとやべえなと思って開発担当管理者提案したんだよ

Gitの導入検討しませんか?」

って。いやだって作業よりマシじゃん?ないよりマシじゃん?

そしたらさなぜか知らないんだけど2,3時間くらい「Gitは難しくて~」とか「導入するとコストが~」とか

クソみたいな言い訳並べて導入したくないみたいなんだよね。だから上司上司に直談判して導入を強制してもらったのよ。

そしたら案の定その上書き保存事件収束したわけ。

なんだけども、

ここからさら問題

普通Gitってさブランチ複数に分けるじゃん?

master develop feature …… 大体多くても3~5とかに分けるよ普通

でもさうち

「master」一本なんだよね。商業でやってる会社がmaster一本て聞いてことないよ。

そこですかさずまた俺は提案したんだよね

ブランチ複数に分けませんか?」

ってそしたらさ開発担当管理者になんて言われたと思う?

「は?効率が悪くなるからダメでしょ」

って言われたのよ。この後に及んで効率取るか?普通

だってもうお前のせいでリリース3回延期してるんやぞ(この際にもいろいろあったけどもっと長くなるので割愛

しかもお前俺以外の開発者全員ソース問題が残ってる状態でなんにも確認せずに「できた!」とか言って

コミット&プッシュしてくれるんやぞ?生き地獄だぞこっちにとっちゃ。

んで一応それがだめならと思ってせめてこれは通ってくれと願いながら

「Pull Request使いましょう?今のままよりマシではないかと」

って提案したら

「面倒くさい」

で一蹴りされた。俺、ここでこの会社辞めるの決意したんだよね。

今まで他担当者タスク管理とかやってあげたり来た指示書の具体的な内容の確認とか全部やってたの自分なんだけど

管理者じゃないのに。それに他に任されてたプロジェクトだってあるのにこっちがあまりにもやばいからっていう理由

太刀で来たのに。悲しくなったよ……。

今この会社には今年の3月いっぱいで退職予定なんだけど、次の会社(もう内定はもらってる)に面接に行った時つい辛すぎてこのこと愚痴ったら

「数年に1件見るレベルの酷さ、頑張ったね……」って言われたよね。「良かった自分感覚間違えてなかったんやな……」って

ちょっと泣いた。

とまあ、これが現実。ちなみに地方会社からね。地方の開発会社はこんなレベルだと思ってもらっていいよ。

都内から3~5年遅れてるって言われてるし。

そもそもなんやねん実績じゃなくて「実務経験3年以上」っていう基準なんの基準やねん。(これは今回関係ないけどこれも愚痴

3、話合いが全くできないので何一つことが決まらず進まない。以下地

 基本的に話し合いが成立するのって問題解決するために、立場・考えなどを述べ合うことだよね。

うんまあこれも普通ならただの話し合いなんだけどさ。

Aさん「今こういう現状で問題が続いているのでこのようなルールを作るべきではないでしょうか?」

って改善案を出すとする。すると健全な話し合いであれば

Bさん「であれば自分意見はこうでこういうルールだったらいいのではないかな?」

これであれば互いの意見いいところを取って互いが納得したルール改善案が出せる可能性は高い

だけどうちの開発者場合

「お前の意見はここがダメだ、ここもだめだ。こうだから絶対ダメ

否定しかしないんだよね。もうこの時点で同じ土俵に立ってないわけ話し合いとして。

んでそういうやつに

「では改善案はありますか?」

って聞くとしどろもどろして何もかえってこないのよ意見がどういう思考回路しとんねん。

基本的否定する暇があったら改善案意見述べてくれねえかなって思うのよ。まあ人によってはこれが意見だ!っていう人もいるけど

否定改善は違うからな。

んでこれがずっと入って1年間続いたわけそこで俺気づいたんだ。

この会社開発者対話すらできないんだって

他の会社はどうかしらないけど大体の大人ってこんな感じだよねテレビに出てる批評家とか辛口専門家(笑)とか。

何が言いたいかっていうと

いくら頑張って改善を試みようとしても無能上司や頭のおかしいやつに蹴られたらおしまい

ってこと。正直者が馬鹿を見るっていうけど本当、当たってると思う。

最後就活頑張ってる人とか転職悩んでる人に伝えたいこと

自分の若干21歳でもう転職2回もしてるから世間体で見ればろくでもないやつって思われるかもしれないけど、

辛い時期もあったけど案外どうにでもなったし頼れるところはいっぱいあるから頼れるものは頼ったほうがいいよ、

親とか友達とか、行政だっていう手もある(求職者支援訓練で検索)。

ネットとかリアルの友人がクソみたいな会社に振りまわれてるの見ると自分まで辛くなるし力になりたいって思うけど

なかなかそういう機会もなくてあれかなと思って今回この記事を書いた。

この情報デマだ!って言われたらそりゃ所詮ネット情報だし信じるか信じないかは……になるけど

でも確かに自分経験した体験談からここに書いてるのは承知してほしい。

んでこんな自分から伝えたいことがいくつかある

1、真面目に生きると損する

これ3年間社会人やってたどり着いた心理。そりゃ責任感は捨てちゃだめだけどさ

世の中の大人って呼ばれる人たちまあおおざっぱだし適当だよ。

自分学生の頃「社会に出たらもっとしっかりしなきゃ……」って思ってたけど

今になっては「真面目に生きるのもアホらしい」って思うくらい。

本当好きなこといっぱいやったほうがいいよ。

2、求人は基本信頼するな

 これも転職活動しててわかったこと。

正直求人情報よりもネット情報がまだ正確だったりする(某掲示板とか)

かといってネット情報鵜呑みにしすぎるのも危ないから気を付けてね。

一番いいのは会社訪問させてもらうこと。あとOB訪問とか。

3、難しく考えすぎないこと、逃げ道はいくらでもあること

 さっき上にも書いた通り真面目に生きるだけ損するから嫌だったら辞めてもあながちどうとでもなるから安心してほしい。

上京した人とかは大変かもしれないけどそれこそ親頼ったりとかしてもいいんだし逃げ道はあるから気にしないほうがいい。

自分最初会社は3か月ちょっとパワハラ受けて精神病院行きになってやめたけど今は多少ぴんぴんしてる。

転職したいな~って思ったら迷わずハロワに行くなり、転職エージェントやら就職支援サービス登録しておけば企業からスカウト

来たりするしいい求人来たら面談してみるとかでもいいし。逃げ道作るのもいいと思う。

あともし転職するなら多少忙しいだろうけど在職中にした方がいいよ。収入が絶え間なくなるからおすすめてかそうして。

っとめちゃくちゃ長くなったけど言いたいことは言えたのでよし、

現状こんなIT系の開発会社謳っていながらこんなやべえ会社あるんだよっていうのと

自分が苦しんだからあとの世代には気楽に生きてほしいってことを伝えたかったんだよね。

まあこの記事に対する反応とかは

「うちはもっとこんな風にひどいから気を付けろ!」とか

就活はこうすると良い!」とかアドバイスがいっぱい来ると嬉しいな。

それじゃまたどこかで

2017-08-29

Jアラートと、改善バージョンアップの違い

幸い、今朝のJアラートがならない地域に住んでいたので、やはり当事者意識は弱めなのだが、だからこそ、第三者的に見て、色々どうかな?という面も多々あった。

 

要するに、「地下に逃げろ」「コンクリート建物の中に逃げろ」と言われてもそんなところなどない、みたいな話があり、全くもって笑い話にならないのだった。

 

地域ごとに出るメッセージを適切に変えれば良いだけだと思うのだが。

ケータイ基地局の判定するなどして、そこから割り出すとか出来ないんだろうか?

 

最初から上手くやれ」とは言わないが、少しずつシステム改善して欲しい感じはある。

 

で、ふと思ったのは、どうも、日本プロダクトは「作っておしまい」みたいな部分が大きい気もする。

不具合修正はするとしても)

 

もちろん、「改善」の語源から考えると、日本はその元祖的な部分もあるのだろうが、日本の「改善」は、例えば、開発プロセスなど供給者内の製造方法論みたいな話が多い。

 

それに対し、例えば、顧客体験としてのはてブバージョンアップは「改善」というよりも、「刷新」的な意味合いを感じてしまう。

 

逆に、アメリカ製プロダクト、例えば、YouTube動画サムネイルマウスカーソルを合わせると動画が動いたり、動画の長さがサムネイルに表示されりするなどして、顧客体験の地道な改善をしている印象がある。

2chアメリカ業者に乗っ取られてから、専用ではない通常のブラウザで見てみるとかなり使い勝手改善されている。

 

もちろん、日米の違いを一概にそう言えるか?と言ったら、違うと思うが(フラットデザインとか)、意識の強弱の差はハッキリと見て取れると思う。

 

繰り返すが、「最初から上手くやれ」とは言わない。

でも、少しずつ顧客体験改善していく方向で進めればより良いシステムを作ることが出来るようになるのではないか

2017-04-18

http://anond.hatelabo.jp/20170417202931

手に職を付けたい理由お金技術をもって自由に稼ぐハッカー

まず、前者なら大手SIer鉄板です。なぜなら、給与が圧倒的に高いからです。中小比較すると同年代で100~200の差は出ますあなた結婚したころにはその重みが分かることでしょう。

後者なら、残念ながらもう手遅れです。そういう人は小学生くらいから自ずとプログラミングをして、高校生くらいで何らかのコンテストに出ているような人かと。あなたくらいの年齢では、もう起業しているか企業からの取り合いになっていることでしょう。今、それをしていないということは、あなたはそういう人ではないということです。

大手SIの良いところは以下のとおりです。聞こえがいいとかそういうのはどうでもいいことです。

・外部の研修をある程度自由に受けられる

企業システムのある程度精緻に作られたソース設計書を見れる

SI開発プロセスを学べる

 「技術」とは何もコーディングだけではないことを知るいい機会になります

給与福利厚生中小に比べて圧倒的に勝っている

転職に困らない

バカ管理者比較的少ない(中小はその比ではないと思われる)

手に職と言いますが、それを持ち得て必要とされるような能力の持ち主は非常に稀有です。

からそれを目指すということはそれなりの覚悟努力する才能が無ければ難しいかと。

研修が手厚い会社を探しているとのことですが、

システム開発全般について、体系的に教えられる人を外部の講師含めて、ほとんど見たことがありません。

自主的に学ぶ場合は上流から下流工程までを見渡せる大手SIがいいです。

新卒カード中小企業に切ったら、次は中小企業カードスキルのある人カードしかないです。

大企業に切れば、新卒に準じる大企業カードか、大企業スキルがある人という強いカードになりえます

良く悩んでください。

2017-02-11

職場の開発スタイルが古すぎて限界なんだが

IT業界プログラマなのですが、どれだけ技術進歩しても何年も同じ開発スタイルから一向に改善しなくて限界を感じています

例えば次の点が挙げられる

バグ個人責任のせいにする

 ・世渡りが上手い奴は口だけ出して手は動かさな

  ・こいつが手を動かすのは最小限で、なおかつビビりなのでよく確認する

 ・手だけが早くリリースしてから考えようぜって思っているタイプバグを出すたびに個人攻撃される

開発プロセスが雑

 ・レビューがない

 ・仕様最初から作るつもりがなく、毎回担当者が長年の勘で仕様を考える

  ・故にどこかで矛盾が生じる

  ・担当者の長年の勘が頼りなので、作り手としては要求に答えるしかない

   ・仕様明確化されていないので、言われた通りに作るしかない

   ・一部しか担当していないので、一部しか知らないのだがそれを「もう何年もやっているのに担当したところしかできない」と言われる

    ・尚、これに対し口答えは許されない模様

 ・仕様がないので自分なりに担当者確認して作る

  ・このあたりはOKなのだが、その内容は一切ドキュメント化されていないしするつもりもない

  ・いつでもこの仕様担当者の気分で変更できる

   ・変更できるのは問題ないが、言い方が「お客さんがバグ報告がきた」みたいな切り出し方

   ・バグではなくただの仕様だし「作る時にそう言いましたよね?」と言ってもドキュメントがないので根拠なし

テストを書かない

 ・開発スピードが遅くなるから理由テストを書かない

 ・というか書き方を知らない

  ・xUnitすら使えない

MVCを知らない

 ・単語は知ってて理解しているつもりなんだけど的外れ(いわゆる Fat Controller が普通だと思っている)

・新しい知識を覚えるつもりがない

 ・自分達で勉強した最新の知識デザインパターン

 ・新人が入ってくるもこの調子なので2〜3年もすると社内の仕事はできるが若いのに技術力は10年以上前技術者レベルになる(仕事必要なことしか知らないのでそれ以下か)

 ・そして、いつまで経ってもこの開発スタイル改善しない

けものフレンズがバズったので、ついカッとなってやった。

2016-06-25

[] ウォーターフォールメリット

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが,この記事もその反論記事支援記事も含めて,「ウォーターフォール採用する(せざるを得ない)理由」について書いてあるものはあっても,「ウォーターフォールメリット」について書かれた記事が見当たらないのには驚く。

各種記事

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

まずこの記事。「メリットはない」って言ってるんだから,書いてないのは当然なのかもしれないが,アジャイルメリット=なぜアジャイルがいいのか,についても書かれていない。これではFUDといわれてもしかたない。

日本アジャイル流行らない理由

http://ledsun.hatenablog.com/entry/2016/06/21/102501

日本アジャイル流行らない理由」≒日本ウォーターフォール採用される(消極的な)理由は書いてあるが,ウォーターフォールメリットについては書かれていない。

ウォーターフォール開発プロセス有効

http://ledsun.hatenablog.com/entry/2016/06/21/102501

タイトルから期待して読んだが,「ウォーターフォール課題と言われてるものは,実は解決されてるよ」という記述が大半を占める。

最後の一節は「アジャイル問題」として,「変化に人間がついていけない」点が挙げられていて,その裏返しでウォーターフォールがいいよ,ってことを言いたいのかもしれない。しかし,アジャイルは「変化に機敏に対処する」ことが眼目であって,何でもかんでも変化させなければいけない,というものではないので,指摘自体的外れに見える。

ウォーターフォールアジャイルを考える

http://arclamp.hatenablog.com/entry/2016/06/23/172941

冒頭,

まず、「ウォーターフォールは何のメリットも無い」は嘘です。何のメリットもないもの存在するわけないので。

とあって,メリットを語ってくれるかな,と期待させるが,結局「スコープが確定しているならウォーターフォールでいい」,という消極的採用理由が述べられるだけで,メリット積極的採用理由は述べられていないように見える。

ウォーターフォールメリット

ではウォーターフォールメリットは何なのか?

それを語る前に,まずウォーターフォール定義しておく。現在日本ウォーターフォールとして認識されているプロセスは,国防総省式の「戻りの線」なしのものである。即ち,確定した要件なり仕様なり(以下まとめて「スコープ」と呼ぶ)は変更しない。「ウォーターフォール」という名前自体が,この一方向性に由来している。従って,ウォーターフォール定義としては,「(フェーズゲートを超える際に)確定したスコープは変更しないプロセス」で良いだろう。

この定義に沿わないプロセスは,「偽ウォーターフォール」であり,以下に述べるウォーターフォールメリットを受けることはできない。メリット享受できないだけでなく,この種の「偽ウォーターフォール」は(「偽アジャイル」同様)大きな害悪を撒き散らす。

さて,「確定した要件仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが,手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者/受注者含め何がうれしいのか。

答は

納期 and/or コストぶれるリスクを小さくできる」

である

すごく当たり前のことなのだが,これが書かれている記事が見当たらない。

そしてウォーターフォールメリットはこれだけで,それ以外にはメリットと言えるものはおそらく存在しない。

やはりウォーターフォールにはメリットなどほとんどなかった

ここで,前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。

よく見るとこれらは,いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく,本来意味での「品質」,即ち利用者の役に立つか,使いやすいか,ということまで含むものであるスクラムアジャイル)を知る人であれば,「トレードオフスライダー」の「品質」に相当するものだと理解してもらえればよい。

そうすると,前節のウォーターフォールメリットは,以下のように言い換えることが可能である

ウォーターフォールメリットは<品質を固定することで>コスト納期ぶれるリスクを小さくできる点にある」

これで問題が明らかになった。要するにウォーターフォールは,コスト納期のために品質二の次にするプロセスなのである

その結果,これまでどんなことが起きてきたか

あくまで変更を行わなかった場合

開発の途中で,要件仕様問題が見つかったとしても,あくまウォーターフォール定義に殉じると,出来上がるのは「使いにくい」「使われない」システムである

事業会社IT会社に転生させることが、これからSIerミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に,その実例らしきものがでてくる。

禁を破って変更を行った場合

これを行った瞬間からウォーターフォールはその(ほぼ)唯一のメリットを失い,混沌が始まる。

最も多いパターンは,発注者側が(もはやスコープ品質を固定するという前提が失われているにも関わらず)納期コストの確定というメリット享受を譲らず,プロジェクトデスマーチ化する,というものであろう。あるいは,コストは譲るが納期は譲らない,というパターンの方が多いかもしれないが,いずれにせよデスマーチ化につながりやすいことは間違いない。

そしてこの副作用として何が起きたかというと,受注者側がそれを見越して納期コストバッファを積むようになった。当然それは見積もりの不透明感につながり,発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。

うまくいくのは非常に限られた条件が成立する場合のみ

スコープの変更の必要が生じたら,どちらに転んでもいい結果は得られない。となると,ウォーターフォールがうまくいくのは,「スコープが明白で,変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので,そのような案件がどの程度あるかはわからないが,直感的には「ほとんどない」のではないかと思う。なぜなら,そこまでスコープが明白であれば,今はパッケージSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。

もう一つの可能性としては,スコープが変更不要になるまで,とにかく事前の準備と調査を徹底的に行う,というパターンもありうる。しかし,これは「準備と調査」の過程事実上いろいろ試作することになる(そうしないと変更のリスクが消せない)ので,もはや作業プロセスの大半が実はウォーターフォールではない,ということになるだろう。

アジャイル銀の弾丸ではない

ではアジャイルプロセスを導入すれば,これらの問題はすべて解決するか,というとそういう話ではない。ウォーターフォールメリットが(ほとんど)ないことと,アジャイル有効であることとは,独立議論である

そもそも「アジャイル」というのは考え方であってプロセスではない。だから,考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって,害悪を撒き散らすことが多い。

アジャイルの考え方は,主に以下の2点でウォーターフォールと大きく異なる。

1. スコープの変化がありうることを前提としている

2. スコープ品質=役に立つこと(=使えないものを作らないこと)が最優先であり,そのためにコスト納期が変化を(ある程度)受け入れる

この考え方こそアジャイル本質であって,CI/CDやDevOpsなどは,変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし,CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。

また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために,スコープはできるだけ確定する努力をする,というのはアジャイルでも変わらない。変えるべき時は変える,という点が違うだけだ。なんでも後で決めればいい/変えてもいい,というのは「偽アジャイル」であって,害悪しかない。

もちろんこれがあれば何もかもが解決する,という類のものでもない。上述の2点があるだけで(少なくとも今のたいていの開発案件において)ウォーターフォールよりマシになりうるとは思われるが,別の問題(例:納期コストの変化をどう扱うかという問題)も,同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり,これが「納期コストの変化」と絶望的に相性が悪い。

もっとも,今の「ウォーターフォール」によるソフトウェア開発が,請負契約の成立条件である契約時にスコープを確定(し,変更しない)」を厳密に守っているわけでもない以上,これだけを理由アジャイル否定するのはどうかとも思う。

契約については,IPA等でも取り組みがあるようだが,いずれにせよ契約を行うのは発注者と受注者であり,受注者側だけでどうこうできる問題でもないので,発注者側の意識の変化を期待するしかいかもしれない。

2015-08-15

http://anond.hatelabo.jp/20150815144407

開発プロセスはたいてい上流が偉くて責任とらなくて

下流に責任押し付けるだけだな。

上流の無能は、まじで死ねよと思うわ。

2015-06-21

夢のあるシステムに関わりたい。

夢のあるシステムに関わりたい。

いわゆるプログラマをしているが「屑システム」にかかわりたくない。

「屑システム」とは以下だと思ってる。

なお、一応言っておくと、私がかかわっているシステムすべてが以下に当てはまるとは言ってない。

自分が開発にかかわってるが、開発が進んでも自分利益にならない。他人の懐具合がよくなるだけ。

安月給はもらってるから、それで満足しろということになるわけだが。

その安月給は当然あがることはない。私から見れば立派な「屑システム」だ。

枯れた技術けが使われ、そのシステムにかかわったことが何の宣伝にもならない。

例えばいまさらsyslogが使えます、とかsnmpが分かります、とか意味なす。

いまならビックデータとか、クラウドとか、機械学習とか。

かいNoSQLとかクライアントサイドJavascriptとか。

次につながるようなシステム開発がしたい。そういう意味で「屑システム

システム」とは、プログラムのものだけを意味するわけではない。

プログラムを開発する、開発プロセスのものも「システムである

プログラマに丸投げしておけばシステムができるわけではない。

プログラムを開発するシステムが「屑」だとやる気が出ない。

例えば、ある作業をやったら、諸事情無駄になるようなのが「屑」な開発プロセスだ。

責任者に、リーダシップがないせいだ。あるいは、プログラマに何の権限もないと起こる。

人間から、全部有効な作業というわけにはいかないが、そんなんばっかりだとやる気にならない。

なお、リーダーシップというのは権限とセットだ。責任とセットなわけではない。

適切な権限があってこそリーダシップが発揮できる。

プログラムを作る責任だけあっても、その責任を全うできる権限がない以上

どんな提案をしても無駄になる。

そんなものは「屑」としかいいようがない。

上と被るかも知れないが、一週間に一回も会議を行わないようなのも「屑システム」だ。

確かに会議だけしても意味ないが、しなくても全く情報共有ができず、プログラマは何していいかさっぱりわからない。

また、各作業員の間で信頼関係がないのも、なかなかにシステムだ。

真の意味コミュニケーションが取れていない。というかそんなものそもそもない、ということなる。

2014-10-17

ソフト開発は認定試験の類を必須にして欲しい

情報処理はもちろん、言語とかDB関係とかベンダー試験も。

あとオブジェクト指向とか開発プロセスとか、コードの書き方みたいなやつも。本を1, 2冊読めば合格できるレベル試験でいいから

試験合格してないと開発にはかかわらせないようにして欲しい。

試験合格して当たり前だろ」とか言う人いるけど、職業プログラマには合格できないレベルゴロゴロいるから。

PHP入門書の一冊も読んだことないだろってレベル人間PHPコードレビューしてるとかギャグのような状況が日常

で、そういう客観的に見たらどう考えても水準に達してない人に限って自分レベルの低さを自覚してない。

自覚してないどころか「おれ10選手から」みたいに経験年数の長さだけを根拠に、むしろレベル高いと思ってる。

いや、普段の言動をみてると自分レベルの低さはうすうす感じてるのかもしれない。

学生時代にかじってた新人は変なクセがついてだめだ。なにも知らないやつのほうが素直で教えやすい」みたいなことをいいがちだけど、これって新人にも自分は負けるって自覚があるからその防衛反応だろうし。

認定というか免許制度にすれば、とりあえず、そういう素人レベル排除できるのにって妄想してしまう。

2014-07-10

http://anond.hatelabo.jp/20140710082319

そんなことないよ。シリコンバレーエンジニアの数も求職数もものすごく多く、裾野がかなり広いので、実力レベルは上から下までさまざま。博士号なんてもってたら給料が高くなるから雇用側もあえて学士程度を望んだりするケースも多い。すーぱーぷろぐらまーレベルがどうしても必要会社なんて一握りだし。一部の花形企業以外は、実力はそこそこでいいから$80Kで来てくれますありがとうみたいなところは多いと思う。

会社スタンスもさまざまで、純粋CSでやってきた人じゃなくても、新しいプロダクトを作るセンスがあるとか、HTML/CSSJavaScriptに強いとか、NginxとかNode.jsを使って仕事したことあるとか、IT土方だけどJavaだけは人並み以上にできるとか、インディー系で携帯ゲーム作ってたとか、アジャイル開発プロセスに明るいとか、色んなタイプの人が評価される。何か得意なこと持ってれば、そういう人を探してる会社は必ずある。シリコンバレー最先端で尖ってるっていうイメージもあるけど、枯れた技術での固い職ってのも多い。JavaとかPHP仕事なんていくらでもある。Flashですらいまだに結構ある。ほんとに裾野が広い。多くの人が、それなりの実力でそれなりの仕事をしつつ、家族との時間自分時間を大切にして人生楽しんでる。

会社によっては、平均的な日本人の勤勉さを知っていて、そういう面で重宝されるケースもある。世界中から人が集まってるので、勤務態度も様々で、その中では日本人の真面目さは割と有利。まあ、日本人英語しゃべれないとも思われてるけど。逆にちょっと話せればかなりインパクト強い。

結局、

大学高専出てるか(出てないとビザが厳しい)・・・できれば理系、できればCSメジャー

英語で最低限のコミュニケーションができるか

採用したらすぐ来れるのか

くらいじゃないのかね。

2014-04-19

アジャイル開発プロセス

顧客:「お客様向けのシステムが全部止まってるんだけど。なんとかしろ!」

営業:「すみません。原因調査中です。早期復旧を最優先に現在対処中です。」

営業:「はやく、なんとかなんないの?。顧客、怒ってんだけど。」

PM:「すみません現在、原因調査中、及び復旧優先で動いています。」

PM:「なんか、わかんないだけど、早く復旧して。」

プログラマー:「はい。原因調査中です。(なんか休日だけど・・・)」

プログラマー:「原因分かりました。バグです。こうこうしたら、復旧・・」

PM:「復旧優先で、あとで直しておいて、リリース明日。」

プログラマー:「明日法事休みをもらってまして・・」

PM:「はぁ?お前しかからないんだから、お前直せよ。で、すぐにリリースな。」

プログラマー:「・・・

PM:「属人性排除しないお前が悪いんだろ、ドキュメントもないし。誰も引き継げないだろ。明日までにやっとけよ。」

プログラマー:「・・・

PM:「お客さん困ってんだよ。やれるだろ?」

旅立つには十分だった。

2014-04-10

プログラム中級者が感じる関数型の違和感

なんだか話題になってるから書く。

やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。

1 圏論かいらないんじゃないの?

Haskellが短いコードプログラムを書けるというのは分かる。

forループmapやfoldで抽象化する利点も分かる。

それでやりたい処理のほぼ全てがまかなえるということも実感している。

副作用のない小さな関数を合成して大きな関数を作る利点も分かる。

再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。

ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。

むしろ邪魔なんじゃないかと思う。

ファンクターやモナド概念圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。

圏論必要なのはHaskell設計する人であって、使う人ではないと思う。

なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。

Linux上で開発環境整えるのにカーネルコードを読めって言うぐらい的外れだと思う。

いや、知識として持っとくのはいいだろうけど、役に立たんだろ。

2 言うほど新しい機能ないような?

Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語オブジェクト指向言語とそこまで違いがあるような気がしない。

純粋言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。

その無名オブジェクトもっとあれこれデータ関数詰め込めば、いつの間にか普通にJavaC#で使うようなクラスのできあがり。

その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。

関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。

上級者はデザインパターンdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。

デザインパターンオブジェクト指向言語欠点を補うための苦肉の策じゃないよ。

関数プログラミングの基礎的なパーツだと思う。

からちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。

3 なんか選民思想にとらわれて無い?

関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。

もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。

けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。

役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。

せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。

開発プロセスとかを見直す方が仕事を楽にしてくれるんじゃないのかな?

2014-01-15

プログラマ会社的には

プログラマと呼べるようなスペシャリストが不在で、

多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社

そんな会社だと、プログラムでなるべく解決する(コードが業務プロセスを頑張っちゃう)ために頑張るよりも、

業務プロセス開発プロセス全体で最適化するよう頑張った方が、

たいていはハッピーであることに気づいた。

プログラムで頑張ろうとすると、

学習コストがかかりすぎるか、

外注するのに設計しようにも結局学習コストがかかりすぎるとか、

外注とのスムーズな協力関係無駄に気を使うとか、

外注が逃げるとか、

引き継ぎ先がいなくて死ぬとか、

そんな余計なことが多かった。

反復性・正確性が求められるものプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。

プログラムによる生産物を主要な糧にして事業をやっていると、

ともすればプログラムスペシャリストでないことに大きなコンプレックスを抱くけど、

生産物割合ライト公共性も低い(例えばエンタメスマホアプリ)だったら、

無理にスペシャリスト風にやる必要はない。

身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。

オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して

ライトフレームワークを選択して、ライト開発プロセスでやる選択がもっと歓迎されていいと思う。

そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からボトムアップ的な思想やツールでなく、

マネジメント視点経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。

プログラマ経営層になっての話は近年よく聞くけど、非プログラマ経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。

こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。

暇ができたらまとめたいなあ。。

その前に売上UP(白目)

2013-11-10

http://anond.hatelabo.jp/20131109185658

技術者の力量を見極めるためには職務経歴は参考程度にして、顧客への納品物以外で個人的にどんなプログラムを作ったかを聞いた方が早いかも。

何だかんだで企業向けシステムの開発って分業制だから一部分しか携われないけど、自分プログラムを作るってのはアーキテクチャ選定、要件定義設計プログラミング最適化etc開発プロセス最初から最後まで責任者立場担当するわけだからね。

パートナーや中途の採用に関してももっとこの点を重視する文化になって欲しい。

2012-02-11

Web企業バックエンドエンジニアとして必要な知識メモ

そこそこPVがある場合。そうでなかったら、どうにでも動くしね。

基本はLAMPなんですけど、オペレーションの部分も分かってないと即戦力にはならんと思う。


かいWEB企業でも、下記をわかってて、ちゃんとできる人ってそんないねーよな、っていうことを最近知ったお。

もちろんフロントエンドまで一人で担当する場合もっと必要な知識が増えるわけだが。

そう考えると、「ふつうエンジニア」に到達できるのって、3年とか5年とか10年とか普通にかかるよなーって思うわけですよ。

2009-07-25

デッドライン ソフト開発を成功に導く101の法則

正しい管理の四つの本質

・適切な人材雇用する。

・その人材を適所にあてはめる。

・人々の士気を保つ。

・チームの結束を強め、維持する。

(それ以外のことは全部管理ごっこ

安全と変更

・変更は、あらゆるプロジェクト成功のために(ほかの大抵の物事についても)必要不可欠である

・人は安全だとわからないと変更を受け入れない。安全保証されていないと、リスクを避けようとする。

リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である

・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。

負の強化

脅迫は、結果を上げさせる手段としては不完全である

・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。

さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。

管理者の身体本質的な部分

管理は心、腹、魂、鼻でやるものだ。

 つまり……

 心で指揮をとる。

 自分の腹を信じる(直感を信じる)。

 組織に魂を吹き込む。

 くだらないものを嗅ぎ分ける鼻を持つ。

戦闘指令と管理関係

戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。

面接採用

採用には、管理必要身体の器官、心臓、魂、鼻、腹をすべて使う(しかし、腹が大部分だ)。

・一人でやろうとするな。二つの腹には、一つの腹の2倍以上の力がある。

・新しく採用した人材には、1回は実証済みの能力レベルプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。

意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。

・話すより聞け。

・これらのことは、下準備をしておけばさら効果がある。

生産性の向上

短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

短期的な効果約束するものは、いんちきである可能性が高い。

リスク管理

リスク管理することによってプロジェクト管理せよ。

プロジェクトごとにリスク調査方法確立して継続せよ。

・最終的な望まざる結果だけでなく、日常リスクに注意せよ。

・それぞれのリスクの実現する確率と予想コスト評価せよ。

リスク現実になる前の初期の兆候予測せよ。

・やる気のある態度を常に引き出そうとしない人物リスク管理人に任命せよ。

・悪い話が上層部に伝わりやすい経路(匿名性など)を作っておくこと。

防御体制の強化

無駄を減らす。

成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。

・失敗した作業は早く打ち切る勇気を持つ。

・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。

・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する(本人たちにその意思があれば)。

・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす

プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。

・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。

開発プロセスモデリングシミュレーション

仕事を完成させるプロセスに関する直感モデル化する。

・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。

モデルを使って結果をシミュレートする。

・実際の結果と照らし合わせてモデルを調整する。

病んだ政治

・いつでもクビを賭ける覚悟必要である

しかし、それでも病んだ政治の影響を受けないとは限らない。

・病んだ政治はどこにでも、最も健全組織にも出現する可能性がある。

・病んだ政治の決定的な特徴は、個人権力と影響力の目標が、組織自然目標より優先されることである。これは、病んだ目標組織目標と相反する場合でも起こりうる。

・病んだ政治副作用の一つは、少人数のプロジェクトを抱えることが危険になることである

測定基準

・すべての製品サイズを測定せよ。

単位を気にするな。客観的尺度ができるまでの間は、主観的単位を使えばよい。

・手に入るすべての基本要素(ソフトウェアの数量化可能な特徴)をもとに合成尺度作成する。

考古学データ収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。

・合成尺度公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。

過去データベースをもとにトレンドラインを引き、予想される労力を、合成尺度の値の関数として示す。

・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンドラインから予想される労力を割り出す。

生産性トレンドノイズレベルは、予測を立てるときの誤差の目安にする。

プロセスプロセス改良

・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。

形式的プロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトプロセス改良の為に費やされた時間相殺できる可能性は低い。

プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。

プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数技能改良プログラム(たとえば、全般的CM等級の引き上げ)は、プログラム実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。

標準的プロセス危険な点は、人々が賢明な省略を行う機会を失わせることである特に人員過剰のプロジェクト場合標準的プロセスによって全員に行き渡るだけの仕事(役に立とうが立つまいが)が発生するなら、標準的プロセスが厳密に守られてしまう。

仕事のやり方を変える

デバッグ時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。

・優れたプロジェクトは、デバッグに費やす時間割合はるかに低い。

・優れたプロジェクトは、設計に費やす時間割合はるかに高い。

相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由理解し、尊重しなければならない。

プレッシャー効果

プレッシャーをかけても思考は速くならない。

残業時間を増やすのは、生産性を落とす方法である

一時的プレッシャー残業は、人々の商店を定め、その仕事重要であるという認識を高めるには有効方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。

管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからいから、または、ほかの方法の難しさにひるんでいるかである

・おそるべき推測:プレッシャー残業を使うほんとうの理由は、プロジェクトが失敗したときごまかすためかもしれない。

怒れる管理

管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる(虐待された子供自分の子供を虐待するようになるのと同じ)

管理者が部下を侮辱すると、それが刺激となって部下は自分仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」であるしかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。

管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである

あいまい仕様書

仕様書あいまいなのはシステム利害関係者の間で対立解決されていないしるである

・入出力の完全なリストのない仕様書は、見込みなしである使用を明確にする最初の一歩にもならない。

仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである

対立

・開発に複数当事者が関わっている限り、利害の対立は避けられない。

システムの構築と導入の事業には、特に対立が多い。

システム開発組織ほとんどは、対立解決能力に乏しい。

対立尊重すべきである対立プロらしくない行動のしるしではない。

・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベル勝利条件を引き出すようにする。

交渉は難しい。仲裁簡単だ。

勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。

・注意:われわれは味方どうしである。敵は問題のものだ。

触媒役割

触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても(通常はほかにもいろんなことをするが)、触媒役割重要で貴重である

仲裁は、触媒役割特殊なケースである仲裁わずかな投資学習できる。

・「あなたたちの仲裁をさせてもらえますか」というささやか儀式の開始が、対立解決本質的な第一歩になることがある。

人為的ミス

・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。

スタッフの人数

・初期に人数が多すぎると、プロジェクト重要設計作業を省略せざるをえない(全員に仕事を与えるため)。設計が完成する前に大勢仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。

・このため、相互依存性が高まり会議が増え、やり直しが増え、フラストレーションたまる

理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤(プロジェクト期間の最後の6分の1ぐらい)に人数を大幅に増やすというものである

・おそるべき推察:無茶なスケジュールを達成するように決められたプロジェクトは、妥当スケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。

プロジェクト社会学

会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単方法は、議事予定表を発行し、それに厳密に従うことである

プロジェクトには儀式必要である儀式は、小規模な会議や無欠点運動など、プロジェクト目標理想に目を向けるために使う。

罵倒などの怒りから人々を守るために手を打つ。

・注意:怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである

考察:怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる(これは怒っている人の問題解決できないが、ほかの人の悩みは軽減できるだろう)。

病んだ政治(再び)

・病んだ政治を下から治療することはできない。むだな努力時間を浪費したり、自分立場危険さら必要はない。

問題自然解決するか、行動するチャンスが来るのを待つしかない場合もある。

奇跡が起こることもある(だが、あてにしてはいけない)。

倹約精神

倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である

・それは、組織自然目標である繁栄福祉精神とは正反対である

・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。

急進的な常識

プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である

2009-07-02

http://anond.hatelabo.jp/20090701031715

こんな増田よむとマスマス田舎に帰りたくなくなる。

多分増田の住んでる所は滋賀、でオレも滋賀

オレ、東京に住んでる30歳毒男職業はIT系なんだ。東京の生活に疲れて来たから、地元に帰ろうかと思うんだが、田舎には有るわけない。

なんだかんだ言って東京は学ぶ環境が発達してるし、ITって勉強会も盛んにある。開発プロセスに関しても会社によっては最先端だ。

横文字使ってはなしたり、「~~感」の様な会話も成り立つ。

けど、田舎帰ったら、業務系のITドカタ系の仕事しかないと思う。

もし、ITドカタ系に就職しても上流工程とかで「仮説が~」なんて言葉を出した瞬間にシカトされそうな気がする。

エクセルの使い方を知らないCプログラマーが隣でグダグダ馬鹿な事いってそうな気がする。

そして、30過ぎで地元に帰ると周りの目が MAXで都落ちめって感じで見てくると思う。

おまけにやはり出会いが無い。田舎で30過ぎの女はもはや売れ残り以外の何者でもないだろう。

これまで散々遊んできたから田舎の30過ぎの田舎毒女には多分、納得できないだろう。

こう考えると、次は海外に逃げるかっと思ってしまう。

2008-09-26

「要は、勇気がないんでしょ?」で始まるデスマーチ

ちょっと昔の話。今よりも僕はずっとずっと言い訳をするのが好きで、理屈を説明するのが好きだったんです。

でまぁ、当時も今と変わらずデスマーチがへりませんで、

アジャイル信者と飲みながら「いいプログラマがいない、だからデスマーチがへらないんだ」と文句言ってたのです。

進捗報告会議で。

したらまた、このアジャイル信者が「じゃあ、わかった」と言うのです。「今からプロジェクトのやりかたを変えよう」と。

プロジェクトのやり方を変えたことなんかないオレは焦りました。「いや、ちょっと待って」とあわてます。

でもアジャイル信者は、少し遠くで打ち合わせしている2人組のプログラマを指さし、「あそこ行って一緒に検討しようぜ」と言い、席を立ちます。

オレは「いや、向こうも迷惑だし」とか「さすがにうざいっしょ」とか言って止めます。

アジャイル信者は「嫌がられたら戻ってくればいいんだよ」と言ってましたが、オレが動こうとしないので行くのをやめました。

「じゃあ、海外発注して、オフショア開発にしようか?」とアジャイル信者は言います。

「逆にそっちの方が難易度高いだろ」とオレは顔をしかめます。

「でも時間がないんだろ? だったらやり方を変えるしかないだろ」とアジャイル信者は口調を強めます。

「そうだけど、もっと普通にやりたいっていうか」とオレ。

「なに、普通って?」

ウォーターフォールとか、Vモデルとか、そういう…」とハッキリ言えない自分。

「じゃあ、オレが今からテスト仕様を具体化してきて、それでお前に渡したらいいか? それも時間の削減だよな」という友達。

「それは…、だけど、ほら、お前もこの前言ってたじゃん。ドキュメント作らないやりがあるとか」

「は?」

「その…」

「…ドキュメントを作らないじゃねぇよ。無駄ドキュメントを作らないだよ」

「あ、そうだったね。…でもオレ、ドキュメント書くの、少し苦手だし。そこまでしてプロジェクトのやり方変えたいってわけでもないし…」

アジャイル信者はオレの顔をじっと見つめながら、一言、

だせぇ

と言いました。

ちゃごちゃ言ってるけど、技術力がないだけじゃん

彼は言います。

言い訳をして、さも「こういう事情なんだ、だからしょうがないんだ」って言うけれど、

技術力がない自分を必死になって正当化してるだけじゃん、と。

プロセスを変更する勇気もないやつが、時間が無いとか言うんじゃない。

どうせオープンソースライブラリを使えば「オープンソースは保障がないから怖くて使えない…」って言うし、

スパゲティコードを変更しようとすれば「動いているコードに手を入れるプログラマとは仲良くなれそうにない」とか言うだろうし、

開発プロセスを変更しようと言えば「いや、いままでこのやり方でやってきたし」って何かにつけて言い訳するんだろ?

だったら「自分にはソフトウェアを開発する技術力がないんです」って素直に認めて文句言うんじゃねぇよ。

そっちの方が、よっぽど何かってときに力になりたいってと思うし、

つーか、できない理由並べて、今の開発プロセススパゲティコードを変更させずに、バグをなくしてもらおうとするその魂胆がだせぇ、と。

2008-07-20

トイレエンジニアリング人類学

増田です。今日ショッピングセンタートイレを利用したところ、そこの男性用小便器のデザインが今まで見たことのない斬新なものでした、というか、率直に言うとものすごく女性器に似ていました。それだけの話なのですが、色々考えるところがあったので文章にまとめます。以降男性用小便器を『それ』、女性器を『あれ』と呼称します。私はトイレ産業の関係者ではありません。他の業界エンジニアです。部外者の立場で書きました。

普通『それ』のデザインというと、四角いものを思い浮かべる男性が多いと思います。大きさは様々で、例えばホテルのような高級っぽいところだと、厚みがあって重量感があるものが備え付けてあったり、駅とかだとそれほどでもなかったり。丸っぽいものは学校にありました。それらは大抵小ぶりだったような気がします。正直、今日まで『それ』のデザインについては無頓着だったので、思い出しながら上のような例を書いています。

『それ』は工業製品ですから、基本的には素材の体積で値段が決まると考えられます。大型のものは高価なはずで、だとするとそれは高級感を持つのみならず、パフォーマンスも違ってくるのではないか、と予想します。じゃないと、アドバンテージが少なすぎじゃね、って。

そこで『それ』の性能の指標として『尿のユーザー及び環境へのはね返り』が重要であると想像しました。ここではそれが数字化できるものとして扱い、ユーザー環境(例えば床)は別々のものですが、まとめて『はね返り係数』と呼称することにします。『はね返り係数』が小さい『それ』ほど優れていて、メーカーはそこで技術競争しているに違いありません。先程の『それ』の大きさに戻ると、大型のものほど尿を受ける曲面の設計に自由度を持たせることができ、結果的に『はね返り係数』を向上させることができます。

さて、開発プロセスイメージしてみましょう。『それ』を利用するユーザー身長は様々であり、使用時におけるユーザーと『それ』との距離にもばらつきがあります。使用状態も検討しなければなりません。ケータイで話しながら用を足しているかもしれません。設計では、あらゆる状況でまんべんなく『はね返り』係数を最適化させる必要があります。

私、男増田の経験からいうと、モデル体型を数種類用意して、それにモンテカルロシミュレーションを組み合わせているのではないかと予想します。

このあたりがエンジニアリングですね。

私が見た『あれ』の形をした『それ』に戻ります。第一印象は「細!」でした。ボウリングのピンを上下からつぶしたようで、下部はもっと丸みと厚みががあって包み込むような形状、上に行くにしたがって薄くなり、あげくには水を流す部分が突起を形作っていました。こうして書いていると、私がエロエロでひどい欲求不満のようです。皆様に『それ』をお見せできればいいのですが、写真を撮ってくるわけにはいかなかったですし、「小便器 女性器 デザイン」でググっては見ましたが、製品サイトにはたどり着けませんでした。正直、他の男増田の皆様が同じように『あれ』を想起されるかどうかは分かりません。

しかし私に関しましては、用を足しながらいやらしい想像が浮かんでくるのを抑えることはできませんでした。思い切って書いてしまうと、中にどくどくとたっぷりと注ぎ込んでしまいました。そこで、はっと気付いたのです。これは人類学だと。

ユーザーに『それ』が『あれ』だと思い込ませることができたならば、その時のユーザーの行動をより理解することができ、結果製品パフォーマンス向上につなげることができます。射精だったら上手に狙ってこぼさずに。つまり『それ』の曲面設計よりも、『それ』のデザインによって『はね返り係数』の最適化が可能になるのです。人類学民族誌学的アプローチです。

短所としては、『あれ』を想起しない人、特に『はね返り係数』が高そうな子供には何の効果もない、という点が挙げられます。ただ、それ以外の長所として、『あれ』が比較的小さいために洗浄に使う水の量を減らせるということもあると思います。

色々書きましたが、中の人意見がない限り私の空想に過ぎません。ただ、『あれ』の形をした『それ』との遭遇は、休日の私にちょっとした思考をくれました。

ログイン ユーザー登録
ようこそ ゲスト さん