タグ

ブックマーク / terurou.hateblo.jp (8)

  • Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ

    この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと(業界慣習的に3カ月単位が多い認識) 条件交渉者が人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、

    Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
  • 「零細企業経営にはほとんどの意見が参考にならなかった話」を書けと言われたので - terurouメモ

    書けと言われたので、雑に。人に意見されたことはあまりないつもりだったんだけど、思い出してみたら、結構あったような気がしてきた。 零細企業経営にはほとんどの意見が参考にならなかった話 https://t.co/sUpRX51RJq ポエム書いた。— V (@voluntas) 2020年11月22日 これは是非 @terurou にも書いていただきたい。— V (@voluntas) 2020年11月22日 人の意見は参考になるか? 基的に利害関係のない人間の話は「参考にならん」でいいと思う。逆に利害関係のある人間の話は重要で、それは社員だとか、顧客だとか、株主だとかになってくる(うちは株の100%が自分が持ってるので、株主って自分ですねになるのだけど)。 世間には「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という良い言葉がある通りで、 成功体験をもとにしてくる意見はまず参考にならん

    「零細企業経営にはほとんどの意見が参考にならなかった話」を書けと言われたので - terurouメモ
  • 設計書には何を書くべきなのか - terurouメモ

    設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する) 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案(いわゆる比較表で書いていくのが楽) 検証結果 選定・合意結果(合意した代替策や妥協ラインについても記載する) 詳細設計(どういう実装にするとか、パラメーターにするとか、細

    設計書には何を書くべきなのか - terurouメモ
  • 顧客企業の求人情報から受託システム開発契約の単価を決める話(フリーランス・零細企業向け) - terurouメモ

    準委任契約でシステム開発を受託する際の契約単価、どう決めてますか? 相場といわれる額とか、過去の自分の実績額とか、もしくは自分の生活必要な年収からの逆算とか、勘や経験や度胸に近いもので決めてる人が大半なんじゃなかろうかと思います。ただ、それだけだと単価交渉する際に弱いんで、一例としてそれっぽい算出式を書いてみます。 フリーランスや零細企業が、いわゆる事業会社と直接契約するようなケースと考えてもらえばいいです。 算出式 (顧客企業の給与年額 × (1 + 休暇/残業係数 + 福利厚生係数 + 利益/リスク係数) + 受託側の一人当たりの年間経費) これで年額が出るので、月額単価の場合は 12 で割って、時間単価の場合は 1920 (160h×12)で割ってください。顧客企業側の1日の基準労働時間が8hではなく、7.5hとか6hだったりする場合もあるので、その場合の時間単価の計算は適時修正して

    顧客企業の求人情報から受託システム開発契約の単価を決める話(フリーランス・零細企業向け) - terurouメモ
  • 安定寄りの零細IT会社を作って1年ちょいで得た知見 - terurouメモ

    デンキヤギ株式会社という名のITの会社を作ってから1年強になった。 自社プロダクトを事業の中心に据えたいとは考えているが、まずは安定経営のため受託開発を優先してきたことにより得た知見をまとめておく。ちらほらと「会社を作ってどうよ」みたいな事は聞かれた際に、まともに答えてきていなかったという自覚があるので、その回答でもある。 設立以前から現在までのざっくりの状況 中小SIerでサラリーマンエンジニア歴10年(うち5年ぐらいはR&D部門所属) 名古屋ローカルではあるが、コミュニティ活動はガッツリやってきた方 まずは1人だけの株式会社を設立 設立から1年ちょいの間に社員を2人採用 現時点では受託開発中心で、安定に寄せた経営方針 業績はボチボチ、倒産の危機とかはない程度には良い とりあえず受託でっていくために必要なもの カネ コネ 相場・市況感 ちゃんと仕事を回してちゃんと納品する能力 さえあれ

    安定寄りの零細IT会社を作って1年ちょいで得た知見 - terurouメモ
  • Serviceのライフサイクルの動作確認 - terurouメモ

    ググればライフサイクルのフローチャートが出てくるだけど、念のため動作確認してみた。想定していたのと違う挙動をしたパターンがいくつかあった。 要点 unbind()せずにServiceは停止できない。 テストコード 基的にはAIDLを使ったServiceを作ってるだけ。テスト内容に合わせてコメントアウトしたり。 ITestService.aidl package local.ServiceLifecycle; interface ITestService { int add(int x, int y); } TestService.java ログ取ってるだけですね。 package local.ServiceLifecycle; import android.app.Service; import android.content.Intent; import android.os.IBin

    Serviceのライフサイクルの動作確認 - terurouメモ
  • Android組込みのHttpComponent(HttpClient)の正しい使い方といくつかのtips - terurouメモ

    ブログ等に掲載されているHttpComponentのサンプルコードは、重要なところが端折られて紹介されている(というか間違っている事を知らずに書いている疑惑すらある)ことが多いので、正しいサンプルコードを書いておく。 まぁ、ここだけでなくApache HttpComponentsのドキュメントもちゃん読みましょう。あ、Androidのリファレンスにはロクに使い方が書いてないので、あんなゴミだけ読んでてもダメですよ。 要点 ポイントは2つ。 ResponseHandlerを使ってコードを書く HttpResponseの内部リソースを自動で解放してくれるので、ミスがなくなり、コードも簡潔になる。ブログ等ではHttpResponseを使わないコードもよく掲載されているが、リソースの解放処理が記述されていないことが多いのであまりよろしくない。 なお、ResponseHandlerを使わずに自分でリ

    Android組込みのHttpComponent(HttpClient)の正しい使い方といくつかのtips - terurouメモ
  • Androidでパスワード付きzipを生成する - terurouメモ

    Java Zipユーティリティークラス (Hishidama's Java Zip class)のhmzip16.jarをdarty hackする必要がある。 hmzip16.jarはAndroidで使うことができない ダウンロードしてきたjarをそのまま使おうとすると java.lang.VerifyErrorが発生する。このExceptionは実行しようとしているクラスファイル(バイトコード)がおかしい時に発生するらしい。 仕方ないので、jarを展開してEclipse/ADTにソースをインポートしてみると、InfoZIP_Native.javaでシンタックスエラーが出ていた。Androidでは用意されていないメソッド(java.io.File#canExecute())が使われているのが原因ということか。 仕方ないのでdarty hackする 前述のjarをダウンロードしてきて、アーカ

    Androidでパスワード付きzipを生成する - terurouメモ
  • 1