質問: 以下、今の自分の現状です。 *Too Long Don't Read* なので、 読むかはご自由にお願いいたします。 現在、 「あるJava製のオープンソースソフトウェアが実務で使えるか」 と、並行課題として 「Go言語による自動ソースコード生成の課題」 をプロジェクトリーダーから振られているため、業務で行っているところです。 ソースコードを読むのも書くのも辛くなった --------------------- 情けない話、プログラマとして働けるのかと問われそうですが、 ソースコードを読むのも書くのも辛くなってしまいました。 多分実務が5年程度ですので、 おそらく大規模な開発や セキュリティ対策まで施した独自のHTTPサーバーの構築方法などを知らない、 所詮スクリプト・キディなので、自分の実力がその程度だったのだなと受け止めつつ、 調査業務や課題に取り組んでいるつもりですが、 ソースコードを読んでも概要が理解できない、それゆえ、どんなコードを書くべきなのかも分からなくなってしまっています。 調査について ------- 「セキュリティやお金が関わる部分は、手垢のついたシステムを使いたいので、これが今回つくるシステムに組み込めるか調査してください」 と、あるオープンソースソフトウェアの調査を依頼されています。 「ドキュメントは英語しか無いけどあるのだからそれを読めばいいし、私はメインシステムの開発と現行システムのスケールアウトなどの対応で忙しい」 そんなリーダーの雰囲気ですので、ひたすら自分達で調査しておりますが、調査していくうちに、 「これは今回作るシステムに適していないのではないか」 という調査結果と気持ちがわいてきて、意欲が減退しているのかもしれません。 しかし既に、 「半年でできるはずの新規システムの開発に2年かかっている」 うえに、 「このオープンソースソフトウェアの調査で半年近くかかっている」 という要因が、この調査を打ち切ってくれと言えない原因になっているかもしれません。 ましてや、リーダーは「完璧なシステムを作る」ことに執着にも似たこだわりがあり、 その話を出せば、 「いや、私の考えではもっとうまくできるはずだ」 と返され、話を受け入れる様子が全く無いです。 課題について ------- そんななか、別の部署の方から 「あの調査させているメンバーがかわいそうだろう。開発させてやれ」 とリーダーに指摘があったため、今月の初め(2018年10月)から並行で課題を依頼されました。 渡されたのはテストコードと、予め自動生成した結果のソースコードのみで、 「このテストコードが成功するように動作させることはもちろん、セキュリティリスクは最小限に、かつ汎用性の高いコードジェネレーターを2週間で作ってください。むしろ今まで自己学習してなかったんですか?」 と言い渡されました。 もちろんながら、リーダーは、 「メインシステムの構築に忙しいし、資料はいっぱいWebに転がってるから、自分で調べてください」 という方針です。 しかし、私も今の会社に派遣されて半年経っているのに、 自宅や寝る間を惜しんでGoを触ってreflectやgorutineの仕組みを理解しようとしなかったしっぺ返しが来たのだろうなと受け入れて課題に取り組んでいます。 疲れてちゃ行けないのだろうけど、疲れました ---------------------- ここまで読んでくださってありがとうございます。 本来こんな事を書いている暇があったら、調査や課題に取り組んでいるのが正解だとは理屈では分かっていますが、 素直に申し上げるとそんな心の余裕が無いです。 ただの私の「融通が利かない現状」に対するわがままだとも思います。 --- 「私はそもそもプログラマとして働くことが間違っていたのだろうか」 と思う今日このごろですが。コンピューターが好きだし、コンピューターを使う仕事しかやれそうにないので、 こんなくだらない質問をさせていただきました。 以上、駄文・長文、失礼いたします。 最後までお読みいただき、ありがとうございます。
回答: こんにちは。 たいへんそうですね。お察しします。 > > 「これは今回作るシステムに適していないのではないか」 > > という調査結果と気持ちがわいてきて、意欲が減退しているのかもしれません。 > > > ここがちょっと気になりました。「気持ち」の意味が「好き/嫌い」の意味なら、調査しているOSSを嫌いになってしまったということではないでしょうか? 半年も1つのプロジェクトを調べていたら飽きますし、成果に結びつかなければ嫌いになるのも仕方がないことのように思います。 一旦、「嫌い」は封じ込めて「これは今回作るシステムに適していない」客観的な根拠、および、その逆のの根拠をリストアップしてみては如何でしょうか? 最終的に使う/使わないを判断するのはリーダーさんでしょうから、リーダーさんが判断できるような材料を提供するのです。 そして、結果を提示する際にmanzyunさんが感じた直感的な「好き/嫌い」の部分も「自分はこんなところが嫌い」のような意見として提示するとより好ましい結果に繋がるような気がします。(単に「嫌い」では言うだけ無駄ですので、ご自身の思いをちゃんと言語化することが重要です。) > > 「このテストコードが成功するように動作させることはもちろん、セキュリティリスクは最小限に、かつ汎用性の高いコードジェネレーターを2週間で作ってください。むしろ今まで自己学習してなかったんですか?」 > > > その課題が今まで調査していた OSS の分野とかぶるようなものでしょうか? もし、YESなら、調査の過程で学習は必須だっただろうと思いますので、それを怠っていたとすると調査も捗りませんので「向いていない」可能性はあります。 逆に、NOなら「OSSの調査に注力していたので OSS周りについてはかなり学習したが、goについての学習までは手が回っていない」旨説明し、学習(調査)時間も含めて現実的に対応できそうな期間を提案した方が良いように思いますよ。 なお、調査アイテムと開発アイテムが入ってきた経緯的には、開発アイテムを優先して作業してよいのでは?(同時並行なんて効率が落ちるだけですから、ちゃんと効率よく作業できるよう、それぞれに注力できるスケジュールを組んだ方が良いと思います。)