Webエンジニアの視点
∼開発現場からの視点で∼
株式会社ツインスパーク/日本Rubyの会
高橋征義
自己紹介
高橋征義
所属
株式会社
ツインスパーク
仕事
Webアプリ
ケーション
開発
別の肩書
日本Ruby
の会 会長
日本Ruby
の会
目的
Ruby利用者
の支援
Ruby開発者
の支援
活動内容
日本Ruby
会議の開催
Rubyist
Magazine
の発行
各種イベント
への参加
地域Ruby
会議の後援
本日の
お題
Web
エンジニア
の視点
開発現場
からの視点で
研究開発
ではなく
事業戦略
でもなく
技術とビジネス
のベタな話
思い
ついた話
とある宴会
での議論
デザイナーと
プログラマ
プログラマは
HTMLを
書くべきか
意見が
対立
話が噛み
合ない
業務システムと
コミュニティ
サイト
違う
ビジネス
異なる
前提
残念な
すれ違い
本日の
内容
3つ
第1部
4つの
世界
Web開発にも
いろいろある
ジョエルの
パクリ
第2部
Web開発
の変遷
技術の
変わり方
言語を
中心に
第3部
未来の話
どうなる
どうする
正直よく
分からない
話半分程度に
聞いていた
だければ
よろしく
お願いします
第1部
4つの世界
5つの世界
ジョエル・オン
・ソフトウェア
ソフトウェアに
関するエッセイ
5つの世界
Webでも
公開
ソフトウェア
の世界を5つ
に分けて説明
・パッケージ
・インターナル
・組み込み
・ゲーム
・使い捨て
1つ目
パッケージ
箱売り
ダウンロード
販売
オープン
ソース
2つ目
インターナル
業務
システム
一つの会社,
一つの状況
で使われる
ユーザビリティ
優先度は
高くない
開発速度
は重要
3つ目
組み込み
ハードと
セット
アップデート
できない
品質要求
が高い
速度重要
プロセッサ
の遅さを
カバー
4つ目
ゲーム
当たれば
でかい
ほとんど
当たらない
どこで儲けて
どこで損するか
どこまで損して
大丈夫か
ポートフォリオ
が重要(らしい)
5つ目
使い捨て
ちょっとした
コード
仕事中に
よく書く奴
一回だけ
使用
二度と
使わない
スクリプト
が典型
違う世界
での事例
当てはま
らない
自分は
どの世界に
いるのか
情報収集時
は要注意
Web
の世界
異なる世界
に分かれる
4つの世界
2×2の
マトリクス
業務
システム
メディア
自社
開発
A B
受託
開発
C D
2つの
対立軸
業務システム
vsメディア
自社vs受託
私はメディア
で受託が中心
業務システム
vsメディア
業務
システム
業務に使わ
れるもの
インターナル
に近い
ユーザ層
は限定
メディア
コンシューマ
向けサイト
ITというより
メディア産業
の一種かも
コーポレート
サイト
コミュニティ
サイト
ポータル
サイト
セールス
プロモーション
サイト
この2つは
性格が異なる
受託の場合
顧客の
違い
業務システム
の顧客
情報システム
部門
予算は
大きめ
メディア
の顧客
企画宣伝
部門
予算は
少なめ
直接収益化は
困難・無理
機能の
違い
業務システム
の機能
差別化の
根幹
絶対に譲れ
ないものも
メディアの
場合
機能は
なくても可
差別化の
ポイント
早さ
リリース
時期
広い意味の
ユーザ体験
伝達する
情報とセット
素朴でも
構わない
静的でも
構わない
速度と
コスト
ここでの
ポイント
私たちは何を
売っているのか
何が売り
なのか
見失い
がち
技術の
変化
メディアに
業務システム
の速度感
業務システムに
メディアの
コスト感
混乱
もう一つ
の軸
自社か
受託か
主な違い
要件管理
自社でなければ
細かく管理
できない
Webは
更新が重要
受託の
難しさ
自社開発
の困難
正直
詳しくない
人材を常に
抱えておく
のが難しそう
運用時と
開発時
常に開発
コスト的に
見合うように
する必要
業務
システム
メディア
自社
開発
A B
受託
開発
C D
まとめ
自分の位置を
把握する
第2部
Web開発
の変遷
3つの
時代区分
∼2000年頃
Webの
黎明期
CGIの
全盛期
C/Perl/
VB(ASP)
既存言語+
便利な関数
回線も
貧弱
ブラウザ
も貧弱
牧歌的な
時代
2001年∼
2005年頃
Webアプリ
の特性への
理解が進む
Java
(Struts)と
PHPの登場
サーバサイド
の特徴を
踏まえた開発
開発の
パターンが
見えてきた
Webアプリ
ケーション
フレームワーク
作業の省力化
・効率化が
進む
主に
業務システム
寄りの動き
もう一つ
の流れ
PHP
言語自体が
薄いWeb
アプリケーション
フレームワーク
便利な関数が
てんこもり
HTMLに言語
を埋め込み
手軽さに
軸足を置く
メディア側
で歓迎
2006年以降
Ruby on
Rails
必要最低限の
ことのみ
記述
フレームワーク
の徹底化
書かなくても
良い部分は
一切書かない
汎用言語の
枠内で実現
Java的な
流れとPHP的
な流れの融合
業務系的な
流れとメディア
的な流れの融合
プログラミング
言語の中でだけ
考えるのは不十分
プログラミング
言語について
掘り下げ
もう一つの
言語
設定
ファイル
プログラミング
言語の
2つの視点
書きたいことが何でも書ける
書きたいことが簡単に書ける
相反しがち
自由度
書きたいことが
何でも書ける
難易度
書きたいことが
簡単に書ける
何でも書ける
言語の極北
アセンブラ
C/C++
ポータビリティ
等の問題
正直、そこまで
何でも書きたい
わけじゃない
書けないことも
ある言語で十分
簡単に書ける
言語の極北
設定
ファイル
CSV
ini
XML
独自記法
プログラマ
ではない人でも
書ける
決められた事
しか書けない
特にロジックを
書くのが困難
■ プログラミング言語/設定ファイル
設定ファイル プログラミング
言語
自由度・高
難易度・高
自由度・低
難易度・低
中間が
欲しい
DSL
Domain
Specific
Language
ドメイン
特化言語
一種の
簡易言語
ほどほどの
記述力
ほどほどの
書きやすさ
言語内
DSL
独自言語の
ように見える
汎用言語
Ruby on
Railsで駆使
class Person < AR:Base
has_many :groups
belongs_to :company
validates_presence_of :name
end
■ プログラミング言語/設定ファイル/DSL
設定ファイル プログラミング
言語
DSL
自由度・高
難易度・高
自由度・低
難易度・低
他フレーム
ワークにも
多大な影響
ご清聴
ありがとう
ございました
Webデベロッパの祭典@東京:Webエンジニアの視点
Webデベロッパの祭典@東京:Webエンジニアの視点
Upcoming SlideShare
Loading in …5
×

Webデベロッパの祭典@東京:Webエンジニアの視点

1,267 views

Published on

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

  • Be the first to like this

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

No notes for slide

Webデベロッパの祭典@東京:Webエンジニアの視点

  1. 1. Webエンジニアの視点 ∼開発現場からの視点で∼ 株式会社ツインスパーク/日本Rubyの会 高橋征義
  2. 2. 自己紹介
  3. 3. 高橋征義
  4. 4. 所属
  5. 5. 株式会社 ツインスパーク
  6. 6. 仕事
  7. 7. Webアプリ ケーション 開発
  8. 8. 別の肩書
  9. 9. 日本Ruby の会 会長
  10. 10. 日本Ruby の会
  11. 11. 目的
  12. 12. Ruby利用者 の支援
  13. 13. Ruby開発者 の支援
  14. 14. 活動内容
  15. 15. 日本Ruby 会議の開催
  16. 16. Rubyist Magazine の発行
  17. 17. 各種イベント への参加
  18. 18. 地域Ruby 会議の後援
  19. 19. 本日の お題
  20. 20. Web エンジニア の視点
  21. 21. 開発現場 からの視点で
  22. 22. 研究開発 ではなく
  23. 23. 事業戦略 でもなく
  24. 24. 技術とビジネス のベタな話
  25. 25. 思い ついた話
  26. 26. とある宴会 での議論
  27. 27. デザイナーと プログラマ
  28. 28. プログラマは HTMLを 書くべきか
  29. 29. 意見が 対立
  30. 30. 話が噛み 合ない
  31. 31. 業務システムと コミュニティ サイト
  32. 32. 違う ビジネス
  33. 33. 異なる 前提
  34. 34. 残念な すれ違い
  35. 35. 本日の 内容
  36. 36. 3つ
  37. 37. 第1部
  38. 38. 4つの 世界
  39. 39. Web開発にも いろいろある
  40. 40. ジョエルの パクリ
  41. 41. 第2部
  42. 42. Web開発 の変遷
  43. 43. 技術の 変わり方
  44. 44. 言語を 中心に
  45. 45. 第3部
  46. 46. 未来の話
  47. 47. どうなる どうする
  48. 48. 正直よく 分からない
  49. 49. 話半分程度に 聞いていた だければ
  50. 50. よろしく お願いします
  51. 51. 第1部
  52. 52. 4つの世界
  53. 53. 5つの世界
  54. 54. ジョエル・オン ・ソフトウェア
  55. 55. ソフトウェアに 関するエッセイ
  56. 56. 5つの世界
  57. 57. Webでも 公開
  58. 58. ソフトウェア の世界を5つ に分けて説明
  59. 59. ・パッケージ ・インターナル ・組み込み ・ゲーム ・使い捨て
  60. 60. 1つ目
  61. 61. パッケージ
  62. 62. 箱売り
  63. 63. ダウンロード 販売
  64. 64. オープン ソース
  65. 65. 2つ目
  66. 66. インターナル
  67. 67. 業務 システム
  68. 68. 一つの会社, 一つの状況 で使われる
  69. 69. ユーザビリティ
  70. 70. 優先度は 高くない
  71. 71. 開発速度 は重要
  72. 72. 3つ目
  73. 73. 組み込み
  74. 74. ハードと セット
  75. 75. アップデート できない
  76. 76. 品質要求 が高い
  77. 77. 速度重要
  78. 78. プロセッサ の遅さを カバー
  79. 79. 4つ目
  80. 80. ゲーム
  81. 81. 当たれば でかい
  82. 82. ほとんど 当たらない
  83. 83. どこで儲けて どこで損するか
  84. 84. どこまで損して 大丈夫か
  85. 85. ポートフォリオ が重要(らしい)
  86. 86. 5つ目
  87. 87. 使い捨て
  88. 88. ちょっとした コード
  89. 89. 仕事中に よく書く奴
  90. 90. 一回だけ 使用
  91. 91. 二度と 使わない
  92. 92. スクリプト が典型
  93. 93. 違う世界 での事例
  94. 94. 当てはま らない
  95. 95. 自分は どの世界に いるのか
  96. 96. 情報収集時 は要注意
  97. 97. Web の世界
  98. 98. 異なる世界 に分かれる
  99. 99. 4つの世界
  100. 100. 2×2の マトリクス
  101. 101. 業務 システム メディア 自社 開発 A B 受託 開発 C D
  102. 102. 2つの 対立軸
  103. 103. 業務システム vsメディア
  104. 104. 自社vs受託
  105. 105. 私はメディア で受託が中心
  106. 106. 業務システム vsメディア
  107. 107. 業務 システム
  108. 108. 業務に使わ れるもの
  109. 109. インターナル に近い
  110. 110. ユーザ層 は限定
  111. 111. メディア
  112. 112. コンシューマ 向けサイト
  113. 113. ITというより メディア産業 の一種かも
  114. 114. コーポレート サイト
  115. 115. コミュニティ サイト
  116. 116. ポータル サイト
  117. 117. セールス プロモーション サイト
  118. 118. この2つは 性格が異なる
  119. 119. 受託の場合
  120. 120. 顧客の 違い
  121. 121. 業務システム の顧客
  122. 122. 情報システム 部門
  123. 123. 予算は 大きめ
  124. 124. メディア の顧客
  125. 125. 企画宣伝 部門
  126. 126. 予算は 少なめ
  127. 127. 直接収益化は 困難・無理
  128. 128. 機能の 違い
  129. 129. 業務システム の機能
  130. 130. 差別化の 根幹
  131. 131. 絶対に譲れ ないものも
  132. 132. メディアの 場合
  133. 133. 機能は なくても可
  134. 134. 差別化の ポイント
  135. 135. 早さ
  136. 136. リリース 時期
  137. 137. 広い意味の ユーザ体験
  138. 138. 伝達する 情報とセット
  139. 139. 素朴でも 構わない
  140. 140. 静的でも 構わない
  141. 141. 速度と コスト
  142. 142. ここでの ポイント
  143. 143. 私たちは何を 売っているのか
  144. 144. 何が売り なのか
  145. 145. 見失い がち
  146. 146. 技術の 変化
  147. 147. メディアに 業務システム の速度感
  148. 148. 業務システムに メディアの コスト感
  149. 149. 混乱
  150. 150. もう一つ の軸
  151. 151. 自社か 受託か
  152. 152. 主な違い
  153. 153. 要件管理
  154. 154. 自社でなければ 細かく管理 できない
  155. 155. Webは 更新が重要
  156. 156. 受託の 難しさ
  157. 157. 自社開発 の困難
  158. 158. 正直 詳しくない
  159. 159. 人材を常に 抱えておく のが難しそう
  160. 160. 運用時と 開発時
  161. 161. 常に開発
  162. 162. コスト的に 見合うように する必要
  163. 163. 業務 システム メディア 自社 開発 A B 受託 開発 C D
  164. 164. まとめ
  165. 165. 自分の位置を 把握する
  166. 166. 第2部
  167. 167. Web開発 の変遷
  168. 168. 3つの 時代区分
  169. 169. ∼2000年頃
  170. 170. Webの 黎明期
  171. 171. CGIの 全盛期
  172. 172. C/Perl/ VB(ASP)
  173. 173. 既存言語+ 便利な関数
  174. 174. 回線も 貧弱
  175. 175. ブラウザ も貧弱
  176. 176. 牧歌的な 時代
  177. 177. 2001年∼ 2005年頃
  178. 178. Webアプリ の特性への 理解が進む
  179. 179. Java (Struts)と PHPの登場
  180. 180. サーバサイド の特徴を 踏まえた開発
  181. 181. 開発の パターンが 見えてきた
  182. 182. Webアプリ ケーション フレームワーク
  183. 183. 作業の省力化 ・効率化が 進む
  184. 184. 主に 業務システム 寄りの動き
  185. 185. もう一つ の流れ
  186. 186. PHP
  187. 187. 言語自体が 薄いWeb アプリケーション フレームワーク
  188. 188. 便利な関数が てんこもり
  189. 189. HTMLに言語 を埋め込み
  190. 190. 手軽さに 軸足を置く
  191. 191. メディア側 で歓迎
  192. 192. 2006年以降
  193. 193. Ruby on Rails
  194. 194. 必要最低限の ことのみ 記述
  195. 195. フレームワーク の徹底化
  196. 196. 書かなくても 良い部分は 一切書かない
  197. 197. 汎用言語の 枠内で実現
  198. 198. Java的な 流れとPHP的 な流れの融合
  199. 199. 業務系的な 流れとメディア 的な流れの融合
  200. 200. プログラミング 言語の中でだけ 考えるのは不十分
  201. 201. プログラミング 言語について 掘り下げ
  202. 202. もう一つの 言語
  203. 203. 設定 ファイル
  204. 204. プログラミング 言語の 2つの視点
  205. 205. 書きたいことが何でも書ける 書きたいことが簡単に書ける 相反しがち
  206. 206. 自由度
  207. 207. 書きたいことが 何でも書ける
  208. 208. 難易度
  209. 209. 書きたいことが 簡単に書ける
  210. 210. 何でも書ける 言語の極北
  211. 211. アセンブラ
  212. 212. C/C++
  213. 213. ポータビリティ 等の問題
  214. 214. 正直、そこまで 何でも書きたい わけじゃない
  215. 215. 書けないことも ある言語で十分
  216. 216. 簡単に書ける 言語の極北
  217. 217. 設定 ファイル
  218. 218. CSV ini XML 独自記法
  219. 219. プログラマ ではない人でも 書ける
  220. 220. 決められた事 しか書けない
  221. 221. 特にロジックを 書くのが困難
  222. 222. ■ プログラミング言語/設定ファイル 設定ファイル プログラミング 言語 自由度・高 難易度・高 自由度・低 難易度・低
  223. 223. 中間が 欲しい
  224. 224. DSL
  225. 225. Domain Specific Language
  226. 226. ドメイン 特化言語
  227. 227. 一種の 簡易言語
  228. 228. ほどほどの 記述力
  229. 229. ほどほどの 書きやすさ
  230. 230. 言語内 DSL
  231. 231. 独自言語の ように見える 汎用言語
  232. 232. Ruby on Railsで駆使
  233. 233. class Person < AR:Base has_many :groups belongs_to :company validates_presence_of :name end
  234. 234. ■ プログラミング言語/設定ファイル/DSL 設定ファイル プログラミング 言語 DSL 自由度・高 難易度・高 自由度・低 難易度・低
  235. 235. 他フレーム ワークにも 多大な影響
  236. 236. ご清聴 ありがとう ございました

×