前回やらせて頂いたイベントの第2回目です。
元ネタはこのツイート
ITの上流工程勉強会とかあってもいいよな。お互いに「どうやってお客さんの課題を可視化して、要件定義やってます？」みたいな話で意見交換をビアハッシュな感じでやる。
— ちなヤクのござ先輩 (@gothedistance) 2018年5月10日
ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がおりません。
色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られますし、第1回のイベント開催後に分科会(反省会)を開催されてお招き頂いたこともありました。
私はアジャイルだ滝だDevOpsだという開発方法論よりも、ビジネスサイドのIT企画力をアップさせるために何が必要で、どんなやり方や考え方を持って望めば、失敗を少なくすることができるのだろうかということに強い関心があります。 同じような領域に関心がある方、是非ざっくばらんにコミュニケーションを取りましょう〜。
先日、フリーランスで働いている仕事仲間とランチをした際に、表題のようなテーマで盛り上がりました。私の周りでは同じようなことを考えたことがある方が多いようです。
実際にこんな事をやるという話ではなく、こんな会社を作ってうまくいくのかねぇ... という程度のレベルです。話に上がったことを中心に、まとめてみました。
一言で言うと正社員という身分ではあるが、会社に縛られることなく各々が自分の事業を行うような会社です。
フリーランスになった人も何人も知っていますが、会社が持っている恩恵は大きいことを充分知っています。端的には、会社の都合が兎にも角にも優先されてしまう硬直さが受け入れ難く結果的にフリーランスになったという人も多くいます。自分で今日の仕事をデザインし、いつ仕事を開始して何を区切りとするのかを、自分で決めることができる「生き甲斐」を求めている人も、たくさんいると思います。
フリーランスだけの会社の場合は、仮に社員になったとしても、会社は何も社員に対してあーしろこーしろとは言いません。銘々が今までと同じように活動するだけです。出退勤もどうぞご自由に。残業も定時もありません。
フリーランスをやってみると改めて身に染みるが、法人組織に所属することのメリットが大きいことです。代表的なものを上げます。
+ 社会保険への加入 + バックオフィス業務からの開放 + 法人税・個人事業税からの開放 + 福利厚生の適用や設備投資
一番大きいのは、健康保険と年金に関することですかね。個人事業主や自営業の場合、国民健康保険や国民年金に加入します。国保には扶養という考え方はありませんので、家族がいれば全員分健康保険料を納付する必要があります。正社員であれば、会社が年金と健康保険の半額を負担してくれます。この差は大きいです。他にも労災や失業保険など、社会保険は手厚いサポートがあります。
会社をやってみると社保の会社負担の大きさにビビります。給与の15％程度が国から取られましてそれを会社と社員で折半するわけですが、オーナー企業の社長の場合は全部自己負担です。月収40万だと、年間で150万程度。50万だと180万ぐらいです。昔はいくらだったんでしょうか。高齢大国ニッポンであります。
給与の15％程度が国から取られましてそれを会社と社員で折半ではなく、会社が給与の15％、個人が給与の15％を折半するでした。ご指摘を頂き、修正しました。
フリーランスの場合は、売上を上げる仕事だけをやればいいというわけではありません。事務作業や確定申告など、色々と七面倒臭い事務作業も自分でやらねばなりません。会社であれば請求書回しておいてねだけで済みますし、源泉徴収によって税申告も原則不要。フリーランスになればバックオフィス業務全てを自分で管理する必要があります。
法人の場合、損益に応じた法人税が待っています。個人事業主の場合は個人事業税です。法人税の税率は30％程度です。消費税よりかなり高い。個人事業税は個人事業主が払う法人税的なものです。税率は5％程度。社員であれば、これらの税金を収める必要もなくなります。
最後に福利厚生です。法人であれば加入できる福利厚生プランや各種サービスはたくさんあります。様々な保険にも入れますし、退職金などの積立も出来ます。個人事業の場合は、小規模企業共済という月額MAX7万円まで積める積立ぐらいしかないです。労働基準法も何もありません。
法人の持っているセーフティネットとしての機能だけをうまいこと享受できないか、そのかわりに自分の食い扶持は自分で稼ぐからという前提での組織運営について、もう少し考えてみます。
フリーランスで自分で自分の食い扶持を稼げるという前提ですが、以下のようなスキームになると思われます。
+ 売上は会社に入れて、給与や手当という格好で自分の懐へ戻す + 社保、福利厚生、退職金、間接業務などの負担として、売上の5％を会社にプールする + 諸般の事情で働けなくなった場合、プールしたお金を取り崩してOKとする + 売上が増えたら四半期に賞与を出すなどして、適宜調整する + 予算管理を厳格に行い、お互いが迷惑をかけないように情報公開を徹底する
会社を運営する立場にたてば、社員を雇用しても自分で自分の食い扶持を稼いでくれる人しかいないので、楽といえば楽。仕事の面倒をみる必要がありません。また、チームで動くことがほとんどないため、休みたい時にまず休めると思います。顧客が納得すれば。
諸般の事情というのは、端的には入院が必要になったとか、お子さんが生まれて育児休暇が必要になったとか、そういう類のものです。
しかし、この自由すぎる形態で企業組織を運営することが本当に出来るのかという不安も多くあります。
現時点で僕が見えているところは、こんな所です。
+ フリーランスとしての売上が激減した場合に、どうサポートすれば良いのか + 経費の多い少ないの按分を考える必要がある + 個々人の集合体という組織体で、お互いが信頼しあえる組織になれるのか + トラブルがあった時に「会社としての対応」をどう行えばよいのか
一言で言うと、金銭面、健康面、仕事上のトラブルが発生した場合、どうやって責任をとって回していくのかを決めるのがとても大変になるだろう、という話です。
自分で自分の売上を稼ぐ前提とはいえ、良い時もあれば悪い時もあります。そんな中で会社にプールするお金すら稼げない状態になってしまった時に、その人の給与を下げるしか無くなるのでは、と。
会社的には代表取締役を立てる必要がありますけども、あくまで個々人の集合体という前提ですから、その人が他人のビジネスの責任を取るというのは貧乏くじを引くように思えます。でも、仮にその人が仕事上でやらかした場合、顧客に「我々はフリーランスの集まりなんで、社員がやらかしたご迷惑の責任は取りません」とは言えないでしょう。
会社としての筋を通さねばならない局面になった時にどうしたら良いかは、非常に悩ましい問題です。
見込みの売上を達成できそうにない場合、どうサポートしていくのか。給与を下げると決定して良いのか、その場合比率や下げ幅をどう決めていけば良いのか。納得できる形が作れるのか。悩ましいです。自由と責任は表裏一体です。そこをナアナアにしたら、この組織は崩壊すると思います。
経費についても、働き方によってブレがあります。例えば地方在住のフリーランスが車で移動する場合、車を法人で借りてガス代等を経費化するとします。もう一方で、自宅作業がメインのフリーランスの方だとすると、経費の絶対額が違います。売上から経費を引くだけですけど、万が一経費が売上を超えてしまった場合、どういう扱いにすればよいのか。お前のケツまで拭くのは困る、という話になるのか。その点も踏まえて自分の懐に入る給与設定を考える必要がある。
人が増えてしまった場合には、バックオフィス業務をはじめとした組織運営コストが上がる一方なので、取締役になった人が組織運営の責任を負うとしたら本業に負担が出た時に「オレ何やってんのかな〜」みたいな感じになると思います。
グルっと一周回って考えると、フォローアップの仕組みがほとんどないのがこの会社の弱点です。
こんな会社のあり方に興味があるフリーランスや一人会社の人が5人程度集まったら、どこかで打ち合わせをやりたいと思っています。やるやらないは置いといて、自分の求める働き方にマッチした自由すぎる会社運営のあり方をざっくばらんに議論できたらいいな〜と。 みんなが納得してメリットのある会社が作れたら、本当に良いことだと思うのです。
また、「こういう事昔やったぞ」とか「やってみたけど、こんなダークサイドがあってやる意味なかったわ」とか、そんなお話がございましたら、SNSでお気軽にお声がけください！
それでは、引き続きどうぞよろしくお願い致します。
思いの外、多くの方にディスカッションのお申込みがあったので、一旦ここで〆させて頂きます。
ということで、やらせて頂きました。
今回最も重要視したのは、意見交換をする場所を作ることでした。「こういう風に要件定義やればうまくいくよ」みたいなセミナーにはしたくなかった。ビアハッシュでご歓談にしたのも、思いを吐き出せる場にしたかったからです。
私が見る限り、ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がいないように感じています。色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られるのではないか期待していました。エンジニアの方は横のつながりを作る場がたくさんありますが、ITのビジネスサイドになるとその10分の1も無さそうなので、それは不幸なことだなと。このために関西から駆けつけてくださった方もいらっしゃいました。あなたが優勝だ！！！
私のテーブルでは、ITコンサルの方が2名、某自治体の方が1名、メーカー系情シスの方が1名、Webサービス運営の情シスの方が1名という陣容でした。その中で最も深いお悩みを抱えていたメーカー系情シス(レガシーシステムの刷新を行いたいが右も左も分からない的な)の方に対して、残りの全員が全力で案を出し合うという時間になりました。
ITコンサル、システム開発会社、ソリューションベンダー、事業会社の情シスの方、昔の会社の同僚の方(ビビる)... 色んな立場の方が一堂に会する場になって良かったです。楽しい時間でした。
上記のガシさんの参加記事も合わせてご参照下さい。
一言で言うと、書ける壁であり机です。こういうグッズが揃っている会場だったので、積極的に使いました。イノーバ面白いです。
今日は「IT企画をちゃんと考える座談会」(タイトルうろ覚え)で沢山の方がオフィスに来て、ビール飲みながら語り合いました。
— 白川克🥑 (@mshirakawa) June 27, 2018
ちなみにこの写真は1人情シスの方が悩みを語ってるところ。
ちなみにこの書ける机はイトーキのイノーバという製品デス。 pic.twitter.com/FM9WbtkBrm
これを各グループに配布し、立て掛けタイプも配布しました。書き出せる何かがあると、議論も弾みますね。
ビアハッシュでご歓談がメインの場ではありますが、ディスカッションについてはもう少しテーマを絞るとか、LT方式でIT企画に纏わる想い／ノウハウ／課題／お悩みを発表してもらう時間を設けるとか、色々や利用はあると思うので、忌憚のないご意見を下さいませ。
また、本イベントを開催するにあたって場所をご提供頂いた、ケンブリッジ・テクノロジー・パートナーズの白川さんと、課題図書3点セットを3部もご提供頂いた羽生章洋さんに、深謝致します。
それでは！
元ネタはこのツイート
ITの上流工程勉強会とかあってもいいよな。お互いに「どうやってお客さんの課題を可視化して、要件定義やってます？」みたいな話で意見交換をビアハッシュな感じでやる。
— ちなヤクのござ先輩 (@gothedistance) May 10, 2018
かなり伸びてびっくりした。「ありそうでなかった」という点もポイントだったようです。
悩んでいるはずなんですよね・・・！コンサルティングを行う人も、システムを作る人も、エンドユーザーも、情報システム部の方も。
どうやったら良いIT(システム)企画を出来るのかという点については、ずっと頭を悩ましています。システムって「やる前から勝敗が決る」側面が強いですし。
結局ITシステムは作る前で勝負決まるからなぁ。かといって作りながら直していくのも、請負だと受託開発したら検収もらわないと請求出来ないので、はよ終わらせないと死ぬし。不確実なものを具現化して固めていくには、マイルストーン設計してスコープ切るしかないと思うけども、悩ましいわ。
— ちなヤクのござ先輩 (@gothedistance) May 18, 2018
僕自身も悩んでいるので、この辺に興味関心がある・問題意識を持っている方々でざっくばらんにビアハッシュ方式で意見交換ができたらいいな〜ということで、イベント立てました。
MAX30名程度で小さく始めて、次回以降どうすべきかを走りながら検討したいと思います。
それでは、皆様にお会いできるのを楽しみにしています。よろしくお願い致します！！
デブサミ2018、ラスト1枠に滑り込みました。Ask the Speaker コーナーの真横のブースです。
Docurainがどういうサービスなのかについては、下記をご参照下さい。お陰様で、少しづつですが引き合いが増えています。
site.docurain.jp
quality-start.in
お久しぶりの方々も、初めましての方々も、是非ともご挨拶をさせてください。チラッと立ち寄って頂けるとうれしいです。
どうぞよろしくお願い致します。
11/24(金)に開催されるJavaのSpring Frameworkのカンファレンスである「Spring Fest 2017」に、ルート42株式会社 | root42 Inc.
と共同で運営しているサービス「Docurain」のブースを出展させて頂くことになりました。
springfest2017.springframework.jp
Docurainは、Excelをテンプレートにしてオリジナルの帳票を開発できるサービスです。オンプレミスでの導入とクラウドの2種類の導入形態がございます。クラウド版は、現在クローズドβテスト運営中です！
というわけで、お久しぶりの方も初めましての方も、11/24のSpring Fest 2017でお会い出来ることを楽しみにしています！
ビープラウドの佐藤社長よりご恵投頂きました。
いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)
私も独習Python入門――1日でプログラミングに強くなる!というPythonで学ぶプログラミングの入門書を書きましたが、こちらの書籍もプログラミング入門としての立ち位置です。「はじめての方でも挫折しないこと」に主眼を置いています。
インプレスさんの「いちばんやさしい」シリーズ共通している特徴だと思いますが、1ページ内に載せる情報を限りなく削っています。説明文は各々のセクションに140文字前後、後は図解とコードの解説しかありません。その構成で全てのページが構成されており、「これだけ、まずは理解しよう」という意図をとても感じます。図も丁寧に作成されており、コードの実行イメージを喚起させる努力がなされています。
技術書まで説明を削ることはより抽象的な説明が増えてしまうことで伝わっている文脈に違いが起きやすいという問題はありますが、全体を掴まないことは何も始まらないという割り切りが、入門書を作る上で大切なことです。その点、本書は徹底されています。
プログラミング入門であれば、この構成が鉄板になりやすいです。どんどん出来ていくことの範囲が広がって、UIが必要なプログラムを書くことで「動くものができた」という実感が湧きます。基礎文法だけで終わってしまうとプログラミングをやった気がしない。文法の学習はどうしても退屈ですし、黒い画面だけでは面白みも出てこない。
サンプルコードを1回〜2回動かしただけでは、なかなかコードに書かれている文脈はわからないですよね。私が
Pythonで学ぶ、初めてのプログラミングという授業をSchooさんで担当させて頂いた時に最も好評だったのが、コードリーディングです。このコードはブラウザからやってくるリクエストを〜こうさばいて〜でもってこのオブジェクトのこの変数に代入しているから〜みたいなやつです。
なので、初級者が中〜上級者になるのであれば、代表的なOSSのコードリーディングを題材にして本が出るといいなぁと思っています。書籍にすると大変ですが、ビープラウドさんの
PyQ - 本気でプログラミングを学びたい人の、Pythonオンライン学習サービスで、拡充コンテンツの候補の1つとして頭の片隅にでも置いて頂きたいなと思いました。
ある特定の言語を学習する理由があるのであれば、その言語の文法や言語仕様、設計思想を学ぶ必要があります。でも、「プログラミングをはじめたいけど、どの言語が良いかわからない」のであれば、私はPythonをオススメしています。他の言語に比べて直感的にわかる要素が多く、記号が少ないからです。
Pythonで学ぶプログラミングの入門書は、本書以外にも私の著書もあれば、他に色んな本が出ています。言いたいことや書いている内容に、大きな違いはありませんが、構成は結構違います。お手にとってみて、最もご自分にあう題材を選んで頂けたらと思います。
いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)
「パパの育児をもっと楽しくするためのビジネスをしたい」がミッションの会社、パパスマイルさんにご依頼を頂き、私がチーフブログオフィサーになりました。
乳幼児や小学校低学年の子育てを支援するスマートデバイスのカテゴリを指す総称です。今年のCESから「BabyTech」というフロアが設立されるなど認知度が高まっており、欧米では多くのスタートアップ企業やクラウドファンディングが存在します。
当面は海外のベビーテックシーンの紹介・資金調達の情報提供をメインに、エンジニアパパトーク的な企画や日本におけるベビテクシーンのプレイヤー紹介などをしていきたいと考えています。日本ではまだまだこれからのジャンルなので、ぜひベビテクのお問い合わせから情報提供など頂けると滅茶苦茶喜びます。
パパスマイルのサイトも御覧ください。
どうぞよろしくお願い致します！
社長の加藤さんから伺ってはいましたが・・・本気だったんですね(笑)
僕はlemonというホストでしたが、皆さんはもしかしたら違うかも。Docker上でコンテナを30分単位で再生成して負荷分散や不正対策に役立てておられるそうです。su rootしたいですね（お
helpと打つと出来ることの一覧が表示されます。雪が降ったり桜が舞ったりします。お問い合わせはviが操作できないとフォームから送信できないですがよろしいですか？ というロックな仕様です。
helpコマンドに掲載されているコマンドには掲載されていない「隠しコマンド」も幾つか用意があるそうなので、皆さんもお時間が許す限り遊んでいって下さい。
4月からプログラミングを教える仕事を定期的に行っていて、集合研修という形が１つ、実験台としてプログラミングに興味がある学生の甥っ子に対してマンツーで教えています。自分の教えている内容がどう伝わるか、どんなイメージ絵を描けばいいのか、どの順番で説明すればよいのか。それらを検証するためです。
で、そんな中、甥っ子がポロッと漏らしました。
「おれ、やっぱりプログラミングのセンスが無いんだと思う。教えてもらっても全くわからないことが多いし...」
「ちげーだろ。お前は単なる練習不足にすぎない。2〜3回しか練習していないのに、どうやってオレと同じレベルで物事が判断できるんだって話。ちょっとしか練習してないのにセンスもクソもない。漢字の書き取りにセンスが必要か？ 100回while文書いてみたか？ 書いてないだろ？ 」
「あ・・・（察し」
彼が言っていたセンスがあるという状態は、「一を聞いて十を知る」というようなもの。言ってることから言わんとしていること(プログラミングの場合は解決しなくちゃいけないこと)を汲み取れるので、どんな手順で進めていけばよいかを自分で見つけられる。そんな状態をセンスがあると表現しているのは、結構よくあるんじゃないでしょうか。
でもこれ、違います。単なる練習不足です。センスという言葉は具体的な手順が見えていない時に使う言葉じゃない。手順が見えていないのは、練習のやり方を教わっていないからです。その結果、何を考えていいかわからなくなり、教わっている内容が身に入らないので益々理解度が下がるという悪循環に入ってしまう。それはセンスがないから起こるわけじゃなく、然るべき練習をしていないから。
その意味ではメンターが側にいるかいないかは大きいといつも思う。自分でゴールを定められるようになるには時間がかかるし、プログラミングのような抽象度の高い概念は、一人では難しいところがあるなぁ。
抽象的な概念がわからないのなら、具体例を出すのが一番。具体的な手順がわからなくなった場合によく使うのが、「例えば」です。
「例えば、対象の文字列に"ABCDE"と入力されたら、何が返って来る？ そうだよね、他の場合でも同じことが言えるはず。つまり、何をどうすれば同じことが出来る？」
「ローカル変数とインスタンス変数の違いを整理して、その違いを例示できるコードを書いてきて」
「このa_listに入っている要素はPersonクラスのオブジェクト。そう。じゃ、このa_listがどういうデータ構造になっているか、図に起こしてみて。こんな感じ。」
今、甥っ子にはこーゆー問いを投げて、紙に書かせて宿題にしています。パソコンじゃなくて、紙ってのがポイント。手を動かせないものはわからない。これがテキメンに効いている。コードで表現されたことを「例えばこれがappendされると・・・」と頭を整理して紙に書くことで、イメージと具体例がパチっとつながり、コードで表現された抽象的なものが腑に落ちる。
プログラミングって、つまりと例えばを交互に行ったり来たりする。その練習をしてこなかっただけだとしたら、センスで終わらせてしまうのは教える立場である以上やりたくないし、逃げたくはない。
この本に面白いことが書いてありました。センスってのは「数値化できない事象のよし悪しを判断して、最適なものを作る力」だそうです。善し悪しが判断できるためには、良いものも悪いものも知っていないといけないし、そもそも「これがスタンダード」っていう自分なりの型がないと始まりませんね。
「練習不足による自分の型がない＝センスがない」には語弊があるので、練習を積みましょう。
