ネタつつき71－スランプの時はどうするのか？

スランプの時私がどうしているのかという質問が来たので、それをネタにして書きます。
誰でもスランプの時があります。学習をしようと思っても集中できないとか、仕事中に集中できないとか・・・
そういった時は何をしても駄目なので、視点を変えるしかありません。例えば・・・
コンパイラの学習が詰まったらネットワークの学習をすると言った分野変え。
C++の学習に嫌気がさした時はJavaの学習をするなどと言った言語変え。
命令型言語に嫌気がさした時は、関数型言語もしくは論理型言語に返ると言ったパラダイム変え。
プログラミングそのものが嫌になった時は、アジャイル開発の思想などを学習するといったレイヤ変え。
情報処理技術の学習に詰まったら数学を学習するなどの学問変え。
という風に視野を変えてしまいます。もしそれでも駄目な場合は、脳が疲れていると思われますので思い切って睡眠を長くとったり、自然の風景を鑑賞したりします。
こういった風に自分のアンテナを広く持つ事が大事です。私はアンテナを広く持っているおかげで、スランプになっても対象を変えて停滞を防いでいます。そうすれば、スランプなんて怖くありません。

追記
初心者の頃の感動を思い出すのも一つの手です。スランプの時は初心に戻るのが良いでしょう。そうすれば、おのずとやる気が出ます。初心に戻る方法は、命令型言語しか知らない人が関数型言語を学ぶなどの未知なる分野で遊ぶのが効果的です。学ぶと言っても楽しまなければ長続きしません。自分の好きなポイントを見つけて、それを元に楽しむ心を持つのが良いでしょう。
あと、人間の脳は成功体験を思い出すと良い効果をもたらすらしいです。成功体験を思い出してモチベーションを高めるのもいいでしょう。
最終的には無知を楽しむ精神があればよいかと思います。知る楽しみが分かればモチベーションが低下する事は殆どありません。

ネタつつき70－分散並列処理についての考察9

前回 から引き続き分散並列処理について考察します。


あまり要素ばかり考えても面白みがないので、今回は言語そのものについて考察します。分散並列処理を実現する言語は動的か静的どちらが良いのでしょうか？私はこれが瑣末な事だと考えております。何故ならば、動的か静的かという側面で物事を考えても分散並列処理は捉えられないと私は考えるからです。
では、何が重要なのかと言いますと、情報の動的性です。これはどういう事なのかと申しますと、分散並列処理では情報の性質そのものが重要となるからです。これまでネット空間と状態に関する情報は常に変化する事を考察しました。前回少し触れましたが、この情報は静的言語／動的言語の区分はどちらでもよく、どのようにオブジェクトが存在するのかという点とオブジェクトは何を判断するのかが重要なのです。
この観点から申しますと、既存の言語設計の在り方そのものを考え直す必要があります。言語と言うある種静的で狭い範囲の情報ばかり着目しても仕方がありません。分散システムにふさわしい規模で物事を捉えないと美しく実用的な分散並列処理コンパイラは実装できないでしょう。
これらの考えから導き出される答えは非常に興味深いものです。私が思うに、これからのコンパイラはOSとの境目が薄くなるでしょう。分散並列環境に於いて、パフォーマンスを向上させるにはOSレベルまで視野に含めないとだめなのです。
さらに、この動きが加速すると、OSそのものが分散並列化し、LinuxとWindowsをミックスして動かすなどと言った事が実現されるものと思います。この世界は非常に刺激的で無限の可能性を秘めた未知なるものです。その時代が来た時に生き残れるのはどのような開発者なのか、そしてどのような開発環境になるのか、非常に興味深いものがあります。


未来への希望を込めてつ・づ・く♪

書籍をつつく129－実践アジャイルテスト。開発チーム必見！

昨日めぼしい書籍を探してインターネット空間を飛んでいたら、おいしそうな本を発見したピヨ♪
実践アジャイルテスト テスターとアジャイルチームのための実践ガイド
テストは重要だよね。さて、どんな本なのかな？目次を見てみたピヨっ

【目次】
序文
第1部 序説
第1章 アジャイルテスティングとは?
第2章 アジャイルテスターの考え方
第2部 組織的なチャレンジ
第3章 文化的なチャレンジ
第4章 チームのロジスティクス
第5章 典型的なプロセスの移行
3部 アジャイルテストの4象限
第6章 テストの目的
第7章 チームをサポートする技術的なテスト
第8章 チームをサポートするビジネス面のテスト
第9章 チームをサポートするビジネス面のテストのためのツールキット
第10章 製品を批判するビジネス面のテスト
第11章 技術面からのテストによる製品の評価
第12章 テストの象限のまとめ
4部 自動化
第13章 なぜテストを自動化したいのか、何が阻害するのか?
第14章 アジャイルテストの自動化戦略
5部 テスターのライフにおける反復
第15章 リリースやテーマ計画におけるテスターの作業
第16章 本格的に行う
第17章 反復のキックオフ
第18章 コーディングとテスト
第19章 反復のおさらい
第20章 成功したデリバリー
6部 まとめ
第21章 重要な成功要因
索引

おおー、組織的にテストを論じているのがボクの食欲をそそるピヨ♪テストというものは、開発者個人が勝手にやるものじゃないピヨ。やはり、組織的にやる必要があるんだ。それにアジャイル開発をスラムダンク方式と勘違いしている人が多く、意外とテスト計画を疎かにされやすいからこういった本は必要だと思うピヨ。
というのも、アジャイル開発では、短いサイクルを繰り返すから、脊髄反応で場当たり的にテストを実施しているところもあるんだ。でも本来アジャイル開発ではテストは重要視され、無計画なテストは推奨されないんだ。これは、初期のアジャイル本による弊害もあるとボクは思う。
初期のアジャイル本は、ユニットテストのコードを書いてからコーディングをしろ的な事だけが強調されて、チーム全体でテストの方針をどのようにするのかという点の説明が疎かになっていた節があるピヨぉ。だからだと思うんだけど、アジャイル開発の事をスラムダンク方式のプロトタイプ的な開発法だと勘違いしている人をよく見かけるピヨ。
この本の目次と紹介文を見るに、組織的にテストを行う方法が書かれているようだから、これは非常に重要な本だとボクは思う。テスト体制は会社の品質に対する意識の表れと言えるから、真面目に情報システムを開発したいチームは必ず読まなければならない書籍ピヨ。


本好きな人は目次コーナーを見ると言いピヨ。それと、他の開発本を知りたい人は書籍紹介記事の目次ーソフトウェア開発関連の本 を見ると良いピヨ♪皆で能力を高めよう！

中の人の徒然草283

休日はDebian5.0を堪能したインドリでーす♪久しぶりにDebian触ったら、細かいところを忘れていて大変でした（笑）例えばapt-lineの設定をしようと思って、「あれ？設定ファイルの場所何処だったけ・・・」とか「設定ファイルの書式はえっと・・・」とか、場所や初期と等の細かい情報を忘れている事に気づきました。
Linuxは開発者の天国ともいえますが、準備面は結構面倒なんですよね・・・
でも、aptの設定が終わったらDebianは病みつきになりますよね♪apt-getは凄いです。依存性を気にしながらダウンロードしたソースコードを解凍してコンパイルする昔のUnix方式とは大違いです。もう、調子に乗ってapt-getしまくりました。Ruby1.9 とかCLISPとかGHCとかOZとか（省略）大量ゲッツしました♪開発環境ゲッツだぜ！
これからはもっとDebianを使っていこうと思います。
快適だし、使っていないと忘れるからね（笑）
それに、コンパイラコンパイラの研究にも役立ちそうだ。
よーし、ぼちぼちLinuxプログラミングをやって感覚を取り戻すぞ！

ネタつつき69－価格設定が出来ないIT会社達

私が前から不思議に思っていた事がありますので、その事について書きます。
私は以前から人月単価から脱却できない会社が多い事を不思議に感じていました。 原因は複数考えられますが、その中の一つとして情報サービスの価格を設定できない事があげられると思います。
私が良く耳にする、価格を人月単価にする理由は、情報サービスは目に見えないです。しかしながら、目に見えない商品は何もIT業界だけではありません。サービス産業の商品も目に見えません。それでも価格は設定しています。それに、そもそも価格は科学的なものではなく、感覚的なもので決まっています。ですから、目に見えないからと言って価格を設定できないというのは言い逃れにしか聞こえません。
では、どのように価格を設定するのかと言いますと、お客様が得る利益に基づいて感覚＋数値で行うのがベストでしょう。数値と言うところがポイントです。実は情報サービスは、目に見えないどころか帳簿でははっきりと目に見える存在です。
これは、情報システムがどのような目的で作られるのかを考えればわかります。エンドユーザーが情報システムを発注する目的は経費削減と生産効率のUPです。という事は、帳簿を見ればどれ程の効果があったのかは目に見えるのです。これは他のサービスにない情報処理技術の利点です。
その利点を売り込まずに、人月単価で価格を設定する会社が多い事が私は不思議でなりません。商品の価格と言うものは、作り手が購買者に与える価値を考え、自信を持って設定するものです。価格設定は商売の基本と言ってもいいでしょう。その商品の魅力の一部であると言っても過言ではないでしょう。
それにも関わらず、自分の都合で価格を設定する会社が多い事が間違っていると私は思います。また、自社が創造した商品の魅力を自信を持って売り込めない会社が存在するのが不思議でなりません。
IT業界の不可思議なところは多々ありますが、商品の価格ぐらい設定できるようになって欲しいと私は思えてなりません。

ネタつつき68－経営者は無知でいいという誤解と業界の正常化について

この業界には経営者はITに関して無知でもいいという迷信がはびこっているので、今日はそれをネタにします。結論から先に言いますと、無知でもいいなんて言うのは商売を嘗めた言葉であり、情報サービス業も嘗めている言葉でもあります。ですから、無知でもいいというのは間違いです。これからその理由について書きます。
先ず第一に考えなくてはならないのは、経営者はどのような能力が必要かという事です。これが曖昧では話になりませんので先にそれを私なりに定義します。一言で言うならば、経営者の能力とは会社を繁栄に導く力だと言えるでしょう。会社は慈善事業ではありません。繁栄しない会社を経営する者が高い能力を持つ人とは言えないからです。では、会社を繁栄させるにはどんな能力が必要なのでしょうか？
会社を繁栄させるにはなによりもお客様が大事です。一言でいえば簡単ですが、これが非常に難しいのは皆様も御承知の事でしょう。お客様のニーズも様々で、人々の価値観は常に変化し続けます。この変化に対応したり、変化に負けない安定した価値を創出するのは並大抵の事ではありません。しかし、それをやり遂げるのが経営者に求められる能力です。お客様に見向きもされないのであれば商売になりません。
ではどうすればお客様に愛される会社が経営できるでしょうか？それは、生産性の高い会社組織にするという一点に尽きると思います。その組織というシステムを設計するのはもちろん経営者です。組織の長として、組織のシステムの運営／管理が出来ないのであれば存在意義がありません。
その組織作りが滅茶苦茶な会社が多いのがこの業界の特徴だと私は考えております。先ず第一に、経営者が無知でいいという戯言が通用するという事は、情報サービスは何も考えなくても売れると言って居るのと同じです。私は職業柄、他の業界のシステムも興味を持っていて、書籍やドキュメンタリーなどを積極的に見ていますが、他の業界で無知でもいいという経営者はいません。逆に、徹底的に調べつくして生産性の高いシステムを作っています。成功した経営者たちは、徹底的に会社というシステムの効率化を求め、他社の製品やサービスを調べ、寝ても覚めても商売の事を考えているのです。これは極当然の事です。
しかしながら、日本のIT業界は「良く分からないからいいや」というお客様の甘やかしが、ITに無知でもいいという経営者を大量に生み出しています。それでも会社の経営が成り立っているのは、ひとえに優しいお客様あっての事だと言えます。日本は信じることから始めると言う良い文化があり、その精神構造が詐欺的な会社を生かし続けています。人を信じると言うのは良い事だと私も思います。しかしながら、信じると考えないのは違います。本当に信じるのであれば、厳しくチェックしても大丈夫だと考えましょう。
IT業界の奇妙な構造は色々な原因があると思いますが、お客様のチェックが甘いというのは最大の原因だと思います。建築業界だって鑑定士は居ます。不動産だって鑑定士は居ます。美術品だって鑑定士は居ます。ならば何故ITに鑑定士を求めないのでしょうか？私にはそれが不思議でなりません。チェック機能が甘い現状では詐欺的商売がまかり通っているのが現実です。悪い人はいないと信じるのではなく、チェックしても大丈夫だと信じましょう。チェックしないというのは、現実から目をそむけているだけであり、本心から信じているのではありません。信じると言う事を勘違いしてはなりません。
この業界を正常化するには厳しいチェックが必要です。中小企業やフリーエンジニアなどのフットワークが軽い（しがらみが薄い）商売人を利用しましょう。ただし、下請けしている中小企業は大人の事情で適切なチェックが出来ないのは言うまでもありません。情報サービスを購入する際には利害関係を把握し、適切なチェックの下購入しましょう。
また、IT会社の経営者は外部の者に冷静な評価を求めましょう。そうすれば、会社の利益を損なう社員に悩まされる事もなくなり、本当に会社に貢献している人が誰だか分ります。部下を信じるのとチェックしないのは別物です。

中の人の徒然草282 寿司奉行

私は小さいころアレルギー体質で、生モノが食べれなかったので、この年まで回転寿司屋に行った事がありませんでした。しかし、もう体質と口が変わったのでトライする事になりました。
妹の強いプッシュで（笑）

妹「お兄ちゃん。回転寿司行こうよ♪最近生もの食べれるようになったからね♪」
私「でも、無難に王将とかにしたいな・・・」
父「王将は定食もあるしな。」
妹「そんなこと言ってたら駄目！人生何でも挑戦だよ♪」
私「最近生もの食べれるみたいだし、挑戦してみようかな？」
妹「そうだよお兄ちゃん。お兄ちゃんは新しい勉強どんどんするやん。それと同じだよ。」
私「そうかもしれない」
父「俺は何でもいいぞ。」
妹「じゃあ寿司屋に決定ね❤私がサポートしてあげるから安心して♪奢ってもいいわよ♪」


寿司が余程食べたかったのか、やけにテンションが高い妹を先頭に回転寿司屋に行きました。


烏賊　皿　皿　トロ　皿　卵　皿　皿　河童巻き　皿　皿　皿　ウニ　皿　皿　プリン　皿　テラミス　皿　皿　ショートケーキ　皿　茶碗蒸し（予約）　皿　
※名前が書いてあるのは名札。

私「おや？デザートも結構あるな。」
カウンター側に座る妹
妹「そうよ、私が高校生の頃友達と一緒によく食べたわ。あっ！お兄ちゃん、トロが流れた！ぼやぼやしていたら回転寿司屋では駄目よ。」
カウンターから遠い位置の私「・・・いや僕の位置からは取れないよ。」
妹「玉子きたよ。」
妹「いくら来たよ。」
妹「あぶり焼きカツオ来たよ。」
名札を全て読み上げる妹。鍋奉行の父も圧倒されていていました。
私「僕は今まで好き食べた事がないからよくわからないよ。」
妹「ならば、最初は玉子から攻めるといいわ。それが鉄則よ。はい、お兄ちゃん玉子よ。」
私「有難う。」
黙々と食べる父。
妹「私はマグロっと・・・お兄ちゃんもマグロ食べておきなさい。」
私「うん。」
妹「あっちょっとお父さん。予約皿は食べちゃだめよ。」
父「でも前を流れて来たぞ。」
妹「予約した人のものは本人以外とっちゃだめなの！」
父「そうか・・・」

暫くこれが続いた後・・・

妹「もぅ、欲しいネタが来ないわ・・・」
父「ここにある画面で何かするんじゃないか？」
父が席にあった画面を指さしました。妹は早速触るのかと思いきや、何故かじっと画面を見つめていました。
私「これ、タッチパネルじゃないかな？」
機械音痴な妹「えっ？タッチパネルって何？」
私（画面を触りながら）「画面を直接触ればいいんだよ。」
妹「へぇー。私が前来た時はこんなのなかったような気がする。じゃあ、トロはっと・・・あれ？どこを触ればいいの？」
私「じゃあ僕がやろうか。」
妹「じゃあね・・・茶碗蒸しと、ショートケーキと、トロと、たらと・・・」
父「じゃあ、俺はネギトロを・・・」
妹の前にあるタッチパネルに腕を伸ばして大量の注文（主に妹）を何とか押した後、くつろいでいると周囲の席に面白い客が居るのに気付きました。

男A（自慢げに）「俺、いつもは女と来るんだ」
男B「そうか・・・」
妹「ねぇ今の聞いた？自分の彼女を１皿100円の回転寿司に連れて来るなんて！信じられない！」
私「こらっ聞こえるって。」
父「確かに甲斐性ないな。そんな奴に娘はやれんな。」
妹「大丈夫よ。私はお座敷とかじゃないと行かないわ！そんなケチな男とは付き合わないわ！」
父「それでいい。女を食わす甲斐性がない奴とは付き合うなよ。」
妹「うん♪」
私「ちょっ二人とも聞こえるって！真後ろの席なんだから聞こえるって！」

他にも家族で来たらしきお客も面白い会話をしていました。
母親「ちょっと、あんた！何してんの！」
息子「えっ何？」
母親「あんたってば、何時もはっきりしなんだから！だから何をしても駄目なのよ！」
私（何の事か分からないが回転寿司でそこまで言う事ないのにな・・・）

そうやっている間に漸く注文の品がやって来ました。
端末「もうすぐ予約の品が前を通ります。」
父「おっ！何かの知らせが来たぞ！」
妹「っすごーい♪ねぇ、お兄ちゃん今の聞いた？聞いた？ハイテクよ、ハイテク！」
私「う、うん。」（普通だと思うけどな・・・）


こんな具合で賑やかに食べていると、小食なわが家族にとっては多い20皿目を超えていました。
妹「いち、にー、さん、し・・・24皿よ。見て♪見て♪24皿も食べているよ♪」
私（さっき細かい奴は嫌いって言ってなかったけ・・・）
父「おっ結構食ったな。そろそろか・・・」
妹「私、今日はおなかの調子が悪いのよね。調子が良かったら今日の二倍くらい食べると思うんだけどな・・・」
父「・・・・・・」
私「くいすぎだろ・・・」


その後、当たり前かのように父がお会計を済ましていました。
あれ？？？妹よ。奢るっていっていたんじゃないのか？
あっでも甲斐性のない私が言うセリフではないか・・・
それはさておき、家族で回転寿司に行くのはいいよね♪楽しかったです。
もっと稼いで両親に何かいいものを奢りたいです。
早く親孝行出来るようになりたいな。

中の人の徒然草281

うぅ寒い・・・ここ数日で一気に寒くなりましたね。寒さに耐えながら、コンパイラコンパイラで遊んでいるインドリです♪
コンパイラコンパイラはやっぱり面白いですね♪オープンソースのありがたみをひしひしと感じます。オープンソース環境は開発者にとって天国です♪
そういえば、最近Linux触っていないな・・・仮想マシン内でOSを動かすと、どうしても億劫になって離れてしまいます。Debianも5.0になった事だし、そろそろLinux専用機を用意しようかな♪
Linuxといえば、Emacs等でシステム開発していた事を思い出します。その当時と今の開発環境を比べると、意外と大差がないような気がします。最近の開発環境はリフレクション機能が便利ですが、それ以外は案外Emacsなどを駆使した開発とやっている事は変わらない気がします・・・
それを考えるとUnixの開発者たちは凄いですよね。
私にとっては遠い昔の人々が、現在にも通用する思想を有してツールを作っていたという事実は非常に驚きです。やはり、ハッカー達の優秀さは群を抜いています。その思想や技法を学ぶためには、もっとLinuxを使わないとね♪お小遣いを貯めてLinux用のPCを買います。
でも、欲しい本がまだまだあるんですよね・・・どうしようかな・・・
ハードを取るべきか、知識をとるべきか、それが問題だ。

ネタつつき67－システム設計の誤解

今回は意外と誤解している人が多いので、システム設計について書きます。その誤解を感じる場面は多々ありますが、システムエンジニアはプログラミングを知らなくてもいいとか、運用の事を考えていない時などで誤解していると強く感じます。これは、もしシステム開発を誤解していなければ出ない言葉です。
そもそもシステム設計とは、情報処理システムを設計するという事です。その情報処理システムは、当然プログラミングによって作られます。その製造過程を知らない人が設計を出来る筈がありません。どのようにして作られるのかもわからない状態で何をかを設計する事なぞ出来る筈がありません。仮に出来るのであれば、エンドユーザーがすれば一番良いという事になりますし、そもそも分からないものを設計出来るのであれば、建築に無知な私だって家を設計出来る事になってしまいます。そんな事出来る筈がない事は明白です。
次に動けばいいというお客様を馬鹿にした態度は、最初から設計行為をしていないと言っても過言ではありません。何故ならば、依頼された情報システムはお客様が抱える問題を解決するためのものであるはずです。もしこれに異をとなるのであれば、不要なものを売りつけているという事を意味します。それならば、犯罪行為ですので普通の商売ではありません。問題外です。問題を真に解決する事を目標とするのであれば、お客様の運用形態を考えて作るのは至極当然の事なのです。
では、情報システムの設計とはどうあるべきなのかと言いますと、お客様が抱える問題を解決し、新しい価値を生み出すものを創造する行為であると私は考えております。ですので当然、私はシステム構築をする際には、お客様が抱える問題を解決して、より生産的な作業に没頭できるようにと、全行程および未来を考えて設計します。また、多くの場合私自身が実装して、絵に描いた餅でないようにします。そうすることにより、お客様に新しい概念が生まれ、新しい仕事も発生する事になります。
しかし現実は、その様に全体像を考えて仕事をする人が少ないと感じます。日本的会社組織の弊害により、個々の人が自身の守りに入ってしまっています。無論そういった保身的な人々も初めからそうであったわけではなく、日本的組織しいては経営者の意思によりそうなってしまったというのが妥当でしょう。そういえば、経営者は情報処理について知らなくてもいいというセリフを何度も聞いた事があります。知らないものを何となく売って勝てる程、商売の世界は甘い世界ではないと思うのですが・・・それに、それは売れば勝ちという詐欺師的発想であり、商売以前の問題だと思います。
長くなりましたのでそろそろ纏めに入ります。私が言いたい事を一言で表すと、システム全体を意識して仕事をしようという事です。誰がためにシステムを作るのかという点を忘れてはなりません。それを忘れる時、デスマーチや不信はやってきます。

ネタつつき66－車輪の再発明に関する誤解

この業界にいる人々にとって車輪の再発明をするなは有名な言葉だと思います。これは、無差別に実装するのは効率が悪いから避けるという意味であり、お金を頂いている者にとって当たり前の事だと思います。それは、元からあるものを実装するのは、コスト面から考えて避けなければならない事だからです。経営者やお客さまにとって、元からあるものを作るという行為は余計な人件費以外の何物でもありません。
しかし、この言葉の意味を勘違いして受け取っている人が居ると私は感じます。というのも、車輪の再発明を避けるという名目でオープンソースや実験から学ぼうとしない人が結構居るからです。これは大きな誤解です。今回はその誤解について書きます。
私が思うにこの誤解の元は車輪の再発明を避けるべき状況を考えていない所にあると考えております。先ほど少し触れましたが、ビジネスでプログラミングや設計をする上で、プロであるならばその作業コストを常に考えるべきです。例えば、貴方の時給が1000円で、既存のライブラリにある機能を100時間かけて実装したと仮定した場合、会社にとって10万円の損失となります。その作業に使う時間を違うものを生産するのに使用していれば、利益になるのにも関わらず、まったく利益が出来ないものに10万円も浪費したわけです。これは明らかに会社に損害を与える行為です。
しかし、私は勤務時間外での車輪の再発明を推奨します。その理由は2つあります。先ず第1つ目に、勤務時間外では他者に迷惑をかけていないからです。2つ目の理由は、プロであるならば仕組みを学んでより一層腕を磨くべきであり、仕組みが分からないものをコピペで使うだけではならないからです。意味もわからずコードをコピペしたり、オブジェクトパターンなどの既存の設計セオリーを無暗に使っていると弊害を生み、生産的な行為が出来なくなります。開発者の仕事は、単純な反復作業ではなく、創造的なものである点を忘れてはなりません。
そうした理由から私は、元からあるものを鍛錬の一環として実装したり、オープンソースを読んだりします。そうすることにより、今まで何となく使っていた車輪がどのような意味を持ち、いかなる状況で使うべきなのかが学べます。プライベートな時間に、自分が興味がある技術に関連するオープンソースを読んで自身でも実装してみる事をお勧めします。
もしこの意見に反対するのであれば、その前にHello worldプログラムを書いた事を思い返して下さい。これは車輪の再発明とすら呼べない単純極まりない非生産的行為です。しかし、価値のないHello worldプログラムを書くことにより多くの人がプログラミングを学んでいます。すなわち、学ぶと仕事で作るとは明確に区別しなくてはならないのです。仕事時には車輪の再発明は避けなくてはなりませんが、鍛錬をする際には車輪の再発明的行為をするべきです。
与えられた仕事だけをこなしても居てもスキルは一定以上伸びません。仕事とは別に先人から学び、自主的に鍛錬をするのが本当のプロフェッショナルだと私は考えます。スキルを伸ばし、与えられた仕事だけではなく、自分で仕事が作れる人間をともに目指しましょう。