GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

Javaで「はじめてのプログラミング」を教えるのはキツイと思った話

2017年4月から人生初めての新人研修講師を務めさせて頂くことになりました。プログラミング入門がテーマです。

先方は昨年までJavaでカリキュラムを組んでいたんですが、JavaをやめてPythonでやらせてもらえないかと提案し快諾頂きました。プログラミングの入門書を書いたから特に感じることなんですけど、Javaはプログラミングの初学者に向いていない言語だと思います。

クラスありきの言語設計

それがJavaの良いところでもあると思いますが、プログラミング自体が初めての方を対象に考えた場合、はじめの一歩として不適切だと感じます。

Hello Worldが重たすぎる

お馴染みのHello Worldです。初めてのプログラミングで以下のコードを見たら、何のことやら分からないでしょう。

public class Test {
    public static void main(String[] args) {
       System.out.println(“Hello World!”);
    }
}

これをどうやって初心者に説明したら良いのか… クラス/関数/引数/配列/名前空間等/エントリポイント等の概念が全部まとめて出てきます。とりあえず「おまじない」で通すとしても、はじめの一歩からおまじないというパワーワードに逃げるのは筋が悪い。PythonPHPならprint/echoするだけなので、体で覚えやすい。

Javaコンパイルが必須

コンパイルのような環境構築を伴う作業は、ハードルが高い。環境変数をセットしてjavacコマンドを叩くなんて、人生でターミナル起動したことがない人には恐れ多い。IDEをインストールしろって初学者に言い放つのは「とりあえずこの栄養ドリンクをがぶがぶ飲めや」って話に近い。

その点、インタラクティブシェルがある言語はやりやすいです。そこで練習してから、ファイルを指定して実行できるようになれば良い。

サーブレットが鬼門となる

これは聞いた話なんですけど、サーブレット(Servlet)が鬼門になるそうです。【Java/Web再入門】その2.サーブレットを作ってみよう - KnowledgeFortよりServletのサンプルコード引用させて頂き、簡略化しました。

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class Servlet002 extends HttpServlet {

	@Override
	public void doGet(HttpServletRequest aRequest, 
                                HttpServletResponse aResponse) {
		try {
			aResponse.setCharacterEncoding("UTF-8");
			aResponse.setContentType("text/html");
			PrintWriter _writer = aResponse.getWriter();
			_writer.println("Hello World");
		} catch (IOException e) {
			e.printStackTrace();
		}
		return;
	}
}

これが正しいかは置いといて、あまり直感的じゃないです。HTTPやHTMLが理解できていないと、上記のコードの意味はわからない。わかってから書けよって話は、初学者にはちょっと可哀想。サーブレットを動かすための環境設定も必要で、動かす前に覚えないといけないことが多くて大変です。クラスローダーも理解しないといけない。

Pythonだとすげー簡単です。ビルトインサーバの機能を使いつつ、マイクロフレームワークWelcome | Flask (A Python Microframework)を使えばこれだけで同じことが出来ます。

  @app.route('/')
  def hello():
     return 'Hello World'

プログラミング入門と言語の入門は別の話

これは自分が本を出した問題意識に直結しますが、プログラミングの学習には「プログラムに落とすための考え方」と「プログラミング言語の仕様、動くコードの書き方」の2つがあります。プログラミング自体の入門と、プログラム言語の入門は、別の話です。Javaが初心者に向かないと感じたのは、前者を学ぶのにJavaの思想が前に出すぎているからです。プログラムを書く考え方が怪しい状態で、Javaの思想や仕組みを理解しないと動くコードが書けないのは可哀想だと思いました。

プログラミングでいちばん重要なのは、論理に落とし込む文章化能力だと思います。アウトラインを描き上げる力が最も大切。それがないと、プログラミング言語が提供する技術で何を表現したら良いか、判断がつかないからです。掛け算と一緒で、ゼロに何をかけ合わせてもゼロなんで。

企業向けの研修では未だにJavaが主流のようだけど、個人的にJavaでプログラミングの入門を上手く説明できる自信がありません。はじめの一歩にJavaは正直オススメできないし、そのスタンスでご納得頂いてお仕事を頂いてきたので、「実はオレもそう思ってたんだ」層に届けばと思って、記事書きました。

プログラミングの入門書を書きました

Pythonの書き方は僕よりも優れたプログラマの方がたくさん本を出されています。サクッと「プログラミングってなんだろう、どーゆーことをするんだろう」という要点をつかみたい方には、手前味噌も良い所ですけど自信を持って自著をおすすめします!

独習Python入門――1日でプログラミングに強くなる!

独習Python入門――1日でプログラミングに強くなる!

【御礼】自著「独習Python入門」の増刷が決定しました

gothedistance.hatenadiary.jp

上記の告知を昨年8月1日にさせて頂き、8/5より販売開始。およそ7ヶ月半で増刷の運びとなりました。ご購入頂いた方や書評を書いて頂いた方を始め、本書に関わる全ての方に御礼申し上げます。

独習Python入門はプログラミングの入門書

書店での販売戦略の関係上で「Python入門」という書名になっていますが、Pythonというプログラミング言語の入門書ではなく、「プログラミングを身につけるために必要な知識と考え方」をテーマにした書籍です。

プログラムを書けるようになるためには、当然ですけどプログラミング言語の仕様を理解しなくてはなりません。動くプログラムを書くために絶対に必要です。が、それだけでは「自分のやりたいことを、どうやってプログラムに落とし込めばよいのか」というイメージが湧かないので、初学者の方はつまづきます。

その為、本書の構成においては、Pythonの言語仕様や文法については必要最低限の説明しかありません。従来のPython本の2〜3割程度だと思います。動かせもしないのに言語仕様をじっくり学んでも徒労なので、思い切って削りました。

「読み切れる」入門書を目指してます!

技術書の入門書で「最後まで読み切れる」のは、かなりハードルが高いと思っています。そこに挑戦していますので、分量も従来の入門書に比べて少なめでイラスト多め、サイズも技術書にしては小さい。コードを写経しなくても読み物として読めるように、最大限配慮しています。書かれている日本語の意味が曖昧だったり書籍の構成(要は伝える順番)が雑ですと、一気に読む気が失せます。写経以前の問題です。そうならないように、あの、頑張っています!

書籍のお買い求めは、なるべく書店にて...

これには多くの出版関係者が同意頂けると思うのですが、Amazonでお買い求め頂いても書店への配本が増えることにつながりにくいので、電子データでなくても良くお近くに書店がお有りの場合、可能であれば書店にてお買い求め頂けると幸甚でございます。伏してお願い申し上げます。

書籍に関する情報

版元である技術評論社様の「独習Python入門」のWebページです。

gihyo.jp

Amazonのページはこちらです。

www.amazon.co.jp

僕自身、別の本を出したいという気持ちはあった

ぱっと見たところ「要件定義本?」というイメージだと思いますが、僕なりの独自の切り口で構成案を作り上げています。あとは・・・中身です。頑張ります。

ブログで生計を立てるのは、ハイリスク・ローリターンな人生戦略

ブログが右肩上がりに儲かってるのでブログ飯やる宣言→2日後に検索順位が急降下して無事死亡したハートフルストーリーを見て、ほっこりしました。

www.airdays.net

よかったですね。撤退できる状況で撤退できて。撤退するタイミングや状況を逸したら死亡フラグがこんにちは。Google先生の粋な計らいです。

個人がブログでお金を稼ぐのは公序良俗に反しない範囲で好きなだけされたら良いと思いますが、ブログで生計を立てることには懐疑的です。冷静に考えると、リスクに見合ったリターンが得られない可能性がとても高いからです。

そう考えている根拠をいくつか上げます。また、これらのリスクをどう管理したら生きていけるものなのかも、興味があります。

Google牧場の小作人でしかない

検索順位を上げるという収穫を得るために、ブログ畑をせっせと耕す。その手間暇をかけても儲かるかどうかはお天道様次第って、個人的には怖くて付き合っていけない。Google牧場の小作人でしかない。小作人として上手く立ち回る練習を積んでも、下記のような敗戦処理を強いられるリスクは少なくない。

www.hironorisatomoto.jp

生計を立てるなら、必ず儲からなければなりません。 かけた手間に対して定期的に収入が得られなければ、絶対に続かないですよ。ブログに賭けるより先に、別の手段で定期的に収入を得る事を考えるほうが生産的なように思えます。PVに依拠しないで稼ぐためには、法人組織と取引するしか無いでしょうし。

収益化につながるノウハウをお持ちの方は沢山おられるのでしょうけど、テクニックの延長線に過ぎないとしたらオワコンの始まりですよね。旬が短い流行りものについていかねばならない割に儲からないとしたら、人生戦略を形成する事業として考えるとかなり微妙です。

こんな感じで、Google先生は日々アップデートをされておられるようなので。

www.kk3marketer.com

潰しが効かない

ブログを運営して個人で収入を得たとして、その能力を必要とする企業組織がどれだけいるのか。そこを考えると怖くなります。職能のないブロガーは、全く潰しが効かない。

ブログは誰でも書けるし、書きまくっても何かの問題解決につながる専門的能力が身につくわけでもない。ブログを運営して稼いでいます!というのは能力ではあったとしても、職能じゃない。能力(Ability)と職能(Skill)の違いについて、考えて欲しいです。金を出す価値があるのは職能だけ。英語が得意な方は、英英辞典を引いて下さい。克明に違いがわかります。

ライティング能力があがる? 全然ない。その点は、Hagex氏のブログをたくさん書いても文章は上手くならない - Hagex-day info に詳しい。文章力を上げるには、良い読み手であることが一番先。書くことじゃなく、読み解けることが先。これを勘違いしてる人が多い。読解力がない人間の書く文章は、企業媒体から依頼が来てお金が取れるものにはなりません。そもそも、文章力と報酬額は比例しません。

個人は個人でしかありません。個人の時代キタコレみたいな話、2005年頃のWeb2.0が持て囃された時からありますからね... 今こそWeb2.0関連の本を読むと学びがあるのでは。

C to C モデルでしか食っていけない

企業組織に相手にされない個人が稼ぐには、個人を相手にするしか無い。個人と個人が取引をするモデルです。

C to C は、事業運営の基盤としては非常に脆弱です。個人でやれる範囲のことしか出来ないので、解決できる課題に限りがあります。その結果、伸びしろが薄くなるのでスキルを切り売りして行き詰まる。顧客が個人なので単価は法人相手に比べて非常に低いので、頭数を集めるしかない。集まっても300人ぐらい? 1000円/月で年間で360万。やっす…

ブログ運営ノウハウ的なものって、ほとんどマネーの話に帰結しています。ブログが欲しいわけでなくブログを運営してお金が欲しい人が大半です。そういう狙いを持っている人が最も集まりやすいけど、お金だけを目的とした事業は長続きしません。価値を生み出せないからです。

ゴールドラッシュでツルハシを売れという話は有名ですが、ツルハシを買った人の大半はどうなりました?

HTMLの画面キャプチャを信じるな

話はそれますが、アフィリエイト好調アピールをするやり方として、ASPなりの管理画面を見せてエビデンスとする方式が散見されます。下記が一例です。とある方のツイートを抜粋し、個人批判をする気はないのでマスクさせて頂きました。

f:id:gothedistance:20170321170359j:plain

上記のようなHTMLの画面キャプチャはいくらでも偽装できます。

HTMLを使ったスクリーンキャプチャがいくらでも偽装可能だってことは、インターネットリテラシーとして知っておくと良いかもしれません。下記は当社のトップページをFirefoxを使って偽装する動画です。誰でも出来ます。

youtu.be

管理画面のようにログイン前提の画面だと、真偽を見極めるのは困難なのでとても質が悪い。昨今のブラウザはこういうツールが標準装備されているので、HTMLの画面キャプチャはエビデンスとして機能しないと考えて良いでしょう。

Hoping for the BEST, but preparing the WORST.

僕の周りでも、ブログを上手く活用されて生計を立てているプロがいます。でも、片手で数えるほどしかいません。

生計を立てられる以前に企業組織で相当な下積みを積まれていたり、会社員時代に何年も併用しつつフェールセーフとなるポイントを見極めて独立されたりと、堅実に地に足を着けてステップアップされ、舵を切っています。

僕が好きな言葉に「最高の状態を望みなさい、でも、最悪の事態に備えなさい」という言葉があります。後者があるから前者を考えることが出来ます。最高の状態ばかりを見ていると感情が思いっきり入るので、多かれ少なかれ道を踏み外します。

ブログで食う夢に食われて人生を食いつぶされることがないようにね。

国内ラボ開発という新たな受託開発のビジネスモデル

古い読者の方はご存知かと思いますが、僕は受託開発においてアジャイル開発をそのまま適用するのは否定的で、アジャイル請負は自爆テロと紙一重だとすら思っています。上手くやれる組織もあるんでしょうけど・・・。

アジャイルを受託開発で正しく推進するのなら、ビジネスモデルを大きく変える必要があると見ています。永和さんの価値創造契約や、倉貫さんの納品のない受託開発等、新しい受託開発のビジネスモデルが出て来ました。そんな中、こんな会社があるんだけど知ってますかと連絡がありました。(株)プラムザさんが掲げる「国内ラボ開発」です。

labo.plumsa.co.jp

受託開発専業の会社さんでアジャイル開発を独自の方法論で推し進められているようなので、2/20に開催されたセミナーに潜り込んでみました。

国内ラボ開発のビジネスモデル

契約は準委任契約で、最低契約期間3ヶ月。それ以降は月額課金となり契約解除が可能になる。初期費用も頂かない。ここまでは「よくある話」なんですけど、この進め方の絵にご注目下さい。

f:id:gothedistance:20170221222506p:plain

各々のロールに沿って、プロジェクトの進行と共にチーム構成やそのロールを担う人の稼働が変わっています。最初はPMとSEが多めで、開発が進んでくるとPGが多め、みたいな。稼働の見積もりが「日単位」で、チーム構成は月単位で柔軟に変えられる。過剰に人を割り当てるとお客様に不要なお金を払ってもらうことになるからギリギリまで合理化しよう、というポリシーでやっておられるそうです。最適なチームをその都度構成するのがベストだと考えられているのでしょう。

仕事の進め方も「最初からすべての要求を確定するのは辞めて、走りながらやりましょう」というスタイルです。要件定義をかっちりやっていったら、時間ばかりかかってしまう。最小契約期間の3ヶ月で何も動くものが出来ないのが、最も望ましくない。ゴールをシステムの完成におかずに利用し続ける限り手を入れて、システムを進化させていきましょうという考え方ですね。

青天井をどう捉えるか

この手のビジネスモデルを考えるには、費用をどう捉えるかが重要です。やる方は、システムに手を入れ続ける限りお金が入ります。お客様からすれば青天井になります。支払いに終りがありません。

そうはいっても、そのシステムが継続的に利用され事業運営に資するものであれば、常に最善の形は変わっていくはずです。また、業者が手を入れるか自分たちで管理するかだけの違いになるでしょうし、メンテナンスする人員は必要。お客様の立場で定期的にメンテナンスできる体制があることの意味がご納得頂けるかどうか、そこがポイントなのかな〜と感じました。

色んなモデルが出てきて欲しい!

一括請負以外の受託開発における色んなビジネスモデルについては引き続き勉強したいので、もしこんなことやってる会社があるよ!というお話があれば、僕のブログのお問い合わせフォーム等から頂ければ嬉しいでーす!

色んなことをソコソコできる人が、生きる道

僕は器用貧乏です。色んなことがそこそこできるという、一般的なキャリア論では最もダメな部類に入ると思います。餅は餅屋。ドラッカー先生も言うてはる。あなたは何によって知られたいのか、それが重要だと。

エンジニアとしてキャリアをスタートさせて、恐ろしいことに10年以上の月日が経ちました。残念ながら、エンジニアとしては絶対に大成しないという確信があります。コードを書くのは好きです!でも、要素技術を突き詰めようという気持ちがすごく弱いのです。1つに絞り込むってことが、生理的に出来ない...全く違う分野に対して興味を持ったら、もう止められない。

そんな人って、実は技術職のエンジニアでも結構いるんじゃないかなっと感じたので、ブログ書きました。1つの分野の専門性が築けなくて悩んでいるのなら、「そーゆーの向いてないわ、俺」で諦めちゃったらいかがでしょう? 僕のように。

僕より優れたエンジニア、僕より優れた営業マン、僕より優れた書き手。たくさんいます。

でも、僕のようにエンジニアをそこそこやれて、経営者との折衝/IT戦略立案/要件定義をそこそこやれて、(やりたくないけど)プロジェクト管理もそこそこやれて、そこそこ読ませる文章を書ける人って、ほとんどいないんです。おかげさまで、思いもしないオファーを色々と頂くことができました。

ソコソコも1個じゃダメですけど、毛利家の3本の矢のごとく束ねることが出来たら、とても価値があります。その価値を他業種の方が認めてくれます。

高い専門性が理解できるのは、基本的に同業者だけです。同じことをやってるから、その人の持ってる技術の意味がわかります。同業者に自分を売り込むのなら、専門性を突き詰めるのが良いでしょう。

器用貧乏で、1つに絞るのが生理的に嫌。だけど、何でも面白がってやれる。同業ではない方に自分を買ってもらいたい。そういう指向性をお持ちなら、そこそこやれるスキルをいくつも身につけて下さい。時間はかかるけど。そういう方が一緒になって仕事をデザインしてくれると、本当に頼りになる。僕もそうありたい。

エンジニアであることと、エンジニアとして生きることはイコールでなくても良いはずです。専門分野をソコソコのレベルで留めてしまって違う道をゼロから始められるのは、一種の才能だと思います。道草食っても、その道の味がわかれば楽しいからいいじゃんで、振り向かないで生きていける。独立したら楽しくなるタイプな気がします。安易に勧められないですが、視野に入れてほしいです。

SIの未来は、技術力を武器にSIを行うことで見えてくる

小野さんが、SIの未来についてブログを書かれていました。今後の取組にも期待しております!

小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来

SIの未来を探すという永遠の課題

SIという仕事は必ず必要であり、そこにいる人たちがハッピーになる未来を語りたいけれど、何が未来像なのか明確になっていない。そんな印象を持っていますし、僕が社会人デビューした2003年ぐらいから変わってない気がします。

未来のあるなしを考えるなら、これは未来がないよねという所から始めるのがわかりやすいと思います。出発点を決めるのに役立つので。というわけで、僕から提起します。上流と下流(という言い方がお嫌いの人が多いけど)で工程の分断をするモデルには、明るい未来がない。これだけは確かです。消耗戦の先に新しい未来はないもの。

技術力を武器にSIをやれることが、SIの未来を考える第一歩

未来のない状態を裏返せば、多少なりとも未来に近づきます。なので、SIの未来を考えるということは「工程分断型のビジネスモデルから脱却して、技術力を武器にSIをやる為に必要なこと」を考えるのに等しい。そう考えました。

工程分断型から逸脱するのに必要なことは実は1コしかなくて、顧客と直接契約して価値を届けることだけ。何を届けるかは僕が知りたいというのが本音だけど、形態(やり方)としてはココしかないです。下に入って抜け出せなくなってしまえば、そこから新しい未来を描くことは極めて困難です。

SIが本来持っている価値は、「顧客が行っている事業で築き上げる資産をいかにITで活用するかを考えて、新しいステージに到達すること」だと僕は思います。その価値をどんな提供手段を持って行えば良いのかという点において、僕が最も可能性を感じているのが「作らないSI」です。

だって、労働集約的なやり方をやめたいんだよね?

様々な企業のニーズに応える必要があるSIビジネスにおいて最大のリスクは、プログラムを手組みすることです。案件を回す立場(Not 下請けの進捗管理)になれば、その意味は嫌という程わかります。純粋にソフトウエアを作るということと、顧客にとって必要なシステムを作るということは、どうしても文脈が異なります。しょうがないの、もうそれは。埋まらないって。それに、顧客のIT予算もクラウドが普及すればするほど下がるはずなので、手組みで工数を裂いて人を集めて値段を算出しても「それだと無理」っていう話になりやすいのではないかと思います。

インフラの世界では、設計書を用意してOSやコンテナを自動でセットアップするのが当たり前になっています。ビジネスアプリケーションもそうなれば良い。開発工程が自動化で圧縮されたら、短納期になります。自動化すれば、自動化するプログラム以外の不具合はなくなるので、品質の担保も容易になります。人をかき集める必要もなくなります。ここに上げた内容は極論です。だけど、「ド正論」です。僕はこういう身もふたもない話が大好きです。大抵の場合、正しいので。

・・・で、実際にそこを目指して、自前でそのような仕組みを作って案件をこなしている会社があるわけです。そのような会社さんに出会った以上、そこに未来がなければ僕も困る。なので、主に販促面でサポートさせて頂いております。詳しいお話を聞きたい方は個別に連絡くーださい。

今後どういう取り組みがSI業界でなされるのかはわかりませんし、僕が全然見えていない可能性も当然あるでしょう。僕の推しメンは可能性の一つに過ぎません。再掲しますが、「工程分断型のビジネスモデルから脱却して、技術力を武器にSIをやる為に必要なこと」という前提でSIの未来を考える議論が発展することを願います。

やっぱりこの仕事が好きなもんですから。

【書評】その「エンジニア採用」が不幸を生む

毎度おなじみ技術評論社の傅さんからご恵投頂きました。

結論から先に言いますと、僕が今までご恵投頂いたエンジニアのキャリア本で「ベスト」の一冊です。

採用という切り口でエンジニアのキャリアを見つめ直す

本書は「採用」に絞って、エンジニアが企業組織で良いキャリアを築くためには何が必要なのかを問題提起しています。「エンジニアはもっと採用されるように頑張れ」というクソみたいな話じゃなく、採用すると決めた経営陣、それに従う人事担当者、採用されるエンジニア。この3者の立場を俯瞰しつつ採用コンサルティングとして携わってきた筆者が、重厚な論調で痛快に問題点を指摘しています。

エンジニアで生きていくのと、エンジニアを活かす企業組織を作ることは、すごく難しいことはでないか。それが本書の隠れたメッセージのように感じます。

人材紹介会社のビジネスモデルがエンジニアを不幸にする

自社で集めるのが難しいから人材紹介会社を活用するわけですが、向こうも商売です。マッチングゼロだったらお前何やってんのって話になるし、転職しても3ヶ月未満で退職した場合はノーギャラになるケースもあるそうです。技術要素や担当工程が細分化されているエンジニアの事情を鑑みれば、まずマッチするケースが少ない。でこかアンマッチする案件を紹介せざるを得なくなる。その結果、雇用して退職された場合はアンマッチになった理由を検証するのが困難になって、また同じことが繰り返される… そんなことが書いてあります。なかなか、難しい話です。

良いエンジニアを採用できる採用担当者を

不幸なすれ違いを防ぐ為にどうしたらいいか。ド正論は、その企業のエンジニア採用力を上げることです。良いご縁があっても、採用の質が悪ければ意味がない。

エンジニア採用の難しい点は、エンジニアの評価はエンジニアにしか出来ないことにあるのではないでしょうか。数値化出来る要素があまりない上に、経歴ではなく姿勢が問われることが多い。C#の職務経験はないけどAndroidアプリを作れる人だしUnityも慣れたらいけるよね、みたいな判断は素人にはできない。職務経験の向こう側がね、なかなかね。

また、エンジニアはキャリアチェンジをするのが滅茶苦茶難しい。陸に上がった魚は海には戻れない的な。エンジニアを人事にして2〜3年採用業務をやったら、もう開発の現場には戻れない気がします。それを望むエンジニアの方、どれだけいます? 一般的な人事部門と全く違うあり方が望ましい気がしますし、エンジニアに限らず様々な知的労働者に応用が効きそうです。

ある企業では、エンジニアを採用する時にそのチームのエンジニア全員が採用面接に関わると聴きました。満場一致じゃないとだめらしいです。一歩間違えれば圧迫面接でしょうけど、採用はお互いの真剣勝負と考えている現れですね。

デブサミで「採用」をテーマにしたら面白いかも

次回のデブサミ、どこかのトラックで採用をテーマにしたら面白い気がします。採用で苦労していない組織はないと思うので。取る側がこんなエンジニアがほしいじゃなくて、ウチはこんな人事制度や評価制度でエンジニア像を考えています、という立ち位置で。すでにやっていたらごめんなさい。

技術や工夫を駆使してサービス作った/現場を変えたという話にもう1枚加えるとしたら、キャリアだと思う。エンジニアの祭典で優れた見本市の場として十二分に機能し、エンジニアやってる意味を見つめ直す場にもなっている。同時に、どんな技術を身に着けたら良いかでは語れることに限りがある。社内制度に踏み込んでしまうので「どこまで」という線引きが難しいですが、人事制度まで切り込んで採用に議論する場があれば業界としてプラスに働くように思います。

不幸なすれ違いをなくすために

エンジニア採用が活発になったのは恐らくここ10年のことですから、ITエンジニアのキャリアや採用のあり方にについては黎明期なのかもしれません。試行錯誤が続くと思いますが、現時点でITエンジニアの採用についてまとまって書いてある書籍は本書ぐらいでしょう。自分がどう評価されたいのか、自社の評価軸はどこにおくのか。採用する側は何を気をつけたらいいのか。

本書をあたれば、きっと新しい発見があることでしょう。

【書評】はじめよう!プロセス設計

毎度おなじみ技術評論社の細谷氏よりご恵投頂きました。おおきに。

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

なんでプロセス設計なのか

前作ではじめよう! 要件定義 ~ビギナーからベテランまでという本を書かれた著書の羽生さんが「そもそも材料がないから要件定義なるものができない」という現場が非常に多く、要件定義のその前に考えなくてはならない「プロセス設計」についての本が必要だという考えに至ったと書いてあります。

材料ってそりゃ所属してる会社のビジネスであり自分の仕事じゃないかと思うのですけど、自分の会社が何を商売にしていて、自分達の仕事の意味や課題点を整理して、"こういう仕事に変えていけばいいんじゃない”と落とし込む為の考え方が全く浸透していない。 本書からはそのような問題意識をビンビンに感じました。

ごった煮感が強い

あとがきにも書いてあったのでツッコミますと、本書はごった煮感が強いです。みなさんがプロセス設計に近しい局面にぶち当たった時に役立つ内容が散りばめてある感じで、オムニバスのような仕上がりになっています。プロセス設計のハウツーではなくヒントがたくさんあるので何か1つでも響いてくれたら、という格好。

僕がプロセスを設計する時に考えていること

自分がプロセスを設計する時に考えていることはこの4つです。

  • その仕事はどこから来るのか
  • 作業を終わらせるために何を判断しているのか
  • 終わったら次はどこに行くのか
  • 例外(個別対応)はどれぐらいあるのか

この4つを整理すれば概ね問題なく現状を把握できると思っています。あと帳票のチェックも忘れずに。必要だから存在してるので。

で、本書にもありますがToBeを考えるときは逆算で考えます。本書ではバックキャスティングという言葉を使っています。ゴールは追いかけていくもんじゃなく、近づいてくるもの。逆算しないと近づいては来ないです。

企業のITシステムをデザインする難しさ

企業のITシステムを作るのは非常に難しい仕事のはずです。こういう仕事に変えていくとデザインして、それを実現するITをデザインして、実装して提供しなければならない。その工程はひとまとめにして分断させないことが大切です。仕事をデザインしている仕事、かっこいいじゃん。仕事を変えることの大半は仕事の中で流れている情報の流れを変えること。企業のITを作る人はそれを意識しないとね。昔はビジネスアーキテクトとか言ってたよね。素人童貞臭ハンパなくて草不可避です。

マーケットとしては企業のITをデザインするSI領域のほうがWebサービス系の領域よりも全然大きいのだから、プロセスを設計して自社の事業運営にほんとうに必要なものは何かを見定めることがいかに大切なのかってことを、本書を読みながら思いを馳せてほしいなぁと企業のITシステムばっかりやってきた僕は思います。

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

【書評】エンジニアがフリーランスで年収1000万円になるための稼ぎ方

技術評論社傅さんより恵投頂きました。おおきに。

フリーランスで一番大変なのは営業

本書は社員の方がフリーランスを検討し始めたときに最初に読む本、という位置づけです。細かい話は置いといて、フリーランスと正社員はこういう点が違うという抑えから入り、案件のとり方や自分の売り込み方、地雷案件の見抜き方などの実務に入り、最後にフリーランスで長くやっていくためのポイントを紹介しています。

本書に書かれている内容でフリーランスで最もハードだと感じたのが、営業です。僕もまだまだですが、仕事を取ってくるというのは思いの外難しいものです。ほんとにもう。筆者の方は「自分で営業する」「クラウドソーシングを使う」「エージェントに頼る」の3つがあるとおっしゃっており、最終的にエージェント活用に落ち着かれたようです。

自分で営業しても自分のことを知らない人間はまずスルーだし、万が一引っかかっても仕事を出してくれるかは別問題。間に誰も入らないというメリットは、裏返せば請求から回収まで全部自己責任。クラウドソーシングは地雷も競合も多いので骨折り損のくたびれ儲けになりやすく、どうせ手数料等を支払うのならそのお金でキチッとした仕事先と人脈を構築するためにエージェントを活用するのが最も安定していると書かれておりました。

本書の最高のパワーワードは「自分でWebサービス作って儲けようとして1年間無収入で作ったけどゴミしか作れずウン百万溶かした」です。自社サービス開発をやるのは全然ありだと思いますが、順風満帆だとしても開発が終わってリリースして結果が出るまで2年ぐらいかかりますので、その期間どうやって生きていくのかを考えるのが先になると思われます。

安定とは動かないことではなく、動じないことです。フリーランスでも正社員という形態はメリット/デメリットがあるだけで、善し悪しはありません。どちらの立場を選んでもご自分の立ち位置を振り返って動じないのなら、素晴らしいことです。

エージェントでもクラウドソーシングでも、案件の目利きと自分の技術の伝え方は絶対に必要になります。フリーランスは自分で仕事を取ることからスタート。案件の取り方、見極め、そして継続。本書のコアはそこにあります。ご興味がある方はぜひお手にとってご覧ください。

余談

フリーランスから更に進むと事業運営を行う組織へと変貌を遂げます。僕自身もそうですが、僕の周りでは「自分の食い扶持は自分でできるけど、目指す未来のために(できればお互いの食い扶持を共に稼ぎつつ)事業運営を行える人との出会い」にぶつかっている方が多いです。グルグル回ると自分の今の仕事すらネガティブになってしまうので良くない。ここを超えると個人事業から会社になれるのかなぁ。

medium.com

プログラミングの学習に最適なWebサービス「CODE写経」

僕が作ったものではありませんが、面白いコンセプトだなぁと思ったので紹介します。(株) レベルエンターの代表、山本さんがおひとりで開発されたサービスです。その名も「CODE写経」です。画像をクリックするとサービスのページにジャンプします。

CODE写経

写経はハードルが高い

プログラムの文法に不慣れな初学者にとって、写経は少しハードルが高い。カッコを付け忘れるとか半角を全角で書くとか変数名をtypoするとか、コピペではない手段でプログラムを書こうとすると色んな罠があります。不注意と言えばそれまでですが、何が不注意だったのかもわからないのは可哀想です。

とにかく動くプログラムを書かないと、学習を先に進めることは出来ない・・・ 

山本さんはプログラミングを教えるお仕事をされているので、間違えずに写経ができるサービスがあればと思ってこちらのサービスを開発されたそうです。

操作動画

youtu.be

Chromeでしか動作確認とっていないので、Chromeでやってみてください。

プログラミングの学習効果の向上を目指す

プログラミングを教えている教育機関や企業を対象に、オリジナルの教材を提供しているとのことです。教材とコードをご用意頂き、レベルエンター社がCODE写経にパブリッシュ。そちらを使ってワークショップや研修などを行えば、より高い学習効果が期待できるというわけです。ログイン不要のでもアカウントもあるので、とりあえず触ってみてはいかがでしょうか?

今後の展開に期待しています。

SQLを学習できるWebサービスを作りました。