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

Question

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

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

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

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

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

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

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

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

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

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

lv4u · Accepted Answer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wr5 · Answer

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

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

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

横道にそれました。

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

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

yama-taku · Answer

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

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

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

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

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

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

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

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

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

>>実際にはどうなのでしょうか。

>実際にはどうなのでしょうか。

いやー、若者がよく陥る、浅はかな判断ですね（笑）

この回答への補足

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング