GoTheDistance

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

ITプランナーという職種を確立させたい

先日のDXの時代に関する記事を書いている中で特に感じていたのは、コーディングではなくプランニングに比重を起きつつエンジニアと議論できる人材が必要だということ。プロダクトマネージャというわけでもなく、もう少し守備範囲が広い人。そういった職種を定義したいなと思っており、IT企画というテーマで勉強会をやったりしたんですけど、既に職種化されている記事があって興奮しました。

hatenanews.com

ITプランナーの仕事内容メモ

上記の記事を読んだ私のメモです。

  • ITプランナーは、エンジニアのチームとともにプロダクトを企画開発し、リクルートの商品として世の中に出していくのが仕事
  • 「What(何をやるか)」を重点的に考えるが、エンジニアと同じ土俵で議論をすることが求められる
  • ワイヤーフレームまではITプランナー側で作り、ER図はエンジニアが作る
  • ITプランナーでSQLを書けない人はいない
  • クライアントの業務の課題などから一歩引いて抽象化したプロダクトを作り何が「提供価値」で、どうやったら儲かるかを考える

僕が考えているIT企画を行うポジションの仕事内容に極めて近い。やはり先駆者はいた。

リクルート社の場合は売上拡大がミッションでのITプランナーなので、儲かるサービスをどう作るかになるけれど、業務改善・効率化・コスト削減・事業開発など、色んな背景が本来あると思う。が、「一歩引いて抽象化したプロダクトをデザインする」という、ITプランナーのミッションは変わらないはず。

ITプランナーは複数のロールを持っている

上記記事のこちらの画像が極めてわかりやすいので、貼らせて頂きます。

https://cdn-ak.f.st-hatena.com/images/fotolife/h/hatenanews/20180914/20180914170119.jpg
技術とビジネスのハブになる! プロダクト開発のためにエンジニアとガチで議論するリクルートコミュニケーションズのITプランナーの役割とは - はてなニュースより

これらが絡み合うのが難しいけど面白いのが、ITプランナーという職種だと思います。全部に秀でるのは無理ゲーですけど、どれもこれもバランスよくスキルを併せ持つのは、これはこれで価値がある。このプランニングを行う人は、受託開発の現場でも、事業会社の現場でも、絶対に必要だと思う。経営と開発現場とユーザーの間に立てるのは、このITプランナーという人たちしかいないはずなので。

ITプランナーという職種を確立したい

f:id:gothedistance:20190311174429p:plain

ユーザーとシステム屋の間に立って、適切なITシステムのプランニングやプロジェクト立ち上げを専門にやっていくプロを新しい職種として定義したい。

ITコンサルタントだと、抽象的な言葉が続きすぎてよくわからない。「先生」的な立ち位置のイメージが強いのも好きじゃなかった。IT企画って要はITプロジェクトの立ち上げだから、専門性を生かして企画立案を行う職種であるプランナーが最もイメージに合うし、プランナーという言葉は市民権を得ている。我が意を得たり、という感じです。

ちなみに、上記の記事でも私と同様に「以前はコードを書いていたが、エンジニアリングの道では大成できないと認識してITプランナーになった」という方がいらして、非常によく分かる次第でございます。

私は今でもコードを書いています。主には昔作った販売管理システムのリプレイスをするためですが、それがなくても何かしらはやります。プログラミングは筋トレと一緒なので、やらないと維持できない。ただ、これ以上に技術の筋肉がつくかといえば無理だし、選手として1軍でプレーできる自信はないが、プログラムを書くための脳内筋肉がダルンダルンにはしたくなくて...。ふつーのコードが書ける人間ではありたい。

ITプランナーって要件定義を行う人と何が違うのって話は、守備範囲の違い。要件定義というのはあくまでHowを決めるもの。どうやってソフトウェアを作ろうかという話。でも、プランニングというのは何を何のためにどういう手段で作るのかを検討するWhatとWhyの話。ただ、WhatとHowが分断すると誰一人幸せにならないので、ITプランナーがそこをつなぐ。

WhatとHowは車の両輪で、特にソフトウェアはHowの比重がとても高い。無形の成果物だから。ツール買えばOKという話でもない上に、一般の方から見れば「どんだけ細かいんだよ」ってうんざりするような細部の詰めを綿密にやらないといけない。綿密さをどこまでITプランナーに求めるべきかという議論はあるんですけど、プログラマのキャリアチェンジの方向性としても親和性が高いはず。全員が全員、テックリードというポジションに就けるとは思えなくて。

ITプランナーのスキルセット

ビジネス寄りのスキルセットを上げるとキリがないと思うので、IT技術のスキルだけ。プランナーとして必須なのはSQLが書けること及びER図を読んで理解できること、だと思う。データモデリングができればなおよし。仕様を作るのはエンジニアとしても、UIから送られてきたデータをどうやって保存するかの議論が出来ないと困る。

ちなみに、SQLはある意味で最もわかりやすいプログラミング言語。宣言型だから。プログラムを読み解く難しさは処理内容をつなげていってストーリーを把握して業務仕様を把握することだけど、SQLは宣言文そのものが仕様で実行結果も2次元表しか返さない。全体を俯瞰するコストが低い上に、文章としてなんとな〜く意味が通るから覚えやすいと思います。

ITエンジニアがITプランナーになるパスもあれば、ビジネス側がITプランナーになるパスもあって然るべきで。でも、後者はどこまでIT武装できればいいのかという程度問題があると思っています。どうなんでしょう?

勢いでITプランナーのSlack作りました

こんな感じの議論がしたくて、ITプランナーに興味がある人集まれ的なSlack作りました。

https://join.slack.com/t/it-planner/shared_invite/enQtNTY1NTY3MzI4NjMxLWRkNTBjMzhlNjgzNjg4ZTEzZDkxNDkyNzI2ZGE0ZDVkNzc2MTZkZmJlZDIxOWU5ZmZlN2Y4ODI5NmQ1YTI3ZWE

上記のURLを踏んで頂ければ。ITプランナーSlackへの招待リンクです。

今の所メリットとしては、僕の書いたIT企画方法論の草稿(DropboxPaperで書きました)が読めることぐらいですが、ITプランナーという職種に興味のある方で、雑談でもしましょう。20人ぐらい集まったら、4月の何処かで飲み会でもしましょう。お待ちしておりますー。

DXの時代なるものは当分来ないから安心して下さい

展望2020年のIT企業というシリーズ企画の記事を、たまたまTwitterで見かけました。

japan.zdnet.com

この記事で語られるDX(デジタルトランスフォーメーション)ってものすごいオワコン臭で衝撃を受けました。汎用機をお守りする時代は終わった、これからはオープンなWeb技術を駆使して基幹システムではなく顧客の売上を支えるITを作るのだ、SO!それが!DX時代! みたいなノリで書いてあって、1ミリも次世代感が無い。

生きている時間軸が違うんだなと思いました。

DXの妨げは社内システムにあるらしい

色んな定義をされているDXですが、ここでは経済産業省の提唱する「DXレポート」のサマリー版に書いてある問題点とDX推進のためのシナリオみたいなのを引き合いに出します。

DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~(METI/経済産業省)

簡単に言うとこういう主張です。

  • モバイルやWeb技術を駆使してサービスを作り新事業を立ち上げる。皆がこれをやる時代。それがDX!
  • が、DXの足かせになっているものがある。社内システムだ。地獄でしか無い。
    • 乱立するシステム群によるスパゲティ状態で、全社横断的なデータが取れない
    • 高度なカスタマイズとレガシーな技術を使う為に運用コストが肥大化
    • DX活用のためのデータが一切取れないじゃないか!
  • 既存システムを刷新しその上でクラウドに乗っけてAIとかでいい感じに!

企業の強さはオペレーションによって決まる

この関係性が理解できないと一生DX無理なんで、マジでわかってほしい。

f:id:gothedistance:20190307122855p:plain

どんなにITに金を突っ込んだ所で、現場のオペレーションが変革できなければ意味がないのね。動かないコンピュータの本質はここ。現場が使うのは紙とペンじゃないですよね、何かしらのシステムとそれをサポートするツール。ITを入れるだけ入れてもしょうがなくて、使い方を工夫しないと何にもならない。

この手の話になると、「カスタマイズはもってのほか、色んな会社で使われている効率化がされたパッケージに業務を合わせる、これがベストプラクティス」というクソが出てくるのですが、大きな間違いです。これが出来るのは定型的な業務(総務系)だけ。いい加減に目を覚まして欲しい。

社内システムは業務内容によって決まります。業務は、自社が行う事業によって決まる。事業は需要と顧客によって決まる。つまり「顧客 >> 事業 >> 業務 >> 社内システム」という従属性があるわけ。どの会社でも。

で、事業運営上必要な業務が社内システムになかった時に、「あーうちのITシステムがアホなのはしょうがない。この顧客を取りこぼす、このニーズや売上はいらんわ、それが健全だもんな」という話になるかといえば、なるわけないでしょ。なぜExcelで頑張るのかという理由の9割ぐらいは、ここだと思うよ。

売上を上げるまでのプロセスは、非定型的な業務も多くあるし、顧客や商材によってオペレーションも変わる必要がある。時代が変われば需要が変わって顧客も変わる、それに追従するためのDXではないんですか??

だとしたら、死ぬほど地道にオペレーション設計をするしか無いと思います。サービスや商材はパクれますけど、オペレーションはパクれないんで。自社独自のオペレーションこそ、企業の競争力を生み出す源泉だと僕は信じています。それを支えるためのITをどう作ればいいかという方向で、社内システムのあり方を考えて欲しい・・・!

本当のDXはITありき

僕がDXをやるとすれば、「IT >> 顧客 >> 事業 >> 業務」で考えます。ITありき。え、こんなふうにITを使えばこんなサービスが出来るよねで始まり、ITありきでコンセプトを作って、そのコンセプトにハマるニーズと顧客を作り出して、事業化する。これが本当のDXだと思うんだけど、どうです?

IT企画が出来る人がいないと始まらない

どんなに優秀なエンジニアを抱えていても、どんな価値を提供してかつそれが自社のリソースで実現可能なシステムの形を与えることが出来なければ、意味がない。プロダクト作るのにプロダクトの仕様が決まってなければどうしようもないのと同じで、「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステムの企画立案」ができるIT企画屋さんが、圧倒的に足りていないと思う。業務向けとか個人向けとか関係なくてさ。

その点を無視してCOBOLエンジニアをオープン系に!とか言ってる段階でDXの時代なんて来るわけないので、無関係です。安心してくれ、と。

エンジニアのキャリアチェンジの方向性としても面白いと思っているので、僕はこっち側に仕事内容をシフトしました。仲間が全然いないのでちょっと寂しいですが、この道も面白いと思うのでご一考下さい。

エンジニアがマネージャになることへの憂鬱について

daiksy.hatenablog.jp

既視感があったので反応しちゃう。すげー懐かしいなこの手の話題と思った。

懐かしいと言っているのは、ネット上の議論では誰も肯定的な反応をしていないと思われる「PG→SE→PM」の出世魚キャリアの憂鬱にそっくりだったこと。

技術者とマネージャって職種(ジョブ・ディスクリプション)が全く違うのに、なんでこれが技術者の出世コースになっているのか。でも、ビジネスサイドと話ができるマネージャーは価値高いけど「作りました」ほどわかりやすい評価体系がないし、陸に上がった魚は老害になるんじゃないか・・・みたいな話ですよね。

当時は今ほどITが本業の会社が多くなく、エンジニアの主たる現場は受託開発を中心に行うSIerでした。その内部でも誰もPMになりたがらないのは人材育成上の課題にあげられていた。給料大差ないのに責任は重いので単なる貧乏くじではという風潮でした。

twitter.com

2008年のツイートという所に趣を感じます。

で、2019年のツイートもございます。

問題の構図は変わっていないようです。打つ手が無いもんね。

マネジメントが必要だしビジネスサイドとコミュニケーションをとってチームを率いて行けるマネージャはみんな欲しい。ただ何をどう作るかを判断できる技術力がないと何も出来ないから、まずプログラミングを覚えてもらう。が、陸に上がることを好むエンジニアは非常に少ないので、絶対数が少ない。

この現状認識があっているのであれば、マネジメントを外注することを検討するしか無いのでは? と思います。

僕が考えるマネジメントなるもの

「マネジメント」というやつは企業の中に溶け込んでいくものなで、可視化しにくいと思う。そのチームで、その会社で行っている事業やお仕事そのものが対象になる。薄暗い森のなかにいるようなもので、例えば私にやってくるIT企画的なご相談も、抽象度が高い。プロジェクトを立ち上げたいんだけどどうしていいかわからん、と。何も決めて良いかもわからん、と。

この状態では自分が前に出て手を動かすというよりも、自分の周りの人達とコミュニケーションを取ったり、課題管理をしたり、分かりやすい資料を作ったり、各々の立場に沿った方向性を導き出したりするしかなく、こういうお仕事って定型化するのが困難なので、わかりにくい。

抽象度の高いものを具体的なステップへ落とし込むアプローチを考えること、現場で起こっている不都合な事実を集めて抽象化して、それらのもつ構造や性質を考えてこのアプローチで攻めるべきではみたいな立案をする。僕はこういう事を考えるのが好きですので、苦にならないけど。

正しい方向はどっちなのかを示すのが、一言で言えばマネジメントだと思う。手取り足取りあれやれこーやれってのは、説教でしょ。

こういう仕事であれば外に出せるはず

ソフトウェアを育てていくプロセスは外注によろしくとは言えないから、自社でやるしかない。でも、仕事を円滑に回してチームで結果出す為の仕組みづくりという部分にフォーカスすれば、外に出せると思う。「やっぱエンジニアでよくね?」みたいになる人が多いのであれば、検討の余地はあるはず。実際、自分の周りでもエンジニアの組織づくりやマネジメント系のフリーランスを、何人か知っている。

僕はエンジニアで一本立ちするのはとっくに諦めたので、「エンジニアとしては極めて普通だが、文章を書くのと説明が得意で、企画の立案やロードマップを作ってマネジメントもいける」人材になろうと決めて、その最短ルートが独立だった、という感じです。元々SI時代からPMとかやってて、昔懐かしい「スーツ」の仕事は嫌いじゃないです。やりがいも知ってるし。

まずはディスカッションでもしましょうか

もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistanceの記事を書いた時に、ディスカッションでもしましょうと言ったら結構人が集まった。なので、「受託開発だろうがサービス系だろうが、出世魚のジレンマを解消してエンジニアリングを適切に行うための仕組みづくり」について興味のある人で、意見交換でもやりましょうか。5人ぐらい集まればやるので、Twitterでお気軽にどうぞ。

IT企画をちゃんとやりたい勉強会 Vol.2をやります

前回やらせて頂いたイベントの第2回目です。

gothedistance.hatenadiary.jp

元ネタはこのツイート


ワイワイやろうぜ

ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がおりません。

色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られますし、第1回のイベント開催後に分科会(反省会)を開催されてお招き頂いたこともありました。

私はアジャイルだ滝だDevOpsだという開発方法論よりも、ビジネスサイドのIT企画力をアップさせるために何が必要で、どんなやり方や考え方を持って望めば、失敗を少なくすることができるのだろうかということに強い関心があります。 同じような領域に関心がある方、是非ざっくばらんにコミュニケーションを取りましょう〜。

ご参加はこちらより

connpass.com

もし「フリーランスだけの会社」を作ったらどうなるのか

先日、フリーランスで働いている仕事仲間とランチをした際に、表題のようなテーマで盛り上がりました。私の周りでは同じようなことを考えたことがある方が多いようです。

実際にこんな事をやるという話ではなく、こんな会社を作ってうまくいくのかねぇ... という程度のレベルです。話に上がったことを中心に、まとめてみました。

フリーランスだけの会社とは、どんなものか

一言で言うと正社員という身分ではあるが、会社に縛られることなく各々が自分の事業を行うような会社です。

フリーランスになった人も何人も知っていますが、会社が持っている恩恵は大きいことを充分知っています。端的には、会社の都合が兎にも角にも優先されてしまう硬直さが受け入れ難く結果的にフリーランスになったという人も多くいます。自分で今日の仕事をデザインし、いつ仕事を開始して何を区切りとするのかを、自分で決めることができる「生き甲斐」を求めている人も、たくさんいると思います。

フリーランスだけの会社の場合は、仮に社員になったとしても、会社は何も社員に対してあーしろこーしろとは言いません。銘々が今までと同じように活動するだけです。出退勤もどうぞご自由に。残業も定時もありません。

無視できない法人組織の持つメリット

フリーランスをやってみると改めて身に染みるが、法人組織に所属することのメリットが大きいことです。代表的なものを上げます。

+ 社会保険への加入
+ バックオフィス業務からの開放
+ 法人税・個人事業税からの開放
+ 福利厚生の適用や設備投資

一番大きいのは、健康保険と年金に関することですかね。個人事業主や自営業の場合、国民健康保険国民年金に加入します。国保には扶養という考え方はありませんので、家族がいれば全員分健康保険料を納付する必要があります。正社員であれば、会社が年金と健康保険の半額を負担してくれます。この差は大きいです。他にも労災や失業保険など、社会保険は手厚いサポートがあります。

会社をやってみると社保の会社負担の大きさにビビります。給与の15%程度が国から取られましてそれを会社と社員で折半するわけですが、オーナー企業の社長の場合は全部自己負担です。月収40万だと、年間で150万程度。50万だと180万ぐらいです。昔はいくらだったんでしょうか。高齢大国ニッポンであります。

2018.09.14 追記

給与の15%程度が国から取られましてそれを会社と社員で折半ではなく、会社が給与の15%、個人が給与の15%を折半するでした。ご指摘を頂き、修正しました。

フリーランスの場合は、売上を上げる仕事だけをやればいいというわけではありません。事務作業や確定申告など、色々と七面倒臭い事務作業も自分でやらねばなりません。会社であれば請求書回しておいてねだけで済みますし、源泉徴収によって税申告も原則不要。フリーランスになればバックオフィス業務全てを自分で管理する必要があります。

法人の場合、損益に応じた法人税が待っています。個人事業主の場合は個人事業税です。法人税の税率は30%程度です。消費税よりかなり高い。個人事業税は個人事業主が払う法人税的なものです。税率は5%程度。社員であれば、これらの税金を収める必要もなくなります。

最後に福利厚生です。法人であれば加入できる福利厚生プランや各種サービスはたくさんあります。様々な保険にも入れますし、退職金などの積立も出来ます。個人事業の場合は、小規模企業共済という月額MAX7万円まで積める積立ぐらいしかないです。労働基準法も何もありません。

法人の持っているセーフティネットとしての機能だけをうまいこと享受できないか、そのかわりに自分の食い扶持は自分で稼ぐからという前提での組織運営について、もう少し考えてみます。

フリーランスの延長線上の会社の運営方法

フリーランスで自分で自分の食い扶持を稼げるという前提ですが、以下のようなスキームになると思われます。

+ 売上は会社に入れて、給与や手当という格好で自分の懐へ戻す
+ 社保、福利厚生、退職金、間接業務などの負担として、売上の5%を会社にプールする
+ 諸般の事情で働けなくなった場合、プールしたお金を取り崩してOKとする
+ 売上が増えたら四半期に賞与を出すなどして、適宜調整する
+ 予算管理を厳格に行い、お互いが迷惑をかけないように情報公開を徹底する

会社を運営する立場にたてば、社員を雇用しても自分で自分の食い扶持を稼いでくれる人しかいないので、楽といえば楽。仕事の面倒をみる必要がありません。また、チームで動くことがほとんどないため、休みたい時にまず休めると思います。顧客が納得すれば。

諸般の事情というのは、端的には入院が必要になったとか、お子さんが生まれて育児休暇が必要になったとか、そういう類のものです。

しかし、この自由すぎる形態で企業組織を運営することが本当に出来るのかという不安も多くあります。

運営上に問題になるであろう点

現時点で僕が見えているところは、こんな所です。

+ フリーランスとしての売上が激減した場合に、どうサポートすれば良いのか
+ 経費の多い少ないの按分を考える必要がある
+ 個々人の集合体という組織体で、お互いが信頼しあえる組織になれるのか
+ トラブルがあった時に「会社としての対応」をどう行えばよいのか

一言で言うと、金銭面、健康面、仕事上のトラブルが発生した場合、どうやって責任をとって回していくのかを決めるのがとても大変になるだろう、という話です。

自分で自分の売上を稼ぐ前提とはいえ、良い時もあれば悪い時もあります。そんな中で会社にプールするお金すら稼げない状態になってしまった時に、その人の給与を下げるしか無くなるのでは、と。

会社的には代表取締役を立てる必要がありますけども、あくまで個々人の集合体という前提ですから、その人が他人のビジネスの責任を取るというのは貧乏くじを引くように思えます。でも、仮にその人が仕事上でやらかした場合、顧客に「我々はフリーランスの集まりなんで、社員がやらかしたご迷惑の責任は取りません」とは言えないでしょう。

会社としての筋を通さねばならない局面になった時にどうしたら良いかは、非常に悩ましい問題です。

見込みの売上を達成できそうにない場合、どうサポートしていくのか。給与を下げると決定して良いのか、その場合比率や下げ幅をどう決めていけば良いのか。納得できる形が作れるのか。悩ましいです。自由と責任は表裏一体です。そこをナアナアにしたら、この組織は崩壊すると思います。

経費についても、働き方によってブレがあります。例えば地方在住のフリーランスが車で移動する場合、車を法人で借りてガス代等を経費化するとします。もう一方で、自宅作業がメインのフリーランスの方だとすると、経費の絶対額が違います。売上から経費を引くだけですけど、万が一経費が売上を超えてしまった場合、どういう扱いにすればよいのか。お前のケツまで拭くのは困る、という話になるのか。その点も踏まえて自分の懐に入る給与設定を考える必要がある。

人が増えてしまった場合には、バックオフィス業務をはじめとした組織運営コストが上がる一方なので、取締役になった人が組織運営の責任を負うとしたら本業に負担が出た時に「オレ何やってんのかな〜」みたいな感じになると思います。

グルっと一周回って考えると、フォローアップの仕組みがほとんどないのがこの会社の弱点です。

ご連絡はTwitterまでご自由に〜

こんな会社のあり方に興味があるフリーランスや一人会社の人が5人程度集まったら、どこかで打ち合わせをやりたいと思っています。やるやらないは置いといて、自分の求める働き方にマッチした自由すぎる会社運営のあり方をざっくばらんに議論できたらいいな〜と。 みんなが納得してメリットのある会社が作れたら、本当に良いことだと思うのです。

また、「こういう事昔やったぞ」とか「やってみたけど、こんなダークサイドがあってやる意味なかったわ」とか、そんなお話がございましたら、SNSでお気軽にお声がけください!

twitter.com

それでは、引き続きどうぞよろしくお願い致します。

2018.09.14 10:00 追記

思いの外、多くの方にディスカッションのお申込みがあったので、一旦ここで〆させて頂きます。

「IT企画をちゃんとやりたい勉強会」を開催しました

gothedistance.hatenadiary.jp

ということで、やらせて頂きました。

ガイダンス資料


わいのわいの言える場をつくろう

今回最も重要視したのは、意見交換をする場所を作ることでした。「こういう風に要件定義やればうまくいくよ」みたいなセミナーにはしたくなかった。ビアハッシュでご歓談にしたのも、思いを吐き出せる場にしたかったからです。

私が見る限り、ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がいないように感じています。色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られるのではないか期待していました。エンジニアの方は横のつながりを作る場がたくさんありますが、ITのビジネスサイドになるとその10分の1も無さそうなので、それは不幸なことだなと。このために関西から駆けつけてくださった方もいらっしゃいました。あなたが優勝だ!!!

私のテーブルでは、ITコンサルの方が2名、某自治体の方が1名、メーカー系情シスの方が1名、Webサービス運営の情シスの方が1名という陣容でした。その中で最も深いお悩みを抱えていたメーカー系情シス(レガシーシステムの刷新を行いたいが右も左も分からない的な)の方に対して、残りの全員が全力で案を出し合うという時間になりました。

ITコンサル、システム開発会社、ソリューションベンダー、事業会社の情シスの方、昔の会社の同僚の方(ビビる)... 色んな立場の方が一堂に会する場になって良かったです。楽しい時間でした。

lksdsw.hatenablog.com

上記のガシさんの参加記事も合わせてご参照下さい。

影の主役、イトーキさんのイノーバ

一言で言うと、書ける壁であり机です。こういうグッズが揃っている会場だったので、積極的に使いました。イノーバ面白いです。

これを各グループに配布し、立て掛けタイプも配布しました。書き出せる何かがあると、議論も弾みますね。

www.itoki.jp

次も何かしらやります(多分)

ビアハッシュでご歓談がメインの場ではありますが、ディスカッションについてはもう少しテーマを絞るとか、LT方式でIT企画に纏わる想い/ノウハウ/課題/お悩みを発表してもらう時間を設けるとか、色々や利用はあると思うので、忌憚のないご意見を下さいませ。

また、本イベントを開催するにあたって場所をご提供頂いた、ケンブリッジ・テクノロジー・パートナーズの白川さんと、課題図書3点セットを3部もご提供頂いた羽生章洋さんに、深謝致します。

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

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

はじめよう!  要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

はじめよう! システム設計 ~要件定義のその後に

はじめよう! システム設計 ~要件定義のその後に

それでは!

IT企画をちゃんとやりたい勉強会を開催します

元ネタはこのツイート

かなり伸びてびっくりした。「ありそうでなかった」という点もポイントだったようです。

悩んでいるはずなんですよね・・・!コンサルティングを行う人も、システムを作る人も、エンドユーザーも、情報システム部の方も。

どうやったら良いIT(システム)企画を出来るのかという点については、ずっと頭を悩ましています。システムって「やる前から勝敗が決る」側面が強いですし。


意見交換を出来る場がほしい

僕自身も悩んでいるので、この辺に興味関心がある・問題意識を持っている方々でざっくばらんにビアハッシュ方式で意見交換ができたらいいな〜ということで、イベント立てました。

connpass.com

MAX30名程度で小さく始めて、次回以降どうすべきかを走りながら検討したいと思います。

それでは、皆様にお会いできるのを楽しみにしています。よろしくお願い致します!!

デブサミ2018に、帳票エンジン「Docurain」の展示をします

デブサミ2018、ラスト1枠に滑り込みました。Ask the Speaker コーナーの真横のブースです。

event.shoeisha.jp

Docurainがどういうサービスなのかについては、下記をご参照下さい。お陰様で、少しづつですが引き合いが増えています。

site.docurain.jp
quality-start.in

お久しぶりの方々も、初めましての方々も、是非ともご挨拶をさせてください。チラッと立ち寄って頂けるとうれしいです。

どうぞよろしくお願い致します。

「Spring Fest 2017」にブースを出展致します

11/24(金)に開催されるJavaSpring Frameworkのカンファレンスである「Spring Fest 2017」に、ルート42株式会社 | root42 Inc.
と共同で運営しているサービス「Docurain」のブースを出展させて頂くことになりました。

springfest2017.springframework.jp

site.docurain.jp

Docurainは、Excelをテンプレートにしてオリジナルの帳票を開発できるサービスです。オンプレミスでの導入とクラウドの2種類の導入形態がございます。クラウド版は、現在クローズドβテスト運営中です!

というわけで、お久しぶりの方も初めましての方も、11/24のSpring Fest 2017でお会い出来ることを楽しみにしています!

【書評】いちばんやさしいPythonの教本

ビープラウドの佐藤社長よりご恵投頂きました。

いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)

いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)

私も独習Python入門――1日でプログラミングに強くなる!というPythonで学ぶプログラミングの入門書を書きましたが、こちらの書籍もプログラミング入門としての立ち位置です。「はじめての方でも挫折しないこと」に主眼を置いています。

割り切った構成

インプレスさんの「いちばんやさしい」シリーズ共通している特徴だと思いますが、1ページ内に載せる情報を限りなく削っています。説明文は各々のセクションに140文字前後、後は図解とコードの解説しかありません。その構成で全てのページが構成されており、「これだけ、まずは理解しよう」という意図をとても感じます。図も丁寧に作成されており、コードの実行イメージを喚起させる努力がなされています。

技術書まで説明を削ることはより抽象的な説明が増えてしまうことで伝わっている文脈に違いが起きやすいという問題はありますが、全体を掴まないことは何も始まらないという割り切りが、入門書を作る上で大切なことです。その点、本書は徹底されています。

基礎文法→ライブラリ活用→Webアプリ

プログラミング入門であれば、この構成が鉄板になりやすいです。どんどん出来ていくことの範囲が広がって、UIが必要なプログラムを書くことで「動くものができた」という実感が湧きます。基礎文法だけで終わってしまうとプログラミングをやった気がしない。文法の学習はどうしても退屈ですし、黒い画面だけでは面白みも出てこない。

OSS徹底コードリーディング本

サンプルコードを1回〜2回動かしただけでは、なかなかコードに書かれている文脈はわからないですよね。私が
Pythonで学ぶ、初めてのプログラミングという授業をSchooさんで担当させて頂いた時に最も好評だったのが、コードリーディングです。このコードはブラウザからやってくるリクエストを〜こうさばいて〜でもってこのオブジェクトのこの変数に代入しているから〜みたいなやつです。

なので、初級者が中〜上級者になるのであれば、代表的なOSSのコードリーディングを題材にして本が出るといいなぁと思っています。書籍にすると大変ですが、ビープラウドさんの
PyQ - 本気でプログラミングを学びたい人の、Pythonオンライン学習サービスで、拡充コンテンツの候補の1つとして頭の片隅にでも置いて頂きたいなと思いました。

プログラミングの入門なら、Pythonを選ぼう

ある特定の言語を学習する理由があるのであれば、その言語の文法や言語仕様、設計思想を学ぶ必要があります。でも、「プログラミングをはじめたいけど、どの言語が良いかわからない」のであれば、私はPythonをオススメしています。他の言語に比べて直感的にわかる要素が多く、記号が少ないからです。

Pythonで学ぶプログラミングの入門書は、本書以外にも私の著書もあれば、他に色んな本が出ています。言いたいことや書いている内容に、大きな違いはありませんが、構成は結構違います。お手にとってみて、最もご自分にあう題材を選んで頂けたらと思います。

いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)

いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)

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

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