「会社設立 freee」をつかって実際に起業した話 - レベルエンター山本大のブログ
会社設立のとき「会社設立freee」にお世話になり今は「会計ソフトfreee」お世話になっています。 こんなニュースがあったので、お祝いのつもりで「会社設立freee」が便利だったということを書きます。 「freeeが35億円の資金調達ースモールビジネスを支えるプラットフォームを目指す」 http://jp.techcrunch.com/2015/08/24/20150824freee/ 「会社設立freee」は、まるでソフトウェアのインストール時に使うセットアップウィザードのように、次へ次へとやるべきことを指示してくれるサービスです。 なかなか難しい「電子定款」に対応しているので、それだけで印紙代の４万円が５０００円の代行手数料だけになってお得でした。 「会社設立freee」を使っていなかったら、１つ１つのステップで手戻りや調査に時間がかかっただろうなと思いますし、なにより初めてやる作業
アジャイルって大変 - レベルエンター山本大のブログ
請け負い開発でアジャイルのマネジメントやってます。アジャイルはとても忙しいという実感してることをとりとめもなく。 ムービングターゲットを追うこと自体がとても体力がいります。 アジャイルでやるってことは、動くゴールを追うことです。 当然、止まったゴールを追うよりも体力がいります。 体力とは、お金と技術と要員数です。 アジャイルは価値がありますが体力がいります。 マネジメントは予定の策定、実績の分析に頭を使います。 常に新しい予定を立てており、実績の分析も必要です。 次の一手を考えるために前回の分析をしますが、時間はありません。 分析の甘い１手を打ってしまって結局無駄になることもしばしば。 次のイテレーションで何を優先事項とするか？を素早く決めないと空回りするのです。 開発チームも大変ですが、要望側も大忙しです。 その覚悟が要望側にないと大変です。 終わりを作らないと終わりません。 要件って尽
SI開発で再利用が必要なのは部品ではなくチームだ。 - レベルエンター山本大のブログ
この半年、巨大なシステムの開発で学んだことの1つは、 SIという業態の中で再利用が必要なのは、部品ではなくチームであるということ。 チームに蓄積するノウハウや暗黙知こそ再利用するべきで、 案件の度に体制の伸縮を繰り返すやり方では、いくら部品化や共通化を進めたって効率もへったくれもあったもんじゃない。 部品の再利用は確かに可能で、非機能的な部品やフレームワークは活躍するんだけど、 ドメインオブジェクトのレベルでの再利用はやはり難しいし そもそも部品やフレームワークは使いどころを知っていて、設計や試験を省力化するところまでやってこそだと思う。 システム開発の工程の中で、製造工程はどう考えても一部分であって設計＋試験が圧倒的に長い。（保守期間はもっと長い） 設計や試験に効果を発揮するのは、部品よりもチームだ。 例えば、僕らの現場ではSOAにも取り組んでいて、権威と呼べるような人たちがその設計をや
任せられることで人間は成長するから、人に仕事を振るときは頭から尻尾まで振りなさい。 - レベルエンター山本大のブログ
人に仕事を振るときは、頭から尻尾まで振りなさい。 と、これはウチの社長から教わった、人の活用術ですが、 その真意を知った気持ちです。 今の仕事のチームで僕の片腕になってるメンバーがいます。 片腕というよりも、もう完全に背中を預けています。 彼が最近、提案資料を作ってお客さんのところでプレゼンをしたんですが、 いつも厳しいお客さんが、するすると提案を受け入れてくれて 最後には「提案ありがとうございました」と、感謝の言葉をくれました。 僕も何度かこのお客さんに提案資料を持っていったことがありましたが、 提案が気に入られないときは感謝の言葉どころの騒ぎじゃなく、 コテンパンに突っ込まれて終わることもあるので、この感謝の言葉には価値があります。 彼が作った提案資料は、最初僕が作ろうと思っていました。 彼があまり得意じゃない分野の提案なので、 提案のデビュー戦にはふさわしくないと思ってたからです。
業界の文化と戦え！教え子達の配属1ヶ月目の苦悩 - レベルエンター山本大のブログ
研修が終わって教え子達が配属されて1ヶ月。 大学までの常識と、この業界の常識の違いに苦悩している者が多い。 異様なのは、彼ら新人達なのだろうか？ 一人の教え子が言ってた。 「挨拶をしても、返してくれる人がいないんです。 それどころか、あまりに元気良く挨拶すると、みんな迷惑がっているように思えています。 しかもOJT担当の人から『ここではそんな挨拶なんか要らないよ』 と注意まで受けてしまいました。」 僕はいろんなエンジニアを見ていて、 挨拶もできないエンジニアはほとんどが大成しないって知ってる。 技術的に素晴らしくても、業務にめちゃくちゃ詳しくても上のポジションには行けない。 なぜなら、SIerはサービス業だからだ。 例えばオーダーメイドの洋服の店で、品物が良くても礼儀のなってない店についてどう思うだろうか？ 品物がたいした事ないなら余計にそうだ。 OJTの人というのは、2〜3年目の先輩だろ
越権行為のすすめ - レベルエンター山本大のブログ
ぶっちゃけ僕は越権行為が好きだ。 なぜなら、それは自分の運命を自分で握ろうとすることだから。 そもそも、僕らは大手SIerから切り出しで仕事を貰うことが多い。 しかし正直言って1次受けの会社の人たちが、プロジェクトを上手く回せないことも多い。 それは仕方ない。それを掘り下げても業界の構造の問題を憂うことになるだけだ。 だからといって「あの会社がへぼだからこんなデスマなんだ」とかは言わない。 仕事をくれたときから、その会社には恩がある。 頼られてるんだから仕事で返さなくてはいけない。 だからプロジェクトが失敗したら常に自分のせいだと思ってる。 頼られてるのに返せなかった自分のせいだ。それがプロじゃないだろうか。 それに人任せにしておけば、自分の仕事を自分でコントロールできない。 それはイライラしてしまう。 今回の仕事も初日の時点で、ほっとくとプロジェクトがボロボロになりそうだった。 というこ
交渉の余地がないと思っているならそれが改善のチャンスだ - レベルエンター山本大のブログ
交渉の余地がないと勝手に思い込まれていることは良くある。 例えば「設計書はこのフォーマットでないといけない」とか。 しかし実際は誰が決めたルールでもなく、サンプルとして作られた適当なフォーマットが生きつづけているという場合もある。 少なくとも、交渉の余地があるときが多い。 誰もが無駄だと考えている事ならば、それを正しいものにする交渉をするべきだ。 だめなら引き下がってよい。だけど、交渉もしないで甘んじるなら運命の手綱を手放したと思ったほうがいい。 交渉の余地がないと思っているならそれが改善のチャンスだ
誇りを貫くプログラマのキャリアパス - レベルエンター山本大のブログ
エンジニアの誇りを減退させずキャリアを積むためには、とっとと管理を極めて*1管理の仕事を他の人に振れるようにすることだと思っている。*2 あなたが管理を嫌ってもキャリアアップするにあたって管理という仕事は回ってくる。 管理という仕事に目を背け続けることは出来ない。 僕は、管理という仕事をエンジニアの終着点だと考える必要はないと思っている。 乗り越えるべき通過点なのだと思う。 エンジニアのキャリアアップの中でも管理職の乗り越え方を考える。 原則：エンジニアよ、管理職を超えろ。 会社側の論理で言えば、キャリアの長い人に高い給料を支払うためには、 その人が複数のメンバーの仕事を上手く回してくれなくてはならない。 会社がベテランに求めるのは、チームを引っ張っていってくれることだ。 当然、あなたが管理向きならば問題にはならない。 管理とリーダーシップは両立しやすい。しかし、管理系リーダーが全てではな
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
僕の１日のスケジュールとやたらスケジュールが好きな僕 - レベルエンター山本大のブログ
ご要望いただいたこともあり、自分の平均的な１日のスケジュールについて公開してみます。まぁ、本当に標準的だと思うのであまり面白くはないかもしれません。ただ、改めて振り返ってみると、本当によくスケジュール表の消しこみとか組み換えとかをやってます。 スケジュール表で完了したタスクを塗りつぶす感じが大好きなんです。終わったなー！という感じがするので。だからやたら色を塗ります。判りやすいようにメンテしたり、成果が出やすいように大きなタスクを細かく分割して、色をぬれる範囲を多くしたりするのが至福です。 でもスケジュール管理だけを仕事にするのは死んでもいやです。不思議なもんですね。 まずは午前中から 8:50〜ネット巡回 (10分) 9:00〜スケジュールを確認して前日の消しこみ スケジュールの組み替え(5分) タスクが長すぎれば午前中に成果の出るタスクに分割 今日の進め方とノルマをメンバーと話しながら
３０代に必要な「なんとかやり遂げる能力」 - レベルエンター山本大のブログ
３０代に差し掛かる弊社のリーダー達にとって共通する一つの問題は、 どのような３０代を過ごし、どのようにこれからの仕事人生を送るかということです。 僕も３０代に入って間もないのでまだまだ発展途上ですが、 僕が考えるには、不可能だと思えることをなんとかやりとげる能力が、大事だと思っています。 僕が、困難な仕事をなんとかやりこなすためにいつも心がけていることがあります。 １つ前向きに考え、あきらめないこと ２つまずは全体量を減らすこと ３つ徹底的に分析し、計ること ４つ自分の能力（生産性）を知ること ５つ使えるモノはなんでも使うこと ６つ作業の手順を決めること ７つ片っ端から取り掛かるのは最後の最後 でも、３０代までに必要なこととは、 そういった 「やり遂げるための自分独自の鉄則」 を集めておくことではないでしょうか。 そして３０代から大事なのは、それらを使って実際に様々なことをやりぬくことです
或るエンジニアの生き続ける魂 - レベルエンター山本大のブログ
エンジニアをやっていて、こんなに目頭が熱くなるような経験はこれが初めてかもしれない。 物づくりという仕事は、魂を込めたものを世に出すことだ。 物は、作った人よりも長く生き続けることがある。 それを使う人たちは、多かれ少なかれ作った人のことを想う。 想われつづける限り、その人の生きた痕跡は世に残る。 話は、超有名企業のエンジニアであり、 懇意にしてもらっているSさんという方からのお願いから始まった。 どういったお願いかというと、以下のようなものだ。 Sさんの知り合いで、大手ソフトウェア会社でエンジニアとして務めていた 嶋田通夫さんという方が、 数年前にInterpressという会社をつくって独立し、Javaプロダクトのライセンスビジネスをしていたらしい。 設立当初からWebサーバ管理関係やWebサイト巡回ツールなどを企業向けに提供しており、 2年ほど前から新しいネットワークバックアップツール
ルールを厳格にしてもソースコードは綺麗にならない。規範コードを提供しろ。 - レベルエンター山本大のブログ
今のプロジェクトはJavaで、保守フェイズの新規機能追加なので既存コードをよく読む。 お世辞にも、綺麗なコードとは呼べないし、 オブジェクト指向の観点でも下の中ぐらいのもんだ。*1 しかし、このプロジェクトの初期段階で書かれた開発者向けガイドを読んでびっくりした。 そこには、初期段階でアーキテクトが色々考えてルール決めをしたと思われる形跡が垣間見えた。 例えば、疎結合や、高凝集性、情報エキスパートといった考え方を説明していて 柔軟なオブジェクトを設計することを推奨していたり、 テストコードを作りやすいように、フレームワークAPIに依存しない仕組みを提供したりしている。 当然テストコードも推奨している。 しかし、その成れの果てはというと。。。 ・クラスは出来るだけ少なくするというルールが出来てて、1クラス10000ステップもザラ。 ・テストコードは一切存在しない。junitのjarの参照すら
ルールを徹底する4つの原則 - レベルエンター山本大のブログ
以前のエントリ(ルールメーカーの生産性は、96倍 - 山本大の日記) に対して、コメントをいただきました。 今のPJでは、アサイン当初、まともなルールが無いPJでした。 「おいおい、こりゃまずいんじゃない？？」と思い、 自分が色々とルールを決めてみんなに提示したりしてました。 その結果… ・そのルールに欠陥(抜け)があって、バッシング ・メンバ内で徹底されず、逆に面倒な事に こんな状態でした。 ルールを作り出す事は重要だと思いますし、 必要だと感じれば、柔軟にルールを変える事は大賛成です。 でも、それを周知に徹底させて、実践し、推進していく事も同じく重要だと思わされる事が 今のPJではかなりあります。 周知に徹底させる為には、何が必要でどうすれば実践されると思いますか？ これには僕も覚えがあります。 一例を挙げると、僕が今の会社に入る前、仕事上のやり取りをルール化しようと考え 社内でコミュ
僕なりの業界の変え方 - レベルエンター山本大のブログ
僕は開発現場にも出ていますが、ITの講師もしています。 毎年4月には、他社さんの新人教育を担当しています。 教え子たちにはJavaの基礎と共に、この業界の問題点についても教えます。 技術の空洞化や、大手SIerのゼネコン化についても教えます。 若年層から「マネージメント経験」と称して、 人のマネージメントをやらせ、 技術のマネージメントができず、実質はただの人材ブローカーに なってしまっている現実についても教えます。 君たちの入った業界には、こういった問題がある。 君たちの入った会社にも、恐らくその問題はある。 料理をしたことの無い人が一流シェフにはなれないし、 厨房を仕切れはしないし、レストランの経営もできないんだ。 IT業界も同じだ、とも教えます。 教え子らの中には、ショックを受ける人もいます。 夢と希望を持って入社してきた人もいるからです。 こう付け加えます。 「正しいことをしたけれ
天才でなくても、評価されるために意識する14の原則 - レベルエンター山本大のブログ
1.自分の脳でだけ考えず、他人との共鳴の中から答えを探す。 2.話を聞く。琴線に触れる質問・相談をする。 3.チームを作り、チームを育てる。 4.なぜそれが楽しいかを考える。 5.大事でないことはルーチン化する。ルーチンを成長させるために書き出す。 6.大事なことは初めにこそしっかり考える。 7.ぶつ切りの時間で考えない。時間は1つにまとめる。 8.本番を作る。いろんなところで試合・舞台・講壇などを踏む。 9.リハーサルを徹底的にやる。 10.ちょくちょく片付ける。 11.シンプルに保つ。そのために時間を費やす。シンプル化をシステム化する。 12.全部一箇所にまとめる。置き場所を決める。情報もしかり。 13.小出しにしない。 14.責任を進んで請け負って覚悟を決める。覚悟の儀式を設ける。
Flex/AIRを始めるためのリンク集 - レベルエンター山本大のブログ
画面遷移 ■Flexのリッチな画面遷移テクニック集 http://www.atmarkit.co.jp/fwcr/rensai/flexjissen01/flexjissen01_01.html ■ModuleLoaderを使用した画面遷移について http://www.fxug.net/modules/xhnewbb/viewtopic.php?topic_id=864 ■Flex2 コントロール - Window・Dialog - http://wildcat.cocolog-nifty.com/web/2006/07/flex_windowdial_6c1d.html ■FlexUGでの議論 画面遷移について http://www.fxug.net/modules/xhnewbb/viewtopic.php?viewmode=flat&topic_id=62&forum=2 概要 ■
プロジェクトの成功要因 - レベルエンター山本大のブログ
先日、システム開発のリリースを無事完了しました。 数億円規模のプロジェクトでしたが、遅延もトラブルもなく見事な成功でした。 プロジェクトの成功の第1番目の要因はチームワークにありました。 顧客までを含めたプロジェクトチームのチームワークです。 この顧客は、実は一度同じプロジェクトを、別のSIerとやって頓挫してしまっていました。 この頓挫の苦い経験が、今回のプロジェクトでの動き方を変えたんでしょう。 前回は、情報システム部門にお任せで、SIerと情シスが要件・仕様を詰めていたらしいのですが、 今回は、ユーザー部門が前面に立ち、我々とやり取りをしました。 ユーザー部門が協力的であることは、開発の成功のために最重要なんだと思います。 ユーザーさんからは 「何か起こったときは、一緒に解決しましょう」 というスタンスが感じ取れました。 責任の擦り付け合いに要する時間や、予防線・論理武装などの 無駄
ゆでガエルの回避 - レベルエンター山本大のブログ
ゆでガエルの法則をご存知だろうか。 以下、経営コンサルタントさんの事業計画についてのサイトより。 以下の日本企業が倒産する原因の統計グラフをみてほしいのですが。 注目すべきは「既往のしわよせ」。7％*1で2番目に多い倒産原因です。 この実態は「ゆでガエル」。 カエルを冷水からゆっくり熱していくと、命の危険を知覚できずに最後までジャンプせずにゆで上がってしまうという話です。 業績悪化が危機的レベルにも関わらず、具体的な数値を理解していないので、倒産してしまうケースです。 経験のある経営者は、 具体的な経営指標を把握している リスクトリガー（ジャンプするキッカケとなる閾値）を定義する 速やかに対策を実行する 例えば、「この事業が失敗するのってどんな場合ですか？」 人生をかけて全力で事業をがんばっている社長さんに向かって、こんな失礼な質問をするのは心苦しいのですが、このような質問をあえてさせてい
自動テストとデイリービルドの組み合わせは最強！ - レベルエンター山本大のブログ
自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。 影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。 結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。 それを知らせてくれる仕組みがあるということが安心感は絶大だ。 そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。 Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。 「じゃあ、Web画面からの入力テストはどうするんだ？」とか 私も昔は思っていたけど、画面入力のテストなんかは無理に自動化し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
