dotkuwaの日記： もし自分が人にプログラミングを教えるとすると初めに何を言うか 12
もし自分が「順次・反復・分岐」程度は知っている人にプログラミングを
教えるとすると初めに何を言うか考えました。
１．プログラムは仕様書を元に作る。
２．仕様書はいくつもの理由からあいまいである。
それを逃れる術は無い。
３．そんな仕様書を元にどうやってプログラムを作るかと言うと、
プログラミングし易い様に作るのが第一。
し難い様に作っても使い物にならない。
４．かといって、「プログラミングし易い」というのもあいまいで、
その為にフレームワーク（広義）を使う。
フレームワーク（広義）毎に、プログラミングし易さが明示される。
５．ただし、フレームワーク（広義）というのはそれぞれ非常に
癖があり、それを逃れる術は無い。
他人（フレームワークを作った人）の常識を丸のみするの
だから仕方ない。
６．まず、フレームワーク（広義）の癖に慣れてもらい、それと
仕様書とのギャップを埋めるだけの、それに対する理解を
深めてもらいたい。
となると思います。
１．は所与として、
２．は、自然言語の制限が有ったり、仕様書作成時点で見えていない
部分が有ったり、あいまいに言わず、断言してしくじる方が傷が深く
なったりする為です。
（仕様書作成段階で断言すると５０％の確率でしくじります。
【これは個人の感想です】）
日付を比較して抽出しろと言っても、その日付は発生日なのか計上日なのか、
年月日時分秒の内、細かい部分をどこまで無視するかとか、仕様書作成
時点で決めにくい事が沢山あります。
（この辺の事で仕様書の記述に対し、手のひら返しは茶飯事なので注意。）
３．は、プログラミングし難いやり方でやってもスケールせず、
エンタープライズで使うのは、最終的に断念しなければならなくなる
のを防ぐ為に必要です。
４．は、現実問題、何らかのフレームワーク（広義）を使わざるを得ない
と思います。MS AccessVBAだって、ブラウザ上の生のJavascriptだって、
フレームワーク（広義）の一員です。
５．は、本当に困りますが、逃れる術は無いと断言できます。
MS AccessVBAの、Insert Select文の前者と後者のバインドの仕方の
非標準など、熟練した人でも初見では分かりっこない鬼の様な
癖です。
６．ですから使うフレームワーク（広義）の癖に慣れてもらうのは宿命で、
「偏るから嫌だ」という人間には退場してもらうより無いのが
実情です。
偏りたくなければ、必要より多くの数のフレームワーク（広義）を勉強
して下さいとしか言えないです。
うーん (スコア:2)
ちょっと考えてみましたが、そのプログラムで何をするかによるかもしれません。ちょっとお題から外れてしまうかもしれませんが…。
お堅い業務システムであれば、システム目的の実現が第一であることと、保守性に重点を置いた言い回しになるでしょう。個人の趣味や勉強なら、実装の仕方は拙くても良いので、パッションが導くままにとにかく形にすることに重点を置く言い方になるでしょう。
ただ、いずれにせよ使用する言語やフレームワークから少々離れた視点で、そのプログラムでは結局何を実現したいのかや、そのプログラムはどう動くべきかをコーディング前にしっかり把握して理解するように、とは言うと思います。
実現しなければならないこと・やりたいことが先にあって、特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかないことはしっかりと意識させたいです。問題にぶつかった時に、自分が使っているプログラミング言語・フレームワークの範囲内でしか解決策を考えられないと、たこつぼ的なはまり方をするようになってしまうかもしれませんし。
Re:うーん (スコア:1)
どーも！
この前、職歴30年にして初めてトレーナーをやれと言われて、思いついたことを書きました。
＞特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかない
ですが、手段の対義語たる目的を起点とした開発手法はどれもはかばかしくない様に
思えてならないのです。シーズの無い所に芽を出そうとさすのが土台無理に見えて
なりません。目的だー言っている人間は無能を糊塗しているだけにも見えます。
なにか、自然現象に準ずる論理の限界が有るのかも知れないと疑っています。
ですので、自分が初めてゆうことは、「手段」を起点とする事になります。
もちろん「目的」は見据えないといけないですが、そんな意図です。
Re:うーん (スコア:1)
プログラミング論理世界は超スパースなのではないか？ という事です。
Re:うーん (スコア:1)
私も最近プログラミング初心者への社内講義をするようになったので、このお題にあるようなことは考えるようになりました。私としてはやはり目的重視です。まあ、お互いの立ち位置というか信念というか、その辺りは当然異なりますので、SIer出身で今もシステム構築・運用保守を生業とする私としては、そう考えるということです。
目的と言ってもレベルの高低はあります。情報システムの構築を例に取れば、高いレベルではシステムで達成すべき業務改善なり新しいビジネスの成功ですし、低い(というのは少々語弊がありますが)レベルでは特定モジュールで実装すべき機能のシステム全体での位置付け、およびそのモジュールはどう動くべきか…ということが目的となります。
情報システム構築の現場において、プログラマーに具体的指示を出す立場の人間が、この高いレベルの目的だけメンバーへ語るのであれば、私としてもその人は何か勘違いをしていると言わざるを得ません。
実装レベルにおいては、そのモジュールが存在する目的(何をするものなのか)をプログラマーが強く意識できていないと、様々な弊害が出てきます。例えばそもそもの設計に誤りがあることに実装者が気付かず実装を続けると、後工程へ重大な影響を残します。設計者は100%完璧な仕様を出すことはできませんので、後工程の誰かがなるべく早く気付いてフィードバックしなければなりません。
私見ですが、プログラミングとはコードを書いて要件・設計を具現化する過程を経ることで、要件・設計・実装をスパイラル的に改善していくものだと思っています。ですので、私はプログラマーには自分がしていることの目的を高いレベルでも低いレベルでも正しく理解してもらって、全体としての成果物の品質を向上させることに貢献してもらいたいのです。
…こんなことをプログラマー志望者に伝えたいのですが、なかなか大変ですね。
Re:うーん (スコア:1)
SIerこそ、手段・プログラミング擁護のチャンピオンの様に思うのですが、
逆なのでしょうか？
（そしてSEは低レベル手段・プログラミング擁護のチャンピオン）
そして、Antiプログラミングの多い日本だからこそ、擁護者が必要で
SIer・SEは根深く、なかなかに無くならないのだと思うのですが。
中の人が逆に言っているがゆえにプログラマー志望者に伝わらないのでは
無いでしょうか？
作ってみないと（手段）何をするものなのか（目的）語れないがゆえに、
プログラミングの場合は手段は目的に先行するという主張です。
SIerの方は、散々手段を作りためて「目的」だーと言っているだけ
に思えてならないのです。
間違っていますかね？
Re:うーん (スコア:1)
結論から言うと間違いです。正確に言うならば、SIer/SEと荒く話をされても正直言って困ってしまうのです。その人の置かれている状況によりますので。だから私は「立ち位置や信念は異なるが」と最初に書きました。以下も、かつてのSIerとしての立場で書きます。
SIerがSEに提示するシステム構築の手段には様々なものがあり、SEの視点からは「こんなもの使っていられるか」というのもあります。実際、私もSIerとしての制約の中で、システム構築の最前線で実際に設計・コーディング・テストをする立場でもありましたから、そういうことは良く分かりますし、SEの皆さんへは申し訳なく感じてもいました。
それでも、私が長年携わってきたシステム構築・運用保守において、手段が目的に先行してはならないというのが「私の」信念です。エンドユーザーがシステムに期待する目的が達成できなければ、技術的・審美的に優れたいかなる手段を用いたとしても失敗PJであり、「SIerとしては」ここは譲れません。
私の認識では、誤解を恐れず言ってしまえばプログラミングはシステムの目的を実現するための一手段・一工程でしかなく、その工程に参加するSE(≒プログラマー)にはシステムの目的をまず理解してもらわなければなりません。その理解がなければ、自分が担当する機能がなぜあるのか、どう動くべきなのかが本質的に理解できないままとなり、悪く言えば「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」となります。
ですが、システム構築に参加していただく上では、それでは困るのです。SEにはプログラミングのスペシャリストとしてのアウトプットを当然求めますが、それは直接的なアウトプットであるコードそのものだけではなく、私が前のコメントで記述した視点も当然含まれるのです。
だから、私は相手がプログラマー志望者であっても、常に目的を忘れず、目的からずれることなくSEとしての自分のミッションを果たしてもらうべく、最初に高いレベル・低いレベルの両視点での目的の大切さを伝えたいのです。スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」思っています。
Re:うーん (スコア:1)
＞スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、
＞さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」
＞思っています。
本当にSIerはこう思っているのでしょうか？ プログラミングはそれほど豊潤な世界だ
とは思えません。出来る事が非常に限られているのです。
＞「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」
この様な事にならない為には、出来ない事（シーズの無い事）は受けるべきでは有りません。
＞システムの目的をまず理解してもらわなければなりません。
だから目的を理解したら実現できるのかと言えば、その様な事は有り得ません。
目的はいくらでも膨らませる事が可能でしょうけれど、それとプログラミングとは
無関係です。
その様に「自分は」思い、それに即した「初めに言う事」を考えました。
もちろん顧客の思いつくすべての目的を実現できる手段が有るというのなら最高ですが、
無いと「自分は」思います。
Re:うーん (スコア:1)
もっとも自分も55歳とかになって、
「将来性が無いからもうやらなくていい」となったから
手段だ手段だ言える立場になっただけで、
SIerの中の人は目的で韜晦しないとすぐ潰されるのかも
しれないですよね？
＃自分の様な2次受け3次受けの所でもそうだったのですから
＃お察しはしますが。。。
でもそれではプログラマー志望者には伝わらないと思います！！！！！
Re:うーん (スコア:1)
天動説の離心円よろしく、説明に説明を加えなければならないのは、
第一原理で無い証拠だと思います。
（実用に足るV字モデルが「離心円」を幾つ書いているかご存知ですよね？）
Re: (スコア:0)
（もう時効だと思いますが）昔、SIerの所に行って仕事をした時は、
カンバンをリアルタイムで更新する方、その前で検討する方、
別室でプログラムを検証する方、たばこの部屋にいる方、
廊下にいる方とかさまざまでした。
SIerとひとくくりにも出来ないとは思います。
私なら、 (スコア:2)
とりあえずテトリスを作ってみろと言います（笑）
まぁ、「順次・反復・分岐」程度は知っている人なら、次はアルゴリズムではないかと。
Re:私なら、 (スコア:1)
もちろん１で（元記事で）書いたのも「自分が」です。