質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

Q&A

解決済

15回答

9924閲覧

CをやめてC#の採用を説得するための材料

kuttsun

総合スコア55

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

5グッド

7クリップ

投稿2016/07/28 14:55

いつもお世話になります。

長文になってしまいましたが、皆様の意見をお聞かせください。
(本当は他にもお聞きしたいことがあるのですが、長くなってしまったので分けて質問します。)

###質問事項

現在社内で新製品の開発が始まろうとしています。
機能仕様以外のことで決まっていることとしては、

  • アプリの種類:デスクトップアプリ
  • ターゲットOS:Windows Embedded Standard 7 (WES7)

ということくらいです。

当社では、現在までWindows用のデスクトップアプリをC言語でWin32APIを使用して作成してきました。
これには自社製品に組み込みソフトが多く存在することも関係していると思います。

正直、今時Cでデスクトップアプリを作成している時点でありえないと思っており、私より下の若手の間では不満に感じている者も多くいます。

そこで、新製品ではC#での開発を提案したいのですが、上層部(あまりソフトに詳しくない方々)からは反対されることが予想されます。

予想される主な反対理由は

新たな開発言語の採用による学習コストと、スケジュール(納期)の関係

です。
これを説得するためには、C#で開発することが何故Cで開発することよりも良いのか、学習コストをかけてまで採用するメリットは何なのか、といったことを説明する必要があると思っています。

しかし前述したとおり、私達は今までCでしか開発してこなかったため、C#やJavaどころか、オブジェクト指向プログラミングすら実務経験がない者ばかりです。
C#による生産性の高さや、アンマネージコードによる危険性などは理解しているつもりですが、特に納期を引き合いに出されると説得できる自信がありません。

結局のところ私の勉強不足ではあるのですが、皆様ならどのように説得されるかご助言いただければと思います。
また、そもそもC#以外の選択はどうか、といった観点からの意見でも構いません。
以上、宜しくお願いいたします。

補足事項

質問とは関係ないかもしれませんが、一応状況としては

  • 製品の特性上、一度リリースしたら10年〜20年程度は機能追加を含め保守を継続していく必要がある
  • 現在組み込みソフトとしてあるものが、WES7にプラットフォームを移すイメージ
  • WES7自体は既に他の製品で実績あり
  • アプリケーションの規模はそれなりに大きい

(現在の組み込みソフトはコードが数十万行ある、ただし古いコードをコメントアウトするなどレガシーなコードが多く残っている)

  • 納期は約2年
  • 開発チームのメンバーは5〜10人程度

といったことが挙げられます。

tanat, hsk, izkn, iwamoto_takaaki, nullbot👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答15

0

ベストアンサー

悩み多き感じですね。

簡単にいえば上層部(経営層?)からすれば、費用対効果で利益が出るという根拠が示せればという
誰でも回答できそうなことに落ち着きそうな気はしますが。

組み込みソフトは、やったことありませんが、組み込みならCというイメージありますね、
なので、あながちありえないとも思わないですが、社内的なフレームワークなり
ライブラリが充実しているということであれば、それを捨て去るほどのメリットも説明できないとですよねぇ
もしかしたらC#の生産性より社内ライブラリの方が生産性高いのでしょうし

あと、ん?って思ったのは、

オブジェクト指向プログラミングすら実務経験がない者ばかり

なのに不満を言ってるの?って思いました。

実務は無理でも、根回しとして勉強会を行ってきたとか、
少なくとも一人くらいはメンターとして動けるとかそういうのもあるといいかもしれませんねと
(誰もわからない場合、どうするんだという不安も出ると思います)

今後も業務時間外にみんなが勉強会を定期的に開いていくとか
それくらいの意気込みみせないとかなぁという気もしますが。

そういうこと考えると一気に移行は、厳しそうなのでUI部分はC#でドライバ部分はCでって言う
説得の仕方もあるのかなと思います。

結局苦労するのは自分たちなので、苦労しても乗り越えられる楽しさを見いだせるのか
あとから、やっぱCでやっとけばよかったって不満が本当にメンバーから出ないのか
C#って言ってるのは、質問者さんの好みではないのかとか、
他に回答がいっぱい付けばいいと思いますけどね。

Cの経験があるならC++もいいような気もしますが、学習コストがC#より高いかなぁ

って、私の回答は戯れ言ですので、あまり参考になさらずに ^_^;

投稿2016/07/28 15:28

Mr_Roboto

総合スコア2208

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kuttsun

2016/07/29 14:47

多くの方から回答をいただき、本当にありがとうございました。 GUIに関する生産性というご意見が多かったですが、GUIのみC#でほかはCというのは考えていませんでした。 参考にさせていただきます。 その他、いただいた言葉はどれも胸に刺さるものでした。 その中で、質問に対する回答とはずれますが > 結局苦労するのは自分たちなので、苦労しても乗り越えられる楽しさを見いだせるのか > あとから、やっぱCでやっとけばよかったって不満が本当にメンバーから出ないのか この部分にハッとさせられたため、こちらをベストアンサーとさせていただきます。 ありがとうございました。
Mr_Roboto

2016/07/29 15:01

おおっと、多数票をの回答を抑えてのベストアンサーありがとうございます。 (Chronianさんゴメンナサイw) 何よりたくさんの回答が頂けて良かったと思います。 私も他の方の回答を読んでいて、参考になりました。 いずれにしてもいい感じでプロジェクトが進むとよいですね ^^
guest

0

こんにちは。

正直、今時Cでデスクトップアプリを作成している時点でありえないと思っており

まじでその通りですね。
新規プロジェクトについて、C言語で小型CPU用のファームウェアを開発するのは有りと思いますが、デスクトップ・アプリはいくらなんでも...

最大の差はGUI開発の生産性です。桁が違います。C言語熟練者が1日かかる画面をC#初級者でも1時間かからずに開発できます。
学習コストも2年ものプロジェクトなら、生産性改善効果の方が遥かに大きいと思いますよ。

ただし、1~10mSec単位の応答性能が必要な場合はC#単独ではきついです。CやC++でその部分を作り、UI部をC#で作るのが好ましいです。この場合の難易度はC言語単独の時より上がる可能性があります。そのような制御に慣れている人がいれば問題になりません。

投稿2016/07/28 15:37

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

2016年、C言語はどう書くべきか (前編)

C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです。


ただ、いきなりC#を使うのは多分ムリです。
上の理解は得られていないようですし、
Cの中でしかプログラムを組んだことがない人がC#を使ったところで
「読みにくいCっぽい何か」ができあがります。(実際そうなりました。)
結果「ほらCのほうが良かっただろ」と言われかねません。
そうなったら終わりです。

なんにせよいきなりC#の導入は技術的にも心理的にも抵抗が大きいので
C++/CLI
一部C#化
C#
と徐々に変えていけば
承認する側も違いが小さくて受け入れやすいのでは。

また、C#の導入を叫ぶにはあなたがC#で開発(better Cとしてではなく)できなければ
「怪しい宗教に踊らされている」としか見てもらえません。


VB6が現役バリバリですが、試験に使う自分しか使わないツール(製品にはならない)を
C#で組んでたら、若干浸透しました。

影響の少ない、自分が勝手にやれるところでやってみる(最悪趣味プログラミング)のも
良いのではないでしょうか。

投稿2016/07/28 23:55

ozwk

総合スコア13512

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

私ならC#のデザイナで複雑なハリボテのモックを作って「こんな簡単にGUIが作れますよ!」って見せて説得すると思います。
Cでやるならそれだけでも一苦労ですので。

ただ、そもそもなんでC#を使いたいのか具体的理由が全くないのが問題だと思います。
本当にC#を使って生産性が上がるのですか?
単純なGUIなら何で作っても大差ないですし、手続き型で組みたいなら他のスクリプト言語の方が向いてそうな気がします。

また、組込み系という性質なら何でも動かせるJavaとかの方が向いてるかも知れません。

正直今のまま提案されたとしてもただの思い付きにしか見えません。
複数の選択肢を検討してそれでもC#がベストと言えれば格段に説得力が増すと思います。

投稿2016/07/29 03:55

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

今あるプロジェクトをライブラリとして使い、GUIはC#で作る方向で説得した方がいいと思います。
実績のある今のプロジェクトをC#のGUIでお化粧するといいと思いますよ。

それにはレガシーコードのリファクタリングもする必要がありますね。
また、ソースコードはGitを使った管理を導入することをオススメします。コメントアウトが入ったプロダクトなんて保守したくないですしね。

説得する材料としては簡単なGUIアプリケーションを作って見せるのもいいかもしれないですね。
会社の展望次第ですが、2年後には社内にCとC#に精通した人が10人増えると思えば説得の足しにもなると思います。

投稿2016/07/28 15:47

yona

総合スコア18155

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

こんにちは。
学習コスト以外に、リソースの限られた環境でメモリの無駄づかいをする(ように見えてしまう)ようなC#(.NET Framework)を避けたいきらいもあったりして。。あと書くまでもないですが、C++からでしたらC#化は容易なのですよね。

  • デバイスドライバも一部(USBデバイス)はC#で書ける時代(MSさんの方針として今後対応範囲は増えるでしょう)
  • C#で.NET Fraworkはソース公開されていて挙動の透明性が高い(C言語のソースやネイティブレベルのデバッグもされてこられているでしょうが)
  • 今回開発する製品の保守しかり、おられる若手の方、それからいずれ戦力となって会社と開発部隊を牽引していくことになる優秀な未来の新人さん確保(パイを広げる)のために。急な助っ人も呼びやすい(優秀なスキル所持者を見つけやすいし、こう言っては何ですが同じレベル成果物を得るのにも豊富な技術者数から選べて単価をお安くでき...)
  • 今後一層ユーザーが慣れ親しんでいく System.Windows.Forms 内のUIコンポーネントなどは、.NET Framework のものであり、Win32APIでは利用できない(自分で似たものを一から作ることに)。.NET FrameworkへのアプローチはC#か、もしくはマネージドC++あたりで書く必要あり。

資産がどのようなプラットフォームのものかわかりませんが、そのまま移植するのではなくWindows7向けにリメイクする勢いで。
みなさん書かれおられますが、ハードに近いレイヤーはC言語(アンマネージド・ネイティブコード)のライブラリとして利用し、画面などは.NET Frameworkのようなラッピングしてくれるものを利用することで、何かの事情で着手するかもしれないWindows10などへの横展開も容易になるかと考えます。
このような観点から、経営者層からC#化にGOを出してもらえれば。。

投稿2016/07/29 01:24

編集2016/07/29 01:30
hsk

総合スコア728

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

もう回答が出揃っており蛇足とはなりますが…。

###メリット・デメリットの整理
先ずはC、C#それぞれのメリット、デメリットを整理しましょう。

Cはネイティブに近い言語なのでメリットの例は下記の感じ。
0. 実行効率が良い
0. 上記のためリアルタイム性の高いシステムに強い → 組み込みシステムで採用されやすい理由かも?
0. 言語的制約が少ない

逆にデメリットとしては、
0. 自作ライブラリの作りこみが薄いと開発効率が悪い
0. 自由度の高さ故個々人のプログラマのスキルが高くないと罠にはまりやすい

C#のメリットは、
0. 既存のライブラリが充実しており開発効率が良い
0. オブジェクト志向言語のためしっかり作ればその後の保守性・再利用性が高い
0. メモリ管理などの煩わしさからは解放される

デメリットとしては、
0. 実行効率はCより悪い
0. オブジェクト指向の初期学習コストがかかる
0. 言語的な制約がかかるためCでは気にせず書けることも回りくどく書かなければならない可能性が高い

###上記を踏まえた上で妥協ポイントを探る
組み込みソフトとの連動も多いとのことなので、
スケジュールに余程の余裕がない限り、完全シフトリスクが高いので避ける方が良い気はします。

可能なら段階的にシフトし、
将来的に全移行することも考えてみてはどうでしょうか。

当然その場合はC#に移行する分、しない分の判断という余分な仕事は付属しますが…。

ただ特殊要件のない一般的なGUIを作るのであればC#の方が楽でしょうね。
VSデバッガの優秀さ、かつ.NET標準ライブラリの充実っぷりは目を見張るものがありますので^^

補足ですがオブジェクト志向系の言語は、
開発工程終盤や保守工程になって真価が出るものなので、
言語の選択にはシステムのライフサイクルも念頭に置くと良いかもしれませんね。

投稿2016/07/28 23:47

編集2016/07/28 23:58
Panzer_vor

総合スコア1636

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

IntelliSenseの支援の強力さも強みです。
主にマクロがあるせいで機械的に加工しにくいCのソースに比べてC#は、VS上から

  • 変数名や関数名を(影響範囲を厳密に特定して)変更
  • 選択した行を新しい関数に抜き出す
  • 選択した式を変数に抜き出す
  • 変数を関数引数に昇格(呼び出し側も同時に書き換え)
  • 存在しないメソッドを呼び出す記述があるとき、条件にあったメソッドを生成

なんてソース操作がワンタッチです(一部プラグインも援用)。関数や変数の使用箇所をリストアップするのも一瞬。Cだとなんか時間がかかる上に不正確ですよね。

生産性の違いは、議論するのも馬鹿馬鹿しいほどです。

投稿2016/07/28 23:36

yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

C++ではなくCな時点でどことなく地雷臭も感じなくはありません
相当秘伝のタレ的なものもあるのでは?
あと「デコンパイルされたらどうするんだ(真顔」的なことを言われるご老体もまだまだ多いです

Cを使いこなせている現場でしたら、いらない子扱いされることの多いC++/CLIも検討に値するかもしれません

C++: .NET Framework プログラミング最良の言語

言語プラットフォーム云々より提示されている内容を見る限り、継続的デリバリーの手法を取り入れていく方が先のような気がします

投稿2016/07/28 19:11

dojikko

総合スコア3939

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ずいぶん昔にやった事例としては、GUIはC#で作成して共有メモリとメッセージでやり取りして、
エンジン部分はC++で作成しました。C++内にはクラスで隠ぺいされたC言語のレガシーコードも
存在しました。2つのプロセスを共有メモリとメッセージでやり取りする感じです。
Windows Embedded Standard 7とのことなので、おそらく24時間運転の無停止装置だと推測します。
また、組み込みソフトで数十万行とのことなので、リアルタイムOSを採用していると思います。
ソフトリアルタイムのアプリケーションなら、移植はなんとかなるとおもいますが、ハードリアルタイムなアプリケーション
の場合、Windowsそのものにリアルタイム性がないので、処理を取りこぼしたりして問題をおこす
可能性が高いです。
そこら辺は、社内の組み込みのベテランに判断してもらうのが良いでしょう。
Windows+INtimeのようなものを使うか、ハードリアルタイム部分はFPGAに頑張ってもらうとか。

また、C++でもSTLやBoostはヒープを虫食いにするので使えません、固定長ヒープをクラス化して
使用していました。(まあ、配列もどきですね。)

具体的なコードを提示したいところですが、会社の規程に抵触するためご容赦ください。

投稿2016/08/03 09:33

mk65536

総合スコア12

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kuttsun

2016/08/03 14:41

回答ありがとうございます。 ご推測の通り、24時間稼働のシステムで現在はITRONを使用しています。 しかしながら、そのシステムではリアルタイム性は基本的に必要ありません。 ITRONを使用しているのも他の製品と部品を共通化しているためです。 そういうところからCを使う理由がないことを説明してもよいのかもしれませんね。
mk65536

2016/08/04 00:29

返事ありがとうございます。 リアルタイム性は必要ないのですね、安心しました。 24時間稼働とのことなので、 Full GC時の停止問題と、Windowsの持っている、 Large Object Heapの挙動を調査しておいた方が良いと思います。 昔の知識なので、今は変わっているかもしれませんが、85K以上のサイズのメモリ確保 は、LOHとして処理され、昔ながらの可変長ヒープ管理(虫食いになる) だったと記憶しています。 蛇足ですが、 Embeddedでも電断時にアプリの必要情報を退避できるように、 電断割り込みや、電圧保持時間は、ハード屋さんに確認しておいた ほうが良いですよ。
guest

0

経験からですが、いきなりメリット・デメリット並べてGUIはC#の方がいいと説明して 「でもお高いんでしょう?」的な回答をただひたすら繰り返しされて、まとめとして「今回は納期が納期が厳しいので」などと言われることを想像してしまいます。
(わたしがいた職場の固有の話であることを願ってやみません。)

一番大事にしてほしいのは、ごじしんが適材適所で言語を選択できることだと思います。他の人にとってはいつだって慣れ親しんだCでかけることです。

ですので、担当のプロジェクトか管理者用の機能などでC#を使う許可をもらうことを目標にしてはいかがでしょうか?

そこで、さも楽しそうな雰囲気をだして、一人ずつ引き込んで行くようにすることを提案します。 (RoRのように)

投稿2016/07/29 14:26

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

貴方自体にやるべきだって意思や自信が薄いのではないでしょうか。
上司に何を言われようとも自分に確固たる理由や理屈があれば問題ないはずです。
必要なのは他人がどう思うか、ほかの人がどう言い訳するのかではなく
貴方がなんと言えるのかだけです。もしくは、納期なら楽勝ですと言える実体制を整えてからですね。

投稿2016/07/28 23:38

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

C、もしくはc++ でデスクトップアプリはありえないですね。
自分は C++ で書いたネイティブアプリはDLLどまりです。
それでもC++/CLIでラッパを書いてC#から使ってます。

要は生産効率です。

どのようなアプリを作成されているかはわかりませんが、CよりC#のほうが生産効率が上だと
説明すればいいのではないでしょうか。
どのように、どれくらい、数字を出せと言われれば少し難しいですが、
車でいえば、20年前のカローラと、今のカローラが同じ性能だと思いますか? という
おじいさんが理解しやすい形で説明してあげればいいと思います。
GUIがあるアプリであれば、サンプルを作って、見た目もこんなにリッチになります!とか。

実際、開発効率は段違いだとおもうのですがねえ…。

投稿2016/07/28 18:50

mugicya

総合スコア1046

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

VCとC#では画面の絡む生産性は桁違いにちがいます。
上司が昔の知識でどう言おうとそこを説明できないということは力量不足は否めませんね。
上司の方に生産性を訴えて認めてもらうのが仕事としての進め方だと思います。

投稿2016/07/28 16:17

KIYOSHI

総合スコア268

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

既に解決済のようですが、少しだけご留意いただけたらいいかな、といった点について書いてみます。

Windows Embedded Standard 7という組み込み環境ということでハードウェアによっては大きな制約がある可能性も考えられますが、いかがでしょうか。
C#が動作するために必要な.NETがそのハードで動かせるのか、という点について調査が必要だと思われます。ひょっとすると動いても動作速度に問題が出る可能性もあります。実際、知人の経験では顧客の指示で.NETを使ったが、パフォーマンスが悪すぎて作り直しになった、という話を聞いたことがあります。

ぎりぎりの環境ではC++でさえ使用できないこともあります。
Cから見れば、オブジェクト指向の機能を実現する部分において余分な処理をせざるを得ないからです。

C#のような高級言語を組み込み系の環境に持ち込むことに対する反発、というのがあるとすれば、そもそも組み込み系には向いていない、という考え方に支配されているからかも知れません。
しかし、実際それは事実である可能性もあります。まずは、実際そこを突破できるかどうか、という点について正確な調査が必要かも知れません。

それと、オブジェクト指向の問題もやはり大きいと思います。ハッキリ言いますと、オブジェクト指向が永遠に理解できない技術者というのも相当数いらっしゃいます。僕はかつて言われたデジタルディバイドという言葉になぞらえて、オブジェクト指向ディバイドという言い方をしますが、つまりオブジェクト指向について行ける技術者とそうではない技術者の格差がハッキリとある、ということです。

そもそも、開発効率や保守性といった品質の問題はオブジェクト指向の導入で大きく改善される可能性はあるのですが、それはオブジェクト指向が本当にうまく導入できた場合に限っての話で、会社という組織の枠組みの観点では簡単にはいかない可能性が高いです。

しかし、やはりC言語しか使用できそうに無い、という結論だったとしても、オブジェクト指向を学ぶことは非常に有意義です。同じC言語でも、より信頼性の高いプログラミングをするヒントが沢山含まれているからです。

投稿2016/08/02 04:46

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kuttsun

2016/08/03 14:40

回答ありがとうございます。 たしかにハードウェアの制約はあります。 既にWindows Embedded Standard 7を使用している他製品では.NET Frameworkを使用したドライバ等を使用していたので、あまり気にしてはいませんでしたが、調査は必要かもしれません。 オブジェクト指向ディバイドとは言い得て妙ですね。 私自身はそれなりに勉強して理解しているつもりではありますが、チーム全員が理解できていなければ、上手に導入するのは難しいということですね。
退会済みユーザー

退会済みユーザー

2016/08/07 05:01

.NETでのドライバ、というものに知識が追いついていないのですが、おそらくカーネルモードで動作するものではなく、ユーザモードで動くものかな? と思われます。 カーネルモードで動作するデバイスドライバは独自のAPIを使用するため、Win32 APIを使うCの標準ライブラリも一部使えなかったり、スタックのサイズにも制限があって、スタックを浪費するprintf()系関数も使えなかったりもします。 限定的な使用方法であれば.NETが動作する、というのであれば、あとはメモリリソース等の問題がクリアできればC#で全体を組むことも夢ではないのかも知れませんね。 ただ、メモリの解放に関してはプログラムで完全に制御することが難しいので、その辺りの事前調査、あるいは最終的には長期連用テストが不可欠になってくるのかも知れません。 オブジェクト指向技術の社内での運用技術なども含め、大きな山があるのかも知れませんが、だからといっていつまでも今のままでいいと言うこともないはずですから、余裕があれば社内で研究プロジェクトチームを立ち上げ、平行して進めていくのが理想かも知れませんね。 問題の本質を洗い直して整理し、解決方法の調査を行っていくといいと思います。問題の定義が曖昧だと、あらぬ方向に導かれるともなく迷い込んでしまうこともよくあります。 問題解決という視点にご興味がありましたら共立出版の「ライト、ついてますか」という名著をお勧めします。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問