  |
はてなキーワード: 入門書とは
ある炎上プロジェクトの建て直しを通じて嫌と言うほど思い知らされた。
そのプロジェクトの顧客が一番怒っていたのは「一体どういうテストをしてリリースしてるんだ?」という点だった。
プロジェクトの建て直しはやり慣れているのでまずは検査仕様書をレビューして検査項目の強化だな、とか軽く考えていた。
でもプロマネに検査仕様書を見せてくれと言っても整理できてないから待ってくれ、の一点張り。
まずは社内の人間で見るだけだから整理なんていらないよ、と説得しても頑固に出さない。
なんとそいつは検査仕様書なしでテスト(うちの会社の定義ではそんなもんはテストと言わないけど)して顧客にリリースしてた。
顧客は「全く動かない」と怒っていたが僕はいくらそれはないだろ、顧客が話を盛っているんだろうと甘く考えていた。
しかし、プロジェクトの自称テスターに新規に動作環境を作って導入させてみようとしたら見事に出来なかった。。。
なんとその自称テスターはいつも試行錯誤しながらテスト環境を作り、試行錯誤しながら何とか動けばテストOKとしていたと言う。
これでは顧客が動かないと怒り狂うのは当然だった。
もちろん検査仕様書があればさすがにここまでバカな事態にはならない。
検査仕様書は顧客へ納品する契約になっているし、社内規定でも検査仕様書なしなんて通らない。
プロマネを問い詰めると呆れたことに派遣が検査仕様書を作るのはおかしいなんて言い出した。
うちの会社では通常、検査仕様書は派遣テスターが作っていて派遣テスターの契約内容も「検査仕様書の作成」となっている。
念のために炎上プロジェクトの派遣契約書を確認してみたが内容は同じだった。
一体、派遣テスターに契約通りの仕事をさせずに何をやらせていたのか?
なんと「ある一定時間適当に(検査仕様書なしで)システムを触る」ことをテストだと言い張った。
顧客は「そちらのパフォーマンステストの成績だけは満足しているがうちでは動作していない」とも言っていた。
とてつもなく悪い予感がして聞き取りを進めると時間はストップウォッチで計測したと言う。
普通ならテストコードを書く派遣テスターが計測ポイントを埋め込むのになぜストップウォッチ?
この段階でテストコードを書ける派遣テスターがプロジェクトに1人もいないことがわかった。
さらに実装したというプログラマーに確認すると、実装が難しいので後回しにしていると言う。
テスターに頼まれてストップウォッチで計測できるように処理を数万回か繰り返すコードだけ入れたと。
つまりほとんど空の処理を数万回ブン回すだけの意味のないコードの実行時間がパフォーマンステストの成績として顧客に提出されていた。
顧客のところで動かないのは当然だ、実装出来てないんだから。。。
このことを僕の上司に報告すると「そんなマンガのようなことがうちの会社で現実にあるのか、、、」と頭を抱えていた。
会社の信用に直結するのと他にも多くの仕事を出す大口顧客のため上司から役員へ報告することになった。
パフォーマンスが要求される難しい処理の実装ができてないのに、スケジュール上では実装の進捗がほぼ100%になっている。
プロマネを問い詰めると他にも似たような箇所がいくつかあるらしい。
じゃあ、その難しい部分も含めて一体いつ実装が終わるのかわかるようにスケジュールを引き直してくれ、と言ったが彼には出来なかった。
たしかに開発現場はプログラム言語の入門書を読みながら仕事しているプログラマーが多かった。
不審に思って開発体制の資料や過去のプログラマーの契約書を確認するとプロジェクト初期には僕も一緒に仕事をしたことがある超優秀なプログラマーが2人いた。
契約解除の経緯についてプロマネを問い詰めると「仕事の段取りが悪いから契約更新しなかった」と言う。
僕は2人をよく知っていたのですぐに嘘だとわかった。
プロジェクトメンバーに話を聞くと、2人は「今のテストはまずいですよ」とプロマネに提言したらしい。
でもプロマネは頑固に検査仕様書なしでのテストを強行し、再度2人が提言すると「彼らは頑固者だから仕事ができない」などレッテル貼りするようになったという。
そして2人とも契約解除し、入門書を読みながら仕事するレベルのプログラマーだけが残って実装完了のスケジュールすらひけなくなったというわけだ。
社内での対策会議でプロマネはなぜ検査仕様書を作らないのか当然追求された。
僕に言ったのと同様に「派遣が検査仕様書を作るのはおかしい・・・」と言おうものなら、役員が
「だったら誰が作るんだよ!? 派遣が作らないなら社員が作るのか!? 社員に作る時間がないから派遣が作るんだろうが!!」
「検査仕様書を作れないテスターなんてうちにはまったく要らない人材だよ、そんな要らない人材にいくら支払ったかわかってんのか!?」
と大声で反論する。
プロマネが
と言い訳しても
「他所の会社なんて知らねーよ!!うちの会社はうちのルールでやるのが当然だろうが!!」
と火に油を注いだだけだった。
「検査仕様書なしに異論を唱えたプログラマーを契約解除した理由をここで説明してみろ!!」
そんな追求をされているうちにプロマネをまったく明後日の方向の話を始めた。
「これはパ!、(机を叩く)、ワ!、(机を叩く)、ハ!、(机を叩く)、ラ!、(机を叩く)」
そして猛ダッシュで会議室を出ていったが、引き止める者は誰もいなかった。
僕は呆れるのを通り越してこんな人間がうちの会社のプロマネやって会社の信用を失墜させたのか、と思うと情けなくなった。
後日、プロマネは本社に役員からパワハラを受けたと訴えたが相手にされず、懲戒免職となった。
プロマネとしての力量不足でプロジェクトを失敗させたなら懲戒免職なんてありえないが、彼の場合は社内規定にも顧客との契約にも故意に背き頑固に検査仕様書を否定した結果、失敗させたのだから仕方がない。
普通ならプロジェクトの建て直しでは(体調不良などで)プロマネがいないのは困るもんだが彼の場合は特に困ることはなかった。
特に役員の言う通り、検査仕様書を作れないテスターなんてうちの会社では全く必要ない。
テスターを派遣していた会社への説明はあっという間に終わった。
同席した役員が「検査仕様書を作れないなら支払いはできません。契約書の作業内容に検査仕様書作成とあるのにやらなくていいと主張されるなら裁判所を通してください。」と言ったからだ。
派遣会社も彼のように「検査仕様書を作らせない派遣先もあるのですが・・・」と切り出したが「だったらそういう会社とだけ取引すればいいでしょう。うちは検査仕様書すら作れない会社とおつきあいする気はまったくありません。」と返されて終わった。
なぜ彼はプロジェクトをこれだけ大炎上させながら頑固に検査仕様書を否定し続けたのか？
ただ、プロジェクトメンバーから彼がある女性派遣テスターと男女の関係にあったと聞いた。
彼女はテスターといっても検査仕様書が作れないのでプロジェクト内での彼女の存在を正当化するために彼がおかしなことを言い始めたんじゃないかと噂されていた。
と言うのを辞書っぽく書いてもよくわからないと思うので、ここでは「小さな指示をまとめた手続き」ぐらいの説明で十分だと思う。
イメージで言うと、
と言うような感じ。これがプログラムです。
この例で明らかにしたいのが、基本的にプログラムは上から順番に実行される、と言うこと。
大人ならさっきの例でお米が炊けると思う。じゃあ5歳児ができるか、と言うとちょっと説明が足りないと思う。どうかな? 実は子供を育てた経験がないので、5歳児がどれぐらい賢いかわからない...。でも次の例ならいけるんじゃないかな。
どうだろう? できそうじゃない? これは例だから感覚的な感じだけど、実際のプログラムを書くときの指示の細かさはだいたいこれぐらいだと思う。
自分がやりたいことをプログラムに起こすときは、5歳児に教えるぐらいの気持ちでやるといいと思う。本物の5歳児はもっと賢いかもしれないけど...。
暗記力のある5歳児だと、
と言うのを覚えることができると思う。パソコンは5歳児より暗記力があるので、パソコン向けのプログラムなら安心して覚えてもらう前提で書ける。
これで 1 合でも 5 合でも炊けるようになった。釜さえ対応できれば 100 合でもいけるはず。これがプログラミングで変数って呼ばれるやつです。
ここまで、お米をとぐステップは 3 回やればいいってことにしてたけど、2回でいい時もあれば、4回やりたい時もあると思う。箇条書きにしてみよう。
1. ボウルに水を入れて、猫の手で5回かき混ぜる
2. 水を見て、真っ白に濁っていたら 1. に戻る。うっすら濁る程度なら次に進む
ちょっと複雑になった。でもこれでいい感じにお米がとげると思う。プログラミングの解説書を読んでいると「制御構文」ってやつが出てくるんだけど、これです。上から実行するはずのプログラムが、また上の行に戻ったりするのが面白いね。
プログラムの雰囲気をより掴むためにそれっぽく書いてみると、こうです。ふーんって感じで見て。
for {
// KomeWoTogu(ToguKaisuu): コメをとぐ命令。コメを研いだ後にはどれぐらい濁ってるか(0.0 〜 1.0)を教えてくれる。1.0が真っ白。
nigoriGuai := KomeWoTogu(5)
if nigoriGuai < 0.5 {
break
}
}
// 続きの処理...
実は "(1) に戻る"、みたいな意味の命令もだいたいのプログラミング言語にあるんだけど、プログラムが読みにくくなるのであまり使いません。ここではループって言う繰り返し処理に置き換えてます。
気がしませんか? 気がしない人は大丈夫。難しい気がした人にはおすすめのツールがあります。フローチャートっていうの。
https://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88
これは限られた図形を使ってプログラムで解決したい課題を表現するので、課題を理解するのにとても役立ちます。
プログラミングを初めて最初のうちって、「自分がやりたいこと」と「プログラムで表現できること」の間に谷があって苦しくなることがあると思うんだけど、そういうときは落ち着いてフローチャートを書くといいよ。慣れてくるとフローチャートなしでバリバリ書けるようになります。
航空機のようなズボン…ストライクウィッチーズ(JK？)
ロードバイク…ろんぐらいだぁす！(JD)、南鎌倉高校女子自転車部
バイク… ばくおん！
サバゲー …さばげぶっ！、ステラ女学院高等科c3部、サバゲっぱなし(OL)
旧車レストア…ぜっしゃか！
格ゲー…対ありでした。
返信、ブコメより追加
カメラ… カメラはじめてもいいですか？、しかくいシカク、ｍｏｎｏ、たまゆら
ゴルフ… すいんぐ!!
釣り… カワセミさんの釣りごはん、釣りチチ・渚、つれづれダイアリー、浜咲さんなら引いている、スローループ
野球…球詠
エースをねらえ！とかアタックNo.1は入れるべきなんだろうか…
各ジャンルの興味を持つための
大学卒業後4年ほど会社員をやったあと、ウェブ関係のプログラマを目指して1年ほど、バイトしながら独学で勉強しています。
ネット上には詐欺師まがいの情報商材屋とイキリマウントゴリラが跋扈し、普通の人間向けの情報が少なかったので、参考までに書いてみます。
なお、ここ数年のウェブエンジニア転職ブームとは無関係に転職を考えていたので、ブームは正直迷惑だと思っています。
独学にはいくつかの大きな問題点がありますが、もっとも大きいのは「全体のロードマップが存在しない」ことだと思います。
初学者は具体的に何をどの順番で学べばいいのかわかりませんし、この情報はネット上にはありません（冒頭にも書いた通り、そう思ったからこそ、このエントリを書いています）。
などありますが、どちらも普通の人間向けというには若干ゴリラ臭と商材屋臭がします。
また、プログラミング初心者向けの教材はおしなべて貧弱で、腹が立つほど不親切です。読んでいて何度もブチ切れそうになります。
特に初学者の場合は、教材の練習問題ひとつ解くにしても、誤字脱字等の初歩的なエラーのために平気で数時間のロスが発生したりします。
当たり前ですが、これは純粋に時間の無駄なので、すぐに講師に相談して解決したほうがいいです。
こういうことを書くとすぐに「自力で問題解決できない人間はプログラマに向いていない」と言いだすゴリラが現れますが、いまはそういう話はしていません。
そのほか独学だと自分の実力や相場感を測ることもむずかしく、その分詐欺師やゴリラに引っかかりやすくなりますし、基本的におすすめしません。
いまさらC言語と思うかもしれませんが、勉強するうえで重要なことはプログラミングの仕組みを理解することであって、どの言語から始めるかではありません。
その点、上記「苦C」はとても丁寧に文法を説明してくれますし、ポインタの説明を通してメモリの仕組みも教えてくれます。
ただし、回答例のコードに誤字脱字があって動かない等の発狂ポイントがいくつかあるので、注意が必要です。
勉強のやり方としては、まずはサイトを読みながらスマホのC言語アプリでポチポチ書いてみるところから始めると気楽でいいと思います。
途中で頭が混乱してきたら、再度冒頭からきっちり丸暗記するつもりで勉強するのがおすすめです。プログラミングに暗記は不要だと言うゴリラもいますが、あれは嘘です。
intはintegerだからintなんだとか、そういうことを調べながらやるだけでも解像度が格段に向上すると思います。
実際にC言語でバリバリ書けるようになる必要はないので、おおよその仕組みを理解してしまえば、最後のほうは流してしまって大丈夫です。
検索するとこの手のサービスが一番上に出てきますが、内容は不十分だと思います。かゆいところに手が届かず、使っていて非常にいらいらします。
とはいえ他に代替となるものもないので、サービスを利用しつつ、必要に応じて入門書を読むのがおすすめです。
私が利用したかぎりでは、Progateは教材の内容が薄く、Paizaは無意味にオタク臭くて私は苦手でした。N予備校やUdemyの評判がいいみたいですが、使ったことがないのでわかりません。
私はウェブ関係のプログラマ志望なので、ProgateとPiazaでHTML/CSS/JavaScript/Git/Ruby/Ruby on Railsを勉強しました。
最近は初心者Railsエンジニアが供給過多の印象があり、DjangoやLaravelのほうが就職には役立ちそうな気がしています。
余談ですが、無料の教材として有名な「Railsチュートリアル」 https://railstutorial.jp/ は、あえて劣悪な翻訳を放置することで、自社のプログラミング講座に顧客を誘導するビジネスモデルのように見えるので、内容はともかく個人的にはあまりいい印象を持っていません。
ちなみに私はこの辺で迷走していたため、いろんな言語をちょっとずつかじっています。
『スッキリわかるJava入門』はオブジェクト指向を理解するのに役立ちましたし、『退屈なことはPythonにやらせよう』で覚えたスクレイピングは求人情報の収集にとても役立っています。ほかには『プログラムはなぜ動くのか』も読んでためになりました。
基本的に本を読んで損することはないので、時間の許すかぎりたくさん読んだほうがいいと思います。私はあまり読めていません。
Railsチュートリアルを参考にRailsアプリのポートフォリオを作りましたが、完成まで半年くらいかかりました。
上述の劣悪な翻訳のせいもありますが、データベースの設計を考えたり、UIを工夫してみたりすると、いくらでも時間が吸い取られていきます。
知識ゼロから3ヶ月でポートフォリオを作りました！ みたいな若手情報商材屋を見かけると、そんなにすごい能力があるなら普通にエンジニアだけやってればいいのに、と思います。
完成したアプリはDockerでコンテナ化したうえで、GithubActionsで自動テストを走らせ、AWSのサーバーにデプロイしていますが、この辺は言語の勉強やアプリの製作と比べたら全然むずかしくありません。
まともな日本語で書かれたまともな教材が揃っていますし、ネットの記事も豊富にあります。ここまでの勉強で、エラーメッセージや多少わかりづらい文章を読み解く能力も身についているはずです。
それぞれ1、2週間集中すれば最低限の実装はできると思います。ただしAWSの設定だけは、適当にやると数万円の請求書が届いたりするので注意が必要です（届いた）。
上記のポートフォリオを公開し、求人に応募していますが、一向に就職できる気配はありません。
だいたい加藤一二三名人の頃に生まれて、小学生の頃に加藤一二三監修の入門書で将棋を覚えて、60歳くらいまでA級にいたすごい棋士で、ファンだったんだけど。
Twitterも結構おもしろくてフォローして見てたんだけど、藤井聡太がタイトル戦に出るようになってからなんか過激化している気がしてつらくなって外してしまった。
いや元から苛烈な性格だし人間将棋みたいなイベントでも全く空気を読んだりしない人ではあるんだけど、藤井聡太を過剰に持ち上げたり加藤一二三自身を褒めたツイートをエゴサしていいねしたりリツイートしたりリプライしたりし続けてるのを見てるとやっぱ疲労しますね。藤井聡太好きなのでなおさらきつい。
ほとんどのプログラミングスクールの何万円もする教材よりも、市販の数千円の参考書や、公式のチュートリアル（無料）の方がはるかに質が高いです。既にプログラミングができる人の参考書としてだけではなく、初学者の入門書としても、後者の方が適切です。
率直に言って、これだけ良質な情報がどこにいても手に入る時代に、独学でプログラミングを習得できない人は、もう諦めた方がいいと思います。プログラミングなんて別に生きる上で必要なスキルじゃないのですから。包丁持ったことすらない人が、何十万も払って料理習いたいと思うのかって話です。
これが最大の理由です。
まず現実的に、ちゃんとプログラミングができる人は、プログラミングスクールの講師になんかなりません。少なくともこの日記を書いている時点では。
レベルが低いというのは、実務上の話をしているのではなく、本当に素人に毛が生えた程度ということです。彼らのほとんどには、コンピュータサイエンスに関する体系的な知識がありませんし、そもそも基礎的な言語仕様すら把握していません。
これは「文字列を整数に変換する関数の名前がToInt()だったかParseInt()だったか覚えていない」などということではありません。そんなものは調べればいいわけです。彼らはもっと基礎的なこと、たとえば「浮動小数点数には誤差がある」とか、そういうレベルのことを理解していないのです。
だから彼らの「講義」は、間違いだらけであるか、言ってること自体は正しくても著しくピントがずれたものばかりです。昨日今日プログラミングを覚えたばかりの人と大して変わらない知識で、動くコードを自己流に解釈しているだけなのですから、当然そうなります。喩えるなら、中学の英語教師が中学英語の知識しかないようなものです。彼らはその範囲で「プログラミングを覚えるコツ」を編み出しています。
SICP=Structure and Interpretation of Computer Programs（計算機プログラムの構造と解釈）ね。
いや、悪い本じゃないから、読みたい人は読めばいいと思うよ。
ただ、この本を読んだり、薦めたりしている人は、ほとんどこの本の主旨理解してないんじゃないかな。
まず、プログラマやプログラマ志望の人がこの本を読むのは、根本的にズレている（とくに、LispやSchemeを学ぶためにこの本を読む人）。
自動車を運転したい人が自動車のしくみを勉強するようなものだからだ。
もちろん、何度も言うように教材としては優れているから、読みたい人は読めばいい。
あと、これは前提知識が限られた人向けの参考書であって、計算機科学の主流の教科書ではない。
喩えるなら「経済学部生のための高校数学でわかる線形代数」とかそういう類の本であって、計算機科学を専攻する人がわざわざこの本を読むのは遠回り。最初から自分が学びたい分野の専門書を読めばいい。
int a=1;
int x[] = {2, 3};
int b = a[x];
bに格納される値とその理由を答えよ。
（includeとかmainとかは省略）
10年超のプログラマやってるものだけど自分の成長過程を書いてみよう
とりあえず近くのできるだけ大きな本屋に行って、iOSアプリの棚を見てみ。
そして、サンプルプログラムが充実していいて、入門と掲げていて、自分がやっていることに近そうな本を選んで「本の最初から最後までのサンプルプログラムを作ってみ」
それができればある程度iOSアプリの基礎がわかるから、そのうえで次に何を勉強しないとならないかがわかる。その積み重ねだ。
あと、少しプログラムを作ってみたらわからないことが出てくるだろう。その段階で再度本屋に行って今度は索引を見て、自分がわからなかったことを的確に調べられる本を探すんだ。