サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
tonotonotono.hatenadiary.org
システムがトラブった時の現場でうれしいお偉いさんの行動は何か? 1.ユン○ルを差し入れてくれる 2.とりあえず叱咤激励という名の下、怒鳴り込んでくる 3.まずは落ち着かせろ、責任はオレが持つとか言ってくれる 最近報道されなくなったけど、 ぼくらの国の政権与党様ったらほんとーに 「やってはいけない対処、反応、行動」を的確にとらはりますな。 トラブった現場に怒鳴り、 責任はとらん、 事態が収集つけそうな気配を敏感に察知して潰すので 事態はより混乱の道を進む。 自身の経験を思い出せば出すだけなんだか腹が立つ。 ってあたりは、 現場と上層部がかけ離れているって事実を感じるには十分な要素だなと思う。 先日友人と飲んだくれているときに 「トラブった時には、まず沈静化させるため、『オレが責任取るからお前ら何とかして見せろ』っとハッパの一つもかけてくれ、こっそり○ンケルのいいヤツを差し入れてくれたりしてく
問題集みてたらこんな項目があった。 ある開発プロジェクトの見積もり工数は88人月である。 作業を開始した1月〜5月までは各月に10名を投入したが、 5月末時点で40人月分の作業しか完了していない。 8月末までにこのプロジェクトを完了するためには、 6月以降は最低何名の要員を追加する必要があるか。 6月以降の全ての要員の作業効率は、5月までの要員と同じであるものとする 答えは10人なのだが、とっても納得いたしかねる。 ・計算上はそうなることは受け入れられる ・現実は全ての要員の作業効率が同じなんてことはありえない ・追加要員が即時戦力化されることもない ・初期メンバーの作業効率が、1ヶ月目と5ヶ月目で同じなわけがない ・例えば以下のような成長を遂げていても平均作業効率は0.8となる → 1ヶ月目:0.1、2ヶ月目:0.6、3ヶ月目:0.8、4ヶ月目:1.0、5ヶ月目:1.5 試験問題とわりき
・問題が起こる ・解決策を模索する ・解決策見つける ・でも適用するには有象無象のバリエーションに対応する必要がある ・って言われる ・ハナからやっとけやって思うし言う ・もちろん解決策はうやむやに ・また、解決策が既存のソースの質の悪さゆえに解決しきれない時に、解決策を提案したものの能力不足のせいにされる ・ゆえにソースコードに携わらないものだけがでかいツラする まーしっかしどこいっても事欠かない状況。 人員次第でなんとかなるのがこの手の問題なのだが、 人員がいてもそれを阻害する輩がいるのもまた事実。 少数精鋭でかつ、やる気あふれる人たちだけがシステム開発に携われるとしたら、 失敗なんて珍しいことだと常々思うのだが世の中そんなにうまくはいかない。 牛歩が大好きなやつほど革新的なことを潰しにくるからな。 人月の悪影響だな。
入社3年内の離職率35.9%――指導が必要なのは学生ではなくクソ会社w。 http://kusoshigoto.blog121.fc2.com/blog-entry-273.html しかも「社会人wなら仕事を優先させるのが当たり前」みたいな社畜の価値観を押し付け、サビ残、休日返上でろくに休みも与えず、クソ労働環境で理不尽だらけの我慢大会を課せば3年も続く方が奇跡だよ。 理不尽といえば、 ・残業時間は40時間まで って昔々のことからはじまり ・仕事は3倍、納期は変わらず ・仕様は大幅変更、納期は変わらず って業界的に当たり前になってる事柄から ・裁量労働制導入 → 仕事量じわじわ増える → 増えすぎて出来ず → お前は出来ないやつだと評価下がる ・他チームがおかしなことしてるのを忠告 → 忠告も聞かずに突っ走って失敗 → おれ達尻拭い ・朝10分遅刻したらその日一日出勤しなかったことにしろ
なんで誰も用意しないんだろう。 開発時に。 って思う現場は多い。 最近の現場でも「綺麗なデータを用意してください」といったら(゚Д゚)ハァ?っていわれたし。*1 開発時に「こうあるべき」って姿を用意できないデータ。 作るの難しいから後回しにされるデータ。 テスト段階でデータに苦労する前に作ろうぜって試みは 無知によって潰される。 *1:本番に近いデータですよ、ほら。こんなデータが作られるからこう動くとか誰の目にも明らかになるようなデータのことですって言ってもやっぱり(゚Д゚)ハァ?だった。
・ウォーターフォールモデルでの開発は至難だ。 ・開発において技術力は必要不可欠な要素だ。 以上2点を考慮してプロジェクトを成功に導くにはどのようなアプローチがよいか? 答え ・技術力のある開発者を集めて、アジャイル。 現実問題で考慮すべきこと ・ウォーターフォールモデルで提案するととりあえず通りやすい ・ウォーターフォールモデルは金にはなる 開発モデルの利点を生かした現実策はどうのようになるか? ボクの答え ・ウォーターフォールモデルで提案し、スケジュールと予算を決定する。 ・内部進行は技術力のある開発者を集めて、アジャイル。 ・ウォーターフォールの進捗体裁を整えるために管理者がんばれ
技術者達にとって ウォーターフォールモデルを押し付けられるくらいなら、 内部進行と外向けのスケジュールの嘘をつかない調整程度は、甘受できる増加作業だ。 ってなことを いろんなところでいろんな技術者達と話したときに感じた。 そんなことをウォーターフォール信者に話してみると、 まー100%断られたのはいいとして、その理由はこんな感じ ・ウォーターフォールでやると言った以上それ以外に方法はない →でも現実は失敗の道を行っている ・進捗がどうなっているかわからないですやん →そもそも今をもっておまいは把握しているのか? ・もしそれで失敗したらどう責任取るんですか? →ウォーターフォールで失敗するのはいいってことか? ・それってドキュメント残るんですか? →あとからつくりゃーいいじゃない。つまり残るってこった。 ちょっとだけ聞けば耳に心地よい言葉だし、まっとうな正論とも言えることもあるが いかんせん
ちなみに。 ・プログラム(機能)の予定工数を決定する ・プログラム(機能)作成工程を10段階ほどに分ける ・各工程に案分の重み付けを行う ・各工程が完了したら案分の分だけ作業が進んだと管理する ってなことをそのときのメンバーの実績値から工程や案分量を割り出して 調整材料にしましょーよと言ったとしても そんなことができるなんて信じないから受け入れない。 ボクとしてはそこまでやったらウォーターフォールという看板を守れるんじゃね?と思っているからやった。 でもやっぱり信じないから受け入れない。 誰でもプログラムに落とせる詳細設計書と要望されたものを 誰でも落とせるように書いて達成したら、 「そんなん書ける人がナンボほどいるんですか」と断られた。 お前らいったい何がしたいんだ?と真剣に思ったことがある。
知らないと恥をかく プログラミングの常識 http://d.hatena.ne.jp/bleis-tift/20090301/1235850947 いろいろ突っ込みの量ってか分量書き上げたところに感服した( ´∀`) 今日の笑いを提供していただいた気持ちになれたのでとっても感謝(−人−) より良いコード?いやいや あたりでみた↓このソースのここまで見て、昔見たアホソースを連想した。 // // Rrectangle.cpp // #include <iostream> #include <cmath> using namespace std; class Rectangle { private: int x1, y1, x2, y2; 1秒でわかるアホソース http://d.hatena.ne.jp/tonotonotono/20060707 グローバル変数をローカル変数に置き換えたプロ
Agile失敗パターン三部作 http://d.hatena.ne.jp/masayang/20090227/1235782899 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。 だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。 ウォーターフォール大好き人間達にいつも言われたことは 「リスクと問題点は全て洗い出して解決しなきゃいかんのです。 随時解決するなんてリスクはとれませんよ」 よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。 ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 いかな方法にも実力は大事。納得。
建築業界に例えられることの多いIT業界ですが、 こればっかりはIT業界に追いついてきた感があります。ヽ(´ー`)ノ 談合消滅後の建設業界で何が起きているか 工事単価の“ダンピング”や発注者の権限強化で職人は青息吐息 http://business.nikkeibp.co.jp/article/topics/20080327/151329/ 自由競争という大義の下にダンピング競争が始まった。 あらま。 職人の仕事はハードだから、賃金でカバーしていてくれたんや。 〜(中略)〜 ブルーカラーは確かに、地位は低いけど賃金はあった 働けば実になる。 今は一級の国家資格を持っている腕利きの職人でも350万円程度。 普通の会社員から見ても決して高くない。 だから職人のなり手がいない。こんな職業に夢が持てるか。 けど今は働けば未になるになったようです。 問 談合組織が消滅したことで、ダンピングが激しくなっ
プログラムは誰が作ってもいいってもんじゃーない。 この当たり前を最近改めて実感した。 仕組みを作った。 誰がやっても最低ラインが保障できそうな手順。 一連の流れをツールに押し込めて、 手順に沿って作業を行えば8割くらい出来上がる。 (,,゚Д゚)<あとは手順を覚えりゃそれでいいな なんて思っていたんです。 (,,゚Д゚)<手順もデキルヤツなら意図は汲めるしな なんて淡い期待も抱いていたんです。 しかして現実は。 最低限このくらいだろうという想定が 最高ランクにしか位置しないことだと思い知りました。 ツールはちょっとしか使われない。 コピペ用のパーツとツールを作ってあるのに、使わずに生ソースをコピペ&改変。 メソッドのコメントはもちろん消える。 命名規則は乱れる。 整然としていたテンプレートから生まれるコメントまみれな緑豊かなソースコードは、 またたくまに荒廃した廃墟の様相を呈した。 そうな
ところで。 仕事のための道具にナンボかけているか?っと話がでたときに。 われらがIT業界はほとんどの人が趣味の範囲を超えてないのが実情ではあるまいか。 たいてい会社もち。会社支給。これが当然の事となっている感がある。 先日、昔なじみの美容院へ行ったときのこと。 なにげにUXGAのディスプレイを買ったことに浮かれて聞いてみたことがある。 ( ´∀`)<「そういや美容師さんって自分の使う道具にゼニかけたりするんですか?」 今にして思えばとんでもなく無知な発言だった。 正直すまんかったと反省した。 気持ちよく帰ってきた答えはこうだった。 ξ*゚∇゚)ξ<「全部自前ですよ〜。はさみとか高いんですよ〜。」 (;´∀`)<マジで?高いってーとー1万円くらい? ξ*゚∇゚)ξ<「ピンキリですけどね〜。5〜6万くらいから10万くらいするのもありますよ〜。」 こんな事務用ハサミと大差ねぇだろとか勝手に思って
日本発のソフトが少ないのは日本人が英語が苦手だから タイトルだけ見て一理あると思うも。 一方のソフトは、少々未完成なものでも市場に出し、短期間の間に改良を加えていかなければ競合他社に遅れを取る。 「短い開発サイクル」「低い完成度」という組み合わせの産業だ。 緻密で職人芸を好む日本人の美学には、自動車の方が適しているといえる。 否。 このような限られた状況でなお力量を発揮するのは職人魂であり、日本人の美学にそむく事など無い。 そういう意味では適しているかどうかの答えは等価である。 だいたい、ソフトウェアにしても「短い開発サイクル」「高い完成度」を実現することは技術者には既に出来ている事なのだ。 これを潰す要因となっているのは技術者を使うものの無知である。 例えば、カタチが出来、一応走るようになった自動車をそのまま製品として出荷したらどうなるだろうか? 今の自動車業界となりえただろうか? 多少
先日なんとなしの会話からおもったこと。 ( ´∀`)<知っている知らないの差は、その瞬間では埋められない差よね。 その上で次の手を打てるかどうかは心意気だね。 プログラム開発している際の技術的な問題に直面した時。 知らなければ正解の近くにも寄れない。 「できない」以外の道が無い。 知識があればこそ初めて正解への道が開けることがある。 成果主義をうたう者達がいる。 成果を判断する術を知らなければそもそも成り立たない。 やっぱり「できない」以外の道が無い。 判断できて初めて、予定された莫大な成果を手に入れるチャンスへの道が開ける。 知ってしまえばなんてこたないこと。 しかして「知らない」それだけで判断は狂う。 もがき苦しむ。 とある人種がある。 やったらあかん事をやった上で、それに目を瞑り、 (;´Д`)<うまくいかんのは何でだ。 といい続ける人種。 例えば、プロジェクトがヤバイ時に大量の人員
システムの設計段階でプログラマがいない。 構想を模索する段階ではなく、 実案として固める段階でプロフェッショナルがいない。 子供たちががんばって出し合った意見はかわいいもんだが、 実用的であるかどうかはまた別の話が実社会というものである。 だいぶ前にプログラムを調理に例えてた方がおられたが、 まったくもってその通りな例えだとしみじみ思う。 小学生たちが思い思いに作った料理のレシピを プロのコックは作る事ができるか? もちろん答えはYesである。 しかして味のほうは保障しかねるといった注釈はつく。 レシピなんてものは見ただけで判断できるレベルというものが存在する。 素材と調味料の相性、調味料の配合割合を見れば作成後の味はある程度想像が付く。 そんな世界を想像もしない輩は全否定するものなのだが、知らないんだからしょーがない。 現実はどっちかといえば前者である。 ゆえに作る前に、レシピを見た時点
モデラーはいつも抽象的な現実しか語らない。 概念なんだからしょーがねーだろ っと言われるかもしれないが、 実際問題使う人たちが理解に苦しむのであれば 提供側はもちっと考えるべきである。 ユーザを苦しめるのがベンダの仕事か?ってことにYesYesYesと答えるのは ユーザをないがしろにしている事実にほかならない。 ポリモルフィズムを語る際に、必ずコードが単純になるよってことしか言わない。 再利用性が高まることを示すにはサンプルコードはあまりにも少ないのだ。 理解を促すために必要なのは前提と結論と過程の3つであり、 巷にあふれる説明には過程がカケラしかない。 ふっとぐぐったらこんなんみつかったのだが、中身はひでぇもんだ。*1 コードに落とし込む時、メソッドの役割は2種類必要になる。 ・実処理 ・実処理を呼び出すだけの処理 *1:世で見る普遍的な言葉という意味では「平均的」なのだが、 世の中の平
わが事 最近おいらがメソッドとかクラスのコメントを全く書かない事はない。 正確には記述がない形で放置される事がない。 なぜか? コピペツールバンザイだからである。 メソッドのスケルトンをコピペで定義する。 1から書かなくていいから最低限は存在することになる。 消すよりも、 メソッドをどんなに早くタイピングしようと、 特定のツールウィンドウ探して1クリックして張り付けるほうが早い。 そして記述内容にブレがない。起こるわけがない。 対象のこと そんな今。 ペアプログラミングの最中、そいつが作っている様をみながらしみじみ思った。 (,,゚Д゚)<タイピングが早いやつほどコメントがねぇ。 これはある種必然なのだろうかという視点が生まれた。 IDEの入力補完機能とか使いたおせばさして苦もなく定義していける。 一般人よりプログラマ初心者よりはるかに高速にプログラムをくみ上げていけてるのだが、 それゆえ
プログラムを組むとき、ソフトウェア開発時に経てきた取捨選択。 ・何はともあれ作り始める事。 作るものの形すら見えずに何ができよう。 仕様書という名の書類にある画面は完成形ではない。 機能を作りながら考えても、作り直す事ができなければ バグが消える事はない。 事前に構築する形を想定し設計し試しようやくプログラミングする。 遠回りだと思えたこの行為が最速と平均値を叩き出せる行為であると実感できた時からやめた。 ・とりあえず動くもので完成と言い張ること。 ちょっと触ればエラーがあふれ、 直しても直しても収束しないクサレソース。 後の改変時にも読むのが辛くなる神経衰弱剤。 目先の納期に合わせようと走り始めても目標は自分で遠くしていと気づいた時にやめた。 ・メソッド分割しない事。 用件を考えながらコード化するとしばしば行が長くなる。 これを分割しないことはその場では楽な選択肢なのだが、後が辛くなる。
俺たちの仕事はなんだーと端的に言うと。 「人減らし」 企業がシステムを導入するのはこれによる経費削減が目的だ。 当初の予定通りに納品されて、効果があがれば事務に必要な人手はどんどん削減されていく。 新たにシステムのオペレータという人手は増員されるが、全体数としては減っていく。 こうしてガンガンシステム化して、ガンガン成功させればガンガン就業者は減っていく。 (n゜∀゜)η<世の中の失業率アップは我々の成果だーー ガンガン失業率上げてガシガシ就業率とかさげましょう。 身近なとこで、同業者をターゲットにするのですよ。これ。 現実問題はデスマーチがあり、 人員ブラックホールのように行ったっきり帰ってこれないプロジェクトがあり、 人海戦術大好きプロジェクトマネージャが存在し〜 っという要因があるおかげで、なかなかうまくいかない。 世の中を洗練し続けると、就業者は少なくとも歯車は回るようになるのだ。
ExcelのVBAの仕事の中で、 「現在動いているものですからサンプルに〜」 っといただいたものがあった。 コードを開いたら・・・・・・ Sub Edit_Proc2(Flg As Integer) Dim i As Long Dim j As Long Dim k As Long Dim m As Long Dim n As Long Σ(゚д゚ )!?!? ソースを開いてわずか1秒。 目の前がクラクラしました。 この後のソースを見るまでも無く断言できる。 (,,゚Д゚)<これはクサレコードだ たった7行ですが以下の状況により次のことが推測できます。 Function名が連番名になっている おそらくループカウンタが5つもある その全てが1文字変数である これらより 2より、このFunctionの行数はだいぶ長い 同じようなFunctionが複数ある サブルーチン化などされてようはずはない
人は知識の中から判断材料を探り出す。 ゆえに知らないこと、想像もしないことは選択肢から除外されている。 プログラムを作るという行為において、 ソースコードを組み上げるだけで終わることはない。 メンテナンスもあればデバッグもある。 後にくる改修を想像していない者にとってしてみれば 組み上げることに注力することは必然といえる。 今。自分には方法論がある。 今。自分には最適化を目指すための道具がある。 それらを駆使した結果、どういうメリットデメリットがあるかを語る経験もある。 大規模なプログラムを開発する際に、 言語後特性、フレームワーク、資料の形態、人員、 これらの条件を踏まえたうえで活用するためにとる行動がある。 今。自分にとってそれは必然の行為であり、 今の世の中の標準から外れていることも承知している。 管理職の今やっている行為と効果も承知している。 もちろんお金の出所とその人たちに違和感
ちょっとずつ復帰。φ(..) ついったーを受信機として以外で使い始めた。 アプリ大杉。 こんなことが出来てしまう ・フリーソフトにいちゃもんのようなバグ報告を行う ↓ 作者:いちゃもんゆえに無視 ↓ タイーホ この流れが現実となったら萎縮しまくるだろね。 少なくともボクはVectorに乗せてるフリーソフトの公開を全部やめる。 愉快犯だとしてもナンクセ怖いもん。 <本音> 当時はよかれと思って作ってのせたけど、結局自分で使うものは数限られるやん? 今使ってないものなんかしらんやん? そこ突いてこられたらハラたつやん? フリーソフトでこれなんだから、業者間なんてもっと大変なことになるだろなー ・これを背景に、業者間での不具合対応応酬が激化する ↓ ってか委託元と委託先のパワーバランスが委託元の方にさらに強化される。 ↓ 「これバグじゃねーの?」 って言葉で仕様変更しまくることに拍車がかかる。
IT部門に求められる「標準化」と「開発現場の統制」 http://itpro.nikkeibp.co.jp/as/nri4/index.html 通常の場合、要件定義や基本設計はユーザ企業のIT部門が主導で推進、 その後に続く詳細設計や開発、単体テストを開発ベンダーが担当、 さらにその後の連結テストや結合テスト、運用をIT部門が担当することになる。 これはさておき。 ここで大きなリスクが生じるのが、詳細設計から開発・単体テストの部分である。 (..´Д`)<ん? この部分は開発プロセス全体の中でも最も多くの工数が費やされる部分であり、 この部分を外部に丸投げすることで、工数が肥大化したり、十分な品質が保たれないという危険性がある。 (..´Д`)<あなたも「私の要求定義にミスはない」といいたい人ですか。 要求をキャッチアップできないのは外注のせいと言う類のひとですか。 実物も見ずに基本設計
リンク先でひろった文章。 Software Factoriesに関する陳述 ここ 10 年間に及ぶ徒弟制度の文化により、有能な開発者数の増加と開発者の平均能力の向上に成功したよう思えますが、少なくとも以下の 2 つの理由により、徒弟制度により期待された要求水準を満たすだけの能力を業界が身に付けたようには思えません。 経験により私たちが学んだことは、極めて有能なプログラマがより多く輩出されることは決してないであろうということです。 最高の開発者は最低の開発者より 1000 倍生産性が高いのですが、逆に、最低の開発者は最高の開発者よりも 1000 倍多いのです。[Boe81] Brooks [Bro95] が指摘するように、人々をプロジェクトに追加することは、結局のところ、低レベルな収穫逓減をもたらします。 開発者の新規採用とトレーニングにより獲得されるキャパシティは、漸近的に低下するでしょう
最近プログラムと戯れている状況を利用して。 だいぶ前から仮定していたことを実験してみてる。 それは。 『新入りにプログラムを作らせないほうが全体として仕事は早く終わるかどうか』 期間内のトータルでみて、生産性がマイナスである場合に、 (..゜Д゜)<それなら何もさせないほうが仕事すすむやん と後から思い返すことは多い。 かつてPM11時を過ぎたころ、休憩室の片隅で当時の同僚と語ってたことの実験である。 仕事に空きが出来て、 ( ´∀`)ノ<ちょっと手伝ってもらえることになったから〜 などといわれて2〜3日ほど借りれる状況になったからといって その人にプログラムを作らせない。 ただし、あからさまに放置すると後々に禍根を残すことになるためそれもおいしくないので、 何か別のことをさせる。 短期間でカタチになり、いつ抜けられることになっても支障のないような作業。 かつ、作業指示者にとって、付きっ切
昨日は久々に楽しいソースに出会えた。 声に出して笑えるソースってのはある意味すばらしい。 原文は手元に無いから多少書き直して掲載。コーディングスタイルだけはおいらの。 もともとの作成者は余所の会社のどこぞのだれか。 それをメンテナンスすることになったやつとのレビューがそもそものネタ元。 登場人物: 「( ´∀`)」:おれ 「(=゜ω゜)」 :ソースメンテナンス担当者 まずはコミットを発行するメソッドから public void commitLoop( int intCount ){ try{ for( int intI=0; intI < intCount; intI++ ){ _connection.commit(); } } catch( SQLException sqle ){ // 省略〜 } } ( ´∀`)<あれ?このループって何やってんの? (=゜ω゜)<コミットをやっている
プログラマとしての道を歩き始めてから どれほどの壁にあたったのだろうか。 いくつ壁を乗越えてきただろう。 初めての壁は「プログラムがわかんねぇ」ってところからだった。 たった1人で作れないどころか、教えてもらっても構文もわからん。 そんなころがあった。 次の壁は「1人で仕事がこなせるか」だった。 業務もわからなければ、プログラムもどうつくっていいかわからなかった。 乗越えた次の壁。「0からプログラムが組めるか」だった。 元ネタがあった上での変更作業はなんとかなった。 けれども何も無い状況から作り上げるのはより難しい。 なんとかできるようになった頃。 「どれだけ早く組めるか」が壁となった。 まだ組み上げるだけがプログラミングだと思っていた頃である。 知識が付き、手法を改善できたとき、組み上げる時間は半分になった。 「今の俺は新入り相手の比較なら3〜4人に匹敵する作業がこなせる。」 そう思える
このページを最初にブックマークしてみませんか?
『 ( ・ω・)ノ<しすてむ開発。』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く