タグ

システム開発に関するichiropのブックマーク (9)

  • 無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき

    はじめに システム開発を効率よく進めるための1つの方法として、システム開発のテンプレートを使用することがあります。 ですが、システム開発のテンプレートは企業内で閉じてしまっていてなかなかインターネットで公開されることはありません。 ですので、システム開発で使用するであろうテンプレート集を Excel で作成して公開します。もちろん無料で商用利用可能です。改変も OK です。 プロジェクト管理用 スケジュール管理などのプロジェクト管理用のテンプレートはなかなかないのですが、プロジェクト管理の補助となるようなテンプレートを用意しました。 プロジェクト管理ツールは、別記事の「フリーで使えるプロジェクト管理ツールまとめ」をご参照ください。

  • 泥臭い受託開発Dev love関西

    2017/12/6 Cybozu Days 2017 大阪 のセッション「みんなが働きたい場所で働けるリモート開発チームを目指してやっていること」の発表資料です

    泥臭い受託開発Dev love関西
  • なぜシステム開発は必ずモメるのか? - 勘と経験と読経

    読書メモ。他人の不幸は蜜の味と言われるが、他人の失敗はノウハウの塊だと思っている。というわけで、ソフトウェア開発の失敗の極みである「IT紛争」に関する「なぜシステム開発は必ずモメるのか?」を読んだ感想。このも、ノウハウの塊になっていると思う。 過去に書いた「失敗」に関する関連記事 成功事例には興味がない - 勘と経験と読経 上流工程の失敗カタログ - 勘と経験と読経 書については著者ブログのこの記載がズバリ内容を言い表していると思う。 ベンダだけではなく、ユーザに対しても行われる様々なアドバイスは、単なるテクニック論だけではなく、ITの導入・開発に必要なメンタリティや責任分担にも及び、付録として付けた解説やチェックリスト等を合わせて読んでいくことにより、おそらく2日でIT開発プロジェクトのエッセンスが学べる内容となっています。 有栖川塔子弁護士が語る"開発におけるベンダとユーザの責任

    なぜシステム開発は必ずモメるのか? - 勘と経験と読経
  • ふつうの受託開発チームのつくりかた

    "Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)masashi takehara

    ふつうの受託開発チームのつくりかた
  • 要求定義の肝

    システム開発がなかなかうまくいかないのは、そのための知識や知恵が世の中に存在しないためではありません。日々、新しい手法や技法が提唱されていますが、それはこれまでの知識や知恵が不足しているからだと考えるべきではありません。実際はその逆で、システム開発をうまく進めるための知識や知恵は、既に十分すぎるほどあるのです。 手法がないと悩む前に、まずは「解の公式」で簡単に解を求めようとする、その心に気づくべきかもしれません。それとも手法を求めるのは「統一理論」を求める純粋な科学的な探究心によるものなのでしょうか。そうだとすれば、その心はシステム開発の一つの局面における重要な資質であることは間違いないでしょう。しかし同じ心が、別の局面ではプロジェクトの足を引っ張ることにもなるのです。 まずはソフトウェア工学や開発方法論についての先達の識見です。システム開発にあくまでも数学的な美しさを求める心には、あるい

  • SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道

    某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか?という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と

    SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
  • staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して

    何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい

    staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
  • なぜ糞システムができあがるか

    納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサルPM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ

    なぜ糞システムができあがるか
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。

  • 1