プログラミング教育の目的は、職業訓練ではなく課題解決力であるとは本当か？ - レベルエンター山本大のブログ
「子供向けのプログラミング教育については特に、職業訓練ではないのだからプログラミングスキルを身につけることを目的にしてはいけない。課題解決力を身につけることを目的にするべきだ。」 上記のようなことは、子供向けプログラミング教育を義務教育化するなかで、すごく言われていることです。 確かに、若い人が「目的」に据えるのはできれば応用の効く抽象的なスキルであるほうがよいでしょう。 だが、教育する側として現場にいると、そんなことで子供は付いてくるだろうかという感覚になります。 例え話に引きずられすぎるのはよくないとしても、考える角度を変えるには良いでしょうから、英語教育に例えて考えてみます。 プログラミングに関する冒頭の文は英語教育に置き換えると以下のようになるかと思います。 「子供向けに英語教育を行う目的は、職業訓練ではないのだから会話スキルを身につけることを目的にしてはいけない。国際感覚を身につ
自分向けにソフトウェアを作ったことがないエンジニアと自分向けに料理を作ったことがない料理人 - レベルエンター山本大のブログ
いままで、ITエンジニア向けの研修で「自分向け（または個人的に）どんなものを作ったことがあるか？」をアンケートすると一番多い答えは「特になし」。「これからどんなものを作りたいか？」を聞いたときすら「特にない」と答える人がいる。 技術は仕事のために習得しており。役割になりたい（プログラマになりたい、コンサルタントになりたい）ということを原動力に学ぶ。 しかし、他のプロの職人（たとえば料理人）に、個人的になにか作ったことはあるかと聞いたときに「特になし」なんてありえるだろうか。 他の職人は、何かしら個人的に作りたいものや作った経験があって、作ったことによる喜びも知ってるはず。人に喜んでもらうこともその一つ。 作る喜びがわかってると、自ずと新しいことに興味がわいて学ぶ意欲がでてくる。参考書を丸暗記するよりも効果が高い。 プログラミング講師としては「作りたいものを発見してもらうこと」が、「個別の技
「会社設立 freee」をつかって実際に起業した話 - レベルエンター山本大のブログ
会社設立のとき「会社設立freee」にお世話になり今は「会計ソフトfreee」お世話になっています。 こんなニュースがあったので、お祝いのつもりで「会社設立freee」が便利だったということを書きます。 「freeeが35億円の資金調達ースモールビジネスを支えるプラットフォームを目指す」 http://jp.techcrunch.com/2015/08/24/20150824freee/ 「会社設立freee」は、まるでソフトウェアのインストール時に使うセットアップウィザードのように、次へ次へとやるべきことを指示してくれるサービスです。 なかなか難しい「電子定款」に対応しているので、それだけで印紙代の４万円が５０００円の代行手数料だけになってお得でした。 「会社設立freee」を使っていなかったら、１つ１つのステップで手戻りや調査に時間がかかっただろうなと思いますし、なにより初めてやる作業
施設が立派でも働く人がその思想を理解していなければサービスは価値を失う - レベルエンター山本大のブログ
国立の新しい美術館でのこと。 この施設は本当に子供やお年寄りに優しい施設だと感じる。 授乳室は最近珍しくないけど、託児所まで完備した施設は、東京都内でもそうそうはない。 展示の文字も大きく作られていて、館内全域でバリアフリーだ。 それでも、小さい子供連れ（１歳３ヶ月）での美術館は何かと気を使う。 展示場へは、夫婦交代で入って周りに迷惑をかけないように気をつかった ウチの嫁さんは周りに迷惑をかけるのがとても嫌いだ。 迷惑かけないようにいつも頑張ってる。今日もそうだった。 さて一回りして、疲れたので地下のカフェへ行った。 子供はだんだん疲れて、ややグズりはじめる。もう眠たいのだろう。 カフェの席は、子育て経験も豊富な奥様がたと相席になった。 「かわいいね」とか「あー懐かしい」とか、ほのぼの見てくれてた。 でもいよいよ寝ぐずりタイムで泣き始めてしまった。 立ってあやしてもいうことを聞きそうにない
希代の名著登場！ビジョナリーカンパニー4は必読 - レベルエンター山本大のブログ
ビジネス書の中で僕の今までの最高に影響を受けた本は、ビジョナリーカンパニー2でしたがビジョナリーカンパニー４はそれを越えたかもしれません（今、読んでる途中なので暫定です）。 ビジョナリーカンパニー４ ビジョナリー・カンパニー4 自分の意志で偉大になる 作者: ジム・コリンズ,モートン・ハンセン,モートン・ハンセン共著,牧野洋出版社/メーカー: 日経BP社発売日: 2012/09/20メディア: 単行本購入: 3人 クリック: 116回この商品を含むブログ (16件) を見る ビジョナリーカンパニーシリーズに共通しているテーマは「偉大な組織」です。偉大な組織となり得る要因を膨大なデータ検証に基づいて研究している点が特徴です。 単なる考察や経験則からの見解とは異なっていて説得力があります。 この本では、同じように不確実な環境下におかれながら偉大になった企業と偉大になれなかった企業を1組ごとに対
人月は悪どころか、ものすごい善かもしれない - レベルエンター山本大のブログ
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね？」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
「16秒の奇跡」あるいは計測とタイムアタックこそ生産性向上の銀の弾丸 - レベルエンター山本大のブログ
教育をやっていて、思い知らされたことがある。生産性向上についてである。 語弊を恐れず敢えて言い切る生産性向上の銀の弾丸は、計測とタイムアタックにある。 今年、ある大手企業さんの新人教育を担当していて奇跡とも言える生産性的現象に遭遇した。 僕は、新人さんにいつも、ちょっと変わったレイアウトで席を作ってもらう。 グループ単位であったり、講師を取り囲むようなレイアウトであったり。 講義開始時に、そのレイアウトに席を移動してもらうんだけど、この時間をいつも計測する。 最初は、「5分でレイアウトをそろえて全員が着席できる」ようにと指示する。 そうすると大体の場合、5分ギリギリで全員が座っている状態になる。 5分をクリアするしたので、「よくやった」と褒める。 次の日、一気に半分の「2分30秒でやってみろ。」という。 そうすると、面白いことに皆目付きが変わって必ずクリアする。 さらに次の日。 より高いハ
スーツとギークという区分けがなくなった時代の理由 - 山本大＠クロノスの日記
id:gothedistanceのエントリで話題になってた1つのコメントが、まさに僕のブログに対してつけられたコメントでした。 http://d.hatena.ne.jp/iad_otomamay/20100216/1266333904#c1273690204 上記の「コメント主」に対して言いたいことはなにもないのですが、 id:gothedistanceの話題に少し触発されて、僕がリーマンショック以後の日本のSIerにいて感じることを述べます。 テーマは「スーツとギークという区分けがなくなった時代の理由」です。 （とりあえず、皆がスーツとかギークとかいう論争に飽きたことという理由は除いて語ります。） もはや、今の時代のSI業界では「要件定義だけやるからあとヨロシク」と言って逃げられる人はいなくなりました。 理由のひとつは、簡単な話です。 理由 1. 不景気で逃げる先の仕事がなくなった さ
任せられることで人間は成長するから、人に仕事を振るときは頭から尻尾まで振りなさい。 - レベルエンター山本大のブログ
人に仕事を振るときは、頭から尻尾まで振りなさい。 と、これはウチの社長から教わった、人の活用術ですが、 その真意を知った気持ちです。 今の仕事のチームで僕の片腕になってるメンバーがいます。 片腕というよりも、もう完全に背中を預けています。 彼が最近、提案資料を作ってお客さんのところでプレゼンをしたんですが、 いつも厳しいお客さんが、するすると提案を受け入れてくれて 最後には「提案ありがとうございました」と、感謝の言葉をくれました。 僕も何度かこのお客さんに提案資料を持っていったことがありましたが、 提案が気に入られないときは感謝の言葉どころの騒ぎじゃなく、 コテンパンに突っ込まれて終わることもあるので、この感謝の言葉には価値があります。 彼が作った提案資料は、最初僕が作ろうと思っていました。 彼があまり得意じゃない分野の提案なので、 提案のデビュー戦にはふさわしくないと思ってたからです。
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
ある意味RACより使えるやん Oracle Streams - レベルエンター山本大のブログ
相変わらず大きいプロジェクトでばたばたと色々やってます。 ひょんなことから、システムの可用性設計に関わることになって 当初、めちゃくちゃ作りこみで何とかしようというアイデアしかなかったところへ、 頭をひねってOracle Streamsというのを導入しようということを提案したんです。 OracleStreamsというのは、OralceDataBaseに組み込まれている機能で、（9iから） DBのレプリケーション機能です。 で、お客さんが運よく食いついてくれて、さあ導入のために動き出せると言うことになりました。 で、Oracle Streamsというのを使って色々やってるわけです。 まぁこういう技術検証と方針設計が一番楽しいですね。 （付け焼刃の提案、、、とか色々批判はあるかもですが、まぁ事情が色々ありなのでその辺はご容赦。） OracleStreams仕組みをざっくり言えばこうです。 1.
限界と比較し、相対値として記憶に残る。 - レベルエンター山本大のブログ
今から5年ほど前、東京に来ていたときは奮闘の日々だった。 毎日終電まで現場をこなした後、さらに土日もなく連載記事の執筆などに追われていた。 でも振り返ってみると、あのときの仕事は”今の僕”にとっては余裕な仕事だ。 しかし仕事の難しさは絶対値ではなく、当時の自分の限界と比較したときの相対値として記憶に残る。 あのとき力を出しきったことが、今の自信になってる。 120パーセント出し切ったときに、超えた20パーセントが新たな力になるのだと思う。 常に限界を超えるのは難しいけど、少なくとも100パーセントでやってない人は縮小傾向だといえる。 80パーセントで余力を残して仕事をするのがスマートに見えるかもしれないけど、 あとあと80パーセントがその人の100パーセントになるだけだろう。
たぶん迷ってるだろう教え子たちへ - レベルエンター山本大のブログ
去年、新人研修で教えた教え子たちも、もう現場に入って半年になります。 きっと、たぶん今頃、壁にぶち当たっているんだろうなー。 僕が今入ってる現場でも、教え子たちと同級生の人たちがいて 日々悩んでるように見受けられます。 教え子たちへ。 自分がやっていることに意義を見出せなくなってきた教え子たちへ。 自分はこれでいいのかと疑問を抱き始めた教え子たちへ。 自分のやってることの意義が見出せないのは、 自分をプロデュースしてこなかったからじゃないかい。 僕はこの業界でセルフプロデュースする2つの方法を知ってる。 1つは、自分にあってると思える技術をつけること。 でも、これは一朝一夕では効果が出ないかもしれない。 もう1つの道は、情報通になること。 研修の中でも言ったけど 発信する者に情報は集まる。 現場には、インターネットで検索できない情報がたくさんある。 めちゃくちゃ簡単な話だと、ファイルサーバ
与えられた環境と分析し、戦い、乗り越えることで、与える側に立つ。−募集に対するQA - レベルエンター山本大のブログ
一緒に働いてくれる人を募集とか呼びかけてみる - 山本大の日記についてトラックバックで質問をいただきました。 これはとても有難い反応ですので、感謝の気持ちと共に、僕なりの答え方で答えさせていただきます。 【トラックバック】 採用募集について、幾つかの質問 - @katzchang.contexts Q 「大中規模の〜」とありますが、規模とは何のボリュームをさすのでしょうか（ユーザ数？データ数？ステップ数？）？ また、どの位が中規模以上となるんでしょうか？ A 僕らが携わっているシステムは100万ユーザであり、大規模といえるでしょうね。 それに対して僕が1年前に携わったシステムは、総ステップは100万ステップ以上ありましたが、 保守プロジェクトで、2人で追加機能をつくっただけなので小規模プロジェクトでしょう。 じゃあ、何が正しい答えなの？と思うかもしれませんね。 僕らが提示した「条件」は応募
トラぶってグチャグチャに行き詰まるからこそ勘や発想力が養われる - レベルエンター山本大のブログ
伸び悩む若手のエンジニアのひとつのタイプは、 まじめで努力家だけど、どうにも勘が効かないというやつです。 彼らは、実直でまじめだからキチンとマニュアルを手順どおりにやるんですが、 敷かれたレールから外れることに非常に弱いのです 彼らに対するアドバイスを日曜日の夜中0時にテレビを見ながらふと気づきました。 マニュアルどおりにやるから発想力や勘が養われないんだ。 気づいたことは以下です。 日曜日の夜0時、テレビをつけたらことごとく全ての局がスポーツニュースを流してました。 月曜日の現実に達する前に、ちょっと息抜きに笑えるような番組を探してもそんなのありません。 なぜこんなどの局も横一線なんだと憤慨したということを 友人に話したとき、彼は知ったような口ぶりでこんな事を言ってました。 「そりゃ、テレビ業界のマニュアルやらリサーチやらに従ってるからだよ。 日曜夜0時は、これこれの層がテレビを見てるか
机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか？ - レベルエンター山本大のブログ
プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言いながら、机の前、パソコンの前に座って取れる方法だけにとらわれていたことが 僕自身にもありました。 そのプロジェクトのエンドユーザーさんはとても田舎の工場で、 僕が勤務してた大阪の市内からは、車で行って2時間（高速代などで10000円）、 電車で行くと2時間40分（片道3000円）かかるところにある、 なかなか厳しい立地条件のお客さんでした。 僕はこの案件で、要件定義から参画しましたが、 ミーティングをするために、客先に出向いても往復に4時間以上かかるので せいぜい3時間しかミーティングの時間が取れません。 このため時間的にもお金的にも、ミーティング
メモを取るのはこの3点だけに絞れ - レベルエンター山本大のブログ
小飼さんのブログ「404 Blog Not Found:メモらぬ阿呆にメモる馬鹿」で、メモについて話題になっている。 仕事ではメモが重要だ、新人はとにかくメモをとれ・・・というのが一般論で、 TB元で話題にしてるのは「メモ不要論」に近い。 僕は基本的には「過剰メモNG」のスタンスだけど ALL or NOTHINGで議論せず、メモの内容を最低限に絞るべきだと考えている。 具体的には、僕はメモを以下の3つだけに絞っている。 1.あとで質問すること、疑問に思った点 2.日時・場所・数値 3."相手が"重要視しているキーワード 前提、メモ魔は結局話を聞いてない IT講師をやっていて思うことがある。 それは、授業にノートをがんばって取っている受講生さんが話を理解しているとは限らない。ということだ。 講義の場合は、うまくノートを作らせてあげたうえで話を理解してもらうのも講師の力量なんだけど、 ビジネ
クラウドはパラダイムシフト確定だから、四の五のいわずにGAEとKey-Value Storageをやっとけ - レベルエンター山本大のブログ
Google App Engine(以下GAE)がJavaに対応してから、その衝撃的サービス内容から 「これはパラダイムシフトであり、破壊的イノベーションなのではないか」と論議されるようになった。 クラウドはとっくにバズワードではない。そして、 クラウド型のアプリケーション提供方式は、間違いなくパラダイムシフトだと断言する。 ただし、既存のものに急に取って代わるという破壊的イノベーションではないと考えている。 RDBなどは必ず生き残り役割分担の選択肢となる。いままでのインハウス型プロジェクトもなくならない。 しかし、１〜２年で開始するプロジェクトは、もう.NET or Javaといってプラットフォームを選択するまえに、アプリケーション提供形式としてインハウス or クラウドを選ぶ時代になるだろう。 管理コスト面、初期コスト面ともに優れたクラウドという選択肢が提供できない提案・企画は駆逐され
テストは「最低限」のパターンではなく、与えられた時間の中で「最大限」やるべきだ。 - レベルエンター山本大のブログ
本来、高い品質を得るには、できるだけ沢山のパターンを出来るだけテストしてみるのがよく 考え付く限りのパターンを全網羅するテストが出来れば最高だ。 しかし現実問題として、それは全くもって途方もない。 だから何らかの基準を設けて、テストパターンを絞らざるを得ない。 しかし、工数（=お金）をケチることを優先してパターンを絞ると 最低限のテストパターンを求めることになる。 工数(=時間)を掛けずにいかに最低限のテストをするかと考えると、 テスト期間をあらかじめ決めるよりも、ソースコードのボリュームに対して 何割という計り方をした方が、うまくインチキできる。 だからじゃないだろうか、テスト工数の見積りだけ、急に１キロステップ中のバグ数とか、 分岐のパターン数による見積という摩訶不思議な基準が現れるのは。 それまで散々「人日」や「人月」という、時間基準の工数計算をして来たのにだ。 僕は、むしろテストこ
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
