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

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

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回は実証済みの能力レベルプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。

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

・話すより聞け。

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

生産性の向上

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

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

リスク管理

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

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

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

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

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

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

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

防御体制の強化

無駄を減らす。

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

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

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

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

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

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

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

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

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

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

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

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

病んだ政治

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

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

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

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

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

測定基準

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

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

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

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

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

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

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

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

プロセスプロセス改良

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

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

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

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

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

仕事のやり方を変える

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

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

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

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

プレッシャーの効果

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

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

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

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

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

怒れる管理

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

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

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

あいまい仕様書

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

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

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

対立

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

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

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

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

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

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

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

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

触媒の役割

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

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

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

人為的なミス

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

スタッフの人数

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

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

理想の人数配分は、プロジェクト器官の大部分を少人数のコア・チームで行い、プロジェクトの終盤(プロジェクト器官の最後の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

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

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

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

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

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

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

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

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

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

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

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

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

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

2007-09-05

ドーナツ2.0

これからはドーナツ指向言語によるマッシュアップ的なアジャイルドーナツ開発プロセスを選択することで

エクストリームドーナツプログラミングを実践し、中国インドへのオフショア開発でグローバルなアウトソーシングを促進。

それによるドーナツ化現象が発生すると。

なるほどなるほど。

2007-08-31

http://anond.hatelabo.jp/20070831005830

まぁ、年齢からいって近いうちに転職されるのだと思いますが。

今いる世界は今いる世界できちんと色々と見ておくと、転職後に役に立ちますよ。

特に確立された開発プロセスの元での開発経験は、そうでない、開発プロセスなんてものが存在しない現場(大抵そういったとこは「うちはアジャイルでやってます」って掲げてますね)にいった場合に結構役に立ちます。

すぐに転職されないのなら、今の仕事は今の仕事で色々と学ばないと時間がもったいないですしね。両方の世界を見てきたことのある1エンジニアからの提案です。

まぁ、両方見てきた人間としては、COBOLメインフレームの世界もあれはあれで色々と考察できるというか。

COBOLは結局のところ業務処理用DSLだよなー、とか、やたら一本一本のプログラムが短くてそれらをJCLでつないでデータを流す様はPlaggerでたくさんのプラグインを設定ファイルでつなぐのと似てるよなー、とか。

とはいえプログラマーとして退屈なのは確かにありますね^^;

それに業務知識を本気で活かすつもりなら最終的にはユーザー企業側に転職した方がいい気もします。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん