「独習Python入門」というプログラミング本を出版します

「独習Python入門――1日でプログラミングに強くなる！」というPythonでプログラミングを学べる入門書を出版します。皆さんご存知の小悪魔女子大生(現在はOL)サーバーエンジニア日記を書かれていた、aicoさんにイラストを頂戴しました。

8月5日、販売開始です。

8月5日、販売開始です。

大切なことでございますので、2回述べさせて頂きました。Amazonで予約受付を開始しています。詳しい目次や電子版の案内等があるので、版元の技評さんのサイトを貼っておきます。

gihyo.jp
Amazonはこちらです。

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

画像がまだ反映されない...

本書を執筆したきっかけ

身内にプログラミングを教えてほしいと頼まれて、適当に入門書を買って読み合わせながらやっていたのですが、どうもうまく説明できませんでした。そのギャップを埋めるように補足資料を作っていたら段々面白くなっちゃって、結構な分量に。「ここまで来たら本にしたい」という欲が出たので、技評さんに持ち込んだら会議に通して頂いて書籍にすることができた、という経緯です。

本書の執筆で特に気をつけたこと

本書を書くにあたっては様々なプログラミングの入門書に目を通し、何人かのプログラミング未経験者にレビューを頂きました。また、実際にドラフト原稿でプログラミングを教えて実践形式でレビューを行っています。

スクリーンショットを細かく取る

サンプルプログラムを書籍に記載して「はい、実行してください」の一文で終わってしまうと、そこで脱落される方が相当おられるようです。その為、サンプルプログラムを実行する手順で迷わないことを最重要課題におき、スクリーンショットを細かく取っています。

本を1日で読み上げる人はそんなにいません。1章だけ読んで2章を読むのが2週間ぶり、なんてこともあるはずです。ブランクがあろうが書いてあるプログラムは確実に実行できないとまずいので、プログラムを実行する箇所には全てスクリーンショットを入れました。

また、初学者の最大の難関である「動かない理由が、エラーメッセージから判断ができない問題」についても細かく説明を入れています。

なぞるだけの本にしない

手順に沿ってやれば本に書いてある通りに出来たけど、用語や作業内容については説明が足りていないので「出来たけど、出来るようになった気がしない」という事態にはしたくなかった。

結論としては、こまめに練習問題を入れて徐々に高度な事ができるような形にするのが良いだろう、と思いまして、そういう形式にしました。

解説にメリハリをつける

メリハリとは、考えなくちゃいけない所とそうでない所を明確にしていることを意味します。「じっくり考えてほしい」と「そういうもんなんで頭の片隅に置いといて」というニュアンスを、可能な限りきっちり分けています。考えてもしょうがない所で悩み始めるとドツボにはまりますから、それを防ぐ狙いです。

最低限必要な文法を知って勉強して頂き、コードで書かれている内容をひとつのストーリーとして言葉で説明できないと、自分のやりたいことをプログラムに落とせません。場数がモノを言う所ですが、自分のやりたいことをプログラムで表現するのがプログラミングなので、表現するための手法や考え方をイメージできるよう腐心しています。

よろしくお願い致します！

著者がここまで細かく書籍の背景を書くことはあまりない気がしますが、背景が伝われば読者の理解を助ける一助になると感じたので、頑張って書きました。

電子版も出ます。技術評論社様の電子書籍の販売サイトではDRMフリーのPDFとEPUBが、そして大正義AmazonからはKindle本。準備にお時間が掛かりますので、今しばらくお待ち下さいませ。

8月5日、販売開始です。どうぞよろしくお願い致します。

gihyo.jp

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

株式会社 クオリティスタートを設立致しました

5末で前職のエフ・ケーコーポレーションを退職しました。で、会社作りました。6/1に登記申請を行い受理されてから口座開設と税務署への届出等の細かな手続きがございまして、法人としてスタートするのに１ヶ月かかりました。

quality-start.in

StaticPressで作ってS3でホストしてます。WP管理するのがめんどくさくなってしまった。お問い合わせフォームはTayoriというサービスを使っています。

以下、独立に至るまでの経緯を書きましたので、よろしければお付き合い下さい。

独立に至るまでに考えたこと

昨年の今頃から退職は頭にありましたが、次に何をしようと思った時に「これ」というのが浮かなばかった。とりあえず、人に会おう。その中で考えよう。そんな感じで色んな方とランチをご一緒させて頂きながら近況報告をしつつ何をすべきか考えました。

僕がひとりで内製していたこともあり、「業務のわかるエンジニアがいない」という話が特にひっかかりました。

ユーザー企業に対して届けるべき価値は「プログラムをより良く書くこと」ではなく「事業運営に必要なITを提供すること」です。中小企業向けのITシステムは大企業向けの機能縮小版でOK…なんてことはあり得ません。業務の独自性は中小企業のほうが強いのではないかとすら感じます。自社オリジナルの業務を支援する IT を強く求められる傾向があります。

大手は人手でパッケージの隙間を埋められます。中小企業は運用でカバーする(新たに人を雇用する)余裕がありません。ITシステムをわざわざ作ってお金をかけて効率を良くするのに運用の手間がかかるから人を増やせって何事？っていう。

ユーザー企業にエンジニアとして参画する以上、自社オリジナルの業務を支援するITを提供できないと価値が生まれない。でもスクラッチ開発は時間もかかるしリスクが高いしお金もかかる。昨今ではKintoneに代表される「オリジナルのITシステムを可能な限り自動生成を駆使して作ることが出来る仕組み」があります。この辺のサービスをどう活用すればユーザー企業に対する顧問エンジニアをビジネスに出来るのか。

自分がそれをやることで食えるのかどうか確かめてみたいと思いながらもイケるという手応えがなかったので、二の足を踏んでいました。

ルート42株式会社 さんとの出会い

「オリジナルのITシステムを可能な限り自動生成を駆使して作ることが出来る仕組み」でSIやればいいじゃんという内容でブログを書いたら、ルート42株式会社の高橋さんから「ウチはまさしくそれでSIやってます」という連絡を頂きました。え？いるのそんなひと？というのが正直な感想でした。

お話をお伺いしてデモを拝見した所、スクラッチで作ったら億クラスの複雑な業務システムが動いてる。案件をこなして自動生成の仕組みをブラッシュアップしていくうちにここまで来ました、と。

興味があるならウチの仕事をお手伝いして頂けませんかというお話を頂いたので、やりまーすと回答してスタートしたのが昨年12月。お手伝いをしているうちに「これはすごい。新しいSIビジネスが出来る。」という確信が芽生えた。協業させて頂くことで自分のテーマであるユーザー企業の顧問エンジニアに挑戦する素地ができるし、SIは好きなのでやれるだけやっていきたい。色んな仕事ができる道が開けたので独立する決心がつきました。

SIはどんどん自動化されていく

この流れが加速することはあっても、退化することはない。AWSがインフラの構築から始まりそれらを統合的に管理できるプラットフォームへ進化しました。ビジネスアプリケーションの領域も侵食されていくと睨んでいます。

企業が最大限にIT活用をするためには、自分の袖にあったITがベスト。その袖に合わせる作業が大変なわけですが、大変なままであってもいけないと思います。困難な作業ですが、PaaSサービスもこれからもっと進化していくはず。弥◯会計がAWSで動いてそれをlambdaで操作できる時代にならんかな。AWSがlambdaの更に上のレイヤーに行ってPaaSのサービス作るかもしれないし。

先日ブログで「これからは事業会社をIT会社に変革していくのがSIerのミッション」と書きました。

gothedistance.hatenadiary.jp

まずはひとりからのスタートですがこのミッションをクリアできるよう頑張ります。

今後とも、よろしくお願い致します。よろしければ、弊社のWebサイトをご高覧下さい。

quality-start.in

事業会社をIT会社に転生させることが、これからのSIerのミッション

言いたいことがストレートに伝わる良い文章だと思います。

simplearchitect.hatenablog.com

ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。

では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。

確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？

僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエアを作ることがゴールになっている以上、スコープを破綻させることはできない。納期決まってるし、とにかく終わらせないと。検収して頂かないと請求できない。 完成することが基準で対価を頂戴しているわけですから。

ここを無視して方法論の是非の議論を重ねても、意味無いでしょ。ここに切り込んで一括請負じゃなくてエンジニアと二人三脚でアジャイルだよねって実際にやっているのって、倉貫さんぐらいじゃないでしょうか。他に続いた人を知りません。それほどに難しい問いだという理解をしています。

一括請負でギチギチにやるのはお互い不幸なのはよくわかる。それをやる体力もなければ、積んだ工数の金額を出しても通用しない。なので、SIerがそのやり方をみんな辞めたと仮定しよう。請負しないんだから、委任になります。顧客のIT部門に入り込んでその立場で仕事をするのが、主流となる。仮想的な内製部隊として機能していく。こうなりますわな。

嫌なこと言いますけど、上流と下流が分断しているのがSI業界の最もあかん所でかつそれが主流なので、一括請負辞めたら外注管理しか出来ない会社と下請け仕事しか出来ない会社が出来上がって誰得だよねってことになりませんかね？ そんな心配は杞憂ですかね。僕はかなり心配なんですが。

「ウチは一切の請負はしなくて、業務委託でイケてるエンジニアを貸し出します。御社の事業にコミットして、モノも作れますから。毎月XX円お支払ください。」と言われて「なるほど、確かにそれがベストだね！アジャイルにやろう！」 ってなるのかなぁ。 顧客はそれについてこれるのか。 全ての舵取りを顧客に委ねるのが正しいのか。どう説明してご理解を頂くのかイメージが湧かないけど、それしか無いならしょうがないのかな。

これからは事業会社もIT会社になる時代であって欲しい。そうなれと思う。ITを武器にして競争優位を勝ち取って頂けるなら本当に喜ばしい。でも、その為の受け皿にヒビが入りまくっているのではないか。事業会社をIT会社へ変革する為に、SIerとしてできることはなんなのか。それをやるのがSIerじゃないなら、誰になるのか。担い手が変わるのであれば、どう寄り添っていけば良いのか。

こういう議論の先にあるのが、SIの未来ではないのでしょうか。

「事業会社をIT会社に転生させるのが、これからのSIerのミッションだ」という前提に立った議論をしたいので、今後はその目線で記事を書いていきたいと思っております。

【書評】ワークスタイル・パラダイムシフト~「シェアード社員」という選択~

ユナイトアンドグロウ株式会社、取締役高井様よりご恵投頂きました。

ワークスタイル・パラダイムシフト ~会社にぶら下がらない生き方を叶える「レンタル社員」という選択~

弊ブログをご覧頂きご連絡を頂戴して、中小企業のIT活用について意見交換を行いました。非常にユニークな仕組みで中小企業のIT活用を支援されている会社さんです。

www.ug-inc.net

シェアード社員 is 何

「シェアード社員」という働き方を提案しており、それはなんぞやというのが本書の主題です。

正社員として雇用して顧客の現場で仕事をする。複数の現場を担当することもある。でも、派遣社員ではない。仕事の裁量は自分で決定できるから。でも、コンサルタントではない。実際に手を動かして顧客企業の事業運営にコミットするから。

これだけ聞くと無限に働くんですか？という感じですが、過度な労働にならないよう時間単位で契約できるようになっており、社員の労働環境を契約で守る仕組みがあるようです。良い仕組みだと思います。外部の人間が会社の経営の立場になって、現場に入り込んで改善してくれたら最高です。それをやるにはコンサルや派遣社員という形態では上手く行かない。そういう背景があってのシェアード社員であると書かれております。

中小企業のIT活用の課題はやはり人材不足

ITエンジニアとして高い能力を持っている人が、ユーザー企業に飛び込むケースはまだまだ少ない。居場所を作る努力もしなくてはならないので。ユーザー企業は自社の事業運営に貢献してくれるITのあり方を共に考えてくれる人材を渇望している。そこを埋める人材は、どうやったら育つのか。手に入れることができるのか。

僕の答えは簡単で、手段はなんでもいいから自前でITシステムを用意して仕事をする、です。それが一番。自前で用意と言っているのは、自分達で修正ができなければならないということ。ベンダーに投げたら何にも身につきません。自分でデザインしてそれを使って仕事をするから、事業運営に貢献できるITシステムに必要なことがわかります。学ばなあかんのはココ。

スクラッチで作るのは難しいですけど、色んなITサービスがある昨今です。ビジネスアプリケーションの領域も幅広い選択肢が出てきました。小さな所から始めて欲しいと思います。

中小企業のIT活用を支援したくても、それを仕事にするのはかなり難しいです。開発だけやればいいってことは絶対ない。制約も多い。雇いたくても明確な職務記述を書くのは難しい。複合的な能力が求められるので、難しい仕事だと僕は思っています。

どんな形であれ経営に資するIT部門であることが重要なので、ユナイトアンドグロウ様には期待しております。ITProで無能とDISられることが多いIT部門を、皆様のお力で有能にしてください。事業運営やオペレーションによってついた差って、大きいんですよ。目に見えないノウハウはそう簡単には盗めませんから。

ワークスタイル・パラダイムシフト ~会社にぶら下がらない生き方を叶える「レンタル社員」という選択~

2017.09.04 修正

ユナイト・アンド・グロウ様よりご連絡があり、2017年9月からレンタル社員という呼称がシェアード社員に変更になりました。
その為、レンタル社員→シェアード社員に文言を修正致しました。

4年に1度だけ訪れる結婚記念日

あれから4年か。人生は短い。

gothedistance.hatenadiary.jp

盟友のタケルンバ卿も、本当に何の口裏合わせもしてないのに同じ日に結婚して、同じく4年に1度の結婚記念日を迎えた。おめでとうございます！

lord.takerunba.com

奥さんに出会えたことを、改めて嬉しく感じられる日が、結婚記念日。毎年そういられるよう、努力します。大好きなので。

僕は妻のための仕事って思ったことはないけど、家族を不安にさせるような仕事ではあかんし、僕がつまんなそーに仕事してたらアレなので、いつだってリスク背負って立ってGot to go my wayで頑張ります。

まなめも結婚したそうだし、はてなクールボーイズで同窓会やろうね。

クラウドワークスで月収20万超え、わずか111名。働き方革命の未来はどこにある？

元ネタはこちらのTweet。

クラウドワークスは登録数80万人で二十万円以上稼ぐのは111人。ということは0.0138％。ネットでみつける在宅の仕事で生きていくのは甘い考えだよ。と社会の厳しさを教えてくれるデータ。。 pic.twitter.com/KWpHwBVcKy

— Kabu Berry (yama) (@nagoya_kabuoff) 2016年2月21日

公式資料かどうかを確認すべく、クラウドワークスさんの決算説明資料のWebページをチェック、当該Tweetで掲載されている画像の資料は、
2016年9月期　第1四半期決算説明資料(PDF)に掲載されているもので、公式の見解ということになります。

働き方はやっぱり正社員がNo.1

正社員という雇用形態が崩壊に向かい非正規雇用者が増えている中で、正社員でないと社会的信用や経済基盤等が損なわれてしまう。雇用にも限界があるわけだから、「個人」に対して仕事を供給して実績と信用を構築・適用できるプラットフォームがあれば、新しい雇用形態が生まれて個人も企業もWin-Winになる。ザックリとしていますが、クラウドワークスさんが目指している姿はそういう社会像だと認識しています。

で、その未来像を目指し着実にユーザーとクライアント企業を増やした帰結を端的に示しているのが、このページです。

数年の運営を経て得られた帰結は、「登録ユーザー80万人に対し、月収20万に到達する方は110人程度」でした。110名の90%はITエンジニア/Web制作 or デザイナーで占められており、クラウドソーシング関係なくある程度の収入は確保できる方々です。発注者が個人にマウントを取り、お小遣い稼ぎでも良いと割りきっている方を都合よく使っているイメージが拭えません。お小遣い稼ぎならば、クラウドワークスで仕事を請けるよりもメルカリのほうが効率が良くリスクもないので、そちらのほうが...と思ってしまう。

働き方として確立するためには安定性が最も重要な要素ですが、クラウドワークスさんのIR資料から際立って見えてくるのは、「企業組織と個人の関係は、やっぱり正社員がNo.1」という皮肉な示唆のように見受けられます。

今後の成長にも疑問符

さっきリンクを張ったPDFに書かれているPLの報告です。

1Qで10億の売上に対し、営業利益は△1.17億で赤字。通年は単純に4倍の40億の売上に対し営業費用の増加を見込み、営業赤字は△8.5億に膨らむ見通しです。

収入源は成果報酬型(契約額の何%かを貰う)モデルなので、これを拡大するために「ユーザーを増やす」か「単価を上げる」の２つの策が取れます。でも、月収20万超えが110人ですから契約単価の向上を見込むのは難しそうです。これを数万人に出来るんでしょうか。「個人」では限界があるように感じます。月収の高い人が増えてくればクラウドワークスで自分が取ったクラウドワークスの仕事を回すというロックな事案が増えそう。あれ？ 元請けが下請けにマージン抜いて丸投げするアレじゃないですか？ まじかよ〜。

ユーザー数を伸ばしましょうといっても、ユーザーが増えればサポートに関する諸業務が増えてしまう為に営業費用が嵩みます。オートメーションは無理がある。単純な物品の売買じゃないから。現在80万人のユーザーがいるそうですが、仮に200万ユーザーになったとしても成約額が小さいなら赤字体質の脱却は難しい。個人で請けられる仕事は、たかが知れていますから。売上40億で8.5億の赤字って結構辛い数字です。

ただ、「クラウドソーシングで武者修行をすることで、形を変えたOJTとして機能させることにより、人材紹介・教育研修の受け皿としてトータルなキャリアサポートを実現する」企業となり、そこで輩出した人材の能力が高く評価されるようなサイクルが出来上がってくるのであれば、働き方革命の幕開けかもしれません。新卒一括採用というスキームを形骸化させ、誰にでもセカンドチャンスを与える、と。

本資料からは「滅茶苦茶ユーザーを増やせばいつかはペイするンゴ」以上の戦略を読み取ることが出来ませんでした。まだ始まったばかりですから、5年後には僕が赤っ恥をかいているかもしれません。今後の成長を注視したいです。

【書評】システムインテグレーション再生の戦略

技術評論社、傅さんよりご恵投頂きました。システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?の続編という位置づけです。

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

本書は全体的に横文字が多く拡散的になっていますが、方向性を指し示すのが目的ですのでこんなもんかなと思います。「これしかありません」という話はできないですから、色んなヒントを得られるように構成されています。

工数積算やめてどうするの？

ポストSIビジネスというものに問われているのは、「工数積算を辞めて何をしたらええねん？」が主たるものです。ポストSIビジネスモデルとして合計12個のモデルが提示されていますが、切り口が違うだけで提示されているメタ視点は実は同じではないか、と。それが下記です。

「工数積算をやめる為には、納品までのスピードを”圧倒的に”速くするしかない。速くするにはスクラッチ開発を減らしてメニュー化する(or 自動生成する)しかない」

工数積算で3000万じゃペイしないとしたら、まず3000万を下げる必要がある。仮に1500万としましょう。半額にしてもエンジニアの人件は同じように発生する。でも工数は圧縮しなければならない。スピードを上げて単価を下げるためには、クラウドなのかPaaSなのかわかりませんがスクラッチ開発を可能な限り極小化してメニュー化するしか無く、「どこでメニュー化するのか」が切り口として違うだけ、という見方をしました。

お金をもらうスキームは、月額定額 / 買い切り/ 成果報酬などがありますが、どの選択肢を選んでも額は下がる。期間を短縮すると「そんなに速く出来るのに、この値段って高くない？」が絶対に前に来ます。技術的価値を正しく理解しろって言っても無駄。殆どの人は真価に興味はなく、ボリュームで判断するしかありません。速くすれば単価は絶対に下がりますから、数を叩くしか無いです。

アジャイルで請負開発ねぇ...

いい加減にしてくれませんかね、これ。前作の崩壊編でも未来図のひとつとしてこの話が乗ってたんですけど、地雷の可能性がとても高い。

本書では「納期と工数と金額をあらかじめ確定させ、その範囲でビジネス目的達成における重要度から開発対象となるビジネスプロセスの優先度を決定し、順次開発する。その期間で優先度が変わっても、着手されていないプロセスの開発順序が変更できるので、変更への柔軟性を担保できる。」のがアジャイル型請負開発の概要として書かれています。100pです。

・・・これ、まんまウォーターフォールじゃん？ どこがアジャイルなの？ 営業の手の平かな？

優先度が変わっても別の機能を作ればいいって、クリティカルパスが死んでるのに枝葉埋めてデスマになる絵しか浮かばない。寒気がする。

納期・工数・金額が決まってるなら「コレ以外やりません」or「多少のブレを見越して、リスクバッファーを積んでカネを取る」しか身を守る術はないの。ビジネス価値を正しく見極めるためのアジャイル。わかる。でも、その価値はコードを書いてから「これじゃない」とブレていくのが肝。決めた内容を作ることに成果責任を問われる以上、それを守るのが最優先になるって。ウチはアジャイル開発が得意なので開発の順序は優先度や内容については変更が効くようになってます、アジャイル開発だからご安心ください的な営業トークは、もう完全にホラー映画の世界。

このモデルを推すのであれば実際にこのモデルで成果を出している会社の事例をビシっと書いて欲しいです。請負が求められないとは言いませんが、本書のはじめに一括請負は構造的欠陥を生み出す的な文脈で書いてあるのに、なんでアジャイルで請負はOKになるのか僕にはわからなかった。ユーザーが本当に必要なものを作ることがどれだけ難しいか、考えてほしいものです。

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

本書に書かれているように新しい動きは確実に始まっています。ざっと現状を整理し、長期的な流れがどうなっていくのかを考える為に本書を当たるのは、もちろんアリです。

アジャイル請負だけは賛同できないけど。

地方のIT業界に必要な顧問エンジニアというモデルを考えてみた

facebookに流れてきたこのエントリ、衝撃的な内容でした。

risingsun-system.biz

技術者と会話が成立しない

うわっ・・・となった。

こちらのお客様は、過去何度も地元のソフトウェア開発会社に仕事を頼もうと、いろんな会社とコンタクトを取られたといいます。しかし残念ながら、どの会社とも取引にいたることはありませんでした。

理由は様々ありますが、煎じて詰めると「技術者と会話が成立しない」ということでした。

自分の住みたい地方のIT業界をより良くするために必要な構造変革とは？

「業務がわかるエンジニアがいない」→「地方のユーザー企業から元請けの仕事を取れない」→「大手の下請けに入る」→「地元で業務が設計できて実装まで行えるエンジニアが育たない」→「業務がわか(ry」のループに入っている様子が鮮明に見えちゃいました。上記のエントリを書いた方は長野県の方ですが、どの県でも同じようなものでしょう。

中小企業向けのSIが成り立たないワケ

この手の話になると「下請けだからアカンねん」と必ず言われますが、そう簡単に辞められるワケがない。非常に難しいと見ています。やりたくてやってるんじゃなくて、対価が下がる中で重層構造になったんですよ。建築業と同じ理屈です。

こちらの調査を御覧ください。

itpro.nikkeibp.co.jp

記事によれば、平均で年商の0.75%しかIT予算を割いていないとあります。年商が100億以上の会社が母数の半分を占めているのがポイントで、年商10億未満に限定すれば「OfficeソフトとスタンドアロンのXX販売のみ」みたいな会社もわんさかいると思われます。

仮に年商3億の企業の場合、3億の0.75%は225万円。「年間」ですからね。年間で225万の予算しかない所に人月80万で見積もりしますと言っても「は？」ってなるので、スクラッチはまず無理。パッケージやSaaSの導入支援しかないけど、それだけでは全然儲からない。なので、カスタマイズをして売上を獲得しようとするけれど、今度は手離れが悪くなって利益率が悪化するので痛し痒し。中小企業は大手よりも現場が強いから、カスタマイズ要求も熾烈になりやすい。

・・・大手の傘の下で仕事を請けるしかないじゃん？

苦労して利益が少ない導入支援案件を回すより、効率もいいし納品におけるリスクも少ない。大手のしわ寄せを食らうという別次元のリスクは残ってるけど。

どうすれば地方のITビジネスが蘇るのか

まとめちゃうと、人月積算が通用しないけど単なるパッケージ導入じゃ意味が無いという状況だと睨んでいます。なので下請けに入らざるをえない。人月積算でオッケーだから。

仮にコレが正しいすると、打破するには「要件定義はしっかりやって、開発はPaaSを使って瞬殺する」しかないのではと考えています。そういうことをやる人をモデル化したのが下記の資料です。

顧問エンジニアというロールを作りたい from Michitaka Yumoto

www.slideshare.net

ITの相談相手にめぐりあえて自社のプラントとなるIT像が描けても、開発に何ヶ月もかけていたら中小企業には響かない。中小企業はカネも時間もないの。大手より条件は厳しい。PaaSならすぐデプロイ出来る。また、実装コードが人に依存しないので、ツールの使い方を覚えればある程度のことが誰でも出来る。ノウハウが溜まりやすい。WordPressの感覚で業務システムが組めるようになる時代は、もう来ていると思う。

今の時代はLAN前提のパッケージを導入するよりPaaSサービスを活用するほうが安いので、顧客と「対話」をして最適なITをキチッと落とし込んで、これだけのビジネス上の価値が生まれるよというイメージをしっかり共有する。

どれだけIT予算が渋い中小企業も、100万なら出します。アルバイトを1人年間で雇うのと同じだから。パッケージを入れてもその隙間を埋めるのに人が必要ならバイトを入れるのと大差がないですが、バイトを入れて回すほうがITを導入するより安上がりで確実だと考えているしゃちょーさんがとても多い。知らないからね、ITのツボを。エンジニアとしては看破できないし、マンパワーに頼るのはブラックの始まり。なんとかしたい。

仮に100万で考えると、要件定義フェーズは3回打ち合わせして50万。構築はPaaSを使い、ユーザー企業の担当者を教育しながら月額数万円で顧問ビジネスを行う。この値段感で勝負するしか無いと思う。

こんなビジネスを既に人月で食ってる組織が請け負えるわけがないので、僕のように事業会社にいるとか一人親方エンジニア等が中心となるでしょう。スケールすることはありませんが、会計士に代表される「士ビジネス」と同じ形を取れたら裾野が広がる。地方のITエンジニアが地方のユーザー企業の経営に資するITを提供できるようになれば、少しづつ流れが変わるはずです。

・・え？？？

そこまでビジョン見えてるなら、その顧問エンジニアというビジネスをやってくれ？

安心してください、着々と準備を進めていますよ！

昨年末に１件ゲットしております。３月頃から弊社の取引先を中心にウチの社長に本格的に営業に行ってもらうよう手筈を整えてございます。窓口を作る能力は本当にすごい、弊社の社長。天才だと思う。窓口さえ作って頂ければ、後は僕の腕の見せ所。手応えはありますので、今しばらくお待ちください。

出来ない人のレベルに合わせてはいけない

あるあるネタだと思いますが、組織がより優れたパフォーマンスを出す為にやっちゃいけないことが「出来る人とできない人がいた場合、出来ない人のためにレベルを下げること」です。

優れた解決策を持ってる人に合わせよう

コードのバージョン管理で、出来へん人が「あの僕はGit使えないんでZIPで差分管理して欲しい」とか言い出した時に「そうだね！出来ない人に合わせないとね！」とはならず「Git覚えて」となるでしょ。優れた解決策を持ってる人が、結局は出来ない人を助けている。わかりやすいでしょ。

— やきう大好きござ先輩 (@gothedistance) 2015, 12月 24

簡単にいえば「↑」のようなことです。非エンジニアの方にはわかりにくい例ですが、Excelをファイル名＋日付＋バージョン名で複製して管理するのはとても大変ですよね。そんなことをしなくても良いツールがあるんです。それを使える人がいるのであれば、皆がそれを最低限使えるように努力すれば良い。できる人のレベルまでたどり着けではなく、できる人の邪魔をしないレベルまで下駄を履かせることにすごく意味があります。

昔、なんかの記事でExcelで手計算しているシートをマクロか計算式を組んで簡単にしたら怒られたみたいな話を読みました。ソースはごめんなさい、忘れました。が、Excelというツールを高いレベルで使いこなせる人が皆さんが苦労しないように「ひとつ上」のステージに上がれるよう腐心したのが怒られる理由が、ちょっとわかりませんでした。

出来ないひとに迎合した場合は、ずっと「ファイル名＋日付＋バージョン名」で差分管理をすることになる。Excelの手計算を続けなくてはならない。やらなくても良い作業をやらねばならず、何も生み出していない作業に時間が食われる。「みんなで頑張ってます」といえば聞こえはいいのでしょうが、出来る人はできない人の為に足を引っ張られて、ひとつ上のステージに行けるチャンスを逸している。恐ろしい話。

出来ない人に合わせていたら、誰も幸せになりません。できる人の邪魔をしないこと、阻害をしないことが、翻ってみんなの為になる。ExcelマクロでもGitでも同じことで、そのような優れた解決策があれば、出来ない人でも有る一定の質の成果が出る状況を作ってくれるので、会社を経営する立場からすればこれほどありがたいことは無い。

頑張ってもしょうがないこともある

僕、頑張るって言葉あまり好きじゃないです。努力するしか無いわけですけど、優れた解決策に迎合する努力をしないで、ただ目の前のことを頑張っているというのは、全員が不幸になる恐れがあります。ボトルネックを解消せず、ボトルネックをそのままにしておいて皆で頑張りましょう的な考え方は、大変危険です。誰も幸せになりませんから。頑張らなくても良いことに全力で努力しても...ねぇ。僕はエンジニアなので、余計にその思いが強くあります。

人の頑張りというボトルネックを解消しよう

ボトルネックが生まれるのは、その作業が自動化(仕組みとして整備されていないという意味で)出来ていないことが多いです。差分管理もそうですし、手集計もそうですよね。優れた解決策を持っている人がいるのに、それを「出来ない人がいるから」という理由で捨てるのだけは、本当にやめて頂きたい。生産性が上がらない→休みたくても休めないような状況に追い込まれる→疲弊する→優秀な人がやめる→生産性が(ry のループに入ったら終わり。

「出来ない人に迎合したら終わり」→「出来る人はあんだけ努力してるのに何なの」という個人の自助努力を批判する方向に行くケースもあって、これが最悪。生産性を上げるのに努力は不要です。そのやり方に従っていれば、誰でも一定の成果が上がることを生産性が向上したと言えるのであって、人が頑張ってパフォーマンスを上げているのは、俯瞰して見るとボトルネックでしかありません。その頑張りに依存しているのだから、大変なリスクです。

人の頑張りというボトルネックをコードで解決するエンジニアを頼って、みんなで休みを取りましょう！マジでそう思います！！

【書評】お金をドブに捨てないシステム開発の教科書

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

お金をドブに捨てないシステム開発の教科書 ~なぜ、要件定義がうまくいっても使えないシステムができてしまうのか?

本書は公認会計士でありながらシステムコンサルタントをされている中川さんが、システム構想づくりの重要性をじっくりと説く一冊になっています。そう簡単に出来ることではないので「経営・会計・業務・システム」の4つの視点に分けて考えるべきと説いております。詳しい目次はこちらの著者の方の会計事務所のWebサイトにあります。

nakagawa-cpa.jp

本書で挙げられているメッセージは僕の中で違和感が多かったので、書評の内容も「なんでそういう説明になるのかな」という話が中心となります。

構想づくりの大切さを説く「なぜ」が弱すぎる

僕が感じた、本書の最大の不満がこれです。20pの1ページしか、何故システム構想が大切なのかが書かれておりません。システム構想づくりの大切さを説く本のはずなのに、「経営者の決意の重さをこめろ」とか「何故システム構想が難しいのか→ビジネスが多様化しているから」という論理展開は雑です。教科書と謳う以上は、もっと詰めて説明して欲しい。

例えば、経営者の決意をどれだけ込めようが、しょうもない設計書からはしょうもないシステムが出来るので絶対に辞めろ。これが教科書に書くべきことですよ。マジで。

4つの視点を集約しましょうという構成ですが、一読してもう一度頭から読み返すと一体何が大切だったんだっけかなぁとわからなくなりました。視点を切り替えて語ることは必要なことですが、構想を語る為の最終的なドキュメントは下記の構成物で構成され、こういう手順でしっかり詰めましょう、という構成が良かったんじゃないかなぁと思います。会計システムと販売管理システムでは検討事項が異なりますが、本書ではそれを包括的に教科書としてまとめようと腐心されたのでしょうけど、システム開発は暗黙知が多いので大変難しいことだと改めて感じた次第です。

僕が考えるITでお金をドブに捨てない方法

この３つだけ、最低限考えましょう。

• 経営者の思いは適当に受け流せ。
• 自分の仕事の判断基準を全て書き下ろし、ボトルネックを潰せ。
• いきなり作るな。ASPで代替出来ないかを常に検討しろ。

経営者の思い。重要ですよね。プロジェクトの本気度を図る指標としては有用ですが、システム構想には不要なこともあります思いが間違ってることも多いです。僕は自社で内製しましたが、経営者の思いを全く汲んでおりません。聞くだけ無駄でした。やりたい事とやらなくちゃいけない事は、全く別なんです。詳しくは下記をご覧ください。

gothedistance.hatenadiary.jp

業務の洗い出しが重要だ〜とよく言いますが、その8割ぐらいは「で、あなたはその仕事を終える為にどんなことを判断してるの」で説明ができます。判断基準がわかれば、完了基準も例外となることもわかります。そうすれば、業務担当者のボトルネックを見つけてその原因となる構造がどうなっているのか、議論ができます。まずはここを潰さなければ。使う人に使う意味がなければならず、その意味が経営に資するかどうかは、また一つ上の議論です。

ボトルネックの兆候としては、ミスが多い・確認が多い... など。ボトルネックになるのは個人の問題ではなく、組織運営の問題です。その問題が生まれてしまう構造をAs-Isを分析しましょう。その精度が低いと、どうしようもないToBeが出てきてしまいます。新規事業等でAsIsが存在しない場合はToBeから描くしか無いので、余計に難しくなります。

で、最後に。構想を練って業務プロセスを描いて、こういうオペレーションが出来れば改革ができるという段階になって、次に検討すべきはASP等のサービスの活用です。出来合いのもので済ませることが出来るのか出来ないのかを、じっくり吟味する必要があります。昨日の記事で「プラント型ITの構築は企業競争力の優劣の鍵」と書きましたが、中小企業においてはいくらその部分を強化しても無駄なので月3000円払って借りてくるのが最適解であるケースもあります。最終的に業務と業務を繋ぐ血管を作るためにプラント型ITが必要になるとは思いますが、まだその段階まで至っていないケースもありますから。特に新規性が高い業務の場合は。

みなさんのシステム開発が実り多きものであることを祈ります。

お金をドブに捨てないシステム開発の教科書 ~なぜ、要件定義がうまくいっても使えないシステムができてしまうのか?