「正解」なんていつだってないと思う
元ネタ
経Kei 2009年2月号 通巻第88号
「正解」のない時代に突入
ところが、今回の危機はこれまでの問題と違い、救世主となる既存の産業や市場が明確に見えず、手本となる国も存在しない。すなわち「正解」のない時代に突入したのだ。
-中略-
すなわち、明らかな「正解」や「模範」がない状況下で、産業構造自体も進化させる政府の舵取りが求められているのだ。
んと…正解なんて、昔も今も「ない」と思うです。
多分。これを書かれている方(藤井 清孝氏。ベタープレイス・ジャパン代表取締役社長。元ルイ・ヴィトン・ジャパンカンパニーCEO)はそのあたりを知っていて、だからこそ
残念ながら、日本では「正解の呪縛」で硬直した発想の官僚や会社組織が多く、新しい産業構造を構築する「構想力」を持ったリーダーが少ない。
と書かれてるんだろうと思うですが。
…うん「正解の呪縛」とは言い得て妙ですねぇ。
正解なんて。ましてや「唯一の正解」なんて、あろうはずもないのですが。
見ているに、割合に多くの人が。ほぼ無意識に「正解がある」事を前提に物事を思考していたりするです。で、その前提条件ってか前提呪縛でコケる。
ビジネスなんて。基本どこに行っても誰がやっても「茨だらけの道無き道に獣道を作る」のが初手だと思うです。無論その道をきれいに広くするってのも大事なんですがね。
でも、やっぱりどこかで「獣道を作れる」ことが求められるんじゃないかなぁと思うんですが。どんなもんなんですかねぇ？
あ。「おいちゃんがけだものだから獣道が作れる」とかいう突っ込みは無しの方向でｗ
…どうやって学んだんだろう？
最近…という訳でもないのですが。
いわゆる初学者の方々と接する機会というのが決して０ではないわけでして。
彼らが「これからstartをするためにどうしたらよいですか」という質問に対して、まぁ正直なところ「全力でもって回避＆逃走」をしていた訳なのですが(より正確には「初心者に対して教えるのがうまいメンツ」に全力で振ってました)。
いやまぁ当面そのスタンスは変わらんのですが(マテ)、とはいえそこになんの考察もない、ってのも如何なものかと思いまして。
まずは自分の事を思い出すです。…思い出すです。…思い出そうとするです。
っつかですねぇかれこれ30年弱前の事を思い出すのって結構大変なんですよ。頑張れ自分！！
昔。
まだ世界が混沌だったころ…って戻りすぎ。
進めて。
…一番初めに組んだっつか打ち込んだプログラムは、多分こんな感じだったと思うです。
言語はN88 BASIC
10 FOR I=0 TO 100 STEP 10
20 LINE (0,I)-(I,100)
30 NEXT
シチュエーションは…あまり好ましくないので省略*1。
まぁ。とりあえず打ち込んだらグラフィックが出るですよ。なんとなく格好いいですよ(おいちゃんのセンス的に)。
で。
STEPの値をちょっといぢると、またその網目の密度が広がったり狭まったりするですよ！！
そんな感じで遊び。ついでに、TALK文ってのがあっていやまぁ動く機種限定なのですが。これが「しゃべる」ですよ！！
その辺をいぢりながら…ようは「元々あるプログラムソースの、微かにわかる部分をいじっては壊し」を繰り返して、プログラムってものへの抵抗感を削減していきました。…いやまぁそも「抵抗感あったんかい？」って突っ込みはおいといて。
…まぁその後も。ゲーセンのパソコンに「よくわからないけどこれを打ち込むとパックマンのなんか動くのが動き出す」とかってのを覚えたので…プログラムの前にタイピングを覚えたようなもんですかねぇ。
ここで多分重要なのは。
「初めての人でもごにょごにょできる程度にシンプルで単純でプログラム量が少ない」事。
いきなりン千行とかあったらめげるでしょ？
その後…中学の時は…ゲームはしてたし、例えば信長の野望ってゲームの初期パラメタを決める部分がBASICだったりしてその辺でちょっと手ぇ出すと全パラメタをすごい値に出来たりとかってちょっとした「値の変更」くらいはやったけど…プログラムそのものは、な〜んもやってなかった気がするです。
ベーマガのプログラムも、そんなに見てなかったしなぁ。
その後、紆余曲折があった…ってほどでもないのですが…工業高校に入り。そこでポケコンをげとって…ってあたりから、割とまじめにBASICを触り始めた気がする。…理由は「ゲームを作るため」ｗ
…うんこの頃にはすでに、何となく、どう書けばいいかわかってたなぁ。
そか。
ものの数行、というプログラムからstartして。何十行何百行っていうプログラムから「とりあえず自分がごにょりたいところ」を探してごにょってる内に、何となく「プログラムという文法」に慣れたんだな。わからないなりに。
…もの凄く怪しい知識なので不安なんだけど。もしかしてこれって「乳幼児が言語を覚える過程」に似ているのではないかしらん？
だとすると…「単純なプログラムとそれをちょろっとごにょるドリル」を山盛りで作って。
それを少しづつステップアップさせていくと、実は一番確実にプログラムが覚えられるのかしらん？
さて…とりあえずこれを投げっぱなしジャーマンｗ
色々なかたからの様々な突っ込みを期待ｗ
人様へのBlog突っ込み２連発ｗ
軽めというかさっくりとなので、まとめまふｗ
いち。
なぎたんのところ。
ソフトウェア品質の12の属性
http://blogs.wankuma.com/nagise/archive/2009/02/03/167335.aspx
おもひろい！！
後で細かくチェック！！
に。
■[記事より] 23:09
http://d.hatena.ne.jp/tonotonotono/20090209/1234188541
経由
従来のソフトウェア工学が決定的に間違っている点
http://d.hatena.ne.jp/kwatch/20090204/1233769288
ソフトウェア開発では、個人の生産性は上と下とで 30 倍違うと言われる。これが本当だと仮定したら、これだけ差がでるものを均一化なんてできるわけない (したところで間違った結論しかでない) んだから、属人性を排除することは大きな誤りである。
仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。
ど真ん中剛速球。
属人性が重要だとすると、ソフトウェア開発が個人に依存することになるのでそれはよくないと考える人がいるかもしれないが、そもそも高度な仕事というのは個人に依存するしかなのだ。なぜなら、個人に依存せずにできるような仕事は高度でないからだ。特にソフトウェア開発では高度でない仕事は自動化しやすいので、自動化できないような高度な仕事しか残りにくい。
これも諾、としか。
ちなみに。
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。
も概ね賛成ですが、だからといって「メイドペアプログラミング*1」という発想はなんていうか色々間違ってると思います(いや昔うちの若いのが散々「やってみてぇ！！」と騒いでいたものでｗ)。
せめて「美人秘書数人に囲まれてプログラミング」で止めておきましょう。
車輪の再発明はしていない。タイヤを開発してるだけだ。
んと。「車輪の再発明をしちゃいけない」ってのは。多分「新しくソースコードを書くな」ではなくて「広く受け入れられ確立した技術や解決法を無視するな」なのではないかなぁ、と、そういうお話し。
つまり、「車輪の再発名」ってのは概ね設計レイヤーとかそのあたりのお話しであって(「思いて学ばざれば殆うし」ともいいますし)。そのあたりはちゃんと学ばないといかんと思うですよ。例えば「アルゴリズム」とか「データの持ち方」とか、そのあたりはおそらく「学んだ」ほうがよっぽど確実。応用やひねりをきかせる可能性はあるにせよ。
でもね。とりあえず実装系が存在しているからって「無考察かつ無思慮にそれを使う」ってのもそれはそれで如何なものかと。タイヤだって色々種類あるでしょ？ …ってググってみたら…うわぁ予想を超えて種類がある(苦笑
「ラジアル(斜め)構造」とか「バイアス(放射状)構造」とかリブとかラグとかリブラグとかブロックとかスペースセイバータイヤとかスリックタイヤとかランフラットタイヤとか…あぁわからんｗ
これらはつまり「用途によって色々と開発をしているもの」。万人受けが存在し得ない以上、最低限「自分の要求に合った実装系」を選ぶか、もし自分の要求を満たす実装系がなければ「作り直す」のは、ある意味当然じゃないかなぁ、と。
それに。そも本当に「車輪が必要なのか適切なのか」もわからないし。「学びて思わざれば罔し」っていうでしょ？ 学ぶのも知るのも大切だけど。その後はきちんと「思」わなきゃ。
無思慮に「全部自分で作る」のはもちろん危険な行為かもしれないのだけれど。同じくらい、無思慮に「他人の提供物を唯々諾々と使う」のもまた、どうかと思うんですがどんなもんですかね？
っつかせめて。他人の作成物使うなら「ちゃんと相応に検証した上で」使いません？ 自分たちが必要な「要求」をちゃんとList Upした上で。
もっとも。「検証した結果使い物にならない事が判明したんだけど自力で開発するにはボリュームが…」とかいう厄介な葛藤を招く結果になっても責任は取れませんが B-p
まずはご挨拶
んと。特に変数に多いのですが。
- 変数の宣言をしていない
- (初期化していない)：言語による：2009/02/10 修正
- (変数の領域を確保していない)：言語による
- 特に配列の、存在チェックをしていない
など、いわゆる「躾がなっていない」プログラムを(特に最近)多々見るので。
で…この手の「本人的にはちょっとした手抜き」が、案外に後々、巨大な面倒を引き起こしたりするので。
かならず、変数を使う時には「ご挨拶」をしましょう。
つまり
- 変数さんこれから使わせていただきますのでよろしくお願いいたします、と挨拶をして(言語的に必要なら領域を確保して)
- 初期値はこちらでございます、とまずはお渡しモノをして
- 特に配列を使う時には「いらっしゃいますか？」と扉を叩いて、いらっしゃる事を確認してから使う
と。
円滑なご近所付き合いにご挨拶が欠かせないように。
プログラム中は、きちんと変数さんにご挨拶を欠かさないようにしましょう。
「510」と言う恐怖
えと。先日窺った某セミナーさんで出ていた話なのですが。
端的に書くと
1人の技術者が頑張って100のコードを書くよりも。
その人は10でいいから、50のコードが書ける人を10人マネジメント出来れば合計で510になる。
会社としてはそちらのほうが有難い
という話。
根本的な部分で山盛りの問題と勘違いを孕んでいるのだけど…一番の問題は、多分この考え方のほうが「普通に社会では通っているだろうなぁ」というあたり。
どこに行っても「質をはかる」のは非常に難しいのですが。
まず
・出来ていない
・出来ているように見せかけて実は偽装しているだけ
・部分的に出来ている
・出来ている
というまず第一のグラデーションがあって…
んで、出来ているの上に
・マシンを移動させるとちょいと面倒
・普通に移動させてもうごく
・新しいプログラムにも使えるような部品化がなされている
・さらなる機能追加が容易
・色々あるので性能をチューニングしたい(より早く/より軽く/より大量のデータを)
なんていう第二のグラデーション＆トッピングがあって…あとどんな感じだろ？
こんな「質のある程度の見える化」ができあがってこないと、なかなか難しいのかなぁとか思ってみたり。
…いやまぁ、少し長い目で見ると一撃だったりするはずなんですがねぇこの辺の質を見るのって。タコいプログラムは、運用後にえらいことになる事が多いですし B-p
ってのを一度腰を据えて書いてみたいのですが…とりあえずmemo。
アバウトに怒るな！ 細かく褒めろ！
えと…そのまんまではあるのですが。
多くの、似非上司、偽管理者は、とりあえず「全体をアバウトに眺めた」上で、理由はともあれ表面的に…例えば「理由の如何を問わず*1、スケジュールが遅延している」「どれだけ割り込んだかの量や頻度については気にせず*2、こっちがやって欲しい事をちゃんとやらない」などの状況で、とりあえず「怒ります*3」。
また大抵の場合。状況を冷静に説明して理解を求めようとすると「言い訳をするな！！」というoptionが高確率でついてきます。
こんな事をやらかす上司の下にまともな部下が寄りつくはずもありません。下につかざるを得なければ、後は「可能な限り関係性を持たないように」努力するだけです。
あまり見ない(いないわけではないのですが…どちらかというと希少種であるような…)、ちゃんとした上司、素晴らしい管理者という存在が、居ます。本当に。居るんですったら。
彼らは、きちんと中も裏も見た上で、細かく褒めてきます。「あぁあれだけ途中で仕変があったのにこれくらいの遅れですんだんだね。頑張ったね」など。
結局のところ。上っ面を表面だけ眺めてしかも「自分の感情をすっきりさせるためだけに怒鳴る」ような状況下は上司としてあまり好ましいとは言えず。
一方で、好ましい上司は「部下の現状もその裏にある問題もなんもかんもきちんと見た」上で、適切に褒めあげるですよ。
…とまぁ上に立つひとがどれくらいこのBlogを読んでるかってのはあるんですが(苦笑
もしあなたが上に立ったら。部下の子を「細かく褒めて」みましょう。そのためには部下をしっかりと観察しなくてはいけませんし、でもしっかり観察するということは、例えそれが褒めるに繋がろうが叱る(not 怒る)に繋がろうが、それはあなたのためにも部下のためにもなるんじゃないかと思うんですね。
まず「識る」事。尤も軽視されがちな、でも最も大切な事です。
