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

2. はじめに

3. これからの時代を生きていく
エンジニアとして
わたしが大事だと思う
8つの行動
を集めてみました。

4. 別に全てを実践しないといけない
というわけではなくて
自分が必要だと感じたことに
取り組んで頂ければと思います。

5. また、これからの自分に
何が必要なのか？
といったことを改めて考える
きっかけにしてもらえば幸いです。

6. それでは１つずついきましょう。

7. （その1）
ノウハウではなくノウフーを知るべし
（know how） （know who）

8. know how
（やり方を知る）
エンジニアとして
様々なノウハウを身に付けること
はとても大事なことです。
でもそれよりも大事なこと
があります。

9. know who
それは
（誰か？を知る）
ノウフー(誰が知っているか？)
を知ることです。

10. なぜならノウフーを知ることは
ノウハウを得るための一番の近道
だからです。

11. ノウハウを身に付ける一番の方法は
すでにノウハウを持っている人に
教えてもらうこと
または
盗むこと
です。

12. しかしノウフーを知らなければ
これは実践できません。

13. ノウフーを知りましょう。

14. ノウフーは必ずしも
社内やプロジェクト内等の
身近な人でなくても構いません。

15. 社外の人や全く知らない人でも
Twitterでフォローしたり
ブログをチェックしたり
するだけで構いません。

16. きっとそれだけでも鮮度の高い
情報に触れられることでしょう。
または体系的な知識を得ること
も出来るかもしれません。

17. まずは各分野の第一人者を探す
ところから始めましょう。

18. ビッグデータ
アジャイル
鈴木良介氏 @ryuzee
Ruby
@yukihiro_matz

19. とある本の１ページ

20. （その2）
CやJavaや○○ではなく
英語を習得すべし

21. みなさんは
「エンジニアの必須習得言語は？」
と聞かれたらなんと答えますか？

22. それは間違いなく英語です。

23. 例えば日本のOSS
例えば日本のクラウド
例えば日本発端のパラダイム
って何が思い浮かびます？

24. それとは逆に

25. 例えば海外のOSS
例えば海外のクラウド
例えば海外発端のパラダイム
って何が思い浮かびます？

26. 残念ながら
IT業界における技術革新は
ほとんど海外で起こっています。

27. そういった情報をキャッチするためには
英語が読めなければなりません。
（別に話せなくてもいいです）

28. ではどうすれば読めるように
なるのでしょう？

29. 簡単です。

30. 慣れです。

31. 「えぇぇぇ∼∼∼」
「そんなバカにゃ・・・」

32. と思ったそこのあなた！！
とっても良い勉強法があります。

33. 自分が使ったことのあるOSSを
1つ選んでください。

34. そしてそのコミュニティページの
ドキュメントを読みましょう。

35. はじめはWeb上の翻訳サイトや
英和辞典等を駆使して
１文ずつ丁寧に訳しましょう。

36. ×
何章かこなしたら今度は分からない
箇所は読み飛ばして全体を予測
するようにします。
×

37. 基本的な英単語力さえつけば
細かい１つ１つの意味が分からな
くても何となく読み取れるよう
になるでしょう。
（OSSについての前提知識があるので）

38. この勉強法では
OSSの知識／知見も深められるし
英語にも慣れるし
一石二鳥です。

39. とある本の１ページ

40. ちなみにわたしのオススメは
わたしの大好きSpringです。
http://static.springsource.org/spring/docs/3.0.x/
spring-framework-reference/html/

41. （その3）
楽しくなるまでやり通すべし

42. 新しい言語を学ぶとき
新しいOSSを学ぶとき
新しい○○を学ぶとき
楽しんで学べていますか？

43. なんとなくやってみたけど
「なんか面白くないな∼」
と思って中途半端な状態で学びを
やめていたりしませんか？

44. どんなことでもそうだと思いますが
「出来る ≒ 楽しい」
という方程式が成り立ちます。

45. つまり
初めは大体つまらないのです。
（だって初めは出来ないですから）

46. 大事なのは
楽しくなるまで
やり通すことです。

47. それは（ある程度）
出来るようになったこと
を意味します。

48. 楽しくなるまでやり通しましょう。

49. とある本の１ページ

50. （その4）
固定概念を捨て
脳みそのブレーキを壊すべし

51. 「仕事はこうやるもの」
「設計はこうやるもの」
「コードはこう書くもの」
・・・と決め付けていませんか？

52. こういう固定概念を持っていると
なかなか新しいパラダイムを
取り入れることができません。

53. 身近な例をあげましょう。

54. たとえばCとJavaでは
良いとされるコードの書き方が
違います。

55. ※Cの場合
メソッドの頭で
変数を定義
実行結果
http://saeki-ce.xsrv.jp/C_src/kakezan01.html

56. ※Javaの場合
実行結果
使用する場所で
変数を定義

57. Cしか知らない人が
「コードはこう書くもの」
と決め付けてJavaの例を見たら
どう思うでしょう？

58. きっと
「変数定義がまとまってないから
分かりづらい」
とか

59. 「これを書いた人はプログラムの
基本が分かっていない」
とか思っちゃうんじゃないでしょうか？

60. ん？
ひょっとして僕ちん
間違ってる？？

61. 自分がこれまで学んできたことを
絶対だと思ってはいけません。

62. 世の中にはもっと色んな
思考／指向／志向
が存在するし
コンテキストが変われば正解も
変わります。

63. 固定概念は脳みそにブレーキをかけ
「新しいパラダイムを受け入れる」
ことを制限します。

64. 固定概念を捨てて
脳みそのブレーキを壊しましょう。

65. とある本の１ページ

66. （その5）
自分に投資すべし

67. 書籍を買い渋ったり
していませんか？

68. 研修費用を出し渋ったり
していませんか？

69. 自分へ投資しなくなった時点から
自分の退化が始まります。

70. 本を買うも良し
研修に参加するも良し
他のエンジニアと食事会をするも良し

71. どんなことでも良いので自分に
お金を投資してください。

72. そしてもうひとつ

73. 自分に時間を投資しましょう。

74. 業務外でどれだけの時間学びに
当てていますか？

75. 勉強会に参加する時間をとるも良し
読書する時間をとるも良し
コードを書く時間をとるも良し

76. どんなことでも良いので自分に
時間を投資してください。

77. お金と時間をかけて自分の価値
を育てましょう。

78. とある本の１ページ

79. （その6）
設計するな、コードを書くべし

80. 時代は変わりました。
「ちゃんと設計すれば
ちゃんとしたものが出来る」
という時代は終わりました。

81. そういう時代だと思っているのは
日本(のSI業界)だけです。

82. これには日本特有の
多重請負構造が多分に関係していて
元請け／一次請け／・・・といった企業が
潤うためにこういう思想が根深く残っ
てしまっています。

83. こういういわゆる上流工程だけ担当
する企業は
設計して
責任範囲を決定して
切り売りして
ピンはねして

84. という稼ぎ方をします。
・・・これ以上は本題をズレるので
またの機会に（^^;）

85. 繰り返しになりますが
時代は変わりました。

86. ひと昔前のように
「要件を満たすために設計し」
「設計を満たすためにコードを書く」
ということをやっていたら絶対に
うまくいきません

87. その要因はいろいろあると思いますが
一番はEoD(Ease of Development)に
代表されるような設計領域の変化に
あると思います。

88. 昔のように
全領域フルスクラッチ開発
であれば
如何様に設計してもコードは書けた
でしょう。

89. しかし様々なOSSがエンタープライズの
世界に登場してきた昨今では
「如何様に設計しても」
では実現不可能なのです。

90. なぜならOSSには
それ自身の設計思想があり
その思想にそぐわないものは
受入れられないからです。

91. これからのエンジニアに求められるスキルは
そういったOSSの設計思想の上に
要件を満たす設計を
インクリメンタルに実施できる
スキルであると思います。

92. そのためにはまず
「OSSの設計思想を理解している」
という前提はハズせません。

93. となると必然的に
コードを書かざるを得ないのです。

94. 実際にコードを書いてみないと
設計思想なんて理解できないです
から。

95. コードを書けないエンジニア
はいりません。
きてます
きてます
そういう時代がきます。

96. 要件を満たすためだけの
設計をしてはいけません。

97. 責任範囲を明確にするだけの
設計をしてはいけません。

98. 設計はコードと共に在り
常に実現性と隣り合わせで
なければなりません。

99. コードの中に答えがあります。
たくさんのコードを書きましょう。

100. とある本の１ページ

101. （その7）
検索するな、本を読むべし

102. 便利な世の中になりました。
仕事中に分からないことがあっても
ググれば大抵のことは答えが得ら
れます

103. しかし、それで満足していては
いけません。
知識というものはもっと
深くて広いコンテキスト
で構成されています。

104. たとえば日本で生産される
果物の名産地を知りたいとします。

105. みかんの名産地は？
とググれば愛媛・和歌山
という結果が得られるでしょう。

106. りんごの名産地は？
とググれば青森・長野
という結果が得られるでしょう。

107. しかしこれらのことが分かったとしても
その他の果物についてや
なぜその地区が名産地なのか？
については理解できません。

109. これらのことを知るためには･･･
そう、地理の本ですね。

110. 地理の本の中には
その他の果物についても
なぜその地区が名産地なのか？
についても懇切丁寧に載っている
と思います。

111. このように

112. ある事象に関するコンテキスト
を理解するためにはそれに付随する
周辺知識も必要です。

113. 本にはそういった周辺知識も
合わせて詰まっていることが多いので
コンテキストを理解することを
助けます。

114. もちろん本にも当たりハズレは
ありますが
当たりの本を引くのはとても簡単
です。

115. （その1）
ノウハウではなくノウフーを知るべし
（know how） （know who）

116. の教訓を活かし
ノウフーを知れば良いのです。
know who
（誰か？を知る）

117. その人が良いと言っている本は
たぶん当たりでしょう。

118. たくさんの本を読んで幅広い
そして思慮深いエンジニアを
目指しましょう。

119. とある本の１ページ

120. （その8）
残業するな、勉強会へ行くべし

121. 残業が当たり前となっていないですか？
それはとても残念なことです。

122. なぜなら自分を磨く時間を
日々削ってしまっているのですから。

123. 残業する暇（？）があるくらいなら
勉強会へ参加しましょう。

124. そちら方が残業するよりも
得るものが大きい＆多いと思い
ます。

125. 新しいエンジニアとの出会いが
自分を大きく育ててくれるかも
しれません。

126. 新しい技術との出会いが
自分を新しい世界へ導いてくれる
かもしれません。

127. 大事なのは
残業しているということは
自分を磨く時間を削っている
ことだと認識することです。

128. 時間は有限です。
自分のために時間を使いましょう。

129. とある本の１ページ

130. さいごに

131. ここでまとめた8つの行動は
SI業界で生きていくだけなら
必要のないことかもしれません。

132. なぜならこの業界は
「ディフェンシブな開発」
で成り立っているからです。
http://d.hatena.ne.jp/kuranuki/20060116/p1

133. しかし今後、SI市場はシュリンクし
SIだけでは食えない時代が必ず来ます。

134. そんな時代を生き抜いていくための
エンジニアにとって大切な行動
をまとめたつもりです。

136. きっとSIの中でこれらの行動を
実践していくのは難しいことも
多いでしょう。

137. 色んな抵抗もあると思います。
（「残業しない ＝ 頑張ってない」
と思われたりしますしね）

138. でも流されないでください。
自分を成長させることができるのは
自分しかいません

139. まだ見ぬ未来の成長した自分に
出会うため
周りではなく自分を見つめて
自分で判断してください。
自分で道を切り開いてください。

140. 自分はなりたい自分にしか
なれません。

141. とある本の１ページ

142. おしまい