RailsDevConで学んだこと

先日RailsDevConに僭越ながら参加させて頂いたので、そこで学んだことを徒然にかいていきます。
まず主催者の方からこのDevConの目的が話されました。その中でもノウハウ共有という部分のお話が印象に残っています。
RailsにはDRY(Don't Rereat Yourself)の思想があります。まさにその思想に則って、今回の勉強会をノウハウ共有の場にして、以前に悩んだことがある人が同じことで悩むことがないように。といった目的があったようです。素敵です。

Program

  • 「渡米して感じたこと」 ■増井 雄一郎：@masuidrive
  • 「Rails情報源の歩き方」 ■西村　賢：＠IT　副編集長
  • 「とあるソーシャルアプリの開発運用」 ■大仲 能史：@onk、(株)ドリコム ソーシャルゲーム開発デザイン部
  • 「Railsプロジェクトを成功させるために現場ができること」 ■赤松 祐希：@ukstudio、フリーランスプログラマ
  • 「現実の世界で "はじめる！Cucumber"」 ■諸橋 恭介：@moro、(株)永和システムマネジメント、Rails勉強会@東京
  • 「Rails Add-onsで楽々開発 - youRoomを題材に -」 ■松村 章弘：TIS(株) 社内ベンチャーカンパニー SonicGarden
  • 「初めてがRuby」 ■松田 明, 吉田 裕美, ほか

Content

1.「渡米して感じたこと」■増井 雄一郎：@masuidrive
  • USでは「Ruby == Rails」という印象。特にスタートアップではRubyが選ばれるようになってきている。細かいサイクルでの開発ができることがメリットだそう。
  • RubyonRailsの技術はアメリカで高く評価される。高機能のRubyを使える技術者はレベルが高いと評価される。RubyonRailsの技術は世界で通用する。
  • 言葉(English)の不利は言語(Ruby)で返す。

資料⇒http://public.iwork.com/document/ja/?a=p278287629&d=RailsDevCon.key

2.「Rails情報源の歩き方」■西村　賢：＠IT　副編集長

近々、@ITでRailsの情報ハブとなるサイトが始まるそうです。期待です。

3.「とあるソーシャルアプリの開発運用」 ■大仲 能史：@onk、(株)ドリコム ソーシャルゲーム開発デザイン部
  • ソーシャルゲームを作る時のポイント３つ。
    • API利用
      • デバックの勘所
    • 人口爆発
      • 何を想定しなければならないか
      • 正しくWebアプリをつくるということ
    • 短納期
      • 何を犠牲にして何を得るか
      • 超高速でＰＤＣＡサイクルを回す
  • 覚えておくと便利な小技
    • net-http-spy
      • Net:HTTPにloggerを組み込む。
    • WEBrick::HTTPProxyServer
      • Proxyを通せる環境なら便利
    • tcpflow
      • tcpdumpの保存しないバージョン
      • webサーバにくるアクセスをのぞき見したい時とか

資料⇒http://www.slideshare.net/takafumionaka/ss-5852561

4.「Railsプロジェクトを成功させるために現場ができること」 ■赤松 祐希：@ukstudio、フリーランスプログラマ

技術的負債という題目でのお話だったのですが、このセッションが直近の問題点も含めて最も勉強になりました。
まず「成功はお客様の満足」と初めに断言されていたのが素敵でした。
どんなに高機能のシステムをつくったとしてもお客様が使わなければ意味がない。
要はお客様の満足ポイントを明らかにすることは、まず重要であることを改めて認識した。

セッションの中では特に「ＴＤＤ」「バージョン管理」「fat Model slim Controller」この当たりのキーワードが気になりました。
実務でも活かせそうなので、色々と具体的なアクションを考えてみます。

資料⇒http://ukstudio.jp/2010/11/22/railsdevcon2010/

5.「現実の世界で "はじめる！Cucumber"」 ■諸橋 恭介：@moro、(株)永和システムマネジメント、Rails勉強会@東京

こちらと6.に関しては発表準備のため聞けなかったので資料へのＵＲＬだけ貼っておきます。
会社ではCucumber導入していないが、導入した方がよいのかな。少し勉強してみたい。
資料⇒http://d.hatena.ne.jp/moro/20101120/1290243692

6.「Rails Add-onsで楽々開発 - youRoomを題材に -」 ■松村 章弘：TIS(株) 社内ベンチャーカンパニー SonicGarden

資料⇒http://www.slideshare.net/mat_aki/rails-add-ons-derailsdevcon

7.「初めてがRuby」 ■松田 明, 吉田 裕美, ほか

こちらでは、松田さん、吉田さん、groovesの皆さん、ＬＲメンバーと共に僭越ながら登壇させて頂きました。

  • Ruby/Railsをどうやって勉強しましたか？
  • Ruby/Railsを勉強していて躓いたところは？
  • わからなかったことがわかるようになった瞬間は？
  • Ruby/Railsのここが好き。

会場の方から１つ質問

  • 最初にこれを教えていてくれたらもっと早くに理解できたのに、というものはありましたか？

⇒一次情報に当たるべき。ググって分からなくなることが多い。

Conclusion

こんな素敵な皆様と同じ空間をご一緒できたことを心から嬉しく思います。
まだまだ自分の技術力が赤ん坊程であることを改めて痛感致しました。情熱が湧いてきました。
こういったセッションには定期的に参加できたら嬉しいです。

スタッフの皆様、プレゼンターの皆様、本当にありがとうございました。

大野耐一の鬼十訓

改善の鬼と呼ばれる大野耐一さんから学んだことが書かれた本「トヨタ式　鬼十訓」を読んで、自分の習慣を反省するべきところが多々ありましたので、まとめていきます。

大野耐一の鬼十訓

  1. 君はコストだ。まずムダを削れ。それなくして能力は展開できない。
  2. 始めたらねばれ。できるまでやめるな。中途半端はクセになる。
  3. 困れ。困らせろ。安易を好む人と決定的な能力格差がつく。
  4. ライバルは君より優秀だ。すなわち君は「今」始めることでのみ勝てる。
  5. 仕事に痕跡を刻め。十割命じられても十一割めを自前の知恵でやれ。
  6. 平伏させず心服させろ。そのためにはだれよりも長い目で人を見ることだ。
  7. 「できる」とまず言え。そこに方法が見つかる。
  8. 失敗を力にしろ。真の自身そして運さえリカバリーから生まれる。
  9. 労働強化を避けよ。人間「ラクになるには」に一番頭が働く。
  10. お客の叱声は成功の呼び声だ。逃すな。いじけるな。考え抜け。

1.君はコストだ。まずムダを削れ。それなくして能力は展開できない。

「あとで手直し」はムダである

不良がでると、人間はとかく「あとで手直しすればいい」と、見えないところに隠しおくものである。仕事の流れをとめることをしない。だから、そのときは誰も困らない。
しかし、困らない代わりに、何の対策も取らないのだから、いずれ同じような不良が出る。これが大きなムダである。
さらに「手直し」という本来やらなくてもいいムダがでる。
だから大野さんは、不良は見えるところに出して「なぜ不良が出たのか」をみんなで考え、真因（表面に見える原因のさらに奥にある根本的な要因）をつかもうとする。
そして二度と同じ不良がでないように、みんなで改善を重ねることが大切だと考えている。
また、不良をゼロにするために以下の２つのことを徹底した。

  1. 視える化
  2. 「なぜ」を五回繰り返す

この1.において不良の視える化で、「失敗を共有財産とする」「失敗をムダ取りのヒントにする」ことを意識づけようとしていた。

                                                                                              • -

仕事において、問題だと感じたことはすべて表に出さないと、自分以外の誰かが同じことで困る可能性が大いにある。すなわちムダが発生する。
その都度何かにメモしておき、定期的な会議で意見する必要性を改めて認識した。

                                                                                              • -
原価が見えると減価ができる

「視える化」で人は自然と問題に気づき、「原価の視える化」をすれば原価意識を持って仕事に臨むようになる。そこから改善の知恵が出てくる。

                                                                                              • -

自分がやっている業務単位での時間を測定し、その時間でいくらの人件費がかかり、全体の中でどれだけの負担になっているかを計算してみる。
すると、自分が効率悪く業務をしてしまっている時間が、どれだけのコストになっているかを認識する。時間意識を持って仕事に取り組みたい。

                                                                                              • -
モノを作るのではなく、「必要なモノをつくる」

2.始めたらねばれ。できるまでやめるな。中途半端はクセになる。

「なぜ」を五回繰り返す

問題の改善とは、問題を解決することではなく、問題の真因を調べ、二度と同じ問題が起きないように仕組みをつくることである。

目標を達成したら目標を変えなさい

目標は、これでよいというものはない。あくまでも人間の能力に挑戦するのが目標であり、今の目標を達成したら目標を変えなさい。

3.困れ。困らせろ。安易を好む人と決定的な能力格差がつく。

大増産を小増員でやれ。成長の秘密はそこにしかない。

「5000台つくるのに、80人必要」の場合、「10000台つくるために、160人必要である」という単なる「算術の経営」ではダメである。
二倍に増やしたいときも、知恵を使い創意工夫をこらし、改善を重ねてそれ以下でやれるようにする「忍術の経営」でなければならない。

仕事は「可能か」で決めるな。つねに「必要か」で決めよ。

「できない」と決めてかかると出来ることまで出来なくなるが、「できる」と思ってやると案外できるものだ。
トヨタ式の基本は「まずやってみよ」である。
仕事は思い切り遠くにボールを投げる人と、キャッチしようと知恵を出す人が必要である。

答えを教えるな。考えさせる工夫をしろ。

人の知恵を信じ、困ったときにはいつでも手を差し伸べる準備があってこそだ。「期待に応えよう」とがんばらせるヒューマニティが大切である。

厳しすぎる注文が成長をもたらす。

厳しい目標に対して必死に知恵を出すことで「考える力」はつく。ときに「より少ない予算」「より少ない人数」「より短い時間」をあえてみずからに課してみるといい。
ものの見方が変わり、考える力、改善する力が確実に上昇する。

4.ライバルは君より優秀だ。すなわち君は「今」始めることでのみ勝てる。

何でもその場でやれ。なんでもすぐ片付く。
明日でも対策は見込めるが。今日なら良策が仕込める。
積み上げが仕事を鍛え上げる。

「なぜこんな当たり前のことができないんだ」と怒るのではなく、「なぜできないのか」「どうすればできるのか」を自らの課題として考える。
当たり前を徹底することは難しい。自分が仕事をしていて、あるいは部下に仕事をさせていて、当たり前の簡単なことがうまくいかない時、
「当たり前」をどう自分が捉えているかを省みるチャンスである。

                                                                                              • -

自分にとっての「当たり前」は相手にとっては、そうではないことが多々ある。自分の中での定義をきちんと明確にしておくことで、
何かを教えるときにも教わるときにも精度があがる。

                                                                                              • -

5.仕事に痕跡を刻め。十割命じられても十一割めを自前の知恵でやれ。

「できた」で止まるな。「もっとできる」に進め。

トヨタ式では「人間の知恵の数だけ競争に勝てる」と言う。上司に言われたまま、本で読んだまま、マニュアルに書いてあるままの仕事ではいけない。
知恵を使って、もっとうまくやることがトヨタ式である。

                                                                                              • -

まずは、マニュアル通りに「できる」ことが前提。次に、「もっとできる」に進む。この順序は間違えないようにする。
現状がわかっていないのに、改善など出来るはずがない。

                                                                                              • -
言葉通りにやらず、言葉に知恵を足せ。
教えるな。気づかせろ。

大切なのは作業者の知恵や提案を引き出すことが改善の指導だということを忘れてはならない。
指導というより「知恵を出すお手伝い」と考えたほうが良い。
部下には自分の頭で考え、自分で試行錯誤しながら知恵を出すことを覚えてもらう。時間が掛かっても、一つ一つステップを踏みながら考えさせる。
上司がすべてをお膳立てしていては、部下は考えることを放棄し、言われるがままに仕事をするだけになる。
「考える部下」がいない会社に競争力は育たない。

6.平伏させず心服させろ。そのためにはだれよりも長い目で人を見ることだ。

手をかけ時間をかける。そうしてこそ人から声がかかり始める。

人は納得した仕事には全力で取り組むが、納得のいかない仕事には、結局は中途半端な気持ちでしか臨めないものだ。
「なぜ必要なのか、なにをしてもらいたいのか」を丁寧に説明し、できうるかぎり納得を得ることが「人を動かす」「人を育てる」要諦である。

まずやらせるな。まずやってみせろ。

なによりも事実で説得し、理解を得ることが大事。なにごとも、頭で理解しただけではダメで、実際にやってみないと本質がわからない。

汗をかかせるな。知恵に欠けてくる。

上司は部下が考えることを助け、自分の頭で考えることの出来る部下を育てる責任を負う。
考えることを部下に丸投げし、答えも持たず、何のアドバイスもできないようなら、その人は上司である資格などない。

7.「できる」とまず言え。そこに方法が見つかる。

「できる」を信じる。「できない」は疑う。
知恵は平等だ。知恵の引き出し方で差がつく。

「知恵」は知識とは違う。知識は、学校や本など、お金を払って買うことができる。それに対して、知恵は経験で買う。
現場の仕事を通して、知恵を引っ張り出す経験を重ねることで身についてくるものだ。
つまり知恵とは実践と分かちがたく結びついている。
トヨタ式では「仕事に行く」ではなく、「知恵を出しに行く」と考える。自分の知恵の実践で、仕事は各段にやりがいのあるものへと変わる。

8.失敗を力にしろ。真の自身そして運さえリカバリーから生まれる。

成果をあげるにはネをあげないことだ。

危機イコール「知恵を出すチャンス」。問題や難関をチャンスと捉えることが大切だ。
もちろん突破するには大変な苦労をしいられるわけだが、「なんとかしなくては」と考えることで、思いもかけない知恵や力がでてくるものだ。

「失敗だ」とあきらめるな。「失敗にしたくない」と発想せよ。
支持されたいなら、指示を減らすんだ。

失敗に対して、会社や上司が処理を支持するのは、早くてラクでいいかもしれない。指示する側も、指示される側も安心だ。
しかい、それでは人は育たない。失敗のときこそ、忍耐と時間が必要になる。

9.労働強化を避けよ。人間「ラクになるには」に一番頭が働く。

「平均的に」はラクではない。「最速で」がラクである。

改善には順番がある。

  1. 作業改善
  2. 設備改善
  3. 工程改善

トヨタ式では、まず作業改善が先にくる。最初から道具をつくるのではなく、仕事のやり方を変えてみる。
この作業改善の段階では、労働強化にならないよう細心の注意を払う必要がある。
「なぜできないのかという原因をしっかりつかめ」これが労働強化を避ける基本である。

目標値が高ければ、出発点は低くていい。

「標準のないところに改善はない」
作業のやり方が決まっておらず、人によってやり方や教え方が違っている現場では、作業のやり方を変えても仕方がない。
まず標準を決めること、標準作業をつくることが重要なのだ。その標準作業で大切なのは次の３つ。

  1. 現場の実態をきちんと反映していること。
  2. 現場で使えるものであること。
  3. 改善の役に立つものであること。

また、この標準は未来永劫に改善されていくべきものである。

10.お客の叱声は成功の呼び声だ。逃すな。いじけるな。考え抜け。

相手を変えたいなら、自分が変わるんだ。
むずかしいことは優しく言え。やさしいことは繰り返し言え。
「できる」信念も、「できない」信念も強さは同じだ。

「仕組みを考えることぐらいは誰でもできるが、問題はそれをどこまで実行できるかだ。」
仕事は頭で考えるだけでは意味が無い。信念を持ってやり抜くことができるかどうかが価値を決める。

                                                                                                                                                                                              • -

最後までお読み頂き、ありがとうございます。

トヨタ式 鬼十訓 私が大野耐一から学んだこと

トヨタ式 鬼十訓 私が大野耐一から学んだこと

【Rails】form_tagとform_for

form_tag と form_forの違いについて、まとめていきます。

■form-tagについて
  • フォームの開始/終了タグを作成する。
<% form_tag(:controller => "hoge", :action => "fuga") do -%>
<% end -%>
  • 実行結果↓
<form action="/hoge/fuga" method="post">
</form>

※このメソッドでフォームを作成する際には、<%= … %> ではなく、<% … %>で囲む。

  • 第２引数にはformタグの属性を指定するパラメータを指定する。
<% form_tag({:controller => "hoge", :action => "fuga"},
            {:multipart => true}) do -%>
<% end -%>
  • 実行結果↓
<form action="/hoge/fuga" entype="multipart/form-data" method="post">
</form>
  • サブミットボタンを作成する。

submit_tagメソッドで作成する。第１引数にはボタンのラベルを指定。第２引数にはinputタグの各種属性を指定できる。

submit_tag("決定", :class => "hoge")

※画像形式のサブミットボタンは、image_submit_tagメソッドで作成する。

  • 実際の仕様例
<% form_tag({:action => "create"}, {multipart => true}) do -%>
  お店の名前 
  <%= text_field_tag "shop[name]", "", :id => "shop_name" %><br />

  アイコン
  <%= file_field_tag "shop[icon]", :id => "shop_icon" %><br />

  <%= submit_tag "作成" %>
<% end -%>
  • 上記のフォームの各値は、params[:shop]に設定される。よってコントローラーでは以下のようなHashで受け取ることが出来る。
params[:shop] # => {:name => "店名", :icon => #<StringIO:0x19eb780>}
params[:shop][:name] # => "店名"
params[:shop][:icon] # =>  #<StringIO:0x19eb780>

※iconの画像データは任意のファイルを示しています。

■form_forについて
  • 『モデルに対応するフォーム』を簡単に作るためのヘルパーメソッド。
  • モデルに対応するフォームで必要となる機能
    • name属性に[]のついた入力項目からのリクエストを簡単に扱うための仕組みがあるので、それに適応したname属性を使う。
    • モデルオブジェクトを編集するフォームでは、入寮項目のデフォルト値として既存のモデルオブジェクトの値を使う。
    • モデルオブジェクトの検証でエラーがあった場合、その箇所を強調表示する。

※form_forメソッドはこのようなフォームを作る際に便利！

  • form_forメソッドの第１引数には、変数名を『文字列orシンボル』の形で指定。
    • FormBuilderオブジェクトが対象とするモデルオブジェクトを指定する。
    • FormBuilderオブジェクトで作成する入力項目タグのname属性の一部になる。

※つまり、form_forメソッドは第１引数で指定された名前のインスタンス変数を探し、それをFormBuilderに渡す。

  • form_forメソッドの第２引数にはformタグのための各種パラメータを指定する。ほぼ必須となるのは:urlパラメータ。
<%# @entryをもとにしたフォームを作る %>
<% @entry = Entry.new(:title => "Entry Title") %>
<% form_for(:entry, :url => {:action => "create"}) do |f| -%>
  <%= f.text_field :title %><br />
<% end -%>
  • 出力されるHTML↓
<form action=(略)>
  <input id="entry_title" name="entry[title]" type="text" value="Entry Title" />
</form>

※テキストフィールドのname属性が"entry[title]"となる。
※入力項目のデフォルト値がインスタンス変数対象のオブジェクト(@entry)のtitleの値になる。（更新用フォームに使える！）

  • 覚え方
    • 『form_for :entry』を『form for entry』つまり、『entryのためのform』を作成すると覚えると良い。
  • name属性の前半と実際のインスタンスを分けて指定する
    • name属性として使いたい文字列とインスタンス変数が一致しない場合、form_forの第２引数にローカル変数うを指定する。
<% @entry = Entry.new(:title => "Entry Title") %>
<% another_entry = Entry.new(:title =>  "Another Entry Title") %>

<%# @entryではなく、ローカル変数another_entryをもとにしたフォームを作る %>
<% form_for(:entry, another_entry,
            :url => {:action => "create"}) do |f| -%>
  <%= f.text_field :title %><br />
<% end -%>
  • 出力されるHTML↓
<form action=(略)>
  <input id="entry_title" name="entry[title]" type="text" value="Another Entry Title" />
</form>
  • このとき、フォーム内のinput要素のname属性には第一引数で指定した「entry」が使われ、その入力項目のデフォルト値にはanother_entry.titleが使われる。
■form_tag と form_forの違い
  • form_forメソッドでは、ブロック内にフォームの入力項目を作成する際に、FormBuilderオブジェクトが利用出来る！
  • form_forメソッドはブロックを使うことができるので、コードがスッキリ!!
  • ただ、融通が効くのはform_tagな気がする。。

ルートページの設定

  • 特定のURL(トップページのURLなど)で特定のアクションを呼びだしたい場合、configフォルダの下のroutes.rbというファイルで設定する。
    • トップページで、コントローラー…『main』アクション…『index』を指定したい場合
map.connect '', :controller => 'main', :action => 'index'

設計哲学

  • DRY（Don't Repeat Yourself＝繰り返しを避けよ）

　　　⇒同じことを何度も記述するのは避けるべきだという原則です。
　　　 DRYを意識することで、次のようなメリットが得られます。

    • 開発効率が上がる
    • 仕様変更等での修正精度が上がる
    • プログラムとしてスマートになり、動作が早くなる。
  • COC（Convention over Configuration＝設定より規約）
    • 規約（＝デフォルトの設定）に従って開発することで、余計な設定の手間を省き、コードの記述に専念することができます。
    • 例：　データベースでメンバー情報を扱いたい場合

　　　　　　　テーブル名をmembers（複数形）と命名すると・・・
　　　　　　　⇒モデルのクラス名はMember、ファイル名はmember.rbと決まります。
　　　　　『制約が自由をもたらす』

コンポーネント

Railsの実態は、コンポーネント（Rubyで書かれたライブラリ＝汎用性の高い機能群）の集合体です。
Railsは次のようなコンポーネントで構成されています。

  • Active Record：：モデル
  • Action Pack
    • Action View：：ビュー
    • Action Controller：：コントローラ
  • Active Support：：共有ライブラリ集
  • Action Mailer：：電子メールの送受信（デフォルトでは組み込まれません）
  • Action Web Service：：ウェブサービス（デフォルトでは組み込まれません）