今までやってた仕事を新人にもやらせなさいとの事なので、必要な事をあげてみます。
ついでに、このまま新人さんに読んでもらう為の文章にします。
できるだけ自分の言葉で書いたつもりですが、僕が下で紹介している本から多大な影響を受けており、同じような事を書いているかもしれません。まあそれも僕自身の復習という事でご容赦くださいw
うちは基本的にはRubyを主に使っているのでRubyの構文の知識は最低限必要です。
ただ、うちの場合、プログラミングだけでなく仕様案作成、設計、バージョン管理からWebサーバだのデータベースだののソフトウエアの選定からセットアップ、ネットワーク設計、そしてサーバへのデプロイ等、基本丸投げになるので(笑 それらの知識も必要になります。
僕はプログラミング自体初心者の時に下の２冊を常に手元に持っていました。
最初の一冊としては「Ruby プログラミング入門」がオススメです。初心者にもわかりやすく丁寧に解説してありますし、実践的で読みながら直ぐにプログラムを作ってみる事ができます。
「Ruby Way」はもう少し詳しく解説してくれている本です。「Ruby プログラミング入門」では物足りない場合はこちらも購入を検討されると良いでしょう。こちらもとてもわかりやすく実践的な内容だと思います。
もちろん上記以外にも良い書籍があります。自分に合った書籍を常に手元に持っておきながら、まずは自分の手でプログラムを組んでみるのが習得への早道だと思います。
Hellow World はお約束として、その後はとりあえず以下の点を学ぶと簡単なプログラムが組めるのではないかと思います。
Step
もちろんまだまだ覚える事は沢山ありますが、まずは自分の手を動かしてコードを書く事だと思います。本を見てると簡単そうに見える事が実際書いてみると思った以上にうまくいかないことがあります。その理由がわかったとき、一歩成長したと言えるのだと思います。
それを繰り返しているうちにだんだんと自由に思った通りの動きをするプログラムを組めるようになってきます。
設計
ただ、前述のように丸投げになって誰も指示してくれないので、設計もきちんとしておく必要があります。ポリモーフィズムを応用したりシングルトンなインスタンスを検討するなど基本的な設計については最初から考えてコーディングに取りかからねばなりません。
またWebサービスであれば(X)HTMLやCSS、Javascriptも当然必要になってきます。これらも単に
(σ´∀`)σ動いた動いた♪
的な知識ではなく、どう動かすか、つまり設計を自分なりに考えてとりかかる必要があります。そうしないと後でバグだらけになって手に負えないものになったり修正に時間のかかるものになってしまうからです。
この点について、コーディングにかかる前に新人さんには「どのような設計で作ろうと考えているか」を話してもらうと良いかもしれません。その際にテストフレームワークは何を使うか、データベースの設計はどうするか、Railsを使うかMerbやSinatraも検討するか、しないのならそれは何故か。そして最終的なリリースをいつにするかなど、完全に答えられなくても自分の考えを述べる事で技術的経験的に足りない部分が早い段階で浮き彫りになるかもしれません。
ソフトウエアの設計についてはこの業界では読み継がれている本があります。できれば以下の本には目を通しておいて欲しいです。
特に「リファクタリング:Rubyエディション」と「達人プログラマー」は必ず読んでください。
Step
上記の本を読む事で予備知識や、陥りがちな失敗を知る事ができ、それによって事前に対策を打つ事ができますが、それはあくまで机上の知識です。やはり実践に勝るトレーニングはありません。
まずは自分の普段の仕事を、「小さなプログラム」を作る事で自動化しましょう。普段の仕事の中には自分でも気づかずに実行している無駄な仕事があると思います。
もし、その作業が「手でやる場合」と「自動化するプログラムを作る場合」とで同じ時間がかかるならプログラムを組んで自動化しましょう。かりに２、３倍かかったとしてもやはりプログラムを組んで自動化するべきです。そうすれば明日からはその作業にかかる時間は飛躍的に短くできます。
しかし、それ以上に重要なのは「自分が日々使うプログラムを自分で作り保守する」ことにより、ある面では素晴らしい本を読む以上の経験が得られる事です。
ユーザが自分なのですからリスクは最小です（データベースから全ユーザを削除したりしなければw）。そして最終ユーザからのフィードバックが即座に得られます（最終ユーザが自分なのですから当然ですがw）バグはもちろん、使いにくいと感じた所もどんどん直していきましょう。時間がなかったりすると作り手故に知っている”回避方法”を使ってバグのあるままに使い続ける事もできると思いますが、ずっと微妙な「嫌な気持ち」を感じながら使う事になると思います。嫌な気持ちになったらすぐに直しましょう。そうすると今度は逆に少し幸せな気持ちになれるはず...と思われますw
僕も今まで小さなスクリプトを幾つも作ってきました。例えば複数のサーバに同じアプリケーションをデプロイする際にコマンド一つで、最新のソースのチェックアウトから再起動までを自動的にやってくれるようにしたり、同じくコマンドひとつでテキストファイルに登録された全サーバにpingを打ったりポートオープンしてサービスの稼働状況を監視したりするプログラムです。
あるいはもっと地味に、単に特定のサーバへSSHトンネルを張るコマンドを１行書いただけのbashスクリプトだったり。
小さなプログラムなら失敗しても直ぐに作り直せます。失敗はできるだけ他人に影響の無い範囲で経験しておいて、その教訓を他の人が使うプログラムの開発に活かすように心がけましょう。
Step
トレーニング【更に】
上記で小さなプログラムで自分の仕事を自動化する事で経験を積む事を書きました。
いくらかの経験を積んだら、今度は外に向かって「自分のプログラム」を公開しましょう。もちろん小さなプログラムで構いません。なにか便利なサービスを提供してくれるデーモンでも、コマンドで実行するプログラムでも、あるいはWebサービスや、よく使う汎用的な関数をライブラリ化して公開するとか、今ならiPhoneやAndroid向けのアプリもいいでしょう。
どんなに”地味”な公開であっても「アプリケーションの公開」は、それに伴って更に幾つもの判断ポイントが生じます。例えば公開のタイミング。どこまで実装したら公開するのか、開発の初期段階でのシンプルな状態で公開すればバグを少なく済ませられますが、同時にインパクトも小さくなりがちです。インパクトが無ければ折角作っても誰も使ってくれないかもしれません。
公開後はどうやって周知するか。iPhoneアプリなら検索に引っかかるようにタグを設定するとか、アプリ名も検索されやすい単語で構成するとか。
保守も重要です。バージョン管理の仕方、ソースが公開出来るならgithubを使う事をお勧めします。githubは幾らは支払えば非公開にもできます。新人さんには全員githubのアカウントを作ってもらって、そこで個人的なトレーニングの成果や学習プロセスを確認できるようにしておくのも良いと思います。
そしてここに来て「誠実に対応する」事の重要性が浮き彫りになります。あなたがバグを放置すれば気に入って使ってくれていたユーザも使うのを止めたり、あるいはコメント欄に苦言を残すようになるかもしれません。それを見た人がダウンロードして使ってみたりするでしょうか？
逆に、バグの報告を受けて直ぐに直す等のアクションを起こせば、むしろバグによりユーザの信頼を得るきっかけにもなるでしょう。もしかしたらブログで取り上げて頂けるかもしれません。そのような機会が増せば、運が良ければ更に沢山の人が閲覧に来るサイトで紹介してもらえるかもしれません。
真の意味での「誠実な対応」は一見非効率な行動に思われがちですが、目の前のユーザ一人一人に満足してもらう事でしか開けない道もあると思います。それにGoogleやTwitterで自分のアプリ名を検索したとき、ユーザが喜んで使ってくださってたり、人に勧めてくださってたりすると嬉しいものです。この喜びは何物にも代え難いです。仕事の中で全体の一部だけやっていたのではわからない楽しさがあります。
そして、小さな規模とはいえ、自分一人で企画から仕様決め、コーディングに公開そして保守、さらには広報まで、つまりマーケティング全てを行った事で再び全体の一部のみを担う役割に戻った時にも今までとは違う景色が見えて来るものと思います。最終ユーザを含めて、あなたの作ったプログラムに関わる人たちが、何を求め何を拒むのか。それは何故か、が事前に察知出来るようになってくるはずです。それは企業のそれに比べてずっと小さな規模だとしても、あなたがその役割を担った経験があるからです。
以上、プログラミングの学習についてざっと書きました。大切なのは自分で判断出来るプログラマを目指す事だと思います。単に目の前のプログラムが仕様通り動いたかどうかだけでなく、そのアプリケーションやサービスを使ったユーザがどう思うか。それを売らなければならない営業マンがどう思うか、更には経営者がどう考えるかを自分なりで構わないので想像することです。それができれば、時には「自分に出された指示そのものが間違っている」場合にも作業前に気づいて逆に良い方法を提言出来るかもしれません。
Step
さて、次は何を身につけます？そのうちどこまでを”今日”やりますか？
ついでに、このまま新人さんに読んでもらう為の文章にします。
できるだけ自分の言葉で書いたつもりですが、僕が下で紹介している本から多大な影響を受けており、同じような事を書いているかもしれません。まあそれも僕自身の復習という事でご容赦くださいw
うちは基本的にはRubyを主に使っているのでRubyの構文の知識は最低限必要です。
ただ、うちの場合、プログラミングだけでなく仕様案作成、設計、バージョン管理からWebサーバだのデータベースだののソフトウエアの選定からセットアップ、ネットワーク設計、そしてサーバへのデプロイ等、基本丸投げになるので(笑 それらの知識も必要になります。
構文
社内では主にRubyを使っています。ですのでRubyの基礎的な構文の知識は必要です。僕はプログラミング自体初心者の時に下の２冊を常に手元に持っていました。
最初の一冊としては「Ruby プログラミング入門」がオススメです。初心者にもわかりやすく丁寧に解説してありますし、実践的で読みながら直ぐにプログラムを作ってみる事ができます。
「Ruby Way」はもう少し詳しく解説してくれている本です。「Ruby プログラミング入門」では物足りない場合はこちらも購入を検討されると良いでしょう。こちらもとてもわかりやすく実践的な内容だと思います。
もちろん上記以外にも良い書籍があります。自分に合った書籍を常に手元に持っておきながら、まずは自分の手でプログラムを組んでみるのが習得への早道だと思います。
Hellow World はお約束として、その後はとりあえず以下の点を学ぶと簡単なプログラムが組めるのではないかと思います。
Step
- 条件分岐(if文)
- イテレータ(配列に対する"each"によるループ処理等)
- 文字列(String)の扱い。+による連結された文字列の生成やsubによる置換等
- 数値演算
- 配列
- ハッシュ
- クラスとメソッドの定義
- ファイルへの書き出し、ファイルからの読み込み
もちろんまだまだ覚える事は沢山ありますが、まずは自分の手を動かしてコードを書く事だと思います。本を見てると簡単そうに見える事が実際書いてみると思った以上にうまくいかないことがあります。その理由がわかったとき、一歩成長したと言えるのだと思います。
それを繰り返しているうちにだんだんと自由に思った通りの動きをするプログラムを組めるようになってきます。
設計
ただ、前述のように丸投げになって誰も指示してくれないので、設計もきちんとしておく必要があります。ポリモーフィズムを応用したりシングルトンなインスタンスを検討するなど基本的な設計については最初から考えてコーディングに取りかからねばなりません。
またWebサービスであれば(X)HTMLやCSS、Javascriptも当然必要になってきます。これらも単に
(σ´∀`)σ動いた動いた♪
的な知識ではなく、どう動かすか、つまり設計を自分なりに考えてとりかかる必要があります。そうしないと後でバグだらけになって手に負えないものになったり修正に時間のかかるものになってしまうからです。
この点について、コーディングにかかる前に新人さんには「どのような設計で作ろうと考えているか」を話してもらうと良いかもしれません。その際にテストフレームワークは何を使うか、データベースの設計はどうするか、Railsを使うかMerbやSinatraも検討するか、しないのならそれは何故か。そして最終的なリリースをいつにするかなど、完全に答えられなくても自分の考えを述べる事で技術的経験的に足りない部分が早い段階で浮き彫りになるかもしれません。
ソフトウエアの設計についてはこの業界では読み継がれている本があります。できれば以下の本には目を通しておいて欲しいです。
特に「リファクタリング:Rubyエディション」と「達人プログラマー」は必ず読んでください。
Step
- 上記のうち、少なくとも２冊を自費で購入して読んでください。自費で購入することで、自分に対する投資感覚を身につける事につながります。
- 上記以外で良さそうな書籍を自分で探して読んでてください。
トレーニング
プログラミングを仕事をはじめて最初のほうは必ずなにかしらの失敗をします（いや、今でも色々と失敗をしますがw）。ある程度できてきた頃に、あちこちに気に入らない所がでてきて、全部作り直したくなったりもします。そうならない為にはどうすれば良いのでしょうか。上記の本を読む事で予備知識や、陥りがちな失敗を知る事ができ、それによって事前に対策を打つ事ができますが、それはあくまで机上の知識です。やはり実践に勝るトレーニングはありません。
まずは自分の普段の仕事を、「小さなプログラム」を作る事で自動化しましょう。普段の仕事の中には自分でも気づかずに実行している無駄な仕事があると思います。
もし、その作業が「手でやる場合」と「自動化するプログラムを作る場合」とで同じ時間がかかるならプログラムを組んで自動化しましょう。かりに２、３倍かかったとしてもやはりプログラムを組んで自動化するべきです。そうすれば明日からはその作業にかかる時間は飛躍的に短くできます。
しかし、それ以上に重要なのは「自分が日々使うプログラムを自分で作り保守する」ことにより、ある面では素晴らしい本を読む以上の経験が得られる事です。
ユーザが自分なのですからリスクは最小です（データベースから全ユーザを削除したりしなければw）。そして最終ユーザからのフィードバックが即座に得られます（最終ユーザが自分なのですから当然ですがw）バグはもちろん、使いにくいと感じた所もどんどん直していきましょう。時間がなかったりすると作り手故に知っている”回避方法”を使ってバグのあるままに使い続ける事もできると思いますが、ずっと微妙な「嫌な気持ち」を感じながら使う事になると思います。嫌な気持ちになったらすぐに直しましょう。そうすると今度は逆に少し幸せな気持ちになれるはず...と思われますw
僕も今まで小さなスクリプトを幾つも作ってきました。例えば複数のサーバに同じアプリケーションをデプロイする際にコマンド一つで、最新のソースのチェックアウトから再起動までを自動的にやってくれるようにしたり、同じくコマンドひとつでテキストファイルに登録された全サーバにpingを打ったりポートオープンしてサービスの稼働状況を監視したりするプログラムです。
あるいはもっと地味に、単に特定のサーバへSSHトンネルを張るコマンドを１行書いただけのbashスクリプトだったり。
小さなプログラムなら失敗しても直ぐに作り直せます。失敗はできるだけ他人に影響の無い範囲で経験しておいて、その教訓を他の人が使うプログラムの開発に活かすように心がけましょう。
Step
- 自分の普段の仕事、定期的に行っている仕事を自動化するプログラムを作りましょう。
- 作ったプログラムを実際の仕事の中で使いましょう。不具合や使いにくい箇所を見つけて修正しましょう。
トレーニング【更に】
上記で小さなプログラムで自分の仕事を自動化する事で経験を積む事を書きました。
いくらかの経験を積んだら、今度は外に向かって「自分のプログラム」を公開しましょう。もちろん小さなプログラムで構いません。なにか便利なサービスを提供してくれるデーモンでも、コマンドで実行するプログラムでも、あるいはWebサービスや、よく使う汎用的な関数をライブラリ化して公開するとか、今ならiPhoneやAndroid向けのアプリもいいでしょう。
どんなに”地味”な公開であっても「アプリケーションの公開」は、それに伴って更に幾つもの判断ポイントが生じます。例えば公開のタイミング。どこまで実装したら公開するのか、開発の初期段階でのシンプルな状態で公開すればバグを少なく済ませられますが、同時にインパクトも小さくなりがちです。インパクトが無ければ折角作っても誰も使ってくれないかもしれません。
公開後はどうやって周知するか。iPhoneアプリなら検索に引っかかるようにタグを設定するとか、アプリ名も検索されやすい単語で構成するとか。
保守も重要です。バージョン管理の仕方、ソースが公開出来るならgithubを使う事をお勧めします。githubは幾らは支払えば非公開にもできます。新人さんには全員githubのアカウントを作ってもらって、そこで個人的なトレーニングの成果や学習プロセスを確認できるようにしておくのも良いと思います。
そしてここに来て「誠実に対応する」事の重要性が浮き彫りになります。あなたがバグを放置すれば気に入って使ってくれていたユーザも使うのを止めたり、あるいはコメント欄に苦言を残すようになるかもしれません。それを見た人がダウンロードして使ってみたりするでしょうか？
逆に、バグの報告を受けて直ぐに直す等のアクションを起こせば、むしろバグによりユーザの信頼を得るきっかけにもなるでしょう。もしかしたらブログで取り上げて頂けるかもしれません。そのような機会が増せば、運が良ければ更に沢山の人が閲覧に来るサイトで紹介してもらえるかもしれません。
真の意味での「誠実な対応」は一見非効率な行動に思われがちですが、目の前のユーザ一人一人に満足してもらう事でしか開けない道もあると思います。それにGoogleやTwitterで自分のアプリ名を検索したとき、ユーザが喜んで使ってくださってたり、人に勧めてくださってたりすると嬉しいものです。この喜びは何物にも代え難いです。仕事の中で全体の一部だけやっていたのではわからない楽しさがあります。
そして、小さな規模とはいえ、自分一人で企画から仕様決め、コーディングに公開そして保守、さらには広報まで、つまりマーケティング全てを行った事で再び全体の一部のみを担う役割に戻った時にも今までとは違う景色が見えて来るものと思います。最終ユーザを含めて、あなたの作ったプログラムに関わる人たちが、何を求め何を拒むのか。それは何故か、が事前に察知出来るようになってくるはずです。それは企業のそれに比べてずっと小さな規模だとしても、あなたがその役割を担った経験があるからです。
以上、プログラミングの学習についてざっと書きました。大切なのは自分で判断出来るプログラマを目指す事だと思います。単に目の前のプログラムが仕様通り動いたかどうかだけでなく、そのアプリケーションやサービスを使ったユーザがどう思うか。それを売らなければならない営業マンがどう思うか、更には経営者がどう考えるかを自分なりで構わないので想像することです。それができれば、時には「自分に出された指示そのものが間違っている」場合にも作業前に気づいて逆に良い方法を提言出来るかもしれません。
Step
- どのようなプログラムを作って公開するか、自分なりに考えてみましょう。どのような目的で作るか、最終ユーザはどんな人なのか具体的にイメージします。
- プログラムの実行、配布形態を決めましょう。iPhoneなどのスマートフォン上で動作するアプリやWebアプリケーション、コマンドラインで実行するプログラムなど、それぞれでどのような利点、欠点があるかを考慮して決めましょう。
- 開発を行います。先に示した書籍を参考にしたり、自分の頭で考えたりしながらどのような設計にするか、画面仕様はどうするのか、その仕様にした時に、それを見たユーザはどう感じるか、イメージしながら開発します。
- 公開しましょう。どのようなタイミングで公開するのが効果的か、あるいは安全か、関連する要因を考慮しつつ決定します。
- ユーザからのフィードバックを受け取りましょう。Twitterアカウントを作ってそこで受けとるのも良いですし、専用のサイトを作ってコメントを貰うのも良いと思います。頂いた意見に対して従うのか、逆提案するのか、なにもしないのか決定します。場合によってはコメントをくれた人に自分の決定の理由を説明し理解を得なければならない場合もあります。
ちょっと新人さんには重い内容になってしまいましたが、少なくともユーザがどう考えるかだけはどんなに一部分の仕事でも必ず考えるようにしましょう。そうすればユーザに喜んでもらう為にあなたが次に身につけなければならない事は自然と見えてくると思います。
さて、次は何を身につけます？そのうちどこまでを”今日”やりますか？
0 件のコメント:
コメントを投稿