あれ、どうやったっけ

(たぶん)テキストサイト風blog。文が安定するまで書き直しあるからメンゴ。

THE REAL PROGRAMMERS STORIES 日本版を創作文芸してみた

2017/12/19 垢消しの余波により無事死亡

現在もうないです。カクヨムにて2週間で何枚書けるのリハビリやった後に垢消したった余波ですね。

THE REAL PROGRAMMERS STORIESを下敷きにネタ文書いたらあかんやつになってしまった

SI業界決め打ちになりますが。誰かWeb界とかソシャゲ業界やるといいと思う……。

https://kakuyomu.jp/works/1177354054884568734/episodes/1177354054884568845

注意:オリジナルのように、それなりに盛った誇張表現ですのでご注意を

なんでそんなものを書こうとしたのか

求職活動してクチだけ君やるよりは、やはり就活用サンプルアプリとかも作らにゃなあなぁ →

Githubに置くことになろうから日米複数言語は意識せななぁ(僕は英語わかりませんので変な英語勘弁してください) →

どちらかといえばこうメッセージ性(Contributeとかうるせえよ)を交える感じで逝こう →

あと笑える文章でも入れて面接時のネタづくりを意識していきたい →

これはひどい

……マージできないから創作文芸枠扱いにすることにした ( ゚∀゚)アハハ八八ノヽノヽノヽノ \ / \/ \

で、そういやプロジェクトの成功率ってどんなもんなんだっけ

開発者視点では60%、ユーザー視点では20~30%位が「成功率」のようです。まぁこの本見てないから「孫引きの参考情報」程度だな。

ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた - 勘と経験と読経

日本における要求工学の補足(あるいは昔めんどくさかったことの回想)

「何も言わなくても特有の仕事の仕方分かってて当たり前(座学だけだと漏れる可能性高い奴)」「 わからんからよしなにしてよ」「それじゃない」に対しては、要求工学は無力だと思います。

日本人が大好きな「要求工学」は、極端には事前に(プロジェクトに関連することは)ありとあらゆることを知識体系として収集整理してドキュメント化しようということです。

マス向けの工業製品の作り方と同じですが、お客さん視点で見るとそこまで付き合いたいのかなぁ? ってことにもなりそうですし。

お前ら! 工事進行基準はもういりません!(爆破)

itpro.nikkeibp.co.jp

まあ……なんだ、大きな企業の話でしかないんですが、契約書の内容次第ではアジャイルとかDevOps系の対応もしやすくなるのかな? くらいの印象。ただ億単位でアジャイルとかだと分かってる人じゃないとさらに爆裂しそうな気がしますけど、まぁなんであれ爆死はいつものことか。

工事進行基準だと

「オカミはウォーターフォールにコミットします、要件固定が原則でないと進捗出ないでしょ。

ITのひとたちはようけんていぎきちんとしてください!

ミスったらソフト屋の会計処理をめんどくさくしてやる」

以上の意味にならないかと思います。 自称の進捗割合で売上なり原価乗せていく形になるんで、本当の進捗が不明瞭要件がブレた(進捗巻き戻りの)場合、訂正仕訳が乱発ぽいと。あるいは要件が変更したり増減するの前提、モジュール組み合わせ方式で個別撃破中です、今やってる部分の進捗や終了条件は分かりますが全体の進捗は未定義です、みたいなスパイラルモードには向かんというか。僕の理解が間違ってたら訂正してください誰か。

「契約書の内容でこんだけやったらナンボね」を明示すりゃその通りのタイミングで売上乗せていいよってことではあるようなので、まあ契約書の書面次第ではアジャイル風味とかDevOps風味への対応ができるのかな? とも。まぁTier1でなんちゃら作ってナンボ、Tier2でラップなり合体(RestっぽいAPIとかで)、あとは後日考えましょう、みたいなのに対応しやすい会計基準に変更ってなるんならええんかも知らんですね。

あーあと昔見た「永遠の90%」思い出した。進捗書くExcel的なあの表の。