柄にもなく毎日更新なんてしてしまいました。
開発とブログと仕事の両立はぶっちゃけ無理ですね。
開発終了までブログはしばらくお休み。
再開予定、ゴールデンウィーク明けくらい？
僕の生存に興味のあるちょっとアレな趣味をお持ちの方はこちらからどうぞ。
GitHub → https://github.com/zeikomi552
Twitter → https://twitter.com/g7AP7EyFtDEdPCi
ではまた、ご縁がございましたら。
おわり
カテゴリー: ぼやき
命の値付け
時は金なり。時間をお金に交換可能とする言葉です。
人月商売は時間をお金に交換します。
1人月100万円ならば1カ月を100万円で売ります。
サラリーマンの1カ月は土日を除いて約20日。
時間にして約160時間。時給6250円ですね。
会社は一般に給料の3倍稼がないと儲からないらしいので、
会社の取り分引いたら手元に残るのは2000円ちょっと。
少しの遅延であっという間に赤字です。
人月100万円は儲かりません。残業などもっての外ですね。
行先ボードでも作ってみるか⑤ – 見積
あーやだやだ。見積。
人月の神話だとか人月見積が否定されて久しいですが、
請負開発の世界は相変わらず人月見積です。
自分の時間に値段をつけましょう。それが見積です。
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、
労力と進捗を混同している。人月は、人を惑わす危険な神話である。
なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。1人でやれば10カ月の仕事が10人でやれば1カ月でできるのか？
昨今、育休うんぬんで世間をにぎわせていますが、
男性が育休とって協力すれば子供を5カ月で産むことができるという計算です。
少子化問題解決です。
人付き合いの価値
人生において「やらないといけない」と思っていたことが
ただの思い込みだったなんてのはよくあります。
「人付き合い」もその一つです。
例えば以下のようなものです。
- ご近所づきあい
- 実家の会（盆・正月に親戚で集まるアレ）
- 各種イベント事（年賀状・お歳暮・祝箸・結婚式）
- 恋愛・結婚・出産
おそらく煩わしいと感じている若い世代は多いと思います。
僕はぶっちゃけ煩わしいです。若くないですが。
ぬくもりはワイフとこげ（猫）が必要以上に満たしてくれます。
個人的な話になりますが僕の実家は信心深い宗教一家で「助け合い」を重んじます。
僕も幼少期、何度も助け合いに関する神様のお言葉を読み上げましたし
助け合いを軽んじた人が不幸になる映像も何度も見ました。
こんな記事を書いて、たぶん僕はバチが当たります。
しかし、僕は技術者です。神罰は技術力で回避すべきと考えます。
ソフトウェア開発における設計とは何か
設計とは何であろう？それは２つの世界,すなわちテクノロジの世界と人間の世界の両方に属するものであり,
それらを1つにしようという試みである.[実践ソフトウェアエンジニアリング ソフトウェアプロフェッショナルのための基本知識]より抜粋
Lotus 1-2-3の開発者であるミッチ・ケーパーの言葉です。
ソフトウェア開発において設計のとらえ方は人それぞれです。
製造業においては「品質は設計で作りこむ」といわれるくらい
設計は大事な役割を担っています。
しかし、ソフトウェア開発の世界では、
残念ながら設計書を納品のためだけに後追いで作るというケースが後を絶ちません。
ブログの記事数からアクセス数を予測する
僕はブログの記事数とアクセス数の関係を出したいと考えていました。
記事が増えればアクセス数が増える。
感覚的にはわかるのですが、どのくらいの記事にすればどの程度のアクセス数になるのか？
というのがわかりません。
ちまたでは100記事くらい書けば収益化は可能だよ。
とか申しておられるのですが、100記事程度では全然ダメ。
200記事書いたけど赤字の真っ最中です。
元プログラマーがプログラマーと製造業についてぼやくという特段需要のなさそうなコンテンツ。
どれくらいの記事をかけばどのくらいアクセス数を稼げるのか検証していきます。
ついでに月2000円(僕のブログ用のAWS費用)稼ごうと思ったら何記事必要なのかも算出します。
単純な単回帰分析でいけそうです。
IT技術者の性別における給与差
IT技術者の性別による給与差が気になったので調べてみました。
僕の感覚では男性の方が女性に比べおよそ100万円くらい高いと考えていたのですが、
もう少し正確に知りたいと考えました。
ちょっと見ていきます。
ラプラスの悪魔 – 見積は難しい
僕はブラック・スワンの愛読者であり、
不確実性を予測することは不可能という立ち位置です。
見積の段階で全てのリスクを予測することは不可能ですし、
計画の段階でソフトウェア開発に必要な資料を完璧に作成することも不可能です。
ラプラスの悪魔。
例えば、テニスの壁打ちで壁から跳ね返ったボールがどこへ戻ってくるのかは予想がつきます。
その延長で、もし仮にすべての状態を解析できるだけのデータと能力があれば、
全ての未来を予測することは可能だというお話です。
もしもある瞬間における全ての物質の力学的状態と力を知ることができ、
かつもしもそれらのデータを解析できるだけの能力の知性が存在するとすれば、
この知性にとっては、不確実なことは何もなくなり、その目には未来も（過去同様に）全て見えているであろう。
『確率の解析的理論』1812年そんなのムリに決まってんじゃん。
ソフトウェア開発プロセス – 自己流プロセス
ソフトウェアの開発プロセスは混とんとしています。
プロジェクトは基本的にプロジェクトマネージャーやプロジェクトリーダーの理論（持論）やクセで進みます。
中小企業規模のソフトウェアハウスで、きちんとプロセスモデルが定義されているところは少ないでしょう。
ある日突然リーダーやマネージャーに抜擢され、
特に教育を受けることもなく自己流のマネジメントをします。
プロセスすら固まっていないのでマネジメントがうまく行かなくても仕方ありません。
一人で開発する場合はフレキシブルに開発できますが、複数人で開発する場合はそうも行きません。
自信をなくし
「マネジメントしたくない。プログラマーとしてやっていきたい。」
そう考えるプログラマーやプロジェクトマネージャー・リーダーは多いです。
優秀なプログラマーからプロジェクトマネージャーになる人は特にそうですね。
知識不足だけで自分の可能性に線を引いてしまうのは、もったいない話です。
今回は少しプロジェクトマネジメントにおけるプロセスについて考えてみます。
どんなものがあるのか知っておくだけでも有意義です。
なぜ、とっとと失敗しないのか？
たかだか1万行程度のソフトウェア開発に、
何カ月もあるべき姿を議論し何カ月も課題を探す要件定義（？）に疑問を感じます。
GUIを持つアプリケーションであれば、1万行程度のものは画面数も片手で数える程度です。
慣れた言語でそこそこの経験があれば、開発は1人で2週間もあればそれなりの形になります。
テストも1週間もあれば終わるでしょうしドキュメント作成は数日で終わります。
1カ月がっつり使えれば普通に終わります。ぶっちゃけ1カ月も要りません。