巨大なバベルの塔

あまりに大きなソフトウェアがあって莫大な利益をあげていた。

利益にむらがり、初心者たちがソフトウェア開発をしている。

初心者はソフトウェアを知らなかったので、見積もりがうまくなかった。

新しい開発要求が開発中に発生した。

莫大な利益を守るため、開発要求は開発計画に追加された。そして伝説のデスマーチへ。。

最初はソフトウェアは大きくはなかった。新しい要求を営業が顧客からとってきた。その製品の売上がよかったので、受け入れられ、追加されていった。ソフトウェアが大きくなった。 v機能追加は売上拡大に向け必須であると思われていた。

最初のソフトウェアを作った人たちは、その成果が認められ昇進していった。昇進し管理職になった。あるものは会社を去った(これは普通のことだが)。ソフトウェアの構造を知る人は減っていった。

依然、そのソフトウェア製品は売上好調。その会社の売上の半分、利益の半分を占めるまでになった。

そのソフトウェア製品の実績は不動になった。そのソフトウェアをよく知るものはいなくなった。資金を使って開発者が集められた。請負外注、派遣外注、社内の今まで関係なかった人たち。

その一人がぼくだよ。

で、よくわからないソフトウェア開発をしていて、デスマーチなので、ぼくはこのページをうまく更新したり、誰かが読めるようにまとめたりはできない。だから適宜手を入れる、まとまりのないページになってしまったが許してね、グーグル。

ソフトウェア開発と体力

私は体力がないから、ソフトウェア開発はやめておこうと思ったんだが、今、ソフトウェア開発を仕事としている。いつの間にこうなってしまったのやら。

周りは理解していないのかもしれない。画面を見ていても目が痛くなるし吐き気がしてくる。それは仕事じゃなくてゲームしててもだけど。

使えるものなら、どんな人でも使ってしまおう、というのが会社だろう。

体力がないので、ずっと体調不良だ。

体力がある人はいいんだけど、ぼくは知力を活かそうと思った。それで生きていこうと思った。だが、知力が不足していて、ソフトウェア開発の仕事になってしまった。

体力はなぜ必要か?例えば、ソースコードのチェックだったり、調査だったり、膨大なテスト書類のチェックだったり。おっといけない、ぼくがソフトウェア開発作業を結構丸投げしているのがばれてしまう。

自分で、文書を作るものそう。

作業が膨大であれば、作業時間も長くなる。それはちゃんと見積もって作業量が抑えてあれば、よいんだけど。

残念ながら、現状ではぼくはぼろぼろだ。サバイバルが必要だ。

ソフトウェア開発サバイバル工学が必要だよ。開発プロジェクトの成功が今までのソフトウェア工学では取り扱われていた。劣悪な環境だったら自分の身を守らなければならない。

個人的なことは会社は気にしないかもしれないが、個人が倒れたり命を落とすなら、その職場は衰退していくだろう。

ソフトウェア工学は個人を守ってくれるだろうか?現状では、まだ不足だと思う。だから、今のところは自分で身を守る術が必要なんだよ。

ソフトウェア工学は空気になる

ソフトウェア工学は気にならないのがよい。

開発者はソフトウェア工学なんて気にしたくない。

でしゃばっちゃいけない。

黒子、裏方、縁の下。

空気みたいになればいい。

気にならない。それが至高のソフトウェア工学かもしれない。

開発者は素直じゃない。ソフトウェア工学の言うことなど簡単に聞くまい。

開発者にソフトウェア工学を使ってもらわなければならない。それは至難の業。

気づかれないように適用できたら。

自分を消すのがソフトウェア工学かも。

飽きっぽいぼくはソフトウェア工学にはもう飽きたかもしれない。もう少し辛抱だよ。

締め切り破りの常習犯

どうもおれはゴミ箱のように扱われている。

やりきれない細かい仕事をおれに投げてくれるプロジェクトの連中。

テストの自動化環境の評価?

おれは通信周りの開発で手一杯だよ。通信ライブラリは締切が先だが、協力者がいい加減で進まないし、部下の評価やイベントの準備で手一杯なんだよ。

ぽいぽい投げやがって。

もう限界だ。締め切りなど守れない。なんでもかんでもおれに投げてくるから。まあいいさ。マイペースでやるさ。

努力はするよ。でも、できないものはできない。

締め切りを守れないが、おれのせいじゃない。

おれの上司は、他にもやることがあるが、おれの管理は上司の責任のはずだ。おれの面倒を見切れていないが。

だからって、おれにはどうしよう無いんだ。だから、おれは悪くない。

そして、誰も助けようとしない。実はおれの抱えている締め切りは守れなくたって、どうだっていいんだよ、実際!

最初の詩

無になっていく

やる気も

趣味の時間も

風呂の時間も減っていく

興味は何だったっけ?

雑念は減らない

もちろんプロジェクトへの貢献する気もない

やめたい気持ちが30分おきにやってくる

転職したい、やめたいとか考えるのも時間の無駄

もうやめたい、ソフト開発を

疲れた

顔には無の文字

体力はもともとない

精神と体力の限界

もうやめたい、人間を

周りは何でプラス思考なの?

深夜のやりきった感はなんなの?

長時間働けばいい訳でないよ

みんないい人

悪い人はいないよ

なんでこんなに辛いの

黒幕は誰なの?

この状況で

状況が何かもわからない

計画のどこにいるのか

ぼくはどこにいるの

ぼくだけ悪人なの

このサイトは何?

よいソフトウェア工学の教科書はありますが、 現実のソフト開発がひどい状況の場合に教科書にある方法では状況を改善できなかったり自分の健康を守れなかったりします。 開発体験をしてそう思いました。 教科書には模範的な方法は書いてあるものの悲惨な状況で如何に振る舞うべきかについては何も触れられていないです。

そこでソフトウェア工学の基礎だけでは歯がたたない応用的な状況(悲惨な状況)において、 どうすればいいのか考える場がこのサイトです。

まだ課題ばかりで解決策はあまりありません。

ソフトウェア開発に銀の弾丸はない

つまり、近道はないと思われます。

ひどいソフトウェア開発の状況から抜け出す方法を少しでも探れたらこのサイトは少し役に立ったと言えましょう。

目の前症候群

疲れてくると目の前のことで精一杯になる。

まずできることをしよう。

目の前の締め切りを守ろう。次の締め切りは、危なさそうだけど、まずは目の前の締め切りを乗り切ろう。

計画を立てるのも時間がかかる。計画を立てる時間があれば、作業を始めてしまおう。

怖いから。手を動かしていないと。

できるだけ速く手を動かしていれば、最善。

できることの最大限やっていれば、役割を果たしていることになる。

それで、間に合うの?という問いはなされない。

ひとまず、やろうぜ、目の前のことを。

品質は後で上げよう。今日はつかれた。帰りたい。

問題は先延ばしされていく。

最初から無理な締め切り

いやーきついきつい

いつも締め切りに追われていて。

見積もりもする暇がないんだよ

当然日程間もわからない。

で、いつ終わるの?

これも追加で可能?って言われたら

努力します!とか。

見積もりがないから、締め切りに間に合うかわからないんだよ。 p だから、できるだけがんばります(つまり帰れないんだが

だから、開発量も適当で。間に合わなかったりする。

で、謝って、信用を失って。

なんとなく最初に締め切りを決めたじゃん。

いやーそれがだめだったのかな。できると思ったんだけど、思ったより難しかったです。とかとか。

最初に大量の見積もりとか難しいからね。面倒だからね。

でも、そこ大事じゃないかな。

人を責めてはいけない

たのしくたのしく。

人を責めるのはやめよう。

問題の追求もなされない。儲かっているからいいじゃん。

こういった雰囲気を保ったほうがいい。現状維持が実は組織の隠された意向なのでは。

改善提案は、うやむやになっていく。飲みやすい薬でなければ飲まない。

楽しい人は邪魔されたくない。

ソフトウェア開発は知的労働か?

『タレントの時代』という本に、定型知識労働と創造的知識労働に分類した知識労働。

ソフトウェア開発は手法が既知であれば、定型知識労働ではないか?

最近、退屈なんだよ。

ソフトウェア工学トリアージ

医療の現場ではトリアージという考え方があります。 どの患者を優先的に救うか、という考え方です。 重症な患者が優先です。

ソフトウェア工学がソフトウェア開発者を救うものなら誰を優先的に救えばよいでしょうか。

重症なソフトウェア開発者が優先です。重症なソフトウェア開発者とは誰でしょう?ここは意見が別れるでしょう。

不具合を出して社会に大きな影響を与えるソフトウェア開発者か? 毎日徹夜で死にそうなソフトウェア開発者か?

重症な患者は収入もよくないでしょう。グーグルのような会社では優秀なソフトウェア開発者がそれほど残業もしていない、良い状況のようなイメージがあります。実際どうかは知りません。

ソフトウェア開発者の待遇の格差は広がっていくのでしょう。良い状況のソフトウェア開発者は高収入を得てさらに開発の状況も改善できるでしょう。

よくないソフトウェア開発現場の開発者は改善もできずさらに状況が悪化していくと思われます。

残念ながらソフトウェア工学はよい環境のほうが積極的に取り入れられ格差はさらに広がっていくように思えます。

ソフトウェア工学は広い目でみれば劣悪な開発現場を先に救うべきです。トリアージはソフトウェア工学ではそれほど考えられていないと思います。

最後に、もう助からない現場は助けない。これもトリアージです。

動くかな?というソフトウェア工学

動くかな?動くと思うけどな、みたいなことはソースコードをよく知らないと起きて、 よくあまり知らないソースコードを手探りで改造しているとやっぱり品質がよくないと思うんですね。

でも実績があるソフトで、製品も売れていてその後継機のソフトを開発しなければならないと従来ソフトを改造が必要だ。

従来ソフトを作った人がいなくなっている場合もあるので上記の状況はありがちだ。

そういった疲れる状況で微妙な修正を慎重に実施するのは新規にソフトを作り上げるのが好きな人はモチベーションが上がらぬだろう。 でも仕方ないので頑張る人も必要だがそのソフトを人生をかけてソフト開発者として開発したいかはよく考えたほうがいい。

ソフトウェア開発における過労死

ソフトウェア開発技術が未熟だから長時間残業になることはある。 一般的にも長時間残業はあるのだから一般の事例とソフトウェア開発における事例は原因を分離して検討すべきである。

この考察は不十分だが一般的な考察で参考になりそうな情報をここでは挙げておく。 また検討することにする。

過労死といかに向き合うべきか(城繁幸) - BLOGOS(ブロゴス)

残業、カッコ悪い、と偉い人が言い出した時に読む話(城繁幸) - BLOGOS(ブロゴス)

スピン経済の歩き方:電通や東芝といった大企業が、「軍隊化」してしまうワケ (1/5) - ITmedia ビジネスオンライン

企業が軍隊モデルというのは興味深いな。ソフトウェア開発は軍隊モデルがいいのだろうか?

会社辞めると収入が絶たれるし、同僚など回りに迷惑がかかると考えるし、 なによりそれより、今の仕事や生活に変化が起きるというのがものすごい苦痛なんだ。 もちろん現状の過労も苦痛だが、退職するという大きな変化に対応する気力が 無くなってる状態なので、だれかが止めてくれるか、自分で気がつくかしない限り 突き進むしかないんだよ。 選ばないというより自分で選ぶことが出来ない状態にまで追い込まれてるので なんでそんなことしちゃうかな…って、そりゃ外から見ればなにやってんだって 感じだろうけどさ… 過労自殺した電通女性新入社員が労災認定される | スラド

電通、ドンキ、佐川、仁和寺・・・「ブラック企業大賞」ノミネート10社発表 - 弁護士ドットコム一位を決めることに価値はあまりないだろう。共通点を探る等のほうが良い気がする。

なぜマイルストーンに間に合わないか

例えば仕様決めが決められた期限になぜ間に合わないのでしょうか。

仕様決めが大変?精密に仕様を記載できない?仕様と設計の区別がついていない?

わかりますわかります。

よくあるあるはマイルストーンを決めたが根拠が薄弱という状況。

ろくに見積もりがない。あるいは何となく置いたマイルストーンだから守らなければならないという意識が希薄。いい加減なマイルストーンは誰も本気で守ろうとしない。

顧客も後工程に影響なければいいよとマイルストーンの直前で言い出します。

開発メンバーや顧客などステークホルダーが本気で守ろうとしない期限は守ることができません。

まず守れそうな計画をたてない。何か問題があればすぐに遅れる。そんなマイルストーンって単なる掛け声なのです。

ソフトウェア開発の遅れを残業で取り返す

深夜残業や休日出勤で取り戻そうとする。

疲れ。

頭はパープー。

早く帰りたい。

手を少し抜こう。

結果、品質が下がる。

もっと楽なソフトウェア開発

定時退社を導入するとどうなるか

働き方改革、ドイツに学ぶべき点はここだ : 深読みチャンネル : 読売新聞(YOMIURI ONLINE) 1/4

ソフトウェア開発者の給料

工事中

ソフトウェア開発デスマーチ予兆チェックリスト

ソフト開発がうまくいかないとき、開発者に大きな負荷がかかります。 そんなとき、プロジェクトには特徴があるはずです。

既にデスマーチになっていないか? これからデスマーチにならないか?

やばいパターンをまとめてみたいと思います。適宜更新。

見積もりや計画なき、ソフトウェア開発

仕様未決で、ソフトウェア開発の期限から決まる状況。あるいは逆線表。

間違いを以下の順から探してほしい。顧客からの請負開発の場合だ。

  1. 幹部やプロマネが大雑把に、開発の期限を決める。このリリース時期を逃すと、ビジネス的に億円単位の損失になる。
  2. マイルストーンを決める。マイルストーンは、成果物だったり、製品プロトタイプリリースだったり。
  3. 仕様を決める。
  4. マイルストーンを必死にクリアーする。
  5. 予想より開発量が多く、マイルストーンのどこか、あるいは、製品リリースには、間に合わない、あるいは、品質が伴わない。結局、顧客に不具合指摘され、製品リリースが間に合わない。

問題は、仕様を決める前に開発期限を決めている点だ。 仕様が決まっていくと、だんだん期限に間に合わないことがわかってくる。 しかし、プロマネは死守、あるいは、加速してくださいというだろう。((だいたい加速とは何か?))

幹部は予算達成のため、リリース時期を決める。こう言うだろう。「この計画が守れるように、プロマネくん、君が工夫しろ。できない?もっと考えろ」

下の者が意見を言いにくい雰囲気でこういうことが起きやすい。率直な意見が言えないと、デスマーチを誘発するのだ。 プロマネは自分の立場がかかっている。幹部が決めた期限に対して、できません、とは言えない。できないと言えば、あいつはネガティブだから、だめだ、と言われかねない。出世の道が閉ざされかねないよな。会社は明るく健康に!そういう建前がここでは効いている。

プロマネに開発期限を決められた部下も反論できない。人事権はその上司であるプロマネが持っているからだ。 開発途中で、開発者は間に合わないことをわかっている。 しかし、間に合わないことを言えない。計画変更を言えない。 なぜかというと、最初に反対しなかったことで、仕様未決での期限決定に知らず知らずに賛成しているも同然だからだ。 最初に異を唱えなかった時点で、仕様未決のまま期限を決めることに手を貸したことになる。だから、ますます計画見直しを言えなくなり、期限死守のための過負荷な開発を受け入れることになる。

そうやって、プロジェクト員全員が無理な計画にコミットする。結果として、命を削って、期限を守ろうとする。

こういう開発体質では、振り返りによって、開発プロセスの見直しを実施されず、次のプロジェクトでも同じ失敗を繰り返すことになる。なぜなら、最初の計画の時点で間違っていた、とは誰も言えないからだ。上司が怖いからね。

仕様決定、見積もり、期限の決定は基本的な順だが、儲かっている状況では、製品リリースの欲に目がくらんで、この順序が守られなくなる傾向がある。 「イケイケ開発」と呼びたい。結局は、開発が間に合わない。損失が出る。そして、開発者の命も削られる。

ソフトウェア開発における武士道

だめプロジェクトでだめなのわかっていながらデスマーチにつきあうのは武士道の影響もないかな。真面目がよいという考え方。あるいは儒教か。

実際おかしなプロジェクトで上司に意見を言いにくいのはなぜだろう?

まじめに考えるときに上司が悪い、上司の上司が悪い、上司の上司の上司が悪い。。 という考えになりにくい。

自省することも必要だが原因がプロジェクトの根っこからある場合もある。

そういう場合にまず自分を責めたり自分に問題がないかを探し他人の問題を検討しなかったりする傾向もあるのではないか。

ひとまず、できることから工夫しようぜ

全体の計画がないが、プラス思考だから、できることからやろうぜ。 期限に間に合わないかはわからないけどさ。いい雰囲気で進めようぜ。いい雰囲気が、開発効率を向上させるぜ。

とまあ、よくある話だ。

しかし、はっきりいって、ナメている。いい雰囲気であることは、ときには、まっとうな指摘をしにくい組織を生み出す。

いい加減でプラス思考、精密なマイナス思考。どちらをとるか。

プラス思考と楽観主義は異なる。思考しろ。プラス無思考ではだめ。

バグは精密にシステムをむしばむ。バグは精密に開発プロジェクトをむしばむ。バグは精密に開発者をむしばむ。

期限がある。計画はない。なんとかチカラを合わせて間に合わせよう

いい加減な状態で、全体の計画なく進む。目の前の期限はある。できることをやろう。 短期の計画は決められる。いずれ、担当の決めることだから、いまでも決められるのだ。全体の計画からのトップダウンを待っていてはいけない。 だから、なんとなく開発が始まる。ソフトウェア開発者同士が囁いて進んでいく。ボトムアップに提案してください。そういう人を会社は求めています!

そのとき、開発責任者は幹部と計画や利益率を相談している。仕様はまだ決まっていない。全体としてざっくり。仕様はなくても価格や期間を決めようぜ。 今までの経験があるのだ。幹部がYESといえわないと開発費ももらえないのだ。正確な見積もりは後だ。

しかし、一方で、無理な計画をうえと約束することは、部下への裏切りである。たとえ、自分の保身であっても。

売上や利益の目標ありきで、決めた無理な目標は、部下たちに無理を強いる。 無理な目標が、期限、品質、コストのどれかである。

仕様がきまり、計画が無理かなあとぼんやり思い始めたとき、すでに客と期限や価格は決まっている。整合性はなくなっている。 あとはデスマーチプロジェクトが進んでいくだけだ。

リーダーの責任のとり方。部下が残業の場合

いい人は部下より先に帰らぬ。監督責任がある。 部下に残業をさせているのも上司の責任である。

上司と部下は役割が異なる。 上司は自分の仕事が終われば帰っても良いと言えるが部下の作業を終わるを見届けるのも感情的には賛成である。

しかし結果として疲弊し役割が果たせなくなっては困る。 それよりは充実した上司が部下の残業が無くなるように努力することを部下が喜ぶ。

まず残業がないような計画を立てるられるのが良い上司だ。 無理な場合には少なくとも部下の体調、都合を考慮しなければならない。 残業は管理すべき。部下が自分で決めるというのはよくない。 管理にはコストがかかる。程度問題だが原則的には残業は命令され管理されるべきである。部下が自主的にするものではないだろう。

精神論的な運営で気合いを部下に求めるような職場やプロジェクトでは管理はされない。上司は武士道的に部下の残業に付き合うこともあるが部下はそれを望まない。先に帰るだけではなく正常な残業の少ない職場になるように努力する上司を期待する。

大企業でのソフトウェア開発

大企業でのソフトウェア・ライセンス管理と、自由と、ソフトウェア最新技術 2015/02/19

わいの会社は、管理が厳しい。ウイルスにかかったらいけないから、がちがちな、ソフトウェアインストール管理体制。

ブラウザはインターネットエクスプローラー8。つまり、IE8。結構Javascript動かないんだよな。。つまらん。

見えないのは、SlideShare、あと、ネットのプログラム処理系とか動かないよな。まあ、職務的には、必要ないけど。それに、必要なら、申請して、最新のモダンブラウザをインストール申請すればよいって?

そういうもんじゃないだろう。

新しい技術はすぐ見てみたい。申請して、上司と情報システ無部門の承認、待っている場合じゃないし。

コンパイラも自由に入れられない。そういう会社といえば、そうだろう。遅い会社だ。その、ノッソリした動きが、変な失敗を防ぐ。ゆっくり動いたほうがいいことはあるんだ。インフラ系の会社とか。

それと、Githubが見えないぜ。これはネットフィルタだ。コードを盗んだと言われないためだが、Githubだけがソースが見れるわけじゃないし、Githubでもソースじゃなくて文書もある。それに、ソースをブラウザを見たからって、訴えられたことあるのか。このあたり、会社の改善必要なところかも。

ぼくは、飽きた。新しい情報を見てみたい。

管理と、興味。これはトレードオフだ。もっとがんばれって言われるかもしれないけどね。

大企業のまあまあのソフトウェア品質

バグのないソフトウェアはない。

それは認めるとして、みんな、毎日品質向上のために、努力していますか?

僕の周りは、家に帰って、プログラムなど書かない、という。コンピュータも触りたくない。 ましてや、勉強などしないだろうね。 今のままでいい。バグはたまにでる。品質保証部は、文句をいう。ではこうします、と対策を回答。 これで、いい。ちょっとずつ、進歩していけば。

大きな企業は早く変化できない。ソフトウェアの品質を上げる勉強などしたら、健康を壊す。家に帰ったら、家事だってあるんだ。 今のままでいいんだ。少しずつ進歩していっているじゃないか。社外自己は、とりあえず社内システムに掲示しているじゃないか。誰か読んでいるか、知らないけどさ。

なんとなくマイルストーン

マイルストーンを置いて進捗をチェックする。 一見するとよいことだ。

マイルストーンがいい加減に置かれるとたちが悪い。

マイルストーンに根拠がないとそのマイルストーンは守られない。なぜ守らないといけないか不明だからだ。マイルストーンを置いたのだから守れ、というのは順番が逆。守らないと問題があるからマイルストーンを置いたのだ。

いい加減なマイルストーンはそれが守られない。守られないと後の工程への影響が不明だ。

マイルストーンでチェックするのも遅い。マイルストーンは守るものだ。マイルストーンより前にチェックする。マイルストーンの前にチェックポイントがある。

マイルストーンを守れないとき残業でリカバリーしようとするだろう。しかし深夜残業になったら作業品質は下がっていく。成果の品質が低いと品質向上が必要になり計画は遅れる。リカバリーなどできないと思ったほうが良い。

ソフト工学のコンサルタント

ソフトウェア開発のコンサルタントが手を抜くとき

医者は、お菓子が食べたくなっていました。お菓子は午後3時に医院の冷蔵庫からだしてきて、クーラーのきいた部屋で食べるのです。

医者は患者の家を訪れ、いいました。

「あなたは、目が痛いでしょう?腹が痛いでしょう。目薬と腹の薬、どちらにしますか?」

医者は知っていました。患者の2つの痛みが、実は心臓の病に原因があることを。 しかし、医者は心臓の病はすぐに治らないことを知っていました。心臓の病を治すには、手術が必要で、午後3時に医院に戻れません。

患者は、うつむいて、目薬と、腹の薬のどちらをもらうか、考えていました。 ここ数年、体全体が調子が悪いのです。

ぼくは、何も言わずに、その話を聞いていました。医者がお菓子を食べるために、患者の心臓の病に気づかないふりをするところをじっと見ていました。

ソフトウェア工学の研究

ソフトウェア工学の研究は論文を書いて採録されたり賞を取れたりすれば研究者はよしとされます。 その成果は既に適用されたか適用予定のものです。

論文が認められるかと現場が改善されたかは必ずしも一致しません。 論文が解決するのは一課題です。未だにソフトウェア工学の課題を全て解決した論文はないはずです。それは銀の弾丸と呼ばれおそらく存在しないとされています。

論文が解決した一課題でソフトウェア開発者が楽になるかは検証が必要です。 一つの課題が解決しても他の要因で改善しないかもしれません。

例えばUML適用に成功した。しかし工数見積もりがほとんどされていない場合や製品リリースの日程があらかじめ決められて間に合わせる必要がある場合開発者の負荷はあまり変わらないでしょう。UML適用によって効率は改善するかもしれませんが仕事がもっと増えるかもしれません。

ソフトウェア工学の研究者やコンサルタントとソフトウェア開発者が改善活動する場合、長期的な計画を作り改善する必要があります。

研究者が成果を挙げたといって現場が楽になっていなかったらその格差に現場は気持ちが落ち込み改善のモチベーションが下がってしまうのです。

ソフトウェア開発技術について、まじめに考えよう

テスト自動化は常にいいことだ、という風潮。あるいは、テスト自動化が常に最優先課題なわけじゃない

テスト自動化したら、回帰テストの工数が減る。というのはいい。

だけど、テストケースが漏れ漏れの現場で、テスト自動化は最優先じゃない。 テスト設計ちゃんとやろうぜ。つまり、テストケースちゃんとつくろうぜ。

テストがスカスカだったら、いくらテストぶんまわしても、バグはとれず、お客さんからクレームきて、信頼を失うか、開発期間が伸びるぜ。 テスト自動化が本当に最優先か、よく考えたまえ。きみの判断は教科書知識に基づいていないか?

リバースエンジニアリング

ソフト開発業界でいうリバースってのは、ソースコードから設計を取り出すことだ。 ふつうは設計をもとに、ソースコードを作る。 けど、設計をさぼっていると、設計がないのにソースコードがあって、読解不能になる。

そんなとき、役に立つのが、リバースエンジニアリングツールである。

Doxygenとか?

Doxygen は、C++、C、Java、Objective-C、Python、IDL (Corba、Microsoft 風)、Fortran、VHDL、PHP、C# 向けのドキュメンテーション・システムです。 D にもある程度対応しています。

ソースからドキュメントを作る、「ドキュメンテーション・システム」って言ってる。 「ドキュメンテーション・システム」って、なんだよ?とか言ってはいけない。

もしかして、会社のルールでフローチャートが必要になったら?怖いよね。 だって、数万行のコードに対して、フローチャートを何百個も作るのって、大変じゃないかな。

そんなとき、リバースエンジニアリングツールが重宝する。入力がコード、出力が設計。

これで、設計の工程はとばして、開発期間を短縮できるはずだ。そして、コードとぴったりの設計書(フローチャート)を入手することができる。設計書とコードが乖離していくのは、よくあることでかなり、困ることだ。

以下、余談だが、 Doxygenはけっして、設計を取り出すとか言っていない。これはリバースツールじゃないのか。 さらにだ。フローチャートを設計って思ってるわけじゃないよね?たしかにソースコードからフローチャートがリバースできるかもしれん。しかし、ソースコードみたほうが早くない?ここは議論が分かれるところかな。もし君がソースコードから設計をとりだしたいと思っていたとしよう。状況はかなり悪い。君の周りには、ソースコードがなぜそう書かれたか、知っている人はいない。ソースコードをみても意味はわからない。辛いのはわかるが、ソースコードのコメントに設計が書かれていない限り、ソースコードはソースコードだ。むしろ、そういう状況を防ぐ方法が必要なんじゃないのか?

ソースコードを少し読みやすく図にしてみるとか参照にジャンプするってのは少し役立つ。そういった取り組みと、ソースコードから取り出せるはずのない情報と取り出すというのは難易度が異なる。だからソースコードから情報と取り出すといえど一概には言えない。取り出せるはずのない情報を取り出せますよ、とかうまい話に騙されがちなのは実際少し役に立つ技術があるからで怪しい技術と見分けにくい特徴がある。

事例

NTTデータ、ソースコードから要件定義書を生成するシステムの開発へ | スラッシュドット・ジャパン デベロッパー

天下のNTTデータ「ソースコードから要件定義書を自動生成するわ」 : IT速報

【本末転倒】NTTデータ「コードから要件定義書を自動生成するわ」 - ブラブラブラウジング

富士通研究所がプログラムから業務仕様を抽出する技術を開発 | スラド IT

ソフトウェア開発プロセスと、内部ルール

真っ当な会社なら、開発プロセスの定義があるだろう。そのルールに則って開発する。

でも、そのルールがいくらすばらしいものであっても、守られなければ意味がない。

たとえば、設計書はちゃんと作って、レビューしましょう。それから、実装しましょう、というルールがあったとする。

でも、実際のところ、まず実装してしまって、後で品質保証部の検査のときに、設計書を実装から起こすとかやっていないだろうか。だれもルール違反には気づかないし、検査のときにはちゃんとやっているように見えるわけだ。

しかし、実装から起こされた設計書をレビューして、不備があったとしてももう実装は終わっているから、実装を直したくないという心理になり、ごまかしたりする。また、実装を直しても手戻りだ。

また時間の関係で、すべては設計書におこさなかったりする。そうするとレビューは抜ける。書かれていないものに人間は気づきにくいんだよね。

かくして、バグバグなソフトがルールを違反していないという前提のもと、作られて、開発は進んでいく。 ##可視化

可視化もリバースに似ている。いや、似てないか。

なにをみたいのか?

ソースコードを作った人に聞いてわかることは可視化の対象ではないよね。だって、聞いたら早いから。 聞けないって?だったら、状況は悪い(リバースと同じ)。

もし、わかってる人がいるなら、はやく聞けばいい。 「このコードの意味がわからないのだが、どういう意味?」とか。

聞けないなら、きみは恥ずかしがりやか、大企業病の組織の壁とかだろう。

いったい何がみえないんだ? ソースコードがそこにあるじゃないか?

ソースコードを作った人も知らない情報だけが可視化の対象とするなら、 なにを可視化すればいいんだろうか?

探索型テスト

これは今までのとはちょっと違う。

これは苦肉の策。

テストは全部したいけど、できないし、早く帰りたいから(じゃなくて、締め切りがあるから?)、怪しいところを重点的にテストします。許して!ってやつ。

バグのないソフトはない、ってのは本当かもしれん。

だけど、気持ち悪いよね。探索して、バグが見つからない場合だってあるし、全部とるのは諦めているわけだ。

バグが許されない業界ってあるかもしれないが、そういう業界では探索型なんて言ってはいけない。

バグはやっぱり存在するんだろうな。だから、バグは許されないってのが嘘なのかも。

ソフトウェア工学は永遠です

ソフトウェア工学に終わりはあるのか?

QCD、つまり、品質、コスト、デリバリー(納期)を改善するのが、ソフトウェア工学ならば、終わりはあるのか?

まあ、明確なゴール指標はないよな。

品質だったら、バグ0が実現できたら、完了だろう。でも、それは難しいことだ。 コストだったら、コスト0円?それに近づいていく間に人間の一生が先に尽きる。 デリバリーなら、注文した日の夕方、ソフトができる?これはいいね、プログラマも早く家に帰れる。

現代は、競争社会です。競合他社より、QCDが勝ることが大事なのです。競争に終わりはあるでしょうか?競争がある限り、他社より、QCDをあげなきゃならないかも。(まあ、そうじゃないかもしれないけど。)ソフトウェア工学も終わらないはずです。

向上心、あるいは、欲がある限り、ソフトウェア工学はなくなることはないでしょう。ああ、安心した。

納期を守ろうとする(上司の?)せいで、残業、ひどいと徹夜になったりする。だれがそんなこと望んだのか?

ソフトウェア工学は、実は欲に関する学問ではないか?

田舎のソフトウェア工学

田舎のソフトウェア工学(1)

田舎に工場がある。そこでは組み込み機器を作っている。昔はソフトは小さかった。機械屋が片手間にソフトを書いた。ドキュメントなど不要だった。メカ屋は開発が終わると家に帰り、家族と団欒し、休みの日は農作業をした。

最近、ソフトの規模が大きくなった。片手間でできなくなった。地元からソフト専門の開発者が採用された。ソフトはスパゲッティ化している。みんな早く帰れなくなった。

デスマーチが終わり、開発が一区切りつくと、開発者は家に帰る。土日には農作業ができる。

開発が終わると、プロジェクトで反省会が開かれた。バグはどうしておきたか。ドキュメントはどこが足りなかったか。反省会の結果、開発に関する規則が追加されていった。作るドキュメントが定義された。

開発が終わるたびに、失敗を繰り返さないため、規則やドキュメントが増えていった。

かくして、緩やかに田舎の工場では、ソフト開発が進化していく。

田舎のソフトウェア工学(2)

田舎のプログラマは、新しい技術、たとえば、プログラミング言語、検証技術、等を勉強する気持ちが少ない。勉強会なんてほとんどないし、みんな仕事を終えたらすぐに家に帰る。

それは、畑のことが気にになるからかもしれない。うそ。ほんとは、たぶんプログラミングに興味がないけど、食べるために仕事しているからだ。やっぱり田舎の工場だと、ハードがまずあって、ソフトは添え物だった。その流れで、ソフトは重視されていない面がある。また、都会のソフト会社だったら、ソフトしかないから、もちろんソフトが話題になる。また、ソフト会社だったら、ソフト好きが集まる。ソフトが勝負だからソフト重視だ。組み込みだと、システムが商品だ。システムの完成度が問題だ。

それと、田舎の工場だと、その地方出身者が多い。そこで育って、そこで生きている。会社をそんなに選んでない。ソフト好きは、都会に行く。そこに仕事があって、たまたまソフト開発の仕事があったんだ。そこにソフトの仕事があって、プログラミングをした。それで十分じゃないか。土日はゴルフに行く。

都会の出身者からみると、それでは物足りない。かくして、ソフト好きは都会に集まる。だから、格差はどんどん広がっていく。

でも、ネットの普及で興味をもってるやつは田舎でも育つ時代が来る。だから、状況はかわるかもしれない。ほんとはプログラミングに興味はある。だけど、今は情報が入ってきていないだけだ。

これは音楽に似ている。音楽の最先端はいつも都会にあった。

しかし、地球規模でみたら、どうだろう。Linuxはフィンランドから。USだって都会だけではないだろう。

音楽だって、その土地の音楽がある。

Rubyは島根か。田舎にはカリスマが必要なのかもしれない。

田舎のソフトウェア工学(3)

田舎の工場は、ある規模だと、その周辺は城下町とか言われて、殿様気分。 同業のライバルは工場の近くにはいないことが多い。 だから、ライバルの動向がわかりづらい。

また他業種の工場もないことが多い。

結果、井の中の蛙になる。だから、技術の勉強をするやつは少ない。 かくして、田舎の工場のソフト開発は進歩しないのである。

田舎のソフトウェア工学(4)

田舎の人は血気盛んである。あるいは、感情的である。 教育というのは、怒りである。感情で訴える。 こう強く言っているのは、君のためである、というセリフ。

そういわれても、言われている方は気持ちが沈んでいく。

もちろん、都会でも感情的な職場はあるだろう。 でも、それは都会のなかの田舎なのである。

逆に、田舎にも都会はあるのかもしれないが、経験上、田舎には都会はない。 強めの言葉づかいと、強い酒があるのである。

田舎のソフトウェア工学(5)、あるいは、教育、学歴

田舎には、有名大学を卒業している開発者はそういない。差別?先入観?そうかもしれないな。

まあ、ぼくのまわりはそうなんだ。

すると、知識が少なかったりする。プログラミング言語はC言語しか知らないとか。そうすると、それで満足な人生になる。ベストを尽くしている。 ぼちぼちの人生になる。

ソフトは会社で言われたものを作る。せいぜいだ。

教育は、こういう世界もあるよ、と教える。そのときわからなくてもいい。

会社に入った後、知識があれば、思い出す。会社にないものも思い出す。 ネットのニュースを見ていれば、思い出す。新しいニュースと過去の知識(ぼんやりとした、理解の足りない記憶)が出会う。

会社で言われたことだけじゃないこともしよう、と思う。 それが教育の力だ。

教育がないと、簡単に満足してしまう。

さあ、ぼくはどうしよう。田舎でも学ぼう。隣の人に声をかけよう。

ソフトウェア工学と派遣労働

ソフトウェア工学と派遣労働(1)

うちのグループには、派遣さんが正社員より少し同じくらいいる。 正社員のリーダーは、遅くきて早く帰る。遅く来るのは家庭の事情。早く帰るのは知らんが、ポリシーとして、あまり仕事をするといっぱいいっぱいになって、うまく回せなくなるからだという。つまり、自分はまとめ役なので、仕事をしすぎることなく、周りや派遣社員がうまく働けるようにするため、自分が働きすぎるといけない、というようなことを言っていた。だから、派遣さんが遅く残業していても、手伝いはせず、「かえってね」、っていいながら、自分は帰っていく。要は、仕事の種類が違って、自分が働きすぎると、派遣さんがうまく働けなくなるから、先に帰らせてもらいます、ということだ。

自分なら、手伝ってしまい、一緒に残業するだろう。だが、それはよくないと。あくまで、まとめ役は、まとめがうまくいくように、働きすぎてはいけないのだ。論理的にはそうだ。

ただし、派遣さんはちょっと不満に思っているらしい。給料は正社員のほうが高いが、早く帰るという現象をみれば、不公平だと感じるだろう。

ソフトウェア工学と派遣労働(2)

派遣者を使ってソフト開発するメリットは、人員調整が可能なことだ。仕事が多いときには派遣者を増やし、少ないときには派遣者を減らすことができる。

派遣者を使ってソフト開発するデメリットは、いろいろある。

安かろう悪かろうのソフトにならなきゃいいけど。

ソフトウェア工学と派遣労働(3)

正社員より派遣プログラマが待遇が悪い場合、不公平感からモラルハザードが起きる可能性がある。やる気が減るかも。減るどころか、怒りみたいなものがたまっていく。

プログラマがやる気を失うと、何が起こるか。効率が下がり、さらに、品質も下がるだろう。

派遣プログラマを使うのが、コストダウンが目的として、その結果、バグが発生したら、リカバリーするためのコストがかかる。

また派遣プログラマがいなくなったら、プログラムを理解している人がいなくなるなんてことはないだろうか。

そういったリスクを考えたうえで、派遣プログラマを使うか、それとも、正社員がコーディングするか、検討したほうがいい。本当に派遣プログラマを使うのが、コスト安になるのだろうか。

ソフトウェア工学と派遣労働(4)

まじめな派遣労働者がいる。 失敗はなるべくしない。なるべく派遣先の社員の判断を仰ぐ。 それが確実な方法だ。

社員は何でも聞かれるな、と面倒くさい。 もっと自分で判断してくれ、と思う。

確実にやろうとすると、コミュニケーションコストが増える。 まじめな派遣労働者プログラマほど、それにハマる。 派遣プログラマは難しい。

大企業のソフトウェア工学(ふたたび)

コーディングから離れてラピュタは生きられないんだわ!

おっさんが、コーディングもせずに、理想論ばかり語る。 おっさんが、部下が深夜まで残業しているのに、早く帰って、しかも、残業を承認せず、効率化しない方が悪い!だと。 おっさんが、全体のことを考えずに、適当な仕事の仕方で、できる範囲のことしかしない。もっとやるべきことがあるのに、出口の不明な仕事をしている。 おっさんが教科書的な問題をでっちあげて、意味があると言っている。

そう、これは愚痴ですよ。

大企業で定年前の男が、やたら報告書の完成度を求める

ソフト開発はやらせられない男だ。文書にこだわる。 やたら。。。

もうこの世の人でないのだ。ソフト開発の人ではない。

時間があるので、やたらチェックが細かい。そういう人はこちらの別作業も知らず、完璧を求める。 適当にやり過ごそう。あるいは、排除しよう。でも、どうやって?

大企業にはこういった人が一定数いるだろう。 それがやだったら、どっか行くしかないな。やだな。

チェックリストという魔法の杖

不具合がでたら、チェックリストに加えるとする。たとえば、0割がないか、とか、メモリは開放したか、とか、再帰関数はないか(再帰だめ?)、とか。このチェックリストはこれまでの反省の積み重ねで、これを使ってチェックすれば従来の不具合は繰り返さない、魔法のリストになる。

チェック項目は20、30と増え続ける。OS依存のもの、GUI依存のもの。

だんだん魔法の杖は太くなり、ずっしりと重くなってくる。魔法の杖をふるのに、開発者は疲れてくる。そして、その魔法の杖が効果がない魔物が現れたとき、開発者にはもう体力が残っていないのである。

組込みソフト開発におけるソフトウェア工学

メカ設計者とのプロジェクトにおけるマルチタスクの罠

メカ設計者との共同作業では、当然メカとソフトの両方を取り込んだプロジェクト計画が必要だ。 まずそこが第一のハードル。

計画はOKだとしよう。

メカ開発とソフト開発が並行な場合、ハマりやすい罠がある。 一つはマルチタスク作業が発生しやすいということだ。

メカを試験動作するためにソフトが必要なため、動作用ソフトを作ってくれと要望が来る。 すると、本筋の仕様策定や設計と、ひとまず動くソフト(ある意味、やっつけのソフト)の実装が並行作業になる。 この作業がスケジュールに組まれていないと、本筋の仕様策定や設計が、メカへのソフト提供によって、圧迫されて、仕様策定がおろそかになり、もちろん品質低下に繋がる。 品質低下したソフトは、テストあるいは製品出荷後に不具合が見つかり、製品開発としては遅延するわけだ。

だから、計画はOKか?と聞かれたら、よく考えて答えなければならない。

メカ開発が遅れているので、ソフトウェア開発者の遅れが隠される

メカ開発はよく知らないが、ソフト開発はほぼ作業だ。工夫といっても、それほどチャレンジングでないと思う。 本当はメカとソフトでシステム仕様にチャレンジするわけだが、ソフトは作業な感じで、チャレンジでないことも多い。

メカが苦労するので、それがソフトにも影響する。一つは、メカ向けの動作ソフト提供だ。 またソフトがメカ仕様を待つことも多いので、メカとソフトを統合した計画が必要だ。

さっきも言ったとおり、メカはチャレンジングなことが多いので(思い込みかもしれないが)、 メカの開発は遅れる。それをソフトが待つことが多い。

ソフトがメカの開発を待つと、ソフトの遅延はある程度、隠されることになる。 結果として、ソフトの失敗が表面化せず、下手をすると、ソフトは計画通りでした、みたいなことになる。

実際は、遅れるから、深夜作業や徹夜も起こっているかもしれない。 あるいは、不具合が多くても、メカの修正と同時に修正されるため、目立たない。

かくして、メカとソフト開発の並行作業は、問題が起きても目立たないことによって、反省されることはないのである。

ソフトウェア開発者の報酬

ソフトウェア開発者の報酬は開発している装置の価値と簡単に比例する訳ではありません。 大企業では役職に応じて報酬が決まるためせいぜいボーナスが影響を受けるだけです。

ベンチャー企業では大企業に比べて開発するソフトウェアの価値が報酬に反映されるでしょう。

大企業ではソフトウェアの改造の仕事が多いです。最初からソフトウェアを開発するという仕事は数年に一度のこともあります。あとはバージョンアップやバグ対応です。そういった仕事の評価が正しくされると良いのですが0からのソフトウェアアーキテクチャ構築のような仕事が大きく評価されることが多いように思います。華やかですから。改造には改造の大変さがあります。元々のプログラムを理解するのは大変な仕事です。

日本は欧米に比べソフトウェア開発者の報酬が低いとされています。東大や京大卒のような高学歴者が少ないのはソフトウェア開発が大変なわりに報酬が低い事実も一因でしょう。

だからソフトウェア品質も悪くなる(これは決めつけですが)ので大変になって優秀な人が寄り付かなくなってさらに品質も悪くなる。負のスパイラルが動き続ける。

怪しいソフトウェア開発技術

ソフトウェア工学レベル、あるいは、ソフトウェア開発レベル

なんというか、やっぱりソフトウェア開発のレベルってある気がする。 とりあえず、あとで見直す。CMMIとか参考にあとでする。

レベル0

レベル1

レベル2

レベル3

レベル4

メトリクス

メトリクスはなんだか数値化することだよね。このソースコードはよくない、かもしれない、と言ってくれるかもしれない。

でも、悪いとは言い切れない。ものすごく数値は悪くても、必ずしも悪い設計とは言い切れないこともある。

よく考えたソースコードや設計を、数値が悪いからだめ、とか言われたら、腹が立つよね。

そして、メトリクスはこのソースコードはいいね!とは言ってくれない。メトリクスに審美眼はない。

メトリクスさん「いいかも、だけど、言い切れない。悪いかも、でも、ちょっと自信なんだよ」

はっきりしないな、おまえ!

レビュー

だれかがくだらないバグを作りこむのを防ぐんだ、みんなでレビューしてね。

しかし、全部はレビューできないってのが本当のところか。

そんな時間あったら、そいつに作らせずに、レビュアが作ったほうが早いってのは気のせいか。

全部はレビューしきれないとすると、まあバグは残るかもしれんのだ。

モデリング

「設計」のおしゃれな別名

コード自動生成

プログラミングを外注すること。

ソースコードを自動生成するソフトウェアもあることから、人間がちゃんとプログラミングをしているのか、確認できるようにする方法がソフトウェア工学のひとつの問題になっている。

CMMI

よくしらないけど、メモ。

CMMIってわかりづらい。学者の人が考えた感じで、プログラマが理解しやすいように書いていないよな、これ。

各レベルについて、思ったことをメモ。

レベル1「初期」 Wikipediaより引用。

成熟度レベル1の組織は、超過労働、危機に対処するプロセスの欠如、過去の成功を繰り返す能力の欠如、によって特徴づけられる。 レベル1の組織が遂行するプロジェクトの成功は、高い能力をもつ個人に依存している。

うちの会社は、レベル1だな、残業してるし。ソフトウェア工学の特徴は、個人能力への依存の排除を目的とすること。しかし、設計するのも実装するのも個人だ。ソフトウェアでは、職人は存在しないというのか?そんなことはないだろう。個人能力に依存するなら、個人能力を伸ばすことに目標を持つべきだ。能力の底上げと言ってくれれば理解できるけど。

レベル2は「管理された」

基本的なプロジェクト管理プロセスが確立し、費用、予定、開発対象の機能を管理する。 レベル2のプロセスの最低限の規律は、過去の類似した分野と範囲をもつプロジェクトの成功を、反復することである。

とあるが、「過去の類似した分野と範囲をもつプロジェクト」なんて存在するのだろうか?むかしと同じような製品をだす、ってことかい?

レベル4は「定量的に管理された」とあるが、その定量化の方法は研究段階ではないか?

どうもCMMIってあやしいよな、つまり実用に耐えるか、って話。

ソフトウェア工学の研究者はいかにも、自分の研究は有用だ、と主張するし、そうなるのは仕方がない。だけど、使えるかどうかはよく考えないと。

参考:

能力成熟度モデル統合 - Wikipedia

CMMIって何だろう - CMMIって何だろう:ITpro

ソフトウェア工学は科学か?、あるいは、ソフトウェア開発に科学は必要か?

科学とはなにか知らないが、まあ、技術だとしよう。(てきとー

ソフトウェア開発は、よく技術論から離れがちだ。 開発にこの人がほしい、あの人は仕事(残業)をしない。 こういう人間関係的な話になりがちだ。

それも現実であり、克服すべきものだ。

しかし、昔、目指していた未来とは違う。技術を活かして、エレガントに生きようと理想があった。 それがいつしか、泥臭い世界へ。

必要な技術が違うとも言える。

しかし、そうじゃないと言いたい。

泥臭い世界でも、輝く宝石を見つけたい。それは欲というものだ。知識欲。あるいは、美学。 そんな理想もあった。たまには、理想論に戻る。そんな時間が必要だ。

ドロの中でもがくだけでは、人生終わりたくないのだ。

モデル検査と適用行数

今回、検査支援ツールを開発することで、これまでに論文等で報告されている形式手法の適用範囲に比べ、約10倍規模となる量産ソフトウェア(350kLLOC*1 )に適用できることを実証しました。

とある。

形式手法を用いた自動車制御ソフトウェアの高信頼検査技術を開発 従来比で10倍規模の量産ソフトウェアに適用

また。

ソースコードから設計者が検査したい点に関係する部分だけを抽出し、計算機が調べる必要のある検査モデルの状態数を削減します。ソースコードにおける変数のつながり(依存関係)を解析し、検査したい部分だけを高精度に絞り込むことで、近年の大規模な自動車制御ソフトウェアに対しても適用可能としました。

同上。

「ソースコードから設計者が検査したい点に関係する部分だけを抽出し」たのだから、それで何行になったかを示すべきだ。

もともと大規模なソースコードでもスライシングしてソースコードが小さくなったのなら、まあ、モデル検査できるよね。。。

もっと言うと、スライシングしていいってことは、もう調べる性質が決まっていたということなので、かなり特殊な状況かと考えられます。

実験環境が詳しく説明されていない例。。。

ソフトウェアプロダクトライン(SPL)

ある製品Aを作りました。そのソフトを部品ということにして、これから再利用していきます。そのソフトをよく理解していない人が製品B向けに改造して、バグリました。さらに製品C、製品Dがやってきて。。。

ソフト部品とか、ソフト資産とか、なにをもってそう呼べるか。

単なる製品のソースコードでは、そう呼べない。

ソフトウェア工学的改善と残業

開発がうまくいかず、あるいは、残業込みの計画になっていて(笑)、残業しているとき、ソフト開発の仕方は変わらない。みんな仕事終わったら、即帰りたいはずだ。これはモチベーションが低い職場だからかもしれないが、深夜まで開発して、改善について考えるだろうか。早くうちに帰りたいから、改善なんかしない。そして、他人なんか手伝わない。それが普通だと思う。

だから、残業している間は、開発の仕方は改善しません、ふつう。不満を言うだけで、改善策まで行かない。残業してて改善しないから、残業が続く。この状況を打開するところが、知恵の使いどころで、だいたいデスマな職場はずっとそのままで、ボトムアップは期待しちゃいけないと思う。

必死にやってるのに、「そんなに苦労しているのに、改善策考えていないの?」とか上司に言われたとき、キレそうになった話。

ソフトウェア工学に期待すること

ソフトウェア開発は基本的なことができればよいか?

同僚が言った。「ソフトなんて、設計書かいて、実装して、普通にテストすればいいんだよ」

たしかにそうだ。

でも、並行プログラムとか難しいよね。普通にテストってのも、簡単じゃない。 並行性はなくても、テストも期間内に全部できるだろうか?全部のテストって何?って問題もある。 最初にもいったけど、ソフト開発は競争の面もある。自分たちが満足したからって終わらない。

ソフト開発の課題はまだ未解決の問題が多い。いまある基本だけでは終わらない。

ソフトウェアは人である

ソフトウェアは作る人が大事である。なぜなら、ソフトウェアは人が作るからである。しっかりした人がしっかりしたソフトウェアを作る。と田舎の工場で聞いたとき、ぼくはなんだかいやな予感がした。

学生のプログラミング vs 仕事のプログラミング

学生の場合、

  1. 仕様は自由
  2. 自分が書いた意味不明なコードをいじったり
  3. 締め切りはとくになく
  4. 品質は適当

仕事の場合、

  1. 仕様は決まってます。それを実装しろ。
  2. 他人が書いた意味不明なコードをいじったり
  3. 無理な日程で
  4. バグがあってはいけない。バグ0は無理と知りつつも

仕事は厳しいよ

ソフトウェア工学で一番大事なこと

ソフトウェア工学で重要なのは、教育である

で、なにを、いつ、誰に教育する? こんなにひどいデスマーチの状況で。

ソフトウェア工学で重要なのは、優秀な人を集めることか?

結局、才能のない人にソフトウェアを開発させるより、才能がある人に開発させたほうがいい。というかもしれないが、才能とは何か?という疑問がある。

ある時刻に、開発力が優れた人がいるとする。開発力とは、知識、経験、思考力等があり、実際ソフトウェア開発を成功させるチカラだろう。

才能は、天賦の才を指す。ここでは、優秀かどうかは、才能でなく、開発力を指すことにしよう。

日本のソフトウェア開発者は、アメリカのソフトウェア開発者より、劣っているだろうか?Google、Amazon、Facebookの開発者と比較すればよいだろうが、才能面は不明だろう。開発力は劣っている。と思うかもしれないが、そもそも開発しているソフトウェアが異なるので、比較することはできない。

優秀な人材は集めるのは重要だ。

しかし、重要な人材がいない場合に、ソフトウェア工学は存在しないか? そんなことはないだろう。ひどい人材しかいない状況が現実なら、それに立ち向かうのも現実だ。しかし、立ち向かわないのも一つの方法だ。ならば、優秀な人材がいない場合、開発を止める、あるいは、優秀な人材が集まってから開発するのも一つのソフトウェア工学の方法ではないか?

ソフトウェア工学の方法の適用の秘訣

簡単な方法なんて無いよ。

新しいソフトウェア工学の方法があったとしよう。それは、余裕のない開発プロジェクトあるいは開発グループに適用するんだよ。困っていない人たちは後回しでいい。まず困っている人を助けるのが人の道だ。

余裕がないから、新しいことを勉強するのは厳しい。期間がないんだ。そんな状況で、改善する。そうするにはどうしたらいいんだい?

設計書の書き方をもっと手厚くすればいい、とか提案するかもしれない。UMLを使ってみようとか、集合論を使うんだ、とかね。でも、余裕がない。なんで新しい方法を試さなきゃいけないんだい?期限に間に合わない(あるいは、残業が増える)。

短期的に見れば無理に思える。損に思える。そんな方法を使ってもらうのが一番むずかしいんだ。その気にさせるのが難しいんだ。苦い薬なんだ、ソフトウェア工学は。苦い薬を飲ませるのは簡単な仕事じゃない。それを考えるソフトウェア工学は、困難な仕事のはずだ。

ソフトウェア開発のモチベーション

ソフトウェア開発のモチベーションは、開発したソフトウェアが誰かの役に立つ、ということだろう。 それは、遠く離れた人でもいい。近くの愛する人でもいい。

ソフトウェア開発をして、給料をもらって、食べていけるだけでは寂しい。 ソフトウェア開発で、たくさん残業して、残業代をもらっても、そんなにうれしくない。

誰かの役に立つこと。

ビジネスに勝つための開発も、それほどうれしくない。 この世界に既に存在するようなソフトウェアを作ったら、それは2重開発であり、車輪の再発明と呼ばれる。 それが、ビジネスのためでも、あまり、開発したくない。 会社が潤うためだけでは寂しい。会社を超えて地球規模で考えたら、それは2重開発だ。

どうせなら、まだこの世界に存在しないソフトウェアを開発したいものだ。 新しいソフトウェアは、この世界の未解決の問題を解決する。

さて。

どんな未解決な問題を、わたしは、どんなソフトウェアで、解決するだろうか? どんな未解決な問題を、あなたは、どんなソフトウェアで、解決するだろうか?

楽しみだ。

ソフトウェア工学の教科書

一冊、挙げるとすれば、ソフトウェア工学の教科書は、『ソフトウェア工学の基礎』がよい。

このサイトでは、現実的な問題を挙げた。 それらの問題は、ソフトウェア工学の基本から外れてしまって起きる。 開発者本人が、知らず知らずのうちに基本から外れるから難しい。

ソフトウェア開発の状況を改善するには、基本を身につけ、 現状の問題点を解決していくほかない。

おことわり

このページはフィクションの冗談です。

しかし、なんだか全部、プログラマがいけていない、あるいは、組織がいけていないから考えられた苦肉の策(あるいは、研究費のためのネタ)に見えてきたぞ。

ソフトウェア工学には、後手と先手がある。 ここに挙げた技術の多くは後手のソフトウェア工学って言っていいかもしれない。

後手とは、すでに悪くなった状況を緩和するソフトウェア工学だ。だれでも溺れれば、藁でもつかむ。

後手を悪く言うのは簡単だ。 先手のソフトウェア工学に興味がある。

なかなかソフトウェア工学はむずかしい。

まとまらないメモ書き

2017-05-26(金) 00:48:37 いい加減な設計書が送られてきた。プロトタイプ先行、で、あとのドキュメントだから、手を抜いたのか。 まあ、能力かもしれないが、明らかによくわからない。埋め草?

コードステップで測っているようでは、設計品質など上がるまい。

物量主義の弊害。物量とは、知力を測ることを諦めている。設計の努力を敬っていない。まあ、そのような難易度のソフトウェア開発であるのかな。

進め方も問題がある。ヘボい設計書がきたが、既に体力がない。直せるだろうか。

へぼい設計書は負債である。

メンテナンスも困難、新参者の参考にもなりづらい。

なめられたか。既に負債だ。これに立ち向かうか。正念場である。

そういえば、文章を書くのが苦手なのかも?プログラムはいいけど、文章はだめ。コミュニケーション能力の問題かな。

それなら、苦手を理解して、やってもらわなければな。。。まだまだこういうリスク管理、上達せねばな。