「プログラマ」を含む日記 RSS

はてなキーワード: プログラマとは

2016-07-24

ヘルプミー。プログラマ

プログラム書くときって、「Aがしたい」っていう考えから始まると思ってるんですけど、

なんで「Aを行うHogeClientってクラスを作って、次に....」ってする人間がいるんですか?

シンプルに考えるとクラス作らなくてよかないですか?

モジュールで良くないですか?

Simulaとビャーネ、Smalltalkアランが居ない世界にいたかった。

追記

SchemeとCしてました。OCaml齧ります

2016-07-22

一人何役もやってんのわかってるから

大学院卒のプログラマの次はアメリカ短期留学した老人ですか

人生なんて必要ない

別にまれたくて生まれてきたんじゃなくて親が勝手に産んだんだから

金持ちでワルで影の支配者になりたかったのに勝ち組ヤクザにもなれないんですか

しょぼいですね

ていうかプログラマ辞めたんだ?

あ、プログラマって設定なんだっけ

一流の数学者になったからってカネかせげないひとだっているじゃん

それはお前にとっては何者にもなれてないってことなんかね

それとも一流の数学者になれないなら何者でないか価値がないって事なんかね

だとしたらそんなもんになってない人間の方が大半でしょ

何者でもない人間のほうが圧倒的に多いですよ今の世の中

でもそんなの普通ですから

一流の人間でなきゃ生きる意味がないってんなら勝手に死んで下さいよ

そもそもなんで尋常レベル以上のカネが欲しいのにサラリーマンやってプログラマになったのかが理解できませんけども

Webプログラマ女多すぎだろ

うらやましいんだよクソが

他にも女来いよ

2016-07-17

Excelに苦戦中

いわゆるExcel方眼紙システム設計書を書いているのだが、これがどうにも上手くいかない。

問題は色々あるが、大きく分けて「必要情報が見えにくい」「変化に追従するのが大変」に集約される。


まず「必要情報が見えにくい」について。

そのメソッド記述するのに必要な、他の設計書や仕様書を見つけにくい。

例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。

また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。

そもそもどうユースケースを読んで、設計必要クラス抽出するかもよくわからないし。


次に「変化に追従するのが大変」について。

上述の状態設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。

また設計を進めた結果、仕様変更必要事態が度々発生する。

更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。

いずれもExcelファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど

そんなことが相次いで発生した結果、修正対象抽出修正確認作業作業量が膨大化し、全く対応できない。


というわけで、もはや限界ギリギリだったり。

「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合努力根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。

どうしたら対応できるのか・・・

自分天才じゃない

人生の全ての時間プログラミングビジネスに捧げてきた人間がいる。そういう人は、きっと毎日仕事が楽しくて、そして、いっぱい稼いでいるのだろう。

でも自分はそうじゃない。

変人と呼ばれて育ち、病気と折り合いをつけ、自分能力を過信して倒れ、真っ白な部屋で2年ほど過ごした。

才能があった。だから努力したことが無かった。追い越されることを知らなかった。

難しい本が読めた。だから自分は偉いのだと思っていた。一生をかけても全ては読めないと気づけなかった。

未知を知らなかった。だから自由研究が怖かった。そもそも研究に値する自由テーマなんてものを見つけられなかった。

金銭感覚に無関心だった。ウチは貧乏から大学に行けない。その事実意味することが分からなかった。

友人関係を作らなかった。隣人の名前を覚えられないということが、どれだけ失礼なことなのか悟れなかった。

どれもこれも、大人になってから気づいて、赤面したことだ。

全ての選択肢で正解を選んできたと思っていたのに、結論から言えばほとんど全ての選択が間違っていた。

転生して最初から人生をやり直すなんていう作品が多くなってきているが、自分には無理だ。また同じ間違いを繰り返すだけだ。

自分天才じゃない。よくて秀才。いや凡才の類だ。

生産性のせの字すら知らなくても、書くコードの桁と質が違うプログラマに幾人も出会ってきた。

あしかし。幸いにも。

IT業界が頭から尻尾までブラックだと知れ渡ったことで、プログラマを志願する若者は減ってきている。

おまけに、親にスマホだけを買い与えられ、PCを触ったことすら無い世代が育ち、新卒青田買いすらできない状態になってきている。

地方にもはやプログラマ求人は無く、東京一極集中労働力を吸い上げるシステムへと変貌したが、それにも限界がくるだろう。

凡才の俺にとって、これはチャンスだ。

諸条件の重なりによって、プログラマ需要供給関係は崩れ、プログラマは完全に不足してきている。

まりプログラマ35才定年説」は崩れていく一方であり、俺と同い年の連中がしたり顔で語っていた「プログラマ不要論」は幻想だということだ。

自分天才じゃない。

でも現状を分析する限り、自分時代に逆らって生きているわけではなさそうだ。

人生の全ての時間プログラミングビジネスに捧げてこなかった人間でも。俺は、毎日仕事がそこそこ楽しくて、そして、そこそこ稼いで生きられればいいと思っている。

2016-07-11

職場人間関係サービス残業が嫌でウェブプログラマ仕事を辞めようとしてるんだが

アルバイト情報を眺めてたら時給900円か月給20万とかばっかりで、扶養家族が居る俺はもうもとには戻れないんだなと思った。

2016-07-10

政治レガシーテクノロジである理由

選挙日なので現代政治無意味さについて書こうと思います最初に言っておくと政治に傾倒しすぎている人を小馬鹿にしている文書なので反論とかあったら書いてくれれば良いんじゃないでしょうか。

 

政治レガシーテクノロジです。なぜならば科学では無いから。科学では無いので今後も施政者独断による政策を実行し、 結果のフィードバック無しに野放図に存在し続けるでしょう。政治システムは我々がその弱点を理解し手を入れない限り今後も何ら問題解決し得る存在とは成り得ないでしょう。具体的には科学事実と言える以下の要件政策および政策を裏打ちする理由は全く満たしていない為、政治システムが打ち出す政策とは社会システムに対する仮説の域を常に出ません。これはシステム開発のターミノロジーで言うならばテストコードの無いレガシーコード、 あるいは測定の無いリーンスタートアップあんまり変わりありません。

ここですぐ思いつく反論は「投票による民意から正しい」というのがありますが、これは全くこの議論文脈的外れになります投票とは民意を反映するメカニズムではあるものの、正しさに近傍させるメカニズムは一切具備していません。イギリスEU離脱国民投票結果は記憶に新しいですね。国家社会主義ドイツ労働者党投票によって生まれた事にも注目しましょう。投票とは諦めと熱狂のためのメカニズムと捉えた方が良いでしょう。そして科学数学投票などというアプローチなど一切採用してないのを良く見てみましょう。さらに言えば正しさとは何なのかという定義自体が70億人分あるということにも注目しましょう。さらに言えばその70億のあいまいな正しさと,実際に社会システム上でワークする正しさは別物である点に着目しましょう。政策の正しさってなんだとみなさんは思いますか?憲法準拠してることでしょうか?人々の幸福依拠している事でしょうか?憲法とは時代によって経年劣化しない永遠普遍のナマの事実でしょうか?「人々」のカテゴライズには観測者のエゴは入り込まないでしょうか?自然言語記述された憲法の「解釈」には観測者のエゴは入り込まないでしょうか?たぶん僕らは政治システム継続する限り「正しさ」の定義を動的に変更し続けなければなりません。立憲主義功利主義も今は正しそうだけど、 それは時間とともに修正する事が不可欠でしょう。この複雑な系における永遠に正しい事など神以外にわかりようがないのだから。ゆえに正しそうな物に近傍し続ける為に科学アプローチによる継続的フィードバックループが不可欠なのです。またシステム開発ビジネスオペレーションにおいて既に実在している「テスト」や「仮説検証型のアプローチ」は実用的であり有効であると判明していますが、それにも関わらず政治はこうした手法と無縁です。よってレガシー遺産であり旧時代遺物であり維持が困難)であると言えるわけです。次は我々が自然言語はいかに正しさを規定できないかを見ていきましょう。

分野を問わず物事の正しさを充足理由律で語る場合、我々は議論俎上で次の問題にぶちあたるでしょう。わりと有名なアポリアです。

インターネット上で発生する議論なんてのはまさに、このトリレンマの通りで一見正しそうな事を言っていても結局は「相手が根負けするまで議論継続する声のでかいキチガイ」か「権威である誰か」が議論に「勝つ(笑」という結果ばかりが観察できるでしょう。まれ科学事実根拠にした議論も無くはないのですが、圧倒的に多く発生している炎上というやつでは概ねこのような議論ばかりが観察できるはずです。独断独断のぶつかりあいなのでまぁ仕方ないですね。基本的には独断ゴリ押しする為の殺し合いなわけですから。そして政治システム、とりわけ議会が行う議論はこれと大差ないわけです。愚かですね。政治は一応の協約として「投票」により独断を防いでいると言えます議会が成立する前の投票に着目してみても投票とは正しさを導き出す事ができないわけなので(そもそも誰もが独断による正しさを持ち得るわけで)投票簡単に間違いを選択します。ゆえに自民党に怒り、民主党に怒り、そしてまた自民党に怒るのような愚を犯すわけです。科学はこの愚を起こさないために実験観測事実(上記の4要件)によって、無限後退を防いだり観測者のエゴ排除したりする為の協約を敷いています数学ではこれは公理系にあたるでしょう。これらはそれ以上理由を遡らないお約束事として存在します。このトリレンマ観点に立った場合、我々が判別可能な正しそうな物事とはお約束事に依存している仮の正しさであり、実は有限時間を生きる我々には理由の遡りを完全に停止出来る真の正しさ(ナマの事実)を判別出来ない事が分かります。そしてそれでもなお、そのお約束事が役立つ事実っぽいものを生み出す事を我々は経験的にも歴史的にも知っています。また、こうした科学分野のお約束事に比べ政治におけるお約束事(投票)がそれのみではそれほど有効機能しないことも我々は経験的にも歴史的にも知っています

さて、最後にこのレガシーテクノロジである所の政治未来においてましな物になるにはどうしたら良いかを考えてみようと思いましたが、僕にはその答えが「協約」も無いこの場で成立するとは到底思えませんでした。まぁ科学事実をどうやって役立つ形でフィードバック可能な形に実装できるかなわけですが、少なくとも協約も無しにこの場では実証不能な事を断言すれば独断による殺し合いを防げないのでこの文書では取り上げません。政治システムをテスタブルで測定可能フィードバックループ内包をしているシステムにどうやったらカイゼンできると思いますか?みなさんが必要だと思う協約を敷いた上でトラバブコメ議論してみてください。僕からは以上です。

 

追記とか

 

なんとなく民主主義否定してるように誤読されてる感あるので追記しますが,民主主義科学事実によるフィードバック仮説検証によって補強せよというのがぼくの主張です。あと協約の無い議論不毛だな〜という思いを強くしました。協約を誰か敷くかな〜と思ったけど誰も敷かないですしね。

 

返信とか

 

 

レスどうもです。仮説検証の無いオペレーションが野放図に続くからです。政治オペレーションとはそんな不確実な物で良いのでしたっけ? あとは仮説検証まで行かなくても実行したオペレーションテクニカル分析した結果すら乏しいですね。例えばアベノミクスに対する評価なんて個々人の政治信条が混ざりこんでおよそ再現性の無い独断論しか存在しないからです。消費税増税についても同様ですね。こんなものは我々の社会形成するための知識としては今後全く役立たないでしょう。逆にオペレーションの精度を問うているこの文脈において民主主義絶対視する理由ってなんでしょう?無限後退なっちゃますよ。

※/合理とは〜にたいする返信

 

追加レスどうもです。100字だとなかなか語る単語を選ばなきゃいけないだろうからお察しします。さて「目的をどこに定める」と言っているその目的ですが期待効果の無い目的は無いでしょう。たしかにそれは政治科学も同じですね。そして期待効果を発案するアプローチ手段として期待効果近傍するアプローチ政治システム科学事実要件を満たしたファクトから始まっていない以上, 精度に乏しいと話しているわけです。そして政治独断投票という脆弱な仕組みに依拠にしている以上, 科学アプローチよりは望んだ効果を得る見込みは薄いといえますね。

 

レスどうもです。なるほど。ではその決定はどんな理由によって決められるのでしょうか?非理性的な人々の気分で決まるのだと主張されるのでしょうか?ぼくはそれでは期待効果を得られないので(期待効果なるものがあるのかも怪しいが)あるべき姿じゃないと申してます。どんどん無限後退に陥りますねえ協約の無い議論は。これは勝ち負けのパラダイムに陥って根負けした人が負けて勝った人が快楽を得るパターンになる気がするなあ。続けますか?

houyhnhm  生政治とかちょっとモノ読んでから出直して来てほしい。社会システム論もかすってもいない。システム開発者としても中途半端な人だとは思う。

 

はい人格批判と受け止めました。ありがとうございました。初手のレス人格批判レスにあまり興味ないの提示してるのでご理解いただければと。こちらが提示した文のどの部分に対する反論なのか明らかになった時点で反応したいと思います。生政治がどの部分に掛かって来るかなどなど。よろしくどーぞ。

 

改訂履歴

2016/07/10 0:38:追記書いた。
2016/07/10 0:38:返信書いた。
2016/07/10 0:32:引用の見栄えを整えた。
2016/07/10 0:21:返信書いた。眠いですぞ
2016/07/10 0:00:返信書いた。眠い
2016/07/10 21:49:返信書いた。増田ブコメに返信はめんどいですねえ。
2016/07/10 18:25:ぼくの政治信条はどうでも良いので除去
2016/07/10 17:38:トラバの人がおしえてくれたのでカンマを全角に修正プログラマバッドノウハウとしてこうなってたのです。ぼくの人格きもいっすけどね!

2016-07-08

みずほ銀行システム開発話題になってるようだが

webエンジニアSIerのやっている大規模システム開発について、上から目線ドヤ顔しながら意見しないほうがいいよ。

とくに若くてweb開発しかしたことない人ね。注意したほうがいいよ。

web企業でつくるアプリってSIerの作る大規模システム比較すると単純すぎるのよ。

web系のアプリってドメイン(システム化対象領域)が単純だから、まず複雑なデータフローが発生しない。サブシステム分割も考えなくていい。

それに誰もが理解やすドメインから、だれでも各工程レビュー問題点を指摘できる。

でもドメインが相当専門的に勉強しなきゃいけないような領域では、ただ世渡りうまいだけの人や、流行技術に群がるファンボーイでは問題発見することも把握することもできないでしょ。

web系を開発するのと同じような態度でいたら、実装する機能意味理解できないかもしれないよ。

web系はドメインが単純だから、変にビジネス志向だったり、流行技術志向だったり、SE職を軽んじてたり、総合テストといいながら個別に画面をポチポチさわるだけだったりする。

作るのが簡単から「俺スゲェ」感がでやすいのよね。

だけどエンプラ系はもちっと難しいのよ。

エンプラ系開発プロジェクトは大抵クソだけど、クソを取り除いたらチンカスしか残らない気もするけど、そこんところは認めてやってよね。

以上、web系の仕事もやっているエンプラ系おじさん派遣プログラマから意見でした。

2016-07-05

ITって50.60代が殆どいないんだよね、ホント

まあ請負になれば50代までいけるかなーなんて思いつつ、

迷ってる

プログラマは50代いるけどね

サーバーサイドエンジニアで50代って見た事ない

2016-07-02

エンジニア英語必須と言うけれど

まだまだ一部のエンジニアにとって、という話だよね。

少なくとも英語の読み書きができないと最新のテクノロジー情報キャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースコントビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。

でも日本にいる80万人以上のITエンジニアのうち、そうした能力必要とされないエンジニアがこの日本の大部分だ。

なぜならSIerみたいな受託開発・運営ソフトウェア業界売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから

枯れた技術で安定性を担保ってのはわかるが、公式サポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。

オレは新卒で入った受託ソフトハウス大手SIerで計8年働いて、6年ぐらいはwebアプリプログラマSEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードコメント読むなり顧客メール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。

コーディング英語を使うと可読性が下がるから変数名・メソッド名・データベーステーブルカラム名ヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。

とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。

悲しい愚痴、以上。

2016-07-01

http://anond.hatelabo.jp/20160701223810

人足らないから。

ホントプログラマに向いてる人はGoogleとかで4桁万円もらってるんだろうけど、人足らないから向いて無い人も入ってきて、効率化する知恵もやる気もないか残業で埋め合わせするしかない。

【決定版】プログラミング言語を徹底解説!



http://cpg.hatenablog.com/entry/2016/06/30/193755

【決定版】プログラミング言語を徹底解説!


プログラミング言語は、200種類以上存在していると言われていますが、その亜種や野良プログラミング言語を含めれば、星の数ほどあります。たとえば今回紹介しませんが、ベーシックという言語だけでも、ファミリーベーシックプチコン3DSベーシック)、べーしっ君などがあります

今回はその中から厳選に厳選を重ねて厳選した、プログラミング言語を5つ、徹底解説します。

では早速解説していきます!!!

1.Perl

Perl歴史的に古く、sedawkといった歴史として語られる以前のプログラミング言語のいいとこどりをした、とても、素晴らしい言語だ。

モンスト以前のmixiや、みんな大好きはてブはてなブログは、Perlで作られています


学習する際は、歴史が古い分、Perl4の本も、たまに図書館に残っているため、気を付けなければなりません。


2.Perl

よく勘違いされるのが、「PerlPearlって似てるんでしょ?」。違います

何が違うかといいますと、文法から用途までほぼ全てが違います

Pearlとは?

Pearlとは真珠のことだ。あと、バンドメンにとっては楽器。それと、譲れない願いかPEARLCDを買った人も、いるんではないでしょうか。

Perlは?

PerlはAndoridにも、対応してたりします。

https://www.infoq.com/jp/news/2014/06/perl520


3.Perl

Webサービスを開発したい場合、真っ先にお勧めしたいのがPerlだ。

Perlの特徴として、[[TMTOWTDI]]があります。あとPerlを生み出したLarryは、プログラマの3台美徳として、 "Laziness, Impatience and Hubris"というすばらしい考え方があります

https://en.wikiquote.org/wiki/Talk:Larry_Wall


4.Perl

皆さんはAIをご存知ですか?

PerlAI(Artificial Intelligence)でググッテても、わかるように、2000年台前半からすでに話題に上がっており、最近流行ディープラニングでも、Perl6を使った話があるようだ。

http://ai.neocities.org/P6AI_FAQ.html


5.Perl

iPhoneで動くPerlもありますアプリあります

https://itunes.apple.com/jp/app/perl-programming-language/id486217730

だんだん書くのが疲れてまいりました。

http://blogs.perl.org/users/lestrrat/2013/09/perlmotion-perl-for-ios.html

あとはlestrratさんにおまかせします。


それとYAPCは去年で一区切りしましたが今年も、YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa あります!!!!!!

http://yapcasia8oji-2016mid.hachiojipm.org/

2016-06-30

http://anond.hatelabo.jp/20160630145118

最高例を持ち出すのは卑怯かも知れないが。

エンジニア年収4ケタってどうやったらなれるの?稼いでる人に聞いてきた

https://codeiq.jp/magazine/2016/06/42239/

こういう例は、一般公務員には無いから。ダメSIじゃなくて、ちゃんと仕事が身に付くいい会社に入って自分研鑽して自分を高く売れる人なら、公務員より夢があるし、世界に出ていけるチャンスもあるし、プログラマ悪くないと思うけどね。

SI界の最底辺職業という意味でのプログラマなら、夢が無いにも程があると思うが。その中でも頭角を現せる人もいるから、あとは本人次第って所もあるだろうけど。

http://anond.hatelabo.jp/20160630145118

条件のいい公務員になれるなら、そっちの方がいいんじゃない?碌でもない条件のもあるから吟味自分能力との相談はあるだろうけど。

空き時間プログラマとしてのスキル磨いて、そっちが行けそうなら離脱してもいいんだけど。好きじゃないなら、悩む理由が無いでしょう。

プログラマ公務員

当方所謂駅弁大学工学部3年次。専攻は情報系。

3年になりプログラミングの授業が多くなって来てようやく気付いた。

俺はプログラミングがあまりきじゃないし、向いてない。

地方駅弁大学で平均以下のプログラミング能力なのだから社会では淘汰されるのではないか

将来、IT関連の職に就いて生き残れる気がしない



大学院生の話を聞いたり、IT業界活躍している人の記事を見たりすると、この業界で勝ち残って行くにはプログラミングが好きで、常に勉強していかなければならないようだ

今の自分にはそんなモチベーションはない

俺が一番に求めているのはライフワークバランス

てっぺん獲ろうとか、ガツガツ金稼ごうなんてはあまり思っていない

それなりのお金があって、しっかり休みがあればそれでいい

しかし、凡エンジニア実態薄給激務



入学前は情報系の研究に色々興味があったし、プログラミングも頑張ろうなんて思ってたけどもうこの業界への就職は諦めてしまったほうがいいのかな

はやく見切りつけて公務員勉強でもしたほうがいいのかも

公務員だって楽だとは思ってないけどプログラム書くよりはマシなんじゃないか

2016-06-29

http://anond.hatelabo.jp/20160629135806

糞ザコナメクジプログラマほどシェルスクリプトプログラマだと認めない傾向にあるが、そういう糞雑魚ナメクジよりもせいぜい書けてbashの人の方が<圧倒的に>給料高いんだよ。

それがなんでかを理解できる頃には増田はもう死んでるだろうけどな。

ソフトウェアエンジニア転職するときに気をつけること

いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。

自分はこんな感じのエンジニアです。

  1. 技術的には広く浅くタイプ
  2. デザインインフラは不得意
  3. マネージメントは不得意
  4. いままで所属していたのは上場企業が多かったが、スタートアップ経験済み
情報収集
IRを読め、短信だけでいいか

これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事

で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。

公開されているコードを読め

公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社評価という点では使えない。

GitHub会社アカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリコミットしているかもしれない。

面談
経営陣や部長クラス技術に対する考えを聞け

社長エンジニアを信頼しているかCTOがいる場合は、CTO社長信頼関係があるか。

技術手段に過ぎない、ビジネスへのビジョン大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。

これはできれば上層部と平社員両方の考えを聞こう。

使っている技術スタックや将来への展望を聞け

技術目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。

もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいかバージョン管理インフラなどの下回りを一新したい、既存社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。

この話は技術者ならば誰から聞いてもいい。もし面談過程技術者がでてこなければ、その会社は諦めよう。

デザインについてのどう考えているかを聞け

ここでいうデザインは「サービス設計」のことね。デザイナー出身マネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。

サービス開発手法については納得するまで聞け

企画デザインプロトタイピング、開発、リリース改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。

これは現役の技術者から聞こう。実際に自分体験することになる日常になるのだから

外注と内製の比率とどういうとき外注するのかを聞け

外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋エンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。

以上。

願わくば、次の転職がうまくいかんことを。

追記

"見出しエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。

2016-06-28

http://anond.hatelabo.jp/20160628204501

気付けば周りは35歳過ぎたプログラマばかりなんですが・・・

業界的なものかね?

多分このまま定年までプログラマで居られそうな感じではあるが。