エンジニアのとるべき   8つの行動
はじめに
これからの時代を生きていく   エンジニアとして わたしが大事だと思う   8つの行動  を集めてみました。
別に全てを実践しないといけないというわけではなくて自分が必要だと感じたことに取り組んで頂ければと思います。
また、これからの自分に  何が必要なのか? といったことを改めて考えるきっかけにしてもらえば幸いです。
それでは1つずついきましょう。
(その1)ノウハウではなくノウフーを知るべし(know how)   (know who)
know how           (やり方を知る)エンジニアとして様々なノウハウを身に付けることはとても大事なことです。でもそれよりも大事なことがあります。
know whoそれは      (誰か?を知る)ノウフー(誰が知っているか?)を知ることです。
なぜならノウフーを知ることはノウハウを得るための一番の近道だからです。
ノウハウを身に付ける一番の方法はすでにノウハウを持っている人に 教えてもらうこと  または 盗むこと  です。
しかしノウフーを知らなければこれは実践できません。
ノウフーを知りましょう。
ノウフーは必ずしも社内やプロジェクト内等の身近な人でなくても構いません。
社外の人や全く知らない人でもTwitterでフォローしたりブログをチェックしたりするだけで構いません。
きっとそれだけでも鮮度の高い情報に触れられることでしょう。または体系的な知識を得ることも出来るかもしれません。
まずは各分野の第一人者を探すところから始めましょう。
ビッグデータ                    アジャイル鈴木良介氏               @ryuzee        Ruby   @yukihiro_matz
とある本の1ページ
(その2)CやJavaや○○ではなく  英語を習得すべし
みなさんは「エンジニアの必須習得言語は?」と聞かれたらなんと答えますか?
それは間違いなく英語です。
例えば日本のOSS例えば日本のクラウド例えば日本発端のパラダイムって何が思い浮かびます?
それとは逆に
例えば海外のOSS例えば海外のクラウド例えば海外発端のパラダイムって何が思い浮かびます?
残念ながらIT業界における技術革新はほとんど海外で起こっています。
そういった情報をキャッチするためには英語が読めなければなりません。(別に話せなくてもいいです)
ではどうすれば読めるようになるのでしょう?
簡単です。
慣れです。
「えぇぇぇ∼∼∼」    「そんなバカにゃ・・・」
と思ったそこのあなた!!とっても良い勉強法があります。
自分が使ったことのあるOSSを1つ選んでください。
そしてそのコミュニティページのドキュメントを読みましょう。
はじめはWeb上の翻訳サイトや英和辞典等を駆使して1文ずつ丁寧に訳しましょう。
×何章かこなしたら今度は分からない箇所は読み飛ばして全体を予測するようにします。          ×
基本的な英単語力さえつけば細かい1つ1つの意味が分からなくても何となく読み取れるようになるでしょう。(OSSについての前提知識があるので)
この勉強法ではOSSの知識/知見も深められるし英語にも慣れるし一石二鳥です。
とある本の1ページ
ちなみにわたしのオススメはわたしの大好きSpringです。http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
(その3)楽しくなるまでやり通すべし
新しい言語を学ぶとき新しいOSSを学ぶとき新しい○○を学ぶとき楽しんで学べていますか?
なんとなくやってみたけど「なんか面白くないな∼」と思って中途半端な状態で学びをやめていたりしませんか?
どんなことでもそうだと思いますが「出来る   ≒ 楽しい」という方程式が成り立ちます。
つまり初めは大体つまらないのです。(だって初めは出来ないですから)
大事なのは楽しくなるまでやり通すことです。
それは(ある程度)出来るようになったことを意味します。
楽しくなるまでやり通しましょう。
とある本の1ページ
(その4)   固定概念を捨て脳みそのブレーキを壊すべし
「仕事はこうやるもの」「設計はこうやるもの」「コードはこう書くもの」・・・と決め付けていませんか?
こういう固定概念を持っているとなかなか新しいパラダイムを取り入れることができません。
身近な例をあげましょう。
たとえばCとJavaでは良いとされるコードの書き方が違います。
※Cの場合          メソッドの頭で          変数を定義                                      実行結果   http://saeki-ce.xsrv.jp/C_src/kakezan01....
※Javaの場合                 実行結果           使用する場所で           変数を定義
Cしか知らない人が「コードはこう書くもの」と決め付けてJavaの例を見たらどう思うでしょう?
きっと「変数定義がまとまってないから分かりづらい」とか
「これを書いた人はプログラムの基本が分かっていない」とか思っちゃうんじゃないでしょうか?
ん?ひょっとして僕ちん間違ってる??
自分がこれまで学んできたことを絶対だと思ってはいけません。
世の中にはもっと色んな思考/指向/志向が存在するしコンテキストが変われば正解も変わります。
固定概念は脳みそにブレーキをかけ「新しいパラダイムを受け入れる」ことを制限します。
固定概念を捨てて脳みそのブレーキを壊しましょう。
とある本の1ページ
(その5)自分に投資すべし
書籍を買い渋ったりしていませんか?
研修費用を出し渋ったりしていませんか?
自分へ投資しなくなった時点から自分の退化が始まります。
本を買うも良し研修に参加するも良し他のエンジニアと食事会をするも良し
どんなことでも良いので自分にお金を投資してください。
そしてもうひとつ
自分に時間を投資しましょう。
業務外でどれだけの時間学びに当てていますか?
勉強会に参加する時間をとるも良し読書する時間をとるも良しコードを書く時間をとるも良し
どんなことでも良いので自分に時間を投資してください。
お金と時間をかけて自分の価値を育てましょう。
とある本の1ページ
(その6)設計するな、コードを書くべし
時代は変わりました。「ちゃんと設計すればちゃんとしたものが出来る」という時代は終わりました。
そういう時代だと思っているのは日本(のSI業界)だけです。
これには日本特有の多重請負構造が多分に関係していて元請け/一次請け/・・・といった企業が潤うためにこういう思想が根深く残ってしまっています。
こういういわゆる上流工程だけ担当する企業は 設計して 責任範囲を決定して 切り売りして ピンはねして
という稼ぎ方をします。・・・これ以上は本題をズレるのでまたの機会に(^^;)
繰り返しになりますが時代は変わりました。
ひと昔前のように「要件を満たすために設計し」「設計を満たすためにコードを書く」ということをやっていたら絶対にうまくいきません
その要因はいろいろあると思いますが一番はEoD(Ease of Development)に代表されるような設計領域の変化にあると思います。
昔のように 全領域フルスクラッチ開発であれば如何様に設計してもコードは書けたでしょう。
しかし様々なOSSがエンタープライズの世界に登場してきた昨今では「如何様に設計しても」では実現不可能なのです。
なぜならOSSにはそれ自身の設計思想がありその思想にそぐわないものは受入れられないからです。
これからのエンジニアに求められるスキルはそういったOSSの設計思想の上に要件を満たす設計をインクリメンタルに実施できるスキルであると思います。
そのためにはまず「OSSの設計思想を理解している」という前提はハズせません。
となると必然的にコードを書かざるを得ないのです。
実際にコードを書いてみないと設計思想なんて理解できないですから。
コードを書けないエンジニアはいりません。              きてます               きてますそういう時代がきます。
要件を満たすためだけの設計をしてはいけません。
責任範囲を明確にするだけの設計をしてはいけません。
設計はコードと共に在り常に実現性と隣り合わせでなければなりません。
コードの中に答えがあります。たくさんのコードを書きましょう。
とある本の1ページ
(その7)検索するな、本を読むべし
便利な世の中になりました。仕事中に分からないことがあってもググれば大抵のことは答えが得られます
しかし、それで満足していてはいけません。知識というものはもっと深くて広いコンテキストで構成されています。
たとえば日本で生産される果物の名産地を知りたいとします。
みかんの名産地は?とググれば愛媛・和歌山という結果が得られるでしょう。
りんごの名産地は?とググれば青森・長野という結果が得られるでしょう。
しかしこれらのことが分かったとしてもその他の果物についてやなぜその地区が名産地なのか?については理解できません。
これらのことを知るためには・・・そう、地理の本ですね。
地理の本の中にはその他の果物についてもなぜその地区が名産地なのか?についても懇切丁寧に載っていると思います。
このように
ある事象に関するコンテキストを理解するためにはそれに付随する周辺知識も必要です。
本にはそういった周辺知識も合わせて詰まっていることが多いのでコンテキストを理解することを助けます。
もちろん本にも当たりハズレはありますが当たりの本を引くのはとても簡単です。
(その1)ノウハウではなくノウフーを知るべし(know how)   (know who)
の教訓を活かしノウフーを知れば良いのです。    know who    (誰か?を知る)
その人が良いと言っている本はたぶん当たりでしょう。
たくさんの本を読んで幅広いそして思慮深いエンジニアを目指しましょう。
とある本の1ページ
(その8)残業するな、勉強会へ行くべし
残業が当たり前となっていないですか?それはとても残念なことです。
なぜなら自分を磨く時間を日々削ってしまっているのですから。
残業する暇(?)があるくらいなら勉強会へ参加しましょう。
そちら方が残業するよりも得るものが大きい&多いと思います。
新しいエンジニアとの出会いが自分を大きく育ててくれるかもしれません。
新しい技術との出会いが自分を新しい世界へ導いてくれるかもしれません。
大事なのは残業しているということは自分を磨く時間を削っていることだと認識することです。
時間は有限です。自分のために時間を使いましょう。
とある本の1ページ
さいごに
ここでまとめた8つの行動はSI業界で生きていくだけなら必要のないことかもしれません。
なぜならこの業界は「ディフェンシブな開発」で成り立っているからです。 http://d.hatena.ne.jp/kuranuki/20060116/p1
しかし今後、SI市場はシュリンクしSIだけでは食えない時代が必ず来ます。
そんな時代を生き抜いていくためのエンジニアにとって大切な行動をまとめたつもりです。
きっとSIの中でこれらの行動を実践していくのは難しいことも多いでしょう。
色んな抵抗もあると思います。(「残業しない = 頑張ってない」と思われたりしますしね)
でも流されないでください。自分を成長させることができるのは自分しかいません
まだ見ぬ未来の成長した自分に出会うため周りではなく自分を見つめて自分で判断してください。自分で道を切り開いてください。
自分はなりたい自分にしかなれません。
とある本の1ページ
おしまい
エンジニアがとるべき8つの行動
エンジニアがとるべき8つの行動
Upcoming SlideShare
Loading in …5
×

エンジニアがとるべき8つの行動

1,952 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,952
On SlideShare
0
From Embeds
0
Number of Embeds
883
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

エンジニアがとるべき8つの行動

  1. 1. エンジニアのとるべき 8つの行動
  2. 2. はじめに
  3. 3. これからの時代を生きていく エンジニアとして わたしが大事だと思う 8つの行動 を集めてみました。
  4. 4. 別に全てを実践しないといけないというわけではなくて自分が必要だと感じたことに取り組んで頂ければと思います。
  5. 5. また、これからの自分に 何が必要なのか? といったことを改めて考えるきっかけにしてもらえば幸いです。
  6. 6. それでは1つずついきましょう。
  7. 7. (その1)ノウハウではなくノウフーを知るべし(know how) (know who)
  8. 8. know how (やり方を知る)エンジニアとして様々なノウハウを身に付けることはとても大事なことです。でもそれよりも大事なことがあります。
  9. 9. know whoそれは (誰か?を知る)ノウフー(誰が知っているか?)を知ることです。
  10. 10. なぜならノウフーを知ることはノウハウを得るための一番の近道だからです。
  11. 11. ノウハウを身に付ける一番の方法はすでにノウハウを持っている人に 教えてもらうこと  または 盗むこと  です。
  12. 12. しかしノウフーを知らなければこれは実践できません。
  13. 13. ノウフーを知りましょう。
  14. 14. ノウフーは必ずしも社内やプロジェクト内等の身近な人でなくても構いません。
  15. 15. 社外の人や全く知らない人でもTwitterでフォローしたりブログをチェックしたりするだけで構いません。
  16. 16. きっとそれだけでも鮮度の高い情報に触れられることでしょう。または体系的な知識を得ることも出来るかもしれません。
  17. 17. まずは各分野の第一人者を探すところから始めましょう。
  18. 18. ビッグデータ アジャイル鈴木良介氏 @ryuzee Ruby @yukihiro_matz
  19. 19. とある本の1ページ
  20. 20. (その2)CやJavaや○○ではなく 英語を習得すべし
  21. 21. みなさんは「エンジニアの必須習得言語は?」と聞かれたらなんと答えますか?
  22. 22. それは間違いなく英語です。
  23. 23. 例えば日本のOSS例えば日本のクラウド例えば日本発端のパラダイムって何が思い浮かびます?
  24. 24. それとは逆に
  25. 25. 例えば海外のOSS例えば海外のクラウド例えば海外発端のパラダイムって何が思い浮かびます?
  26. 26. 残念ながらIT業界における技術革新はほとんど海外で起こっています。
  27. 27. そういった情報をキャッチするためには英語が読めなければなりません。(別に話せなくてもいいです)
  28. 28. ではどうすれば読めるようになるのでしょう?
  29. 29. 簡単です。
  30. 30. 慣れです。
  31. 31. 「えぇぇぇ∼∼∼」 「そんなバカにゃ・・・」
  32. 32. と思ったそこのあなた!!とっても良い勉強法があります。
  33. 33. 自分が使ったことのあるOSSを1つ選んでください。
  34. 34. そしてそのコミュニティページのドキュメントを読みましょう。
  35. 35. はじめはWeb上の翻訳サイトや英和辞典等を駆使して1文ずつ丁寧に訳しましょう。
  36. 36. ×何章かこなしたら今度は分からない箇所は読み飛ばして全体を予測するようにします。 ×
  37. 37. 基本的な英単語力さえつけば細かい1つ1つの意味が分からなくても何となく読み取れるようになるでしょう。(OSSについての前提知識があるので)
  38. 38. この勉強法ではOSSの知識/知見も深められるし英語にも慣れるし一石二鳥です。
  39. 39. とある本の1ページ
  40. 40. ちなみにわたしのオススメはわたしの大好きSpringです。http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
  41. 41. (その3)楽しくなるまでやり通すべし
  42. 42. 新しい言語を学ぶとき新しいOSSを学ぶとき新しい○○を学ぶとき楽しんで学べていますか?
  43. 43. なんとなくやってみたけど「なんか面白くないな∼」と思って中途半端な状態で学びをやめていたりしませんか?
  44. 44. どんなことでもそうだと思いますが「出来る ≒ 楽しい」という方程式が成り立ちます。
  45. 45. つまり初めは大体つまらないのです。(だって初めは出来ないですから)
  46. 46. 大事なのは楽しくなるまでやり通すことです。
  47. 47. それは(ある程度)出来るようになったことを意味します。
  48. 48. 楽しくなるまでやり通しましょう。
  49. 49. とある本の1ページ
  50. 50. (その4) 固定概念を捨て脳みそのブレーキを壊すべし
  51. 51. 「仕事はこうやるもの」「設計はこうやるもの」「コードはこう書くもの」・・・と決め付けていませんか?
  52. 52. こういう固定概念を持っているとなかなか新しいパラダイムを取り入れることができません。
  53. 53. 身近な例をあげましょう。
  54. 54. たとえばCとJavaでは良いとされるコードの書き方が違います。
  55. 55. ※Cの場合 メソッドの頭で 変数を定義 実行結果 http://saeki-ce.xsrv.jp/C_src/kakezan01.html
  56. 56. ※Javaの場合 実行結果 使用する場所で 変数を定義
  57. 57. Cしか知らない人が「コードはこう書くもの」と決め付けてJavaの例を見たらどう思うでしょう?
  58. 58. きっと「変数定義がまとまってないから分かりづらい」とか
  59. 59. 「これを書いた人はプログラムの基本が分かっていない」とか思っちゃうんじゃないでしょうか?
  60. 60. ん?ひょっとして僕ちん間違ってる??
  61. 61. 自分がこれまで学んできたことを絶対だと思ってはいけません。
  62. 62. 世の中にはもっと色んな思考/指向/志向が存在するしコンテキストが変われば正解も変わります。
  63. 63. 固定概念は脳みそにブレーキをかけ「新しいパラダイムを受け入れる」ことを制限します。
  64. 64. 固定概念を捨てて脳みそのブレーキを壊しましょう。
  65. 65. とある本の1ページ
  66. 66. (その5)自分に投資すべし
  67. 67. 書籍を買い渋ったりしていませんか?
  68. 68. 研修費用を出し渋ったりしていませんか?
  69. 69. 自分へ投資しなくなった時点から自分の退化が始まります。
  70. 70. 本を買うも良し研修に参加するも良し他のエンジニアと食事会をするも良し
  71. 71. どんなことでも良いので自分にお金を投資してください。
  72. 72. そしてもうひとつ
  73. 73. 自分に時間を投資しましょう。
  74. 74. 業務外でどれだけの時間学びに当てていますか?
  75. 75. 勉強会に参加する時間をとるも良し読書する時間をとるも良しコードを書く時間をとるも良し
  76. 76. どんなことでも良いので自分に時間を投資してください。
  77. 77. お金と時間をかけて自分の価値を育てましょう。
  78. 78. とある本の1ページ
  79. 79. (その6)設計するな、コードを書くべし
  80. 80. 時代は変わりました。「ちゃんと設計すればちゃんとしたものが出来る」という時代は終わりました。
  81. 81. そういう時代だと思っているのは日本(のSI業界)だけです。
  82. 82. これには日本特有の多重請負構造が多分に関係していて元請け/一次請け/・・・といった企業が潤うためにこういう思想が根深く残ってしまっています。
  83. 83. こういういわゆる上流工程だけ担当する企業は 設計して 責任範囲を決定して 切り売りして ピンはねして
  84. 84. という稼ぎ方をします。・・・これ以上は本題をズレるのでまたの機会に(^^;)
  85. 85. 繰り返しになりますが時代は変わりました。
  86. 86. ひと昔前のように「要件を満たすために設計し」「設計を満たすためにコードを書く」ということをやっていたら絶対にうまくいきません
  87. 87. その要因はいろいろあると思いますが一番はEoD(Ease of Development)に代表されるような設計領域の変化にあると思います。
  88. 88. 昔のように 全領域フルスクラッチ開発であれば如何様に設計してもコードは書けたでしょう。
  89. 89. しかし様々なOSSがエンタープライズの世界に登場してきた昨今では「如何様に設計しても」では実現不可能なのです。
  90. 90. なぜならOSSにはそれ自身の設計思想がありその思想にそぐわないものは受入れられないからです。
  91. 91. これからのエンジニアに求められるスキルはそういったOSSの設計思想の上に要件を満たす設計をインクリメンタルに実施できるスキルであると思います。
  92. 92. そのためにはまず「OSSの設計思想を理解している」という前提はハズせません。
  93. 93. となると必然的にコードを書かざるを得ないのです。
  94. 94. 実際にコードを書いてみないと設計思想なんて理解できないですから。
  95. 95. コードを書けないエンジニアはいりません。 きてます  きてますそういう時代がきます。
  96. 96. 要件を満たすためだけの設計をしてはいけません。
  97. 97. 責任範囲を明確にするだけの設計をしてはいけません。
  98. 98. 設計はコードと共に在り常に実現性と隣り合わせでなければなりません。
  99. 99. コードの中に答えがあります。たくさんのコードを書きましょう。
  100. 100. とある本の1ページ
  101. 101. (その7)検索するな、本を読むべし
  102. 102. 便利な世の中になりました。仕事中に分からないことがあってもググれば大抵のことは答えが得られます
  103. 103. しかし、それで満足していてはいけません。知識というものはもっと深くて広いコンテキストで構成されています。
  104. 104. たとえば日本で生産される果物の名産地を知りたいとします。
  105. 105. みかんの名産地は?とググれば愛媛・和歌山という結果が得られるでしょう。
  106. 106. りんごの名産地は?とググれば青森・長野という結果が得られるでしょう。
  107. 107. しかしこれらのことが分かったとしてもその他の果物についてやなぜその地区が名産地なのか?については理解できません。
  108. 108. これらのことを知るためには・・・そう、地理の本ですね。
  109. 109. 地理の本の中にはその他の果物についてもなぜその地区が名産地なのか?についても懇切丁寧に載っていると思います。
  110. 110. このように
  111. 111. ある事象に関するコンテキストを理解するためにはそれに付随する周辺知識も必要です。
  112. 112. 本にはそういった周辺知識も合わせて詰まっていることが多いのでコンテキストを理解することを助けます。
  113. 113. もちろん本にも当たりハズレはありますが当たりの本を引くのはとても簡単です。
  114. 114. (その1)ノウハウではなくノウフーを知るべし(know how) (know who)
  115. 115. の教訓を活かしノウフーを知れば良いのです。 know who (誰か?を知る)
  116. 116. その人が良いと言っている本はたぶん当たりでしょう。
  117. 117. たくさんの本を読んで幅広いそして思慮深いエンジニアを目指しましょう。
  118. 118. とある本の1ページ
  119. 119. (その8)残業するな、勉強会へ行くべし
  120. 120. 残業が当たり前となっていないですか?それはとても残念なことです。
  121. 121. なぜなら自分を磨く時間を日々削ってしまっているのですから。
  122. 122. 残業する暇(?)があるくらいなら勉強会へ参加しましょう。
  123. 123. そちら方が残業するよりも得るものが大きい&多いと思います。
  124. 124. 新しいエンジニアとの出会いが自分を大きく育ててくれるかもしれません。
  125. 125. 新しい技術との出会いが自分を新しい世界へ導いてくれるかもしれません。
  126. 126. 大事なのは残業しているということは自分を磨く時間を削っていることだと認識することです。
  127. 127. 時間は有限です。自分のために時間を使いましょう。
  128. 128. とある本の1ページ
  129. 129. さいごに
  130. 130. ここでまとめた8つの行動はSI業界で生きていくだけなら必要のないことかもしれません。
  131. 131. なぜならこの業界は「ディフェンシブな開発」で成り立っているからです。 http://d.hatena.ne.jp/kuranuki/20060116/p1
  132. 132. しかし今後、SI市場はシュリンクしSIだけでは食えない時代が必ず来ます。
  133. 133. そんな時代を生き抜いていくためのエンジニアにとって大切な行動をまとめたつもりです。
  134. 134. きっとSIの中でこれらの行動を実践していくのは難しいことも多いでしょう。
  135. 135. 色んな抵抗もあると思います。(「残業しない = 頑張ってない」と思われたりしますしね)
  136. 136. でも流されないでください。自分を成長させることができるのは自分しかいません
  137. 137. まだ見ぬ未来の成長した自分に出会うため周りではなく自分を見つめて自分で判断してください。自分で道を切り開いてください。
  138. 138. 自分はなりたい自分にしかなれません。
  139. 139. とある本の1ページ
  140. 140. おしまい

×