読者です 読者をやめる 読者になる 読者になる

GoTheDistance

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

【書評】抵抗勢力との向き合い方

著者の榊巻さんが所属されている、ケンブリッジ・テクノロジー・パートナーズ株式会社様よりご恵投頂きました。

抵抗勢力との向き合い方

抵抗勢力との向き合い方

改革には抵抗が必ずある

本書は「現状の課題を解決するための変革を目的したプロジェクト」において、日々奮闘されている現役コンサルタントの方が、プロジェクトのフェーズ毎に適切な抵抗勢力と付き合い方やヒントが書かれた本です。そのコンセプトが纏まっているのが、こちらの絵。

フェーズには「立ち上げ」「計画策定」「施策実行」の3つがあり、各々に適切な対処方法があって、それらがひとつひとつのセクションになっているという構成です。

抵抗は悪ではない

抵抗と聞くと少し感情的なイメージが強いのですが、抵抗が発生する理由は「自分の所属している立場を鑑みると、その改革によって不都合や不便が加速する」という背景があることが多いと本書を読んで感じました。抵抗はなんとなく発生するのではなく、その提案を受け入れられない確固たる理由があります。その根拠は、ぼんやりとしているかもしれません。でも、その兆候を見逃さないことが求められますね。

改革は会社で決めることであるけれども、押し付けになってはいけません。

自分の言いたいことが「相手に伝わる」ための本

抵抗勢力との向き合い方というタイトルではありますが、これを裏返すと自分の意見や意向を伝えて「相手を動かす」為には何が必要なのかを書いた本でもあります。本書の隠れたポイントは、そこにあります。主張を理由、そして根拠。これらをまず的確に伝えるようになること。その出発点からより生産的なコミュニケーションを取るにはどうしたら良いのか。

そのような事を参考にされたい方にも、本書はお役に立つことでしょう。

抵抗勢力との向き合い方

抵抗勢力との向き合い方

Pythonが独習できるオンライン学習サイト「PyQ」のレビュー

社内の主要開発言語にPythonを取り入れたことで著名な(株)ビープラウドさんが、Pythonのオンライン学習プラットフォーム「PyQ」をリリースされました。

pyq.jp

佐藤社長のご厚意でアカウントを発行頂き実際に使用してみたので、使用感をレビューします。

問題構成

以下のセクションに別れています。他にもいくつかありましたが、チュートリアルからWeb開発まで用意されています。

画面構成

f:id:gothedistance:20170501124352p:plain

2ペイン構成です。左側に問題(クエストと呼ばれています)の説明と解説、右側がPythonのコードを実装して実行結果やテスト結果の表示を行う場所になっています。工夫されているのは左側の説明の箇所で、写経前と写経後のコードの差分が見れるようになっており、自分で間違いに気づくことができるようになっています。

また、はじめの一歩で敢えてエラーがでるコードを書いて、初心者が陥りやすい「SyntaxError」「NameError」「TypeError」について先にやらせるのも上手いやり方です。先にエラーを出させて直す工程を踏めば、後々の学習が楽になります。

強いて言えばローカル実行も可能にしたい

正解で動かすことが出来たコードは、自分のローカルに保存(コピペすりゃいいんですが)出来るようにファイルをエクポートできると便利だなと思いました。模範解答として残しておいて、それをプライベートなリポジトリに置いて共有するとか、そういうやり方もあるのかな〜と。

Webアプリの実行について

特徴的なのは、ブラウザオンリーでWebアプリが作れる構成になっていること。PyQでは写経エリアに書いたコードを「ブラウザで表示」することが可能です。各々のサーバに配置されたPythonのWebアプリ(Djangoベース)が起動するので、環境構築が必要ありません。面白い仕組みだなと純粋に思いました。

個人ユースよりも企業ユースが多くなりそう

プログラミングを完全に独習で行うのはハードルが高いですが、PyQのような仕組みがあれば、オンライン学習の生産性もかなり高まるでしょう。講師の講義を聞きつつ写経が出来る。もちろん復習用途で独習もできる。このようなスタイルが確立できれば、現在新人研修講師を務めている私は楽になるな〜と感じました。

「独習Python入門」という本を書いた私からすれば、PyQさんとさりげなくコラボして、書籍で掲載された練習問題を独習して更に理解が深まるような構成に出来たら最高だった。

まずは個人で体験してみて下さい

テキストも分かりやすく書かれています。周りに誰もいない一人でも使えますし、オンラインのサポートが受けられるプランも用意されています。まずは触ってみてください。ホンマによく出来ています!自分の教材も載せてほしいです!

pyq.jp

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システムばっかりやってきた僕は思います。

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

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