山本ゆうごブログ

山本ゆうごの仕事メモ

Web系のツヨミとツラミ

別のブログで、SIerのツヨミとツラミを書いた。 SIerのツラミとツヨミ - 山本ゆうごブログ

ここではWeb系エンジニアのツヨミとツラミを書く。

「SIerからWeb系への転職」というようなワードをみる。まるで良いことのように語られる。

定義は曖昧だがWeb系とはこういう業態のことを指していると思う。

  • 開発したシステムを納品するのではなく、自社でそのシステムを運用する
  • システムはWebサイトが多く、使用料とか広告モデルとか稼ぐ
  • サービス育成にあわせて常にシステムはブラッシュアップする

Web系のツヨミ

合理的につくれる

SIerのツラミは、変な仕様でも仕様に従って作らねばならないというのがある。ところがWeb系は自社でのビジネスはきまっているが、作り方は「最も合理的な方法」をとるしかないので、クラウドを使った仕組みなど合理性優先で構築できる。

開発効率という観点でも合理的に作ることができる。テストも自動化しちゃえる。

自分で事業を作ってる感がある

ソーシャルゲームをつくるエンジニアは、まさにゲームビジネスの中の人だ。自分がリリースしたガチャがどれくらい稼いでいるかを肌感覚で掴める。

システムの育成に立ち会える

受託で作ると構築した人と保守する人は別れることが多い。しかしWeb系は自社ですぐそこで動き続けるので、構築メンバーと育成メンバーはあまり変わらない。

(場合によっては) 会社の価値の向上が自分の資産になる

もはやエンジニアとしてではなく、「株主として」という話になるが、自分でコードを書いて自分でサービスも運営して会社の株も持ってるというのが最強。Web系ベンチャーではそれがある。給与とかそういう待遇とか超越したリターンが得られる。

Web 系のツラミ

実は新規サービスをどんどん作れるわけではない

イケてるWeb系事業ほど「長いこと古い仕組みを育て続ける」必要がある。Yahoo!はずっとYahoo!だし、zozotown はずっとzozotownだ。ゼロから作る機会などほとんどない。「サービス名考えると同時にドメインのアキも探さないとなぁ」なんてことが ほとんどない。

Web系だから新規のサービスを作れるかというとそうではなく、やっぱり「金を稼いでいるサービスの育成」に当たる方が合理的だ。

本当に新しいことを覚え続けないと死ぬ

iOSやAndroidの新しい作りを知っておかないとサービスのアップデートさえできない。どんどんOSのバージョンも変わる。つらい。

待遇がよいわけではない

SIerは「お金を持ってるけど技術がない会社に技術を売る」という商売だが、Web系の場合は技術があるのは当たり前で、その上でサービスが金を稼いで初めて組織に金が入ってくる。これは結構ドキドキもので、この世には金を稼がないWebサービスが山程ある。ここ数年のAppStoreのランキングを見れば分かる。LINE、ツムツム、グラブル、FGO、モンスト、パズドラ、この辺が全然落ちない。しかし、めちゃくちゃスマホ向けにはアプリはリリースされてるの。でも誰の目にも止まらず、消えていってるの。めちゃくちゃ技術的にはすごい人が作っていても、ランキングに入らないの。その場合は会社ごと消える。

反対にSIerに目を向けてみると、あのマイナンバーの仕組みでも100億を超える入札単価だ。 tech.nikkeibp.co.jp

SIerがしぶしぶやって100億。それをアプリで作るのはかなり厳しい。ただスマホゲームで当てると年間1000億くらい売り上げるからそれくらいの夢があるとも言える。ただほんの一部だ。

割とあっさり追い越される

SIerだと存在した経験値の差によるマウンティングが通用しない。この道10年のSwiftエンジニアは居ない。この道5年のVueエンジニアは居ない。定期的にゲームがリセットされるので、アドバンテージがすぐに消える。勢いのある若手と張り合い続けるのがまぁ大変。特にフロントエンドは移り変わりが激しい。

SIerのツラミとツヨミ

Web上のエンジニアの愚痴をみていると、SIerに対する嫌悪感が多い。かくいう私もSIerの硬直化した組織はやりづらいとは思ってる。

一口にSIerと言ってるが、定義としては以下のように絞られるだろう。

  • 自社サービスを持つのではなく、クライアント企業の依頼を受けて動く
  • 割と大規模(だからこそクライアント企業の中の人間ではできない)
  • ビジネスモデルとしては受託(業務委託契約)
  • 納品ベースでお金が動くので、仕様書が契約書に近い効力を持つ

以上の切り口そのものに、何ら問題はない。

SIerと対比される業態に「Web系」とか「自社サービス」などという表現もある。

Web系も定義がはっきりしないが、整理をすると、Web系とはこういうことだろう。

  • 開発費をもらうのではなく完成したシステム自体が稼ぐ
  • 広告費や月額使用料で稼ぐモデルなので、インターネットビジネスが比較的多い
  • 自社で要件定義をするので、常に仕様はアップデートされていく

Web系のツラミとツヨミは別のところで解説するとして、ここではSIerに絞って説明する。

まずツラミ

硬めのクライアントが多い

SIerにとって太い客といのが、官公庁や銀行などだ。多くのSIerが銀行の子会社からスタートしている。だからどうしてもクライアントのカルチャーに引っ張られる。金融系のSIを担当するということは、ソフトウェアビジネスではなく金融ビジネスをしているのに近い。だからスーツだ。自社の新人研修でSIerがやってるプログラミング研修にやると、「机の上にペットボトルがあると叱られた」と帰ってきた。そういう研修をお願いした覚えはないのだが、1文化とも思わず、社会人エンジニアとしての常識ということなんだろう。

硬いこと自体は悪くないのだが、何かとマナーにうるさい。さらに根回しの世界。太鼓持ちを仕事にしたくなくて技術者になったのに、なんでご機嫌を伺うことが最優先になるんだろうという矛盾。

仕様書の通りに作ることが仕事

仕様書どおりに作って納品するというのがビジネスなので、仕様書にかかれていることがどんなに使いづらくともその通りに作らないといけない。逆に仕様書に書かれてないことは作っちゃいけない。そして厄介なのは、その仕様書を作ってるのが、「UIの専門家でもなければコンピュータの専門家でもない人」が作っているというのが辛いポイント。だいたい間違ってる。間違ってる仕様書の通りに作らないといけない。

そしてどんなにクレームが来ても仕様書の通りなら「それは仕様です」と言って突っぱねるのが大事な仕事になる。

技術に疎いクライアントが相手

クライアントが技術に疎いからこそ、外注をしている。先の仕様書の間違いも指摘するのは苦労をする。レクチャーにかかるコストはお金にならない。

新しい技術は使えない(使っちゃいけない)

メーンフレームCOBOLという組み合わせはまだまだ多い。せっかくだから新しい技術も使いたいかもしれないが、年金のシステムは向こう50年は動いてもらわないといけない。毎年変わるアーキテクチャは使えない。

本当に新しい技術が使われているなら、銀行の口座番号なんて、664289d2-dc45-44b8-8b00-c5a20d789e50 となっていてもいいはずだ。ところが、2019年時点の三菱銀行では三和銀行の口座番号とIDとパスワードがそのまま使える。これは技術では解決しない。

ツヨミ

逆にいえば、上記のツラミがあったにせよ、ビジネスとして成功しているからこそ存在しているのがSIerだ。しっかり稼げてうらやましけしからん。

待遇がいい

自社サービスだと自社のサービスの売上が分母となって、従業員に賃金が支払われる。儲かってないWebサイトのエンジニアの給与はそれなりだ。ところがSIerだと客が太いから会社そのものもまぁまぁ潤ってる。そこでのエンジニアの給与も高い。

ホワイト

仕様書の通りに作るというのは一見ホスピタリティは悪いが、仕様変更にいちいち付き合ったのではいくら時間があっても足りない。仕様書通りに作るというのは自分たちを守るための手段でもある。また、SIerからも下請けにながす。本当に労働環境としても辛いのは、二次受け三次受けだ。

業務には強い(これが一番言いたいこと)

例えば、会社のビジネスが変わって、会計システムを入れ替えたいという話がある。クライアント企業の担当は会計システムを入れ替えた経験など、ほぼない。ところが、SIer側はそんなことばっかりやってる。だから会計システムの入れ替えの時の「あるある」がめちゃくちゃ溜まってる。他の会社の事例をしっている。守秘義務があるにせよ、競合他社含めてのバックオフィスの知識と経験は、喉から手が出るほど欲しい。クライアント企業も仕様書をいきなり作るのではなく、RFPという形で、「SIerからの提案募集」をすることもある。

逆にここが強すぎて、入札には手を上げないというケースも発生する。マイナンバーのシステムとかは、入札段階で「あー、これやんない方がいいやつだわー」とSIer個別には手をあげなかった。実際にはSIerの合同で仕方なく国に付き合うという形で落ち着いたが、実際にリリースされたものをみると、確かに国がやりたいことと手段がミスマッチだ。SIerの人たち賢いね。

この「業務に強い」は、SIerの中では常識で、PG→SE→PMという形で出世するというコースが描かれている。「出世したらコーディングできなくなっちゃうよ」という恨み節も聞こえてくるが、SEの市場価値なめんなよと。「ECの倉庫のシステムを構築したことあります。」というのは、「Railsでサクサクサイト作れます」とは別次元の価値がある。

欲を言えば、「業務に強い」のその業務によって当たり外れがあるということ。先に挙げた「ECの倉庫システム」はとても今求められている。「店舗のポイントカードの仕組みとECの在庫の仕組みの両方経験あります」だとさらに価値が高まる。

この業務に強いというのは「複数の会社の類似業務を見ていている」ということもある。これは社内エンジニアにはできない経験だ。不満をもっても何と比較して駄目なのか良いのかが分からない。

ベンチャーも習うべきところは多い

SIerにエンジニアがたくさんいるというのは、それなりのビジネス的な理由がある。とにかく金が動かないと話が始まらない。そして「人を便利にするシステム」を作るには、業務の事例をたくさん知ってるということが、市場価値を生む。

ベンチャーであっても「便利」という価値を生むなら、受託じみた形からサービスや新機能をスタートして「この領域ならクライアントより業務の知識が多いですよ」という領域ができると強い。

ITエンジニアのための謝罪メソッド

システムというのは基本的にはトラブルもの。正確には動いている時にはありがたみがなくて、トラブった時だけ注目を浴びるもの。

やれアジャイルだ、ウォーターフォールだと、開発手法に関してはいろいろ話題にはなるが、謝罪方法を語る人があまりいない。

だが謝罪にはメソッドがある。

経緯書の書き方

謝罪の経緯書はだいたいこういうフォーマット。

  • トラブルの概要
  • 時系列
  • サービスに対する影響範囲
  • 直近の対応
  • 原因
  • 根本対応
  • 組織としての対応

こんな感じ。そんなもん最初からやっておけというお叱りもあるのを承知。がんばりますという対応は駄目なんだけど、がんばりますというのがないというのも良くない。

謝罪のゴールはこちらがペースを握るということ

一番つらいのは、こちらの今後のタスクを先方に切られるというのが一番つらい。経緯書の「今後の対策」は、あくまで自分達が実行可能なタスクにすべき。やりたくないけどやるというのは良くなくて、「これあった方が絶対楽だよなぁ」と自分達でも思える対策が必要。システムトラブルに対する検知ツールのチューニングとかはあった方がいい。

時系列での報告の意味

時系列でのトラブル報告は、「どうやってトラブルが発覚したのか?」「それを伝達するルートはどうなのか?」「対応できる人までたどりついたのか?」をあとで振り返るのに有効。

発覚が自社というのが一番いいが、先方からの指摘で発覚するケースもある。その場合は窓口が動き始めるまでの初動が早いとまぁいい。実際に想定外のことが起こった場合には、回復までに時間がかかるのは仕方ない。ポイントは着手までの時間がどうかということ。

サービスに対する影響範囲

サービスダウンしてましたという場合には、その影響を数で出す。私達はサービスの重要性を分かっていますという姿勢が大事。

直近の対応

その場しのぎでサービスが継続するならいい。新しいシステムのリリースでトラブった場合には旧バージョンに切り戻しというのもありえる。原因不明でサーバが高負荷の場合にはサーバー再起動で収まるかもしれない。理想的なシステム構成は後回しでも、泥臭くともサービスを継続しようとしておりますというのは、ビジネスシーンでは大事。

原因

ここに、バグの原因と、そのバグが見つからずにリリースされた経緯などを記入する。どっかのモジュールがバージョンアップしてその影響でこんなンなっちゃいましたとか。

根本対応

システムのトラブルはシステムの改修で対応する。ログが溢れましたとかお粗末なトラブルならログローテートしますとか、ログサーバーに転送しますとかそういう改修。当然ないよりは合ったほうがいい。

あと、根本対応で駄目なのは、運用ミスでダブルでチェックしますとかレビューを徹底しますとかそういうやつ。ありがちなんだど、システムのトラブルでシステムで解消しないというのは、コンピューターリテラシーなさすぎる。

さらにもう一声

対応にもう一声あるとしたら、「類似トラブルの調査」という観点。こういうミスをやらかすんだから、類似のミスをしでかしていていもおかしくないだろうということ。システム改善のためのタスクをむこう数週間くらいギチギチに入れておく。トラブルが起こる前よりもよりスマートなシステムにする。志を高くもつ。

目的別プログラミング言語

プログラマー初心者が疑問に思う「どのプログラミング言語をやればいいの?」という質問。プログラミング言語の文法などはそんなに違いがないのでどうやって選んだらいいかが分かりづらい。言語仕様意外で決める要素があってそれに引っ張られるころが多いということがあまり知られてない。

動作環境で決まる

  • Excelを自動化したければ、Excel上で動くVBA
  • ブラウザ上で動かしたれば、JavaScript
  • メーンフレーム上で動かしたければ、COBOL
  • LambdaやFirebaseのようなサーバーレスアーキテクチャなら、JavaScript(Node.js)
  • Unityで開発したければC#
  • Windows上の.netフレームワーク上で動かしたければ、C#
  • iOS上で開発したければ、Objective-CかSwift
  • Apacheモジュールとして動いてほしければ、PHP
  • 大規模なマシンの性能をフルに使いたかったらJava

動作する環境で決まるということが多い。

利用できるライブラリ・フレームワークの差で決まる

  • scikit-learn という統計・機械学習ライブラリを使いたかったら、Python
  • numpy などの行列計算を簡易にしたければ、Python
  • RailsなどのWeb+DB系のライブラリを使いたければ、Ruby
  • 標準モジュールだけでWeb開発をしたければPHP
  • スマホ向けの3Dエンジンのライブラリをつかいたければ、Unity(C#)

利用できるライブラリ、フレームワーク(雛形みたいなもの)というのは、言語仕様そのものではなく、そのプログラミング言語をより便利にするために、プログラマー達が「育てた」とも言える。プログラミング言語そのものは、用途を絞ることはあまりないが、ライブラリやフレームワークは特定の用途にフォーカスした形で育成される。PythonもRubyも同じことはできるだろうが、機械学習用のライブラリの充実と、Webサイト向けのライブラリの差は歴然としている。

当然のことながら、RailsというRubyで作られたフレームワークも所詮はひな形なので、別のプログラミング言語でもできる。PHPはもともと言語仕様からWeb開発向きではあったが、Railsほどの雛形にはなってないので、PHPにもフレームワークで開発すれば「Apacheプロセスの中で動くから軽くて開発生産性も高い」という美味しいとこ取りをするケースもある。

swiftでも頑張れば、スマホ向けのアプリは作れるが、大半のスマホゲームメーカーはUnityを使って開発をしている。ゲーム向けのライブラリが充実しているからである。反対に生活ツールではUnityはあまり使われない。

Progateは素晴らしい。だが他にもやることがある。

こちらのエントリ読んで思うところを書いています。

「progateをどれだけやったら仕事ができるの?」に採用について考えてる側から答えたい – fukaminmin – Medium

自社でもエンジニア採用をしているのですが、Progateやプログラミングスクールを経て、プログラマーになろうとしている人は多くいます。

プログラマーになろうとしている人の背中を押してあげるという点では、これらの初心者向けのサービスは本当に素晴らしい。ところがいくつか困ったケースができはじめています。

Progeteのみを永遠と続けていて、エディタを触ったことがない

自社の採用は「未経験OK」とはしているのですが、プログラミング勉強中の人にはFizzBuzz(のような超シンプルなソース)はその場で書いてもらっています。メールで出題をして、結果をメールで返信してもらいます。

  • Progeteでしか書いてないので、エディタは持ってないのですがいいですか?
  • Progateの問題にないコードは書いたことがないので、実行せずに書いたまま出します

あとは、Progateの中でしか実行してないので、ターミナルそのものを触ってないという人もいます。カレントディレクトリの概念がないとか。

ターミナル、コマンドプロンプト、CLI、シェル いろいろいい方はありますが、「黒い画面」で「ファイルをいっぱい繋げていく」というのが、プログラミングの基本です。プログラミング「言語」に引っ張られすぎて、まるで語学習得のようになってないでしょうか。

Progateは料理教室みたいなもの

料理教室はこの世に必要なものですが、料理教室で「しか」料理をしてないというのはよくない。料理教室だと以下の訓練ができません。

  • 食材を買ってくる訓練
  • 食材を貯蔵する訓練
  • 調味料をそろえる訓練
  • 献立を考える訓練
  • 味見をして、レシピを改善していく訓練
  • 同じレシピを繰り返し安定して作る訓練

単に料理本をみて、そこから食材を買いに行くというだけでも十分カバーできることはあります。

そんなわけでProgeteの外で頑張らなくちゃいけないこと

Progateは初心者にプログラミング言語を網羅的に教えてくれるのだけれど、それだけだと足りない。

タッチタイピングの練習をしよう(まさかのここから)

今はスマホネイティブの人も多いので、PCで高速チャットをする機会がない。だからタッチタイピングができないまま、Progateをやりつづけていたり、合宿系のプログラミングスクールに行ったりする。タイピングスピードが遅いというしんどさだけではなく、画面をみながらタイピングができないということは、Googleの第二キーワードもエディタのコードアシスト機能も使えないということ。キーボード見ちゃダメ。絶対。TwitterもPCでやりましょう。Twitterはキーボードのみでほとんどの操作ができます。

新規のファイルからソースを書こう

ファイル名をつけるところからスタート。Proagateみたいに予めファイルが用意されていて、そこを修正するだけなので、ほとんどエラーがでない。実際にはタイピングしているとたくさんのスペルミスがある。requireで指定しているファイル名と、実際のファイル名が違うことなんてベテランでもしょっちゅうある。私はよく「俺たちはファイル製造マシーンだ」といい切ってる。新しいファイルを適切なディレクトリに作るという訓練をたくさんしよう。

読む能力を身に着けよう

どのプログラミング言語も、本屋にいけばテキストがある。テキストだからそれそのものは面白くもなんともない。だけどいずれは、テキストだけで勉強しなくちゃいけなくなるときは来る。プログラミングの楽しさって、「できあがったプログラムが便利だった」というところなので、正直勉強は苦しくても別にいい。そして殆どのドキュメントには公式ドキュメントがある。公式ドキュメントは最初はとっつきにくいだろうけど、読めるようになろう。

読解力というのは人それぞれかなりの差がある。「読むと頭に入らないが質問のキャッチボールでは頭に入る」という人もいる。だけどプログラミングというのは、どこまで行っても読み書きの世界。読み書きの得意な先輩方が作られた業界だから、覆しようがない。適切に質問をする能力が身についているのなら、人間相手ではなく、Googleに聞けばほとんどの答えが載っている。

ググり方を身に着けよう

タッチタイピングができるようになったら、Googleで検索して適切なサイトか適切な情報を引っ張り出す訓練です。Progateは中のテキストが充実しているので、困ったときにスライドにジャンプできます。しかし実際のプログラミングではそのスライドを探し出すところからやらなくてはなりません。適切なワードでググりましょう。ググったら上から順に「これは欲しい情報なのかどうか?」「まともな人が書いてそうか?」などの重み付けをしながら参照します。公式ドキュメントやstackoverflow(英語版)の評価の高い解答などは大事ですね。

エラーメッセージの「ちょうどいい部分」をググるというのも大事です。

環境構築が大変なら環境構築が楽な言語から手を付けよう

Webプログラミングといえば、Railsという相場観があるかもしれないが、残念ながらWindowsだとrbenvの段階で辛い。Railsまでいかなくても、単体のRubyなら十分手元で勉強はできる。またWebで公開して他人に触ってもらいながら学習を進めるのも効果的。そうなると、フォルダコピーだけで本番反映が可能なPHPの方が学習からフィードバックまでのサイクルは早い。ロリポップのようなレンタルサーバーでもすぐ動かせる。

仕事でエクセルをよく使うのなら、エクセルVBAから始めたって構わない。繰り返しや分岐などは全く変わらない。VBAのエディタはIDEとしても完成度が高い。本当にプログラミング初心者ならVBAから初めて、Web系言語にシフトしても全然遠回りじゃない。

手元に自分のサンプルソースをたくさん作ろう

どんなリファレンスよりも、自分で書いたコードが一番あとで参照しやすい。だからできるだけ自分の手元においておこう。絶対あとで見る。Progateを一通りやったら、全く同じ課題を、自分の手元のPC上で書いて、手元のPC上で実行するというのもいい。絶対別の苦労がでてくる。だけどその苦労は仕事でエンジニアになった時には乗り越えなくちゃいけない苦労。

手元でたくさんのサンプルファイルを置くのは、「うまいこと動いているバージョン」「動かないバージョン」と複数バージョンを置いて比較をしながら学んでいくことができます。プログラミングの最初は、「Hello World」と出力するだけのプログラムですが、「いろんな文字列を日付としてパースするサンプル」のようなサンプルソースはベテランになってからも手元でちょこっと作ります。小さくても「手元で動いたプログラム」がリファレンスとしては最高です。

自分ひとりが便利なものから始めよう

プログラミング初心者が作りたいものというと、Railsで作った何かしらのコミュニティサイトを上げる人が多いです。ところがコミュニティサイトはプログラミングだけではなく、Webサーバーのセットアップや管理から、掲示板が荒れした時(もしくは誰も来ない時)のコミュニティ運営まで幅広いスキルが必要になる。PDCAサイクルが一周する時間が長すぎます。

手始めにおすすめなのは、自分がよく見るサイトのスクレイピングツール。定期的にWebサイトを巡回して、欲しい情報があれば、そのサマリーを自分あてにメールで送ったりするツール。このレベルなら、Rubyでクラスなんて作らなくてもできちゃう。継承だオーバーライドだインスタンス変数だとか知らなくても、誰かの生活を便利にすることはできる。自分でやり始めて「あれ、修正すると既存機能が壊れやすいなぁ」とか「部分的なテストがしにくいなぁ」みたいな課題感を持ってから、クラスを覚えたって構わない。まずはプログラミングによって人が幸せになるのだというところは実感したほうがいい。

その点では、エクセルVBAは職場の人が即幸せになる可能性があるので、入り口としては馬鹿にできない。

環境構築もいずれはチャレンジしよう

「環境構築だけがクリアできない課題」という言い訳はあるものの、「エラーメッセージが出る→ググる→ちょっと直してみる→前回と比較してみる」というステップはエンジニアの仕事そのものです。「適切な情報源から適切な文書を取り出して読む訓練」ができれば、環境構築もできます。

オススメのプログラミング学習方法

こちらの記事に感化されて書いてみる。

www.vivi-life.com

「個人差」がかならずあるだろうとは思っているし、「成長過程」に関しては「自分」をサンプルとしている以上は、どうしてもサンプルが少なすぎる。私個人の話と、実際にたくさんのプログラマー向けの研修をしていたときの肌感覚を元に書きたい。

一つ一つ解きほぐしたい。

「一番最初の苦痛から逃げ出さなければよかった」 → 苦痛な時点でしんどくないか

私が一番最初に作ったプログラムは「アクティブなウィンドウに下矢印キーを一秒おきにSendKeyするツール」だった。理由は自分が欲しかったから。ご飯食べながら長い文章を読みたい。コードそのものは10行程度でいいが、勉強にはそこそこの時間がかかった。でも達成感ありまくりだった。自分でも長いこと使っていた。

プログラミングとは料理のようなものなので、自分が食べて美味しいかどうかで上達したかどうかが分かる。試食なしにただひたすらレシピを丸暗記するだけなら、料理はとても苦痛だろう。

その点では、会員制Webサイトというのは、たくさんの人に使ってもらうもの。料理で言えば「レストランを経営してみましょう」に近い。まずは自分一人が使って、楽しい/便利 なものを作るのが入り口としては正しい。

「周りがコードをかけて当たり前の環境に行けばよかった」 → でもその人達も一人でやってること多い

先輩も結構独学でやりきっている。聞けば分かるかもしれないが、先輩方は聞かずに答えにたどり着いていることが多い。もちろん聞けば早いが、聞ける環境にないからといって、あまりハンデだと思わないでいい。うちの研修でも、基本は自分でググる力をつけることを主眼に置いている。「調べ方が分からない」のであれば、調べた方を聞いた方がいいとは思う。

「周りに質問に答えてくれる人をそばにおく」 → なくても構わない

逆に聞かないと進めないとなると、なぜ一人で進めれないかを考えたほうが良い。イマドキは掲示板で聞けるし、ちょっと検索してみると似た質問を投げている人もいる。質問を文章にする能力があれば、検索はできるはず。検索ができないとなると適切な質問もできないと思う。

「プログラミングの勉強の要は、読書によることも多い」 → 月間20万円も買わなくても良い

月間20万というと、2000円の本が100冊なので、読めないのではないか。勉強の順番をつけて順に買っていけばいいと思う。私が初心者の頃に買ったのは、CとPerlの言語の教科書あとSQLの教科書。それ以降に覚えた言語はWebのリファレンスのみで分かるようになった。

「アウトプットをどんどんすればよかった」 → これは絶対にそう

アウトプットはひたすら繰り返す方がいい。だからアウトプットの単位が「会員サービス」だと大ぶりがすぎる。「ちょっと便利なコマンドラインツール」くらいを連発するのがいい。

「コードリーディングをもっとすればよかった 」 → 目的がないと読めない

漠然と読んでも仕方ない。コードリーディングのキモは、「自分がやりたいことのパクリ元を探す」ということだと思う。やりたいことが強くないと読む気も起きないのではないか。

「最初から大きな理想を描き続けない」 → 絶対にそう

今日一日で完成するものを作るというのが理想。下ごしらえはしていいけど、今夜食べるまかない飯も必要。

「最初のプログラミング言語でRubyを選択してよかった」 → Rubyなの?Railsなの?

プログラミング初心者がパニクってるのが、自分がやってるのがRubyなのかRailsなのかが混乱しているというところ。セットでやろうとするからしんどい。

学生さんでサクッとWebサービスを公開しているのをみると、PHPで無料のレンタルサーバーで公開している。覚えることが圧倒的に少ないので公開は楽。ゴリゴリに自分でHTMLを書かなくちゃいけないけど、HTTPとHTMLの理解という点では理解しやすい。そして何よりも安いサーバで公開できる。ことWebプログラミングという観点では、PHPから入る方が理解が早いと思う。

逆にRailsのみで入った人で、scaffoldだけでtodoリストを作って「何が起きているかが分からない」という初心者もいる。FizzBuzzが書けないレベルでWebサイトが作れてしまっているので、「逆にどこから勉強していいのか」という話になる。PHPでフレームワーク無しで書いてみることで、フレームワークの中でやってくれていることが肌でわかると思う。

本当のプログラミング初心者には、以下の順に覚えてもらっている。

  • rubyのコマンドラインのプログラムを大量につくる
  • SQLを単体で覚える
  • フォームからDBにエントリーする仕組みをSinatraで作る(自力で全部書く)

業務で会員向けのサイトを実装するときにはRailsを使うけど、裏で何をしているかは自分で理解しないといけないのでトレーニングの段階では浅めのフレームワークで勉強する方がいい。

オススメの書籍

一つか2つプログラミング言語の本を前から順に習えば、あとはネットの情報でなんとかなるのではないかと思っている。

ネットの情報の中でも単なるトラブルシューティングではなく、ネット上の公式ドキュメントにあたるということ。rubyならrubyリファレンスマニュアル。phpならphp.net。公式ドキュメントって、イラストがないのでそっけないのだけれど、書いてることは正しい。公式ドキュメントが読みづらいなら、公式ドキュメントを読む力を身に着けた方がいい。

検索にもこつがある。

  • サジェストされる第二キーワードもよく見ながら検索しようね
  • 英語でググることで、より多くの検索結果にヒットする
  • site: 演算子で公式ドキュメントの中だけを検索できる

など。特に英語での検索は大事。たまーに「パイソン ループ」というカタカナで検索している初心者がいるが、英語の方がいい。

Linuxコマンドなどは、書籍がどうというよりも、man とか --help で、ドキュメントをみた方が手っ取り早い。ググる必要さえない。英語だけどそのままカタカナとして読めばいい。本を買う事自体はダメではないが、manから逃げる姿勢はほんと良くない。

「コンピューターはグローバルで便利なもの」なんだから、プログラマーが勉強する際にもコンピューターをフルに使いこなせた方がいい。

あとエラーメッセージも初心者が軽視しているポイント。画面に出た文字をちゃんと読むということは超大事。

プログラミングの勉強はどの道を進んでも結局重要 → その通り

ここに、結構大事なことを書いている。

大学の実験結果を解析する時、Excelでちょこっとマクロを組んだり、データをRubyに流し込んで解析をするみたいなこともできるようになります。

逆に、ここからスタートするのが健全なのではないかと思う。Excelをたくさん使ってる人のためにExcelVBAを書いてあげる。そして業務効率があがることでプログラムが発揮した価値を確認する。まさに職業プログラミング。個人向けWebサービスを作るだけが仕事じゃない。

最後に「Webサイト以外のプログラムの用途」が出てきたが、プログラムってのは人間の見えないところで働くケースも多い。Webサイトの形で動いているプログラムはほんの一部。プログラムを学ぶこととWebサイトを作ることはイコールではないし、それ以前にプログラムが社会に与える影響はWebサイトでのみ発揮されるものでもない。ラズベリーパイで自分の家の家電を自動化するというのでも十分プログラミングだし、価値も発揮されやすい。

調整さんの正しい使いかた

簡単みんなのスケジュール調整ツール「調整さん」を作った|blog|たたみラボ

調整さん リリースから10年以上も経つが、そもそもツールだけでは解決しないことが多々ある。 元々はメール文面で、日程調整をしていたのをビジュアル化したいというニーズから作ったものなので全ての課題を解決してくれるわけではない。

調整さん以前に時間調整ってどうするのかということを記したい。

例えば、会社の飲み会の調整。

二週間前後くらいあとの日程で

直近だと急すぎる。先すぎるともっとだいじな予定が入るかも知れない。なので、二週間前後くらいがちょうどいい。

自分の予定はまずはブロック

たまに見かけるのが、自分があとで日程候補に△とか書いちゃうケース。日程候補は自分が行ける日だけにしましょう。

会の重要性を伝える

行っても行かなくてもいいのか、必ず来て欲しいのかって重みは大事。既に予定が入っていてもそれを押しのけるべきかどうかも受けての判断ポイントになる。

調整さんで日程候補を出す前にキーマンの予定をブロック

ありがちなミスが、キーマンが調整さんに最後に予定をいれて、全滅というケース。まずは偉い人の予定を先に確保する。その確保された選択肢を、調整さんに候補として登録する。そして招待する際に「○○さんのブロック済みの候補です」とアナウンスしておけば、下々のものは「ならそっちに寄せるか」と判断しやすい。

日程候補を多くしすぎない

二週間くらいのレンジで飲み会日程候補がやってきたとしても、全てに◯とは書きづらい。「現時点での空き」を伝えるのではなく「日程調整が終わるまでのブロック」を差し出すことになる。二週間全部空いていたとしても、ユーザは「ブロックを差し出す数件」のみ◯にしちゃうので、結果的に日程が合わない。

選択肢は「できるだけブロックして欲しい数件(常識的には最大5件程度)」を提示するのがいい。

入力をお願いする

全員が入力されない場合もある。優先度が低い人は「ではこの日程に決まったのでできれば参加してください」と伝えるし、優先度が高い人(そして往々にして忙しい人)に対しては、直接会ってでも入力を促す。もしくは会ってその場で彼のスケジュールをブロックしながら候補を埋める。会えない人には電話をする。一対一のコミュニケーションでお願いする。

まとめ:時間調整は結構な意思決定を促している

調整さんというお手軽ツールを作っていながらもやっぱり幹事は気を使うべきだとは思ってる。偉い人も偉くない人も時間は平等に24時間。その時間を何らかの予定のブロックとして「差し出す」のは結構な投資/消費の意思決定をしている。その二時間で仕事をする以上のものが得られるのか、その二時間で一本の映画を見る以上の楽しみがあるのか。「どうか私に貴方の二時間を下さい。後悔はさせません」という気合でコミュニケーションをとるべき。