小さな会社ばかりでも困る / 20100306-production-style
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...ループを使わずに1から100までMore... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチ
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
内製する以上は｢すごい｣ものを作らなければ、意味が無い。 - GoTheDistance
孤高というやせ我慢をしながら、会社の経営に直接関わっております。 私のミッションの１つには、会社を回す仕組みを高度化させ本業に貢献する業務システムを作ることがあります。 サラリーマン時代、結構な人が自分の会社の売上があがる仕組みを理解していないことに驚きました。お金が降ってわいてくるわけが無いのに、自分の給与の源泉にさしたる関心が無いものかと不思議に思ったものです。自分が存在する組織の成り立ち・競争原理も理解していないにも関わらず、会社の不平不満を言うだけとはトンデモナイ。 前職は｢人月｣という単位で売上を立てておりましたが、入社して人月単価なるものがあると知った時、自分の売価と自分が手にする給料のあいだには何があるのだろうか、と疑問に思ったものです。自分の給与の数字は売上から｢何か｣を天引きされている数字です。それを知る為には、ご自分の会社の大きな仕事の流れを理解しなければなりません。そ
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
システム業界向け「モデルハウス」開発快調 - 設計者の発言
持ち家を欲しいと考えた人は、たいていモデルハウス巡りをする。その過程で、曖昧だった家のデザインや予算もはっきりしてゆく。依頼すべき業者も決まってくる。顧客が満足できる家を手に入れるために欠かせないもの、それがモデルハウスだ。 ところが、システム業界にはモデルハウスに相当するものがない。簡単にダウンロードできて、簡単にインストールできて、いきなり動かせる業務システムがない。これはおかしい。その異常さを理解するためには、モデルハウスのない住宅建設がどんなふうになるかを考えてみたらよい。たとえばこんな風だったりするのだろう。 持ち家を欲しいと考えたある若夫婦が住宅建設会社にやってくる。担当営業は「わが社はお客さまの持ち家に対する要求をモデリングして、わかりやすくフィードバックします」と言う。何だかわかりにくい言い方をするなといぶかりつつも夫婦が了承すると、数日後、彼らのもとにひとりの技術者が現れ
LingrとRejawサービス終了のお知らせ:Kenn's Clairvoyance
今回は残念なお知らせがあります。 5月末をもって、LingrとRejawの両サービスをシャットダウンすることになりました。いずれのサービスも、すでに新規サインアップは受付停止済み、5月15日までユーザデータのダウンロード依頼を受け付け、5月16日からは新規発言ができなくなり、5月末の完全停止までの間にデータをダウンロードしていただく段取りになります。 今まで支えてくださったユーザの皆さんには、このような結末になってしまい本当に申し訳なく思っています。シャットダウンという最終決定を下すまでには多少の猶予をいただき、営業譲渡などでサービスを存続させる方法も模索していたのですが、受け入れ先を見つけることができませんでした。 2005年の夏にインフォテリアの100%子会社として操業を開始した米国法人のインフォテリアUSAですが、こちらもサービスの終了を見届けた後、6月中に解散・撤収することとなりま
こんなエンジニアはいらない１０個の条件 - すべてのエンジニアへ「明けない夜はない」
仕事以外で、レベルアップしない人→技術の会話もつまんない。 自分の出来ること以外に興味ない人→プログラム、インフラ。両方に興味ない人が多すぎ。両方出来るとかなり引き出しが増えるのに すぐに「リソース」「優先順位」とかいう人→ごちゃごちゃいわずに、前に進もうや。 「期日は？」と聞いてくる人→「いつまでなら出来るけどどうか？」とかいうべき 開発能力が高くても、問題解決能力・意志が低い人→問題解決が開発にも生きるし、サービス提供の志を高く持ってほしい 最新技術を学び続けない人→新しいこと学ばないと引き出し増えないよ いわれたことしかできない人→言われたことだけするのなら、他のエンジニアでも良い デスクトップの汚い人、キーボードショートカットににぶい人→いままで数多くのエンジニアを見てきたが、ほとんどこういう人は作業遅い。 体感とか、感覚で言う人→「感覚的に処理速度が速くなりました」「これでPVが
Groovin' High:三鷹の挑戦 - livedoor Blog（ブログ）
この間、三鷹市図書館システム説明会みたいなのがあって、流れで出席してきた。 このシステム、Ruby on Railsで開発してあって、あまりに上手くできあがったものだから、他の自治体に格安でソースごと販売しちゃおうとしてる。 図書館システムと言えば、傍から見た感じでは国産ベンダー数社で仕事を分け合っている世界に見える。予定調和が起きていて、値崩れしていないというか。そんな風に見える。 そこに、ずばり三鷹市が、全く違うルールを持ち込もうとしている。 だからこういう流れなんだよな。 これまでは、「システムのプロ」がいて、その人たちじゃなきゃできない世界があった。それが、今じゃ開発は開発会社。ユーザーは、システムのことを知らないでいい。みたいな。ヘタすりゃ、情報システム部の人たちでさえ「俺たちは素人だから」みたいなことを、全く躊躇せず口にしたりして。ビックリして、椅子から落ちそうになったことがあ
echo - スポーツのような、チームワークを。
スポーツのようなチームワークを。echo - スポーツのような、チームワークを。 フィールドを見渡しボールを出した。パスが気持ちよく決まり、受けた仲間はすでにゴールに向かって走ってる。このボールはみんなの期待そのもの。彼ならきっと応えてくれる。 プレイヤー登録とダウンロード - 無料でご利用いただけます チームは一つのゴールに向かって。 チームワークは一つのゴールに向かって進みます。もとを正せば一つの大きな仕事です。その大きな仕事を仲間が分け合い達成していきます。echo はチームワークの中で行われる様々なto-doを管理するためのサービスです。数人のチームワークから何百人のチームワークまで、もちろん一人きりの作業でも、自分がやらなければならない仕事を横断的に管理することができます。 ボールのように仕事をつなぐ。 echo では、自分の仕事の一部をチームの誰かに依頼することが可能です。あな
MOONGIFT: » チームワークを大事にプロジェクトを推進する「echo」:オープンソースを毎日紹介
プロジェクト管理、と聞くとどうもお堅いイメージになってしまう。だが実際に期待されているものはそんなことではない。プロジェクトを円滑に進めることが必須であって、メンバーを縛り付けたり、工程を逐一チェックしたりするのが目的ではないはずだ。 一般的なプロジェクト管理とは大幅に異なる画面構成 もっとアクティブに、もっと柔軟にプロジェクトを推進していきたいならechoにチャレンジしてみよう。 echoは日本製のソフトウェアで、スポーツのようなチームワームを実現してくれるプロジェクト管理ソフトウェアだ。 echoはAdobe AIRで作られており、WindowsやMac OSXで動作する。Webサービスであるechoと連動して動作するようになっている。自分がすべき仕事をタスクとして登録し、それを他のメンバーに依頼できるのが特徴だ。 仕事を他のメンバーに依頼できる タスクは準備、実行、確認という3つのス
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
Kousyoublog | ベンチャー企業が残業させてはいけない３つの理由
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
「小さなソフトウェアベンダー」という選択肢 : 小野和俊のブログ
「Eric Sink on the Business of Software」読了。献本感謝。 みんな大好きジョエル・スポルスキーも大絶賛の本書であるが、とても面白かった。 そして、本書で指摘される図星としか言いようのない的を得た指摘の数々がつぼにはまり、読みながら頻繁に声を出して大笑いしていたので、家の中で不審がられた。 私たちは、独創的なアイデアでソフトウェア業界の勢力図を書き換えてしまった人たちや、一夜にして巨万の富を手にした人たちにばかり興味が向きがちだ。 しかし、著者はそれに対してはっきりと「No.」を突きつける。 自分たちのソフトウェア製品を持ち、しかし大企業化を志向しない企業のあり方を、著者は「小さなISV」と呼ぶ。 それを私たちがなぜしようとしないのか、著者は次のように分析する。 1. 私たちはそれを見たいと思わない (巨大なマーケットばかり意識して、ニッチマーケットで優れ
受託のメリット、Webサービスのメリット
このキーワード自体は、最近ずっと考えてたことだったりする。 Webをベースとした技術の受託をやってきましたし、FlashのRIA案件や動画ストリーミング関連で企業システムのお手伝いなどと言った当時のWeb技術の中では先端の方に属するものを商品性としてきました。その後、ペパボに入って自社サービスを提供する立場になって、その両方の良いところと悪いところをそれなりに経験してきたつもり。 受託開発がつまらないなんて言わせない - GoTheDistance を見て、ちょっとアウトプットしてみたいと思いました。 ■受託がサービスに比べて良い点 ・個々のお客様のビジネス推進に関われる。 ・自社では関われない業務、規模やサービスのお客様のシステムに関われる。 ・いろんな最先端の技術に関われる。 ・他人のお手伝いで力を発揮できる人が向いてる。 ・社会的に責任の重いシステムに関われる。 ・会社が違うので書類
技術力とタレント性
最近、文章がスランプで、iPhoneネタ以外書けないのだけど、 優秀なプログラマの給料が低いわけ - ひがやすを blog の答えが、 インタビュー記事（Webエンジニア武勇伝） (ZEROBASE BLOG) エンジニアが特定領域に特化した高い技術を持っているほど、その技術に見合うベンダー水準の報酬を支払えないのがSIerではないでしょうか。構造的に。（※そういう人を「囲っておく」ことのブランディング効果など、間接的な意図で高い報酬を支払って慰留することはあるかもしれません。SIといいつつも意識はベンダー的な会社もあります） ・・・だなぁと思いました。 技術を手段として何かを解決する仕事だけど、実現するものの目的は技術じゃないですしね。 （これはほとんどのWebサービス系企業も全く同じことです。） 技術力の高さが給与に直結することができるのは、そのままずばり技術力の高さが売り上げに直結す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://chikura.fprog.com/index.php?UID=1186645498
作業ログをチームで共有できるシンプルツール『I Did Work』 | 100SHIKI.COM
プロジェクトの時間管理に便利なフリーソフト | ライフハッカー・ジャパン
プログラミングファーストはSIerを必要としない規模の開発には合いそ - そのままなめて