noteで書いているITプランナーを増やしたいというマガジンも掲載しましたが、こちらにも掲載します。
IT企画やIT戦略立案の分野において、ご自身がお考えになっている企画を通す為に必要な相談相手・パートナーがいないので、プロジェクトを立ち上げるにあたっての準備が不足しているのではと感じています。
かと言って、案件になる(予算がつく)ようにならないと、外に正式に依頼することもできない。でも、企画を通す・プロジェクトを成功させるための武器は欲しい。社内に相談できそうな相手が見つからない。
そんな状況になっている方が多いと感じたので、時間限定(60分前後)ではありますけれど、ITプランナーである私が壁打ち相手を務めさせて頂けたらと思っています。
IT企画・システム企画のモヤっとした部分をより明確にして、解像度を上げるお手伝いをさせて頂けたら。
詳しくはこちらをご覧ください。
よろしくお願いします！
半年に1回ぐらいやらせていただいているイベントです。今回が第3回目。1年半ですか。月日が流れるのは本当に速い・・・。
元ネタはこのツイートです。
ITの上流工程勉強会とかあってもいいよな。お互いに「どうやってお客さんの課題を可視化して、要件定義やってます？」みたいな話で意見交換をビアハッシュな感じでやる。
— ちなヤクのござ先輩 (@gothedistance) May 10, 2018
どんなイベントかといえば、セクションタイトルにあるように「ITプロジェクトの企画運営に対する問題意識を共有する」イベントです。
エンジニアの場合は様々な勉強会やコミュニティがありますが、ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がおりません。
色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られますし、イベント開催後に分科会(反省会)を開催されてお招き頂いたこともありました。
私はアジャイルだ滝だDevOpsだという開発方法論よりも、ITプロジェクトのプランニングを適切に行う、質を上げるために何が必要で、どんなやり方や考え方を持って望めば、失敗を少なくすることができるのだろうかということに強い関心があります。エンジニアのせいでITプロジェクトがコケるケースは極めて少なく、プランニングがコケてしまうことで共倒れというケースが多いからです。
同じような領域に関心がある方、是非ざっくばらんにコミュニケーションを取りたいなと思います。
皆さんおなじみWeb技術者の為の伝統ある勉強会「BPStudy」での発表を予定しておりました。
当方の不徳の致すところで、開催日を1日勘違いしていまい、予告先発しておきながら登壇できずにぶっちぎってしまいました。人生初の登壇ぶっちです・・・。
できることといえば、資料を作ってブログで精一杯ご説明させていただくしか無いので、資料を作りました。分量少なめ、エモさ多めです。
なんでこんな言葉を連想したかという点については、このツイートをご参照ください。
要件定義を仕事にしてますってふつーの人から見たら意味がわからないと思うのだけど、プランナーですっていう話なら意味がわかると思う。そういうのも結構大事じゃないでしょうか。
— ちなヤクのござ先輩 (@gothedistance) 2019年3月14日
IT側の方々は要件定義が重要ってのは通じると思うんですけど、要件定義って濃ゆい業界用語にすぎず一般的には何のことだかわからない。要件ってなにっていう反応をされたこともありました。主語がないんで、確かにと思いましたけど。
要件定義の支援を仕事でやってみると、要件定義はどう作るかを決める工程なので、どう作る以外の問題は解決できないという当たり前といえば当たり前の話を痛感することもあって。解決したい課題認識のズレとか、体制がうまく作れなかったとか、手段の目的化、とか。ITって、ビジネス側が思うよりもずっと融通がきかない(複雑な仕組みでできているので、組み立て直すのが困難な場合が多い)というのが落ちるまですごく時間がかかる、とか。
エンジニアとの関わりが薄い企業さんだと、身も蓋もないけど「プログラムを作ってもらう時に、何をどう整理して頼めばよいか」という頼み方がわからないというケースもあった。やったことなければ、頼み方わからないよね。予算や納期に制限が強いと「とにかくすぐ作り始めてくれ」とか「PM削ってプログラマに発注」とかいうやり方をしたがる発注側が少なからずいらっしゃるのですが、その場合は発注側がマネジメントできないとかなり難しい。コンセプトやゴールの策定をすっ飛ばして要件定義から始めようとすると、意思決定がうまくいかない。
ま、目に見えない不確実性が高いわりに融通がきかないものを作るから、なかなか難しい。
システムを作ることへの知見を持っている人が単純に少ない。IT企業を離れていた時期があったのですが、その時の経験を振り返ると無理もないな、と。世の中の会社の多くは、ITが重要ではない。IT技術を手に入れても活用する術を見つけなければ、会社にとって価値がない。スマホを持ったから事業の売上が比例して増えるわけがないですよね、それと同じ。
一方で1990年頃に開発され、今でもそれが事業の屋台骨を支えるシステムになっている会社も知っている。でも、充分な価値を提供できているし、ビジネスの変化に追従して今がある。レガシー(遺産)が活きているのは、ユーザー目線では大勝利。ずっと動いて使われているという側面は無視できない。そこには、ITプロダクトをデザインできる人がいたわけです。
「価値のある、使いやすい、実現可能なITシステムとして作られるべき何か」
これがカチッとハマる事業会社が増えて欲しいし、そのコアの部分は外に出せない。行くべき道は自社で決めるしかないですから。その助けとしてITプロダクトのデザインと実現までのロードマップを考えられる人材が必要なはずで、個人的に言葉のイメージでITプランナーが最も近かった。ITプランナーなる名称に込める思いは、そこです。優秀なソリューション・技術ノウハウ・進め方をもっている会社と巡り合っても、ITプランナー的な仲介役がいないとコミュニケーションが取れないので、物事をドライブして進めていくことができない。このアンマッチを解消したい。
(株) クオリティスタートは、現状私がワンオペで回しているため私がガッツリ入って稼働するのは厳しいです。自分のワークロード超えて仕事を取るのも難しいなと思っていたのですが、やり方はなんぼでもあるしITプランナーという仲間を増やしたいので、ご相談はいつでもWelcomeです。TwitterのDM、もしくは弊社Webサイトのお問い合わせまで。
ソフトウエアが出せる価値を根気よく考えて「価値のある、使いやすい、実現可能なもの」を作り出すパワーを、一緒に出せる関係を築けたら。
よろしくお願い致します！
先日のDXの時代に関する記事を書いている中で特に感じていたのは、コーディングではなくプランニングに比重を起きつつエンジニアと議論できる人材が必要だということ。プロダクトマネージャというわけでもなく、もう少し守備範囲が広い人。そういった職種を定義したいなと思っており、IT企画というテーマで勉強会をやったりしたんですけど、既に職種化されている記事があって興奮しました。
上記の記事を読んだ私のメモです。
僕が考えているIT企画を行うポジションの仕事内容に極めて近い。やはり先駆者はいた。
リクルート社の場合は売上拡大がミッションでのITプランナーなので、儲かるサービスをどう作るかになるけれど、業務改善・効率化・コスト削減・事業開発など、色んな背景が本来あると思う。が、「一歩引いて抽象化したプロダクトをデザインする」という、ITプランナーのミッションは変わらないはず。
上記記事のこちらの画像が極めてわかりやすいので、貼らせて頂きます。
技術とビジネスのハブになる！ プロダクト開発のためにエンジニアとガチで議論するリクルートコミュニケーションズのITプランナーの役割とは - はてなニュースより
これらが絡み合うのが難しいけど面白いのが、ITプランナーという職種だと思います。全部に秀でるのは無理ゲーですけど、どれもこれもバランスよくスキルを併せ持つのは、これはこれで価値がある。このプランニングを行う人は、受託開発の現場でも、事業会社の現場でも、絶対に必要だと思う。経営と開発現場とユーザーの間に立てるのは、このITプランナーという人たちしかいないはずなので。
ユーザーとシステム屋の間に立って、適切なITシステムのプランニングやプロジェクト立ち上げを専門にやっていくプロを新しい職種として定義したい。
ITコンサルタントだと、抽象的な言葉が続きすぎてよくわからない。「先生」的な立ち位置のイメージが強いのも好きじゃなかった。IT企画って要はITプロジェクトの立ち上げだから、専門性を生かして企画立案を行う職種であるプランナーが最もイメージに合うし、プランナーという言葉は市民権を得ている。我が意を得たり、という感じです。
ちなみに、上記の記事でも私と同様に「以前はコードを書いていたが、エンジニアリングの道では大成できないと認識してITプランナーになった」という方がいらして、非常によく分かる次第でございます。
私は今でもコードを書いています。主には昔作った販売管理システムのリプレイスをするためですが、それがなくても何かしらはやります。プログラミングは筋トレと一緒なので、やらないと維持できない。ただ、これ以上に技術の筋肉がつくかといえば無理だし、選手として1軍でプレーできる自信はないが、プログラムを書くための脳内筋肉がダルンダルンにはしたくなくて...。ふつーのコードが書ける人間ではありたい。
ITプランナーって要件定義を行う人と何が違うのって話は、守備範囲の違い。要件定義というのはあくまでHowを決めるもの。どうやってソフトウェアを作ろうかという話。でも、プランニングというのは何を何のためにどういう手段で作るのかを検討するWhatとWhyの話。ただ、WhatとHowが分断すると誰一人幸せにならないので、ITプランナーがそこをつなぐ。
WhatとHowは車の両輪で、特にソフトウェアはHowの比重がとても高い。無形の成果物だから。ツール買えばOKという話でもない上に、一般の方から見れば「どんだけ細かいんだよ」ってうんざりするような細部の詰めを綿密にやらないといけない。綿密さをどこまでITプランナーに求めるべきかという議論はあるんですけど、プログラマのキャリアチェンジの方向性としても親和性が高いはず。全員が全員、テックリードというポジションに就けるとは思えなくて。
ビジネス寄りのスキルセットを上げるとキリがないと思うので、IT技術のスキルだけ。プランナーとして必須なのはSQLが書けること及びER図を読んで理解できること、だと思う。データモデリングができればなおよし。仕様を作るのはエンジニアとしても、UIから送られてきたデータをどうやって保存するかの議論が出来ないと困る。
ちなみに、SQLはある意味で最もわかりやすいプログラミング言語。宣言型だから。プログラムを読み解く難しさは処理内容をつなげていってストーリーを把握して業務仕様を把握することだけど、SQLは宣言文そのものが仕様で実行結果も2次元表しか返さない。全体を俯瞰するコストが低い上に、文章としてなんとな〜く意味が通るから覚えやすいと思います。
ITエンジニアがITプランナーになるパスもあれば、ビジネス側がITプランナーになるパスもあって然るべきで。でも、後者はどこまでIT武装できればいいのかという程度問題があると思っています。どうなんでしょう？
こんな感じの議論がしたくて、ITプランナーに興味がある人集まれ的なSlack作りました。
上記のURLを踏んで頂ければ。ITプランナーSlackへの招待リンクです。
今の所メリットとしては、僕の書いたIT企画方法論の草稿(DropboxPaperで書きました)が読めることぐらいですが、ITプランナーという職種に興味のある方で、雑談でもしましょう。20人ぐらい集まったら、4月の何処かで飲み会でもしましょう。お待ちしておりますー。
展望2020年のIT企業というシリーズ企画の記事を、たまたまTwitterで見かけました。
この記事で語られるDX(デジタルトランスフォーメーション)ってものすごいオワコン臭で衝撃を受けました。汎用機をお守りする時代は終わった、これからはオープンなWeb技術を駆使して基幹システムではなく顧客の売上を支えるITを作るのだ、SO！それが！DX時代！ みたいなノリで書いてあって、1ミリも次世代感が無い。
生きている時間軸が違うんだなと思いました。
色んな定義をされているDXですが、ここでは経済産業省の提唱する「DXレポート」のサマリー版に書いてある問題点とDX推進のためのシナリオみたいなのを引き合いに出します。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）
簡単に言うとこういう主張です。
この関係性が理解できないと一生DX無理なんで、マジでわかってほしい。
どんなにITに金を突っ込んだ所で、現場のオペレーションが変革できなければ意味がないのね。動かないコンピュータの本質はここ。現場が使うのは紙とペンじゃないですよね、何かしらのシステムとそれをサポートするツール。ITを入れるだけ入れてもしょうがなくて、使い方を工夫しないと何にもならない。
この手の話になると、「カスタマイズはもってのほか、色んな会社で使われている効率化がされたパッケージに業務を合わせる、これがベストプラクティス」というクソが出てくるのですが、大きな間違いです。これが出来るのは定型的な業務(総務系)だけ。いい加減に目を覚まして欲しい。
社内システムは業務内容によって決まります。業務は、自社が行う事業によって決まる。事業は需要と顧客によって決まる。つまり「顧客 >> 事業 >> 業務 >> 社内システム」という従属性があるわけ。どの会社でも。
で、事業運営上必要な業務が社内システムになかった時に、「あーうちのITシステムがアホなのはしょうがない。この顧客を取りこぼす、このニーズや売上はいらんわ、それが健全だもんな」という話になるかといえば、なるわけないでしょ。なぜExcelで頑張るのかという理由の9割ぐらいは、ここだと思うよ。
売上を上げるまでのプロセスは、非定型的な業務も多くあるし、顧客や商材によってオペレーションも変わる必要がある。時代が変われば需要が変わって顧客も変わる、それに追従するためのDXではないんですか？？
だとしたら、死ぬほど地道にオペレーション設計をするしか無いと思います。サービスや商材はパクれますけど、オペレーションはパクれないんで。自社独自のオペレーションこそ、企業の競争力を生み出す源泉だと僕は信じています。それを支えるためのITをどう作ればいいかという方向で、社内システムのあり方を考えて欲しい・・・！
僕がDXをやるとすれば、「IT >> 顧客 >> 事業 >> 業務」で考えます。ITありき。え、こんなふうにITを使えばこんなサービスが出来るよねで始まり、ITありきでコンセプトを作って、そのコンセプトにハマるニーズと顧客を作り出して、事業化する。これが本当のDXだと思うんだけど、どうです？
どんなに優秀なエンジニアを抱えていても、どんな価値を提供してかつそれが自社のリソースで実現可能なシステムの形を与えることが出来なければ、意味がない。プロダクト作るのにプロダクトの仕様が決まってなければどうしようもないのと同じで、「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステムの企画立案」ができるIT企画屋さんが、圧倒的に足りていないと思う。業務向けとか個人向けとか関係なくてさ。
その点を無視してCOBOLエンジニアをオープン系に！とか言ってる段階でDXの時代なんて来るわけないので、無関係です。安心してくれ、と。
エンジニアのキャリアチェンジの方向性としても面白いと思っているので、僕はこっち側に仕事内容をシフトしました。仲間が全然いないのでちょっと寂しいですが、この道も面白いと思うのでご一考下さい。
既視感があったので反応しちゃう。すげー懐かしいなこの手の話題と思った。
懐かしいと言っているのは、ネット上の議論では誰も肯定的な反応をしていないと思われる「PG→SE→PM」の出世魚キャリアの憂鬱にそっくりだったこと。
技術者とマネージャって職種(ジョブ・ディスクリプション)が全く違うのに、なんでこれが技術者の出世コースになっているのか。でも、ビジネスサイドと話ができるマネージャーは価値高いけど「作りました」ほどわかりやすい評価体系がないし、陸に上がった魚は老害になるんじゃないか・・・みたいな話ですよね。
当時は今ほどITが本業の会社が多くなく、エンジニアの主たる現場は受託開発を中心に行うSIerでした。その内部でも誰もPMになりたがらないのは人材育成上の課題にあげられていた。給料大差ないのに責任は重いので単なる貧乏くじではという風潮でした。
twitter.com某ブログでみた『プログラマのキャリアパスの先にプロマネを置くのは、FFで例えたら 「戦士からナイトを経て最終的には黒魔導師を目指してください」 と言ってるようなもんだと思うんだけどな』って表現は秀逸だと思う *P3
— t_yano (@t_yano) 2008年12月20日
2008年のツイートという所に趣を感じます。
で、2019年のツイートもございます。
SIerでは今もこのジレンマが継続中。そこに転職市場の売り手市場が乗っかっていい感じに育った中堅どころが企業の大小を問わずに去っている印象 https://t.co/U4J0VMBayz
— amanojach (@amanojach) 2019年2月19日
問題の構図は変わっていないようです。打つ手が無いもんね。
マネジメントが必要だしビジネスサイドとコミュニケーションをとってチームを率いて行けるマネージャはみんな欲しい。ただ何をどう作るかを判断できる技術力がないと何も出来ないから、まずプログラミングを覚えてもらう。が、陸に上がることを好むエンジニアは非常に少ないので、絶対数が少ない。
この現状認識があっているのであれば、マネジメントを外注することを検討するしか無いのでは？ と思います。
「マネジメント」というやつは企業の中に溶け込んでいくものなで、可視化しにくいと思う。そのチームで、その会社で行っている事業やお仕事そのものが対象になる。薄暗い森のなかにいるようなもので、例えば私にやってくるIT企画的なご相談も、抽象度が高い。プロジェクトを立ち上げたいんだけどどうしていいかわからん、と。何も決めて良いかもわからん、と。
この状態では自分が前に出て手を動かすというよりも、自分の周りの人達とコミュニケーションを取ったり、課題管理をしたり、分かりやすい資料を作ったり、各々の立場に沿った方向性を導き出したりするしかなく、こういうお仕事って定型化するのが困難なので、わかりにくい。
抽象度の高いものを具体的なステップへ落とし込むアプローチを考えること、現場で起こっている不都合な事実を集めて抽象化して、それらのもつ構造や性質を考えてこのアプローチで攻めるべきではみたいな立案をする。僕はこういう事を考えるのが好きですので、苦にならないけど。
正しい方向はどっちなのかを示すのが、一言で言えばマネジメントだと思う。手取り足取りあれやれこーやれってのは、説教でしょ。
コード書きたい人しかいないとチームとして回らない。コードの良し悪しは外注に判断ないから、仕事を円滑に回してチームで結果出す為の仕組みづくりを外注使ってサポートしていくみたいな話にすれば、マネジメント派はそっち極めたらいいし、コード派はひたすら書けば良い気がする。すげーラフだけど。
— ちなヤクのござ先輩 (@gothedistance) 2019年2月19日
ソフトウェアを育てていくプロセスは外注によろしくとは言えないから、自社でやるしかない。でも、仕事を円滑に回してチームで結果出す為の仕組みづくりという部分にフォーカスすれば、外に出せると思う。「やっぱエンジニアでよくね？」みたいになる人が多いのであれば、検討の余地はあるはず。実際、自分の周りでもエンジニアの組織づくりやマネジメント系のフリーランスを、何人か知っている。
僕はエンジニアで一本立ちするのはとっくに諦めたので、「エンジニアとしては極めて普通だが、文章を書くのと説明が得意で、企画の立案やロードマップを作ってマネジメントもいける」人材になろうと決めて、その最短ルートが独立だった、という感じです。元々SI時代からPMとかやってて、昔懐かしい「スーツ」の仕事は嫌いじゃないです。やりがいも知ってるし。
もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistanceの記事を書いた時に、ディスカッションでもしましょうと言ったら結構人が集まった。なので、「受託開発だろうがサービス系だろうが、出世魚のジレンマを解消してエンジニアリングを適切に行うための仕組みづくり」について興味のある人で、意見交換でもやりましょうか。5人ぐらい集まればやるので、Twitterでお気軽にどうぞ。
前回やらせて頂いたイベントの第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名程度で小さく始めて、次回以降どうすべきかを走りながら検討したいと思います。
それでは、皆様にお会いできるのを楽しみにしています。よろしくお願い致します！！
