#kzrb meetup 13 に参加してきた話

9月28日（土）に ITビジネスプラザ武蔵 研修室2 で開催された、kanazawa.rb meetup #13 に参加してきました。*1

http://kanazawarb.github.io/meetup/13/
http://kzrb.doorkeeper.jp/events/5667
http://30d.jp/kzrb/3


twitter などで kanazawa.rb の人たちが楽しそうにしているのを見ていて、いつか参加したいなーとずっと思っていたところちょうど仕事も落ち着き実家に帰省することになったので、帰省のタイミングをこのmeetupにあわせて北陸に行くことにしました。

27日（金）に新横浜から米原経由で実家のある福井に帰り、28日（土）の朝に福井から金沢に出かけました。会場の ITビジネスプラザ武蔵 が最初どこにあるかわからなかったのですが、めいてつ・エムザの中のエレベータから行けるのですね。Twitter で教えてもらって無事にたどり着くことができました。
　

今回の kzrb #13 は、「意識高いもくもく会＋α」ということで、参加者の自己紹介のあとに LT があって、その後もくもく会となっていました。
LT については、cotton_desu さんの参加エントリにまとまっているので、そちらを見るのがわかりやすいかと思います。
http://cotton-desu.hatenablog.com/entry/2013/09/30/232425


もくもく会については、先月（8月3日）に参加した Rails寺子屋の復習をやる、というのを目的にすすめました。参加エントリをここに書いていなかったので、まずはそれを完成させ（ http://shiget84.hateblo.jp/entry/terakoya02 ）、その後あまり時間はとれなかったのですが、実際にやったことを復習していました。
プログラミング言語に限らずなんでもそうだと思うのですが、やっぱり一度やっただけでは全然身につかず、定期的に自分の手を動かしていかないと覚えられないですね。仕事も落ち着いてきたので、定期的に自宅で手を動かす時間をとりたいです。



もくもく会の成果発表後は今後の kzrb についての意見交換。11月の開催では、Railsをテーマとするということが決まりました。今後やりたいことをこのように話あったりできて、「みんなでつくりあげていくコミュニティ」というところを意識してるんだなーと感じました。



時間は17時になり、本編はおしまい。その後、懇親会に参加し、とても楽しかったので福井に帰ることをあきらめ二次会・三次会に参加し解散したのは26時すぎ。12時間以上にわたって、とても充実した時間を過ごすことができました。


普段、横浜に住んでいてなかなか参加することができないけど、今後ともタイミングをあわせて北陸に帰ってきて参加したいなーと思うのでした。


みなさん、お疲れさまでしたー！

*1:12/31にエントリをアップしています

Rails 寺子屋に参加した

8月3日に開催された Rails寺子屋 に参加してきました。
以下、エントリの半分くらいは8月3日のうちに書いてしまっていたのですが、そこから約2ヶ月ほど寝かせておいて、そろそろ成熟してきただろうということで、9月28日に残りの半分を書いてアップします。（こんなに遅くなるとは思わなかった。そして、やったことをそこそこ忘れてしまっている・・・）


環境構築

まず事前作業として、8月2日に環境構築を行いました。
会社を有給休暇で休んで、Apple Store 銀座へ行き、Macbook Air 13インチ を買ってきました。
そして家に帰ってきてから、以下のページを参考にして「10.7, 10.8 用 RailsInstaller」を用いて Rails 環境を構築し、その後に gem update rails で 4.0.0 にしました。
http://railsgirls.jp/install/

当日午前の部

Rails Girls のチュートリアルを参考にアプリケーションを作成しました。
http://railsgirls.jp/app/

Rails Girls のチュートリアルは初めてだったけど、scaffold してブラウザで確認するところまでは問題なく完了。他の Rails 入門みたいなのはこの段階でブラウザから確認して終了、だったりするけど今回はその後に「デザインする」という項目で Twitter Bootstrap を利用してスタイルを変更する、という段階があってとてもよかった。その後、「写真のアップロード機能を追加する」という行程もあり、どのように機能を拡張していくか、ということが少しイメージしやすかったです。
過去に Web や本を見ながら Rails に手を出してみたときには、scaffold で作ってブラウザから確認した後に自分の実現したいものに近づけるにはどうしたらよいか、というところがわからなくてモヤッとしていたので、今回このチュートリアルで体験できて勉強になりました。

当日午後の部1の1

引き続き Rails Girls を参照しながら進めることに。今回は Heroku に Rails アプリをアップするところまでです。
http://railsgirls.jp/heroku/
まずは Heroku のアカウントを持っていなかったので取得。その後、データベースのアップデート。本番環境（Heroku）では PostgreSQL を利用するように設定しました。PostgreSQL は仕事で使用することもあるので親しみがわきますね！（わかない）

その後、現在までの状況を git に登録します（登録する、という表現でいいのかな？）
git もちょっと手元で触ったことあるけど、ソースのバージョン管理としてまともに使ったことがなくて初体験。わくわくしながら進めました。

そして待望の Heroku にデプロイ。わーい！ わーい！
おめでとー！！！！！

午後の部1の1で確認できなかったところ

今後、このアプリケーションを拡張したいときの動作確認はどのようにするとよいのだろう？

group :development do
gem 'sqlite3'
end
group :production do
gem 'pg'
end

をやってるから、開発環境（ローカル）では sqlite3 を使って、本番環境（Heroku）を使うときには PostgreSQL にできるんだろうけど、それをどのように指定するんだろう？
具体的には、ローカルで改修して動作確認するときにどう指定するのか、Heroku にデプロイするときにどう指定するとよいのか？　特に意識する必要ないのかな？
# うまく伝わらなかったら申し訳ないです


午後の部1の2

午後の部1の1を終わらせたところで時間があまったので、残りの時間は GitHub 入門！！！
オープンソースとソーシャルコーディング、どのようにカルチャーが変わってきたかということについて。興味深い話題でした。
その後は、日本の歴史のお勉強。
https://github.com/june29/japanese-history
誤った日本の歴史があがっているので、修正して pull request を送る、という体験をしました。
june29 さんのリポジトリを Fork して、自分のリポジトリを git clone して エディタで編集して、commit して push して、june29 さんに pull request を送る、という流れ（であってますよね？）
github をちゃんと使うのも今日がほぼ初めてで、さらに pull request まで送っちゃうなんて、とてもドキドキでした。！！！


午後の部2

sora_h 師範による、Ruby 大喜利。にちょいちょい参加しつつ、主には午後の部1の2までにやったことを復習していました。


まとめ

8月3日に開催された 第2回Rails寺子屋 に参加してきました。
もともと Ruby はテストデータ作成用のスクリプトを書いたり、Excel を処理するのに簡単なスクリプトを書いたりで、Rails や Sinatra などのいわゆる「Web」にはこれまで関わってこなかったので、今回の参加はとても勉強になりました。

なかなか昼間のお仕事が忙しくて Ruby や Rails にふれることができなかったりしますが、せっかくこうやって貴重な体験をすることができたし、この経験を活かしていきたいです！

SIer での働きかたについて考えたりするなど

SIer が利益をあげるには、高い金額で受注して安く完成させる以外にない。
SIer と言ってもやっていることは様々で、僕は特定のお客さまを対象に基盤となる業務システムの保守および派生開発をメインに行っているチームで仕事をしている。

こういうチームの場合は保守料として定常的に一定額のお金をお客さまからいただいているので、障害などが発生しなければ基本的にはこの保守料が利益になる。また、開発案件があるときには、上記のように高い金額で受注して安く作ればそれが利益になる。
お客さまにも年間の予算や事業計画があり、そのなかで SIer に開発を依頼する訳であり、SIer が開発案件を受注したいからといって受注できるものではない。
このような状況のなかで働く人々にとって必要なのは、どれだけお客さまのビジネスに貢献できるかという意識を持つことだろう。

  • お客さまが利益をあげる
    • 投資にまわる予算が増える
    • 開発案件が増え受注も増える（といいな）
  • お客さまが利益をあげられない
    • 投資予算が縮小
    • 開発案件が受注できない、保守料も値下げを要求される、など次々と襲いかかる厳しい状況

簡単な話である。


いわゆる SI としては開発を行い納品したところで終わりなのかもしれないが*1、お客さまとしては納品されたところがスタートでこれを使ってどれだけ利益をあげられるかというところがポイントとなる。
では、開発中にエンジニアはどこを向いて仕事をすべきか。ウォーターフォールであれば実装は設計書に従って行うことになるが、実装中に「ここは設計書では○○だが、△△にしたほうがよいシステムになるだろう」とか、「☆☆機能については明記されていないが実装したほうがよいのではないだろうか」とか思うことは多々あると思う。こういうときに柔軟に対応できるお客さまだったとして*2、どこまで対応すべきだろうか。対象の変更の規模にもよるだろうし、お客さまと相談して品質・コスト・納期などを考慮して決定されるものでいわゆるプロジェクトマネージャやプロジェクトリーダの仕事になると思うが、いざ自分に判断が任されたときに何を基準にするとよいだろうか。
個人的には出来ることは可能な限りやるほうがよいと思うが品質を犠牲にはできず、納期を遅らすというのも許されない場合が多いだろう。求められていることを期間内に完了させることに加え、追加でお客さまのために＋αをやろうと思うと残業などによりコストをかけてやるしかない。お客さまから予算を追加でいただければ問題ないかもしれないが、実際にいただけるケースというのはまれだろう。となると、自社の利益を削って行うことになるが、SIer で働く立場としては「何故利益を自分から削りにいくのか」という問題と衝突してしまう。



上手い例が思い浮かばず一部極端なところがあったりするけれども、「自社の利益を最大限確保するために最低限の求められていることだけをやる」か「多少自社の利益を削ってでもお客さまのビジネスに貢献できるよう全力をつくす」か、どういう意思で仕事をしていくと自分が幸せになれるか、自分だけでなくみんなが楽しく仕事をするにはどうしたらよいか、というところが最近のモヤッとしているところであったり、今後の解決していかないといけない課題だったりするわけあり、id:hotchemi さんのエントリ『人月 - ギークに憧れて』を見て書きたくなったことでした。




世界が平和でありますように

*1:保守等が続いて行くということはある

*2:このようなお客さまは実際に存在しないかもしれないが

「SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-」に参加した #DevLOVE

SI SIer

ちょうど１週間前の10月09日に、マイクロソフト品川オフィスで開催された「SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE」に参加してきました。
詳細については、NAVER まとめ「DevLOVE SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - NAVER まとめ」を読むとよくわかりそうです。
スライドはこちら：業務系SEの今後について


以下、私の記憶に残ったところとか、私が思ったこととか。
（私の思考整理用メモみたいなものです）


「実質所得は体感的に減少する」 （スライド3ページ目、4ページ目）

今まで△△歳で○○万円あった収入が8割くらいに下がる、とのこと。若者としては、もともとあまり給料を貰ってないところに今後も上がる見込みはなく、そんな状況で消費税も上がるのでお先真っ暗という現実。

プログラマの生産性は10倍以上の開きがある（スライド8ページ目前後）

  • 他の業界では開きがあっても3倍
  • 普通はそんなに一人当たりの出力がずれたら商売にならない
  • 優秀な人の生産性が高い、というよりも低い人が多すぎる
  • モチベーションは給料では上がらない、むしろ落ちる
    • できる人の給料をあげられない

SI の現実と今後（スライド12ページ目前後）

人月で売り上げが決まるとか、個人レベルでは残業すればするだけ残業代で懐が潤う、みたいな現場だと、収入が減ってしまうので効率化や生産性の向上をするモチベーションが保てない、ということもあるか。
プログラマの三大美徳を備えていないプログラマはプログラマではなくコーダーだ。そういう人たちばかりな SIer には未来がない、ということか。

大きな SIer になると動きも遅くなるし、組織が大きくなるにつれ制度に縛られて身動きがとりづらくなる。少人数、小さな組織で小回りをきかせながら SI をやって、そのなかで出来る人の給料をあげていく、という道。
# 「会社を少人数でやっている理由は給料をあげやすいから」というのが記憶に残っています


SIer に属する SE として今後どうしていくか？（スライド13ページ以降）

  • 考えるべきこと
    • マーケットがどう変化するか？
    • 変化するマーケットにどう自分自身をビッドするか？
    • 賭けるチップ（自分の能力）は手元にあるか？
  • 手持ちの武器は何が必要か？
    • 最強のカードは、複数の「最強-1」のカードには勝てない
    • 最強のカードになるにはかなりコストはかかるが、最強-1であれば実は真面目にやればいけてしまう

「最強-1」になるのにもかなりのコストがかかるのではないか、と何も武器を持っていない今の私は思います。
複数の興味の持てる分野について「最強-1」になろう、と思ったときにどう学習していくとよいのでしょうか。ある分野について、徹底的に学習してからその次の分野に着手するとよいのか、色々な分野に手を出しつつ少しずつ深度を深めていくとよいのか。人それぞれなのでしょうかね。自分にあったやりかたで勉強を進めていきましょう。
# このことを考えながら、学生時代にやってた探索手法を思い出しました。深さ優先探索とか、幅優先探索とか、反復深化とか。

  • 何をカードにしておくか

に関するそれぞれの解説がとても参考になりました。


まとめ（私の理解）

  • 今後の SIer および SIer に属するエンジニアには夢も希望もない。自分でこの先の未来を切り開いていかなくてはいけない。
  • ふつうのエンジニアは食べていくことが辛くなる
  • が、規模は縮小するとはいえ SI はなくならないし、ある程度マルチでできる能力があれば困ることはなさそう？
  • エンジニアとして自分は何を武器にしていくか？
  • 車輪の作り方をしっておく必要はあります（実際に作るべきかどうかは別）
  • 複数の領域で力を発揮できるように勉強しておきましょう


-「リファクタリングなんてしている時間はない」

SIerにいること、SIerの業務について

SI SIer

shiget84 は入社3年半が経過した。いま三連休だが、まさか休日出勤なんか行ってないよね？ここで仕事せずに遊びにいったり、リフレッシュしたりしている人だけが残れる人材ですからね。

参考：http://togetter.com/li/385963

私は10月6日（土）に出勤してました。振替休日は申請済です。大きな障害などなければ休めるはずです（とか言ってると起きたりしそうで怖いですね）


さて、その土曜日の帰りに同じ部署の1年先輩のかたとラーメンを食べながら話をしました。うちの部署は担当しているお客さまごとにグループがあり、私とその先輩は違うグループに属しているので一緒に仕事をしたことはないのですが、同じ部署で年齢も近いので、ときどき飲みにいったりしています。その先輩と短い時間ですが、食事をしながら仕事・仕事環境などについて話をしました。

いまの私は楽しく仕事をしています。チームメンバーと議論をし、ときにはお客さまと直接話をしながら設計を進めている、というのがここ2ヶ月くらいのお仕事。この後、実装からリリースまで担当する予定で、いわゆる「上流工程と下流工程の分断」が起きていない現場です。上流から下流まで自分が担当することができてとても勉強になる環境で働けること、お客さまと直接話ができる環境であること、チームメンバー・お客さまと協力して問題を解決しようと動けることなど、よい環境があり今はとても楽しく仕事ができています。

一方、先輩は「自分はスキルがついていないのではないか」ということを危惧していました。入社してからずっと保守ばかりを担当していて、開発を全然行っていないためスキルがついていないと感じる、保守に関してもお客さま固有の業務・システムなので汎用性がない、自分はこのままでよいのだろうか、ということを気にしているようです。
ちょっとラーメンを食べながら話をしていただけなので、先輩の欲している具体的なスキルは何だとか、社内で身に付かないなら休日に手を動かすなり勉強会に行くなりするといいよ、というような話はできなかったのですが、改めて思ったのは同じ会社・部署に所属していても普段の仕事内容が全然違うんだから、SIer と一言で言っても色々な業務内容がある、ということです。


SIer と一口に言っても元請けからn次受けまであり、自社開発と客先常駐では仕事内容も労働環境も全く異なります。
要件定義をやる人もいれば、設計をやる人もいる。実装をやる人・テストをやる人もいれば、リリース後の保守・運用をやる人もいる。アプリケーションエンジニアもいれば、インフラエンジニアもいる。色んな人が SIer には所属しています。同じ SIer の SE という立場でも、やっていることは全然違う。
たとえば弊社を考えてみても、私が所属しているのは主に開発を行う部署ですが、別の部署では保守・運用でお客さまのサポートを行うような部署もあります。開発をやるにしても、COBOLをやってる人もいればJavaをやっている人、Ruby on Railsをやってる人もいる。大きな会社になればなるほど仕事は分業化され、自分のグループ以外の人たちは全く種類の違うことをやっていたりします。
SIer といっても色んな会社があり、色んな仕事がある。そのなかで自分は何をやるのか。自分は今後、どのように生きていくのかー。


「スーツ vs ギーク」とか、「SIer はオワコン」とか色々な話題がここ数年あり、今年に入ってからは SIer のエンジニアを対象としたようなイベントも開催されています。

そして明日は、『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE』ですね。私も参加します。
私はSIは楽しくやりがいのある仕事だと思っていますが、それはたまたま今の自分の環境が自分にマッチしていただけなのかもしれません。もしも、新入社員として配属された部署で全く違うことをしていたら、今ごろ転職をしていたかもしれません。SIer といっても色んな仕事があり、たまたま自分が最初に開発をやる部署に配属されたから、運がよかったから今の自分がいるのかもしれません。
私は今4年目。来年の4月には5年目となります。大学院卒で就職したので、年齢としては7年目の人たちと同じ。そろそろ中堅どころということを意識していく必要があります。自分が今後、SIer で働いていくうえでどういう意識をもっていくのか。しっかり考えていきたいと思います。

高専カンファレンス in 東京に参加しました

kosenconf presentation

高専カンファレンス in 東京 (kosenconf-045tokyo) に参加してきました。

 

http://kosenconf.jp/?045tokyo

http://kc045tokyo.heroku.com/

 

全員発表者な開催（後に定員を増やした10人には公式な発表枠はなし）という開催で、僕は「しげっとが地方の SIer に就職して3年が過ぎました」という発表をしてきました。内容は僕のこれまでの3年間の SIer 生活の総括で、SIer に入社した新人さんに向けたメッセージのつもりで準備しました。

http://speakerdeck.com/u/shiget84/p/sier-3

 

僕は SIer に入社して3ヶ月程度の研修期間が終わった後、とあるお客さんを担当するチームに配属になって保守や派生開発を2年目の3月末までやってました。そして3年目になった4月から別のチームにうつり、1年ほど仕事をしてきました。そこで感じたことは、同じ会社で同じ部署・同じ課にいても、チームによってやること・内容・やりかたが全然違うということ。ただそれは当たり前で、お客さんによって欲しいものはそれぞれ違っていて、そのお客さまに応じたソリューションを提供するには、当然やりかたも違ってきます。それに気づけたのがとても大きかったです。

前のチームが自分にとってあっていなかったのか、というところはじっくり考える必要がありますが、個人的には今のほうがよりイキイキと仕事ができているんじゃないかと思います。その要因は何なのか。チームが変わったことにより、お客さんのドメインが変わったことなのか、お客さんとの距離が近くなったことなのか、使ってる技術が変わったことなのか、日々の仕事の進め方が変わったことなのか、チームの方針が変わったことなのか、それ以外なのか、これらどれもが影響しているのか。

少なくとも、この１年間はこれまでとは全くちがったことを、違ったやりかたでやることができ、とても貴重な経験ができました。チームが変わったからこそ、今みえてる世界があるのだな、と。（チームが変わらなかったら、それはそれで今とは別の価値のある世界が見えていたのかもしれませんが。）　チームが変わることで、全く別の経験をすることができ、視野も広がった気がします。つらいときもあったけど、振り返ってみるととてもよい3年間を過ごすことができたな、と思います。

 

そして、3年間をふりかえるなかで欠かせない存在が高専カンファレンス（ #kosenconf ）です。2008年に開催された 003tokyo などは、行きたいと思っていつつも北陸（石川）から東京という距離、そして修論執筆という時期により参加することができませんでした。その後、 004fukui に参加し、就職を機に神奈川に引っ越しをし、東京開催（009tokyo, 014tokyo）のスタッフや、地方開催などに参加してきました。僕の社会人生活は、高専カンファレンスとともにあったと言っても過言ではありません。そして、高専カンファレンスをきっかけに、オブラブのイベントや RubyKaigi に参加したりもしました。

高専カンファレンスが縁で色々な人と知り合い、勉強会や食事などにも行ったりして、いろいろな経験ができたからこそ今の自分がいるのだと思います。本当に、高専カンファレンスには感謝してもしきれません。ありがとうございます。

 

 

これらのことをまとめたところ、今回のプレゼンテーションになりました。

http://speakerdeck.com/u/shiget84/p/sier-3

うまくまとまらなかったりしてお聞き苦しいところもあったかと思いますが、ご清聴いただきありがとうございました。

 

 

 

さて、最近の僕の発表はコミュニティなどがテーマになっているものが多かったので、そろそろ何か技術的な発表がしたいところですね！

またどこかの高専カンファレンス・勉強会でお会いしましょう。ありがとうございました。

僕が今年度の新人の教育係になったらまずオススメしたい書籍３冊

プログラミング

こんにちは！　こんにちは！　4月1日ですね、2012年度がはじまりました！

みなさん、入学・進級・入社、おめでとうございます！　僕は2009年に SIer に就職して今年度で4年目になります。そろそろ新入社員の教育係のようなお仕事が任されるんじゃないかとわくわくしています。

そこで、もしも自分が新入社員の教育係になったとしたら、この本をオススメしたいというものをリストアップしてみることにしました。ここで新入社員というのは、これまでプログラミング等には関わってこなかった弊社の新入社員を想定していますが、特に弊社固有のことを書いているわけではないので、ほかの方々でも参考になるかと思います。参考になれば幸いです。

また、あまり多くリストアップしても読めないし、同じ本でも読む時期によって違いはあるので、僕が新人だったらまずこの3冊を読みたかった、これらをエンジニアになりたてのころに読んでいたら世界が変わったかもしれない、という本について取り上げました。

 

1. プログラマが知るべき97のこと

プログラマが知るべき97のこと

プログラマが知るべき97のこと

世界中で活躍するプログラマたちの97+10本のエッセイ集。グッとくることがいっぱい書いてあるので、何度も何度も読み返したい一冊になるだろう1冊。しかし、今までプログラムを書くことしてこなかった人にはよく分からない話も多々ありそう。その場合には、以下のものだけでも読んでほしいな、と僕は思います。

 

2. 良いコードを書く技術

良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)

良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)

僕が受けた4月の新人研修では、上旬に社会人としての基本的なことを教わり、中旬にシステム開発入門みたいな講義があって、下旬にプログラミング研修がありました。プログラミング研修は Java で行われたのですが、1週間程度の限られた時間だったので基本的な文法とその使いかたに関する説明および演習があったくらいでした。その演習を受けたあとに、一歩すすみだすときにオススメしたいのがこの1冊です。

プログラムは動くものを作ることが大切だけれども、ただ動くものをつくればよいというわけではない。悪いコードではなく良いコードを書いて行く必要があり、そのために「良いコードとは何か」ということを知ることができる本書はおすすめです。

後半になるにつれ、全くの初心者が読み進めていくのはつらくなりますが、最初にすべてを理解する必要はなく、まずは第8章 ユニットテストあたりまでを少しずつ読み進めていければ力がついていくのではないか、と思います。

 

3. 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

本人にやる気がなければいくら社内の研修をやったり本を薦めたところで良いエンジニアにはなれません。では、どうやって本人にやる気を出してもらうか、それは「自分はこうなりたい」という目標を持つことではないでしょうか。最初は「○○さんみたいになりたい」というところから始まるのかもしれません、しかし何かを目標に自分で一歩ずつ進んで行くことによって自分の道は見えてくることでしょう。

その際に参考になるのではないかと僕が思うのがこの本。その道のプロが「△△に贈りたい1冊」という内容で書いてる記事を読むことで、自分がどういうエンジニアになりたいかを考えるきっかけとなることでしょう。そして、推奨されている本を読んだり、その道のプロの blog を読んだりすることでやる気が持続し、学習も続けて行けるようになるのではないでしょうか。

 

 

 

まとめ

「もし僕が新入社員の教育係になったら」ということから、3冊おすすめの本をリストアップしてみました。リストアップしてみて、まずは技術うんぬんよりも考え方を身につけてることが重要なんだと僕は考えているのだということを認識しました。このエントリがこれからエンジニアになろうと一歩踏み出したプログラミング未経験の新入社員さんの参考になれば幸いです。

 

 

関連記事・リンク

以下の記事をみて、「blog に書こう」と思いました。

昨年の企画ですが、とてもグッとくるものがありました。