構成要素。構成部品。
コンピュータの分野では、機能をもったプログラムの部品(ソフトウェアコンポーネント)や、ハードウェア部品などをさす。
UML においては、システム内の物理的で交換可能な部分。インタフェースを実現するもの。ビット列として存在するもの。
実行形式モジュール(EXE ファイル等)・ライブラリ(DLL 等)・データベースのテーブル・ファイル・ドキュメント・ソースファイル・実行時にインスタンス化されるオブジェクトなど。
コンポーネント用の標準ステレオタイプとしては以下がある。
適応型ソフトウェア開発では、フィーチャーの集合のことをコンポーネントと呼ぶ。 オブジェクト群・ビジネス上のフィーチャー群・GUI・コンテナなど。
主要コンポーネント(機能を提供するもの)・技術コンポーネント(ネットワーク・ハードウェア・OS・RDBMS 等)・補助コンポーネント(それ以外のもの)の3種類がある。
会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。
社内にはコミットメントをコアにした管理手法もあり、 その優位性は十分に認めている。 しかし、単純にガンチャートがすきなのである。 特に見た目、がね。 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より
とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。
ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。
ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。
どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。
コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。
逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。
ソフトウェア開発で線を引いてみたときの感想
現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。
必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。
ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。
Visual C# 2008 Express Edition で Windows インストーラ 3.1 と、.NET Framework 3.5 SP1 を「アプリケーションと同じ場所から必須コンポーネントをダウンロードする」ような ClickOnce アプリケーションを発行するための設定。
以下 C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages を %Packages% と書くこととする。
※1: 以下折り返さないで1行で 3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D5 26C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD 9706D05744765CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2 B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E395 8977609BE7AD77C1378D33142F13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D50 74412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F2 7B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001
昨日ホーマック(ホームセンター)に行ったついでにマルシンの「スーパークリーナー万能Jrくん」を買ってきて、昨日と今日とでキッチンのシンクと風呂の鏡と握りバーの掃除に使ってみたところピカピカになって感激した。
今のキッチンはシンクにクレンザーとか研磨剤入りのもの使いたくないなあと思って、デイリーのお手入れだけして1年以上経ったんだけれど汚れが落ちなくてだんだん汚なくなってなってきてしまっていた。でコンポーネントキッチンの取扱説明書をみたらこれがおすすめ便利グッズとして掲載されていたので買ってみたと。ちなみにシステムバスルームの取り扱い説明書にもこれが紹介されていたので、それなら違いないと思ったわけ(しかし実はキッチンはサンウエーブ → LIXIL で、バスルームは INAX → LIXIL であれっと)。
感じとしては靴クリームのような感じ。スポンジか布につけて綺麗にしたい面に塗り、汚れが浮いてきたら擦って汚れを落とす。
シンクのずっと落ちなかった汚れは何回か繰り返すことですっきり落ちてピカピカになった。
しばらくサボっていたレンジフードの掃除にも使ってみたけれど、固まった油汚れも万能Jrくんをつけてちょっと待つと取れるようになる。仕上げに水洗い不要なので助かる。ただ、つける・ちょっと待つ・こすって落ちなかったらもうちょっとつけて繰り返すというのレンジフードだとちょっと大変なのでこれは別の洗剤の方が良いかも。
風呂は鏡と握りバー(シャワーのスライドフックがついている棒)の掃除に使ってみた。鏡のウロコ取りというと研磨剤系が多くて躊躇するのだけれど、万能Jrくんは研磨剤が入っていないのでその点は安心できる。こちらもほぼ綺麗になった。ただ1回では落ちなくて何回も繰り返しつけてはスポンジでこするのを繰り返した。まだちょっと残っているので以降は定期的に掃除する時に使って落とそうと思う。
あと金属の握り棒についていた、お風呂洗剤やメラミンフォームでは落ちなかった水垢も結構落ちてピカピカになった。これは嬉しい。
そもそもあのバー、シャワーフック用のだと思ったのだけれど取扱説明書をみたら浴槽に入るときの握りバーだったという方が驚きであった。握りバーなんだ。握りバー。
[ 製品レポート ]
「エンジニアチームの様々な経験を、未解決の課題も含めて共有する」というテーマで開催された LINE 株式会社のエンジニア向けイベント LINE DEVELOPER DAY_2015 Tokyo に行ってきた。
会場の装飾やクリエイティブなどお金をかけていてすごいなと。始まる前にプレス向けにきちんと立ち位置や照明まで案内していて、とても行き届いていて運営力もすごい。
細かいところだけれどイベントサイトや事前案内は「LINE DEVELOPER DAY_2015 Tokyo」で当日の会場が「LINE DEVELOPER_DAY 2015 TOKYO」と表記を変えていてどんな理由なのかなというのが気になった。まあどうでもいいことだけれど、物を書くのにちょっと困る。
スライドはシンプルで洗練されているんだけれど、完成されすぎていて素材ぽくも感じた。
全体的に microservices アーキテクチャというのが印象に残るイベントだった。
LINE の成長とサービスなどの紹介。ウォーミングアップ的に聞いていた。
「LINE のグローバルな開発組織や文化について」
ちょっと綺麗にまとめられすぎていて感じがした。泥臭さが感じられない。より現場的な話をぜひ聞きたいなと思った。
ペンディング・先送りされた「cold-case プロジェクト」について、また取り組むきっかけを用意するというのは良いな。
「色々な国の通信各社、様々な環境に対応するために進めた実験や改善方法について」
LINE アプリのバイナリは1つとのこと。各国の事情について「LINE 遠征隊」として現地で実際に使って改善していくという取り組みがきちんとできているというのは素晴しいと感じた。グローバルなサービスではなく国内向けのサービスでも参考にできるな。
ストアのレビューについて、レビュー文章のキーワード分析や変化の把握もきちんとしているとのこと。(アプリではないけれど)化粧品業界などが良くやっているやつか。 この辺りは自分の部署でも取り組んでみたい。
「LINE Platformを支えるアーキテクチャ、組織、文化について」
鶴原翔夢氏による LINE のアーキテクチャの変遷について。
など。アーキテクチャは microservices に移行している。
Abusing も独立したバックエンドになっているとのことだった。abuse 対策のコンポーネント化は考えてはいるんだけれど、サービス毎に要件が結構異なるので本体とどの程度の結合にするかが迷いどころなんだよね。いつかはやりたいところ。
HBase と Redis の話し。桁違いだ。
最近 Java を書かれているようだけれども LINE Creators Market はやっぱり Perl で書かれているとのこと。ちなみにアプリケーションサーバでは Starlet を使っているそうだ。
実際に開発する上で問題になったことも混じえた @tokuhirom 氏らしい語り口のセッションだった。
なみかわじゅん氏。
まずはスタンプ間の(レコメンド的な)距離を計算し、その上でユーザー-スタンプ間の距離を計算するというフローでレコメンドを生成しているとのこと。処理には Hive も使っているらしい。
コールドスタート問題については、Naver Labs と共同研究開発した画像の類似度計算を使って似た絵のものをレコメンドできるようにして対応しているとのことだった。
午後は途中オフィスに戻ったりしながら面白げなセッションを聞いてきた。夕方に歯医者があるので 17:30 まで聞いて退散。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。
今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。
複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。
ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。
フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。
ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。
本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。
スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。
リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。