もなかアイスの試食品

「とりあえずやってみたい」そんな気持ちが先走りすぎて挫折が多い私のメモ書きみたいなものです.

ソフトウェア開発の「流用できる」には気を付けよう

はじめに

私がIT業界に就職して3年ほど経った(正確には10月入社のため、3年と半年ぐらいか)

最近炎上プロジェクトに関わったおかげで、悟りが開けた気がする。

(未だに、この炎上プロジェクトが終わる気配が無いが・・・白目)

話をタイトルに合わせて、ソフトウェアの流用について

炎上プロジェクトの初期で、ソフトウェアの流用について色々揉めたことがあった。

全く関係の無い会社が作った画面仕様(当然思想も違う)で、設計もされていない・DBテーブルも違うのに、過去に作ったアプリを「流用しろ」という無茶振り

今回はお世話になっている会社の担当者が代わった、ということもあり色々あった(;´Д`)

また炎上プロジェクトの前には、「流用できる詐欺プロジェクト」もあった。(勝手に私が名前を付けた)

そんなことがあったので、流用できる詐欺プロジェクトのソフトウェアの流用で起きた問題について、若干愚痴みたいな内容を書こうと思う。

炎上プロジェクトについては、流用以外の問題、要件定義やらプロジェクトマネジメント的な部分が非常にカオス・・・

ブログに書いているうちに病気になりそうなレベルなので、またの機会に書こう・・・。

「流用できる」詐欺プロジェクトで起きた問題

関連していたプロジェクトの担当者が代わり、プロジェクトをよく知っている人がいなくなった状態でスタートした。

前の担当者に何回か問い合わせて、何度も「流用できる」と言われていたのだと思う。

「流用できる」と言っている人は、変更点を想像できるから言っている。

しかし、私も含めて「流用できる」と聞いた人は、データの変更(ソースコードの変更はほぼ無し)と 考えてしまう。

そのため、以下の様なことが起きた

  1. 設計するべき人が設計しなくなる
  2. 機能の洗い出しが疎かになる
  3. 過去の仕様を知らない
  4. 変えてはマズかった(?)仕様を平気で変える

1、2、3について、

Aさん「これ、バグだよね?」
私「え・・・?ソースコード変更してないですし、『流用』ですよね?」
Aさん「いや・・・この機能・・・要らないじゃないの?」
私「・・・・・今回は、どうするんですか?」

みたいなことが多々あった。

しかも、過去の仕様書やら設計書に無い機能でゴザル\(^o^)/

4は、DBテーブルのマスタのリレーションが変わったことがあった。

変わった時に気づいた時は、特に疑問に思わなかったが、ソースコードの変更量が偉いことになった・・・

寝るときにうなされたのはいい思い出

今思えば、「作業量を考慮して変えるべきではなかった仕様・設計」だったのだろう

結論として、プログラマの立場の私の場合、「流用できなかった」と感じた。

「流用できなかった」と感じる理由は、何を流用して、何を変更するかを意思決定する人が居らず、 仕様レベルの不具合が多く発生したからだ思う。

単に言葉選びの問題かも

ちゃんと設計している場合、本来なら「流用する」か「流用しない」かの2択

「流用できる」は、真剣に考えていない時に出てくる言葉じゃないかと思うようになった。

「流用できる」という言葉には気をつけよう・・・

ちなみにTech総研で「流用できる」について記事を見つけた時は大笑いしたのと同時に、すごく悲しくなった(´・ω・)

next.rikunabi.com