ソフトウェア会社の開発について

質問

ソフトウェア会社の開発について

現在転職すべきか迷っているのですが、現在所属している会社での開発が他の会社と比べて適正なのかどうか判断材料のひとつとできればと考えています。

現在の会社は、web系なので主にPHPでの開発が中心ですが、上司がクラスの定義方法がわからないためオブジェクト指向開発？ではなく、毎回必要な処理を関数として一から定義しています。

設計は基本的に上司の頭の中で行われ、とっても曖昧な表現のメールで指示が飛んできて、即実装となります。開発規模はあまり大きなものはありませんが、ドキュメントは不要ということらしく作られることはありません。後から作られる場合がたまにある程度です。

テスト計画は存在せず、適当に個人まかせです。

去年の春、私はこの道にまったくの初心者として入り、情報処理の学習を進めてきましたが、一年たった現在、会社の開発方針がおかしいのでは？と思ったので、上司に意見したのですが、一向に変化する気配はありません。

私はまだまだ経験が浅いため、他の会社でのソフトウェア開発がどのような状態なのかを知りません。

私自身の開発経験の少なさもあると思いますが、残業が非常に多く、私の能力とは別の次元の問題が混在しているのではと考えています。
上司の技術も陳腐化しているのでは？などと考える時もありますし、それらすべてを含めてすべて私の能力が原因として片付けられているとしたら、今後の会社の成長も見込めないので、見切りをつけて職場を変えるべきだと考えています。

実際にはどうなのでしょうか。上記のような開発体制も適正と呼べるのでしょうか。
情報処理の学習で学んだこととは別のことをしているような気がしてなりません。

アドバイスいただけないでしょうか。
よろしくお願いいたします。

回答No.3

lv4u · ベストアンサー

>>実際にはどうなのでしょうか。上記のような開発体制も適正と呼べるのでしょうか。

例えば、ソフト開発ではないですけど、橋を作るとき、４０ｃｍの幅の丸木橋を作るとか、日曜大工でちいさな犬小屋をつくるっていうレベルなら、「適切な設計」「適切な作成手順」なんて不要で、個人の頭の中だけで考えてＯＫだと思います。

でも、１０ｍ幅の川を渡る橋の作成とか、戸立ての家をつくるとなると、きちんと設計や体制を整えないと、さまざまな問題が発生すると思います。

そして、質問者さんのケースでは、上司が部下に（あいまいな）指示を出して、開発が進んでいるようですので、４０ｃｍ幅の丸木橋を作るレベルではないと思います。そして、まともな開発体制とは、とうてい言えないでしょう。

>>情報処理の学習で学んだこととは別のことをしているような気がしてなりません。

そのとおりでしょうね。で、その結果が「残業が非常に多くなる」ということだと思います。日経コンピュータ等を見ていますと、きちんとした体制で、開発している会社は、定時で帰っているようです。

>>上司に意見したのですが、一向に変化する気配はありません。

まあ、それが普通でしょうね。もし質問者さんの意見を取り入れたら、上司の仕事が現在よりも難しい仕事になると思われます。つまり、開発上流の仕事が大変になるということです。
現在は、上流工程ですべきことを、下流工程に押し付けているってことだと思います。

まあ、これって「仕事の分担をどこにするか？」という話にもなるわけですけどね。最近、私は渡辺幸三さんという方のサイトで開発手法の話を読んでいたのですが、「うーん、今までは、上流工程の人たちは、難しい部分を下流に押し付けて（楽して）いたのかな？」と思ったりしました。

>>それらすべてを含めてすべて私の能力が原因として片付けられているとしたら、今後の会社の成長も見込めないので、見切りをつけて職場を変えるべきだと考えています。

とりあえず、考え方は２つあると思います。

１）「俺が、この会社の開発部門のトップになって、デタラメな開発体制をまともにしてやるぞ！」と考えて、その日にむけて色々と作戦を練ったり、開発部のトップになったときを想定して、今の会社で働きながらも、管理者として必要なことを書籍やセミナーで学んでゆく。

２）この会社を改革する労力と、その見返りを秤にかけて、さっさとまともと思える会社に転職する。

どちらがいいか、私にはなんとも判断つきがたいですが、さしあたっては、「勝手連」的に、上司の指示があったとき、必要と思えるドキュメントを作りあげてから製造に入ったほうがいいと思います。そのドキュメントの作成に、それなりの時間がとられるでしょうが、いろんな問題点が浮かび上がってくると思います。そのとき「これってどうしましょう？」と上司に相談するほうが、トータルの製造時間は短くなると思いますよ。

ちなみに、「オブジェクト指向開発でやればソフト開発は短時間でバグが少ないシステムができあがる」と思ってしまいますが、現実には、そうでないことも多いみたいです。

お礼

ご回答ありがとうございます。

>　４０ｃｍの幅の丸木橋を作るとか、日曜大工でちいさな犬小屋をつくるっていうレベルなら、「適切な設計」「適切な作成手順」なんて不要で、個人の頭の中だけで考えてＯＫだと思います。

それもそうですよね。
最初はそんな感じで開発が始まったみたいですが、もうかれこれ2年程ずるずると拡張が続けられてる状態のようです。取ってつけたような拡張が頻繁に行われています。

>　「仕事の分担をどこにするか？」という話にもなるわけですけどね
成果が出やすい役割分担ができれてばいいんですけどね。
現状では、上司が上流工程の作業をする時間が取れないのも事実なんですよね…。
正直今の状態じゃ無理だと思います。ってことで話が流れちゃうところが多いのかな？

分掌とでもいうんですかね？に問題があるような気もするんですが、そこ突っ込んでも聞く耳もってもらえないですしね。上司がやりやすい方法に流れるもんなんですかねぇ…。そのやり方に合意できないのであれば、自分の会社でもないから辞めるべきなのかと考えたりもします。

>　とりあえず、考え方は２つあると思います。

うちの会社は小さな会社で、上司が社長なんですよ。
名目上のポストはあっても、結局は社長がやりたいように全部指示しちゃう+押さえつけちゃう(ように僕には見えます。)から何も変わらないし、誰も意見しない状態です。そのくせ会社の成績は右肩下がりです。

>　この会社を改革する労力と、その見返りを秤にかけて

↑この表現わかりやすくて面白いですね。
天秤にかけてみたら、自分の気持ちがもうちょっと見えてきました。

>　ちなみに、「オブジェクト指向開発でやればソフト開発は短時間でバグが少ないシステムができあがる」と思ってしまいますが、現実には、そうでないことも多いみたいです。

オブジェクト指向は魔法だと思ってましたが、そうでもないんですね。yama-taku さんも言われてるように手法のひとつととらえるべきですか、なるほど…。

みなさんのご意見を頂戴して、少し頭の中が整理できました。
やはり、ある程度は自分の考えにも正解があることを知ることができてよかったです。

また、機会があると思いますので、その時は質問させていただきたいと思います。
ベストアンサーも選びがたいのですが、最後にご意見いただいたlv4uさんに差し上げたいと思います。

ありがとうございました。

回答No.2

Wr5

>実際にはどうなのでしょうか。上記のような開発体制も適正と呼べるのでしょうか。

弱小だとそんなコトもあるでしょう。

エロゲ会社でスクリプト書いていたときはディレクターにプログラムの知識は皆無(企画、シナリオ、管理などが担当ですからね。管理していたかは微妙でしたが)なので、
適当に仕様書渡されて、勝手に組んでました。
テストも自分で行うことに。
ゲームですから、他にデバッグ部隊は居ましたけど。

横道にそれました。

会社の案件として開発している場合、仕様書やテスト計画書などはあるべきですし、レビューなどで複数人の視点からのチェックも行うべきです。
それらが無い。ということは、どこかで問題が発生する可能性が高くなります。
「上司のクラスの概念が…」というのは別にして、ライブラリのようなモノすら構築していないようでは開発効率も悪い…かと。
# 上から渡ってきた仕様書の版数が最新より2つほど古い…とかいうことも。

理想論で現場ではなかなかそうも行かない。
という現場も、やはりそれなりの数はあるかと思われますが。
# 職場を変えてもそんな現場…という可能性もある。ということになります。

お礼

ご回答ありがとうございます。

なんだかんだでいろいろと大変なところはたくさんありそうですね。
とはいえ、レビューとか実際に経験してみたいですね・・・。

>　ライブラリのようなモノすら構築していないようでは開発効率も悪い…
ライブラリみたいなものってのはそれなりにどこ行ってもあるもんなんですね。

PEARをベースにした関数郡みたいのがあったような気はしますが、それらは製品の中身だったりような気がします。

>　# 職場を変えてもそんな現場…という可能性もある。ということになります。

結局はそうですよね。
その辺りは戒めて、甘えないようにがんばらないとって考えてます。
自分でしっかりとビジョンもって頑張ります。

貴重な経験談をお聞かせいただいてありがとうございます。

回答No.1

noname#245936

いやー、若者がよく陥る、浅はかな判断ですね（笑）
とはいえ、あなたの見方はそれなりに重要。
プログラマとしては正しい見解です。

オブジェクト指向と言いますのは、文字通りプログラムを
１つのオブジェクト（ないしその基本となるクラス）という
単位にまとめてシンプルに管理する方法ですけれども。

つまるところ、ソフトを買う側が。
たとえば、ゲームソフトなどを私たちは買う時に。
「このソフトはオブジェクト指向のゲームだ。わーい。
　精度が高いから買うぞー」と買うわけではありません。
あくまで、業務ソフトなら役立ちそうか、簡単そうか。
ゲームなら面白そうか。
それだけの話で中身の仕組みは二の次です。

ということで、仕組みと、ソフトの価値は別ですので。
売れるソフトを作っている会社なら、辞めるのはちょっと
もったいないと思います。

なお、オブジェクト指向は、いい面と悪い面があり。
いい面は、長期にメンテを繰り返す定番ソフトに向く。
比較的まとまりよいのででかいソフトをこんがらがることなく
管理しやすい（ポリモーフィズム）

悪い面は、どんなに単純な処理でもコーディング量が増えること。
たとえば、Hello Worldを表示するプログラムの場合、
関数処理なら、Call PrintHello　という関数を作ってCall
すればいいが、クラス処理なら、いちいちインスタンスを作る分
行数が多いこと。なので使い捨ての簡単処理には向かないこと。
もうひとつは、オブジェクトが増えるとオブジェクト同士の関係
管理がややこしくなる。
むしろ関数処理のほうが意図が掴みやすい場合がある。
オブジェクト指向より関数指向のほうがプログラマが多く、コストが
かかりにくい（メンテは別として）…あたりでしょうか？

なお。
DBアプリ、Rails系などは、オブジェクト指向というよりは、MVCと
いう別の考え方でまとまっている手続きです。
（Model View Control）
オブジェクト指向も一つのテクにしかすぎません。

ま、小手先に流されず。
もっと大きい視野で、自社製品を見てみては如何でしょうか？

お礼

ご回答ありがとうございます。

オブジェクト指向と関数処理についてもわかりやすくご説明いただいてありがとうございます。なんだかひとつ飲み込めた気分になりました。

オブジェクト指向が大切だとかなんとか、いろんな本にのってるもんだから、これさえ出来ればいいのかな？って思ってたんですがそうでもないんですね。

>　売れるソフトを作っている会社なら、辞めるのはちょっと
>　もったいないと思います。

なるほど、確かに売れるソフトを作っている会社なら、確かに・・・、辞めるのは持ったいないですね。売れていればの話ですが・・・。

>　ま、小手先に流されず。
>　もっと大きい視野で、自社製品を見てみては如何でしょうか？

なるほどー、小手先技術よりも、世の中に必要とされているかどうかとか、そのへんの視点が大切ってことですかね。

決断の時には、見失わないようにしないとだめですね。
気を付けます。

補足

>　コストがかかりにくい（メンテは別として）
今日の残業の悩みはメンテになるのかな？機能拡張でした。

さっき帰ってきたんですが、先輩が組んだプログラムに新機能追加してたんですよ。
中身解析するのも大変だし、おまけにループが何十にも組んであって、コメントも十分にないし、どんなことやってるか経験不足でピンとこないし。先輩方はさっさと帰っちゃうし。自分以外の若手もさっさと帰っちゃうし。

自社開発で柱となる開発計画がないので、その日の上司の気分で「この日までに作れ！」とかいうので突然忙しくなります。

お客さんに言われたらしかたないなぁって思いますが、上司からも毎回それだきつくないですか？それも上司としてはきっと、「きっついお客さんに慣れるための訓練」とか、そんなことを聞きました・・・。

僕には理解できないんですが、そんなもんですかね？

プログラムの中身については、オブジェクト化できて必要な情報を一括管理できてれば、こんなにもあっちこっちぐるぐる回るような冗長なコードにはならないだろう・・・、って考えてたんですが、パフォーマンスが落ちるからダメダ！とか言われました。

そのくせ製品のコンセプトもしっかりしてないんですよ。一本の線でつながらないので、つっこんだらシカト決め込んじゃったりして。

悶々と↑みたいなこと考えてました。
少し整理できたようです。

ありがとうございました。