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