前職の頃からよく言うフレーズなのだが、受託をずっとやってきたエンジニアが面接に来た時に、「誤解を恐れずに言えば」という前置きとともにこういうことを言うことがある。 「サービスの開発は退屈ですよ？」 Facebookやtwitterや、若年層向けの携帯SNSや、それに従属するソーシャルアプリのような鬼のような成長をするサービスはよくわからないが、それ以外の従来からある、数多くのWebサービスにおいてエンジニアに求められるものは、如何に目の前の日々レガシーになっていくコードを安定的にメンテナンスしていくか？というサイクルになる。 安定成長するネットビジネスは「ストック型」である。お客様がそのサービスを使い始めて、使い終えるまでの期間を生涯価値として、今まで開発したコードで「サービス」を利用する。 その生涯価値がマルチスレッドのように重なることで、毎月安定的にユーザーが増えて行く仕組みである。と
私は、弁護士という職業上、あまりビジネス・コンサルタントっぽい発言は控えてしまう傾向にあります。 ただ、数多くの経営者やコンサルタントの話を耳にさせていただく中で、ある瞬間にいろんなことが結びつき、異なる表現ではあるけれども、同じことを意味しているのではないかと思わさせられることがあります。今回は、その話をさせていただきます。 先日、企業の利益向上のための施策についての議論を耳にしました。話をわかりやすくするために、小売業で考えてください。その議論とは、次の問題に関わるものです。問題とは、「既に市場で売り出されている製品Xについて、さらに利益を上げるためには、どうするか」というものです。もちろん、市場や経済は、様々な要素や人間の気持ちによって左右されますので、画一的な回答があるわけではありません。ただ、一般論として、利益を上げるには、(i)価格を上げる、(ii)販売数量を増やす、(iii)
孤高というやせ我慢をしながら、会社の経営に直接関わっております。 私のミッションの１つには、会社を回す仕組みを高度化させ本業に貢献する業務システムを作ることがあります。 サラリーマン時代、結構な人が自分の会社の売上があがる仕組みを理解していないことに驚きました。お金が降ってわいてくるわけが無いのに、自分の給与の源泉にさしたる関心が無いものかと不思議に思ったものです。自分が存在する組織の成り立ち・競争原理も理解していないにも関わらず、会社の不平不満を言うだけとはトンデモナイ。 前職は｢人月｣という単位で売上を立てておりましたが、入社して人月単価なるものがあると知った時、自分の売価と自分が手にする給料のあいだには何があるのだろうか、と疑問に思ったものです。自分の給与の数字は売上から｢何か｣を天引きされている数字です。それを知る為には、ご自分の会社の大きな仕事の流れを理解しなければなりません。そ
ソフトウェアビジネスラボ第三回の私のスライドを掲載します。 （第2回のスライドは弊社の戦略がばれてしまうため掲載できません、残念。） ソフトウェアビジネスラボ第三回では大阪から壇弁護士に来ていただき、 ソフトウェア受託開発の契約についてお話しいただきました。 来場者の皆様に大変ご好評をいただきました。 また次の機会には是非みなさんお越しくださいね！ あなたが知らないかもしれない 受託開発の基礎知識
つまり試行錯誤という行為がルーティンワークになっており、本当の意味でのルーティンワークになっていかないということを指摘できると感じます。ルーティンワークについては、ルーティンワークはインフラであるもお読み頂ければと思います。 加えて技術面での進化が速いので、実装の落とし込み先が固定しきれないため、結果として前工程への要求つまり前工程のアウトプットも安定しません。変化が激しいので遣り甲斐はありますし、ぶっちゃけ楽しいとも感じるのですが、儲けるとか元を取るということを考えると、効率の悪さも感じます。 かつスタロジのように少人数なのに元請けとして全工程を受け持っていると、それぞれの作業、例えば要件定義は年に一度みたいになっちゃいますし、データ移行作業なども同様です。そうすると喉元過ぎればの典型になってしまい、ノウハウなのか一時しのぎなのかの見極めもつかないまま風化してしまいかねません。 一方で、
株式会社マジカジャパンの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ） 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - yvsu pron. yas あたりの話。 自分は地方の零細の下請け会社なわけなんだけど、自分の判断で契約を行える自由を持っている。かといって、契約内容については、実はそれほど自由には決められないものだ。 というのは、こっちの話ではなく、相手側の話なのだ。中規模以上の会社と契約しようとすると、おおむね定型の契約方式のいずれかを選択、変更可能なのは一部の数字だけ、ということが多い。 フリーエンジニアになってぶち当たる壁 IT関連と言うのは独立が非常にしやすい。設備投資などがほかの業種に比べ圧倒的に少ないから、自分の技術力を買ってくださいと個別交渉することさえ出来るなら即刻独立することができる。 フリーの身に
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
ITエンジニアはシステムを利用するユーザーの問題を整理・分析し，本質的な問題を探り当て，解決する必要がある。この連載では，現場ですぐに適用できる「問題解決の体系的手法」を基本から解説する。 第1回 問題解決のプロセス--何が問題かを見極め,8つのステップで解決”,ちょっとした配慮を忘れない 第2回 問題の認識--場当たり的な情報収集では失敗,MECEなどの思考技術を駆使 第3回 重要問題の特定--集めた情報を整理して,問題に優先順位を付ける 第4回 問題の構造分析--因果関係図で構造を把握,「なぜなぜ5回」で真因つかむ 第5回 改善目標の設定と解決策の立案--目標設定の4つのセオリーと解決策を生み出す秘訣を知る 第6回 計画と実行--現場を動かす説明の仕方と計画策定の基本を身に付ける 最終回 実行（顧客企業への提言）--顧客が頷き受注が成功する必勝プレゼンテーション手法
佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日本における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役（情報システム担当）として、CIO（最高情報責任者）の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日本のITを巡る状況に大変な危機感
コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ■実務的な国語力が必要とされている 前回「メタ情報とサマリーで『伝わる』ビジネス文」に引き続き、典型的な失敗のパターンから実務的な国語力を身に付けよう。 前回の記事で「こんな説明では分からない」10種類の失敗パターンを列挙した。以下のようなものである。 （1）メタ情報の欠落 （2）要点の分からない見出し （3）複雑な条件の文章表現 （4）分類を表さない名前 （5）過剰な言い換え （6）対称性のない表現 （7）指示代名詞の多用 （8）相互関連の分からない個条書き （9）時系列の乱れ （10）語感と実感のミスマ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新訳 経営者の条件