タグ

ブックマーク / arclamp.hatenablog.com (5)

  • 作業ではなく、仕事をせよ - arclamp

    この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 (補足追記:この記事は、一緒に働いている/働くことになる若い後輩たちへのメッセージです) 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア(もうちょっとで四半世紀...)の中で学んできたことも含めて、整理してみます。 心構え:作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実

    作業ではなく、仕事をせよ - arclamp
    zetta1985
    zetta1985 2023/01/04
  • 大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp

    2017/12/15(金)にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。 アジャイル開発を支えるアーキテクチャ設計とは 僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。 大きなアーキテクチャ設計:システム間連携のレベル→アジャイルチームの外で実施 小さなアーキテクチャ設計:システム内連携のレベル→アジャイルチームの中で実施 なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。 小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれな

    大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp
    zetta1985
    zetta1985 2017/12/19
  • チケット駆動開発で作業管理はしないほうがいい - arclamp

    先日、2013/3/23(土)に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください(※アトラシアン製品関連のイベントです)。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS(Bug Tracking Syste

    チケット駆動開発で作業管理はしないほうがいい - arclamp
    zetta1985
    zetta1985 2017/09/18
  • アジャイルがダメだと思う7つの理由 - arclamp

    1.全体スケジュールにコミットできない アジャイルはタイムボックス型(一定期間で棚卸しをして、それを繰り返す)のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ

    アジャイルがダメだと思う7つの理由 - arclamp
    zetta1985
    zetta1985 2017/06/13
  • アーキテクチャ設計の難しさについて - arclamp

    アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ

    アーキテクチャ設計の難しさについて - arclamp
    zetta1985
    zetta1985 2017/06/05
  • 1