OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
極北データモデリング: IE問題の解決
経営工学者・川瀬武志氏の数少ない、しかし圧倒的な内容の著書。 「マネージャと一般社員を分けて、前者が後者を管理する体制」を徹底的に攻撃している。 この本で明かされている経営の秘密の一つを書いておくと... 工員に業績に連動したボーナスを払うことは、会社の金の使い方としては効率が悪くもったいないことだ。 いちばんいいのは ラインの仕事を減らして、例えば４時で仕事が終わるようにする。４−６時は業務改善に使わせる。 改善によって、４時で終わる仕事が３時半−３時 ... とだんだん早く終わるようになってくる。ここで、仕事を増やして余裕を取り上げてはならない。 午前中で仕事が終わるようになったら、ラインの工員に臨時ボーナスを払う。そして、また４時までかかるように仕事を増やす。 １に戻る。 この金持ちサイクルに工場を乗せることだ。 このサイクルでは、永続的な改善効果に対して、報償を１回だけ払っている。
生産管理講座 - トヨタ生産方式
トヨタ生産方式とは トヨタ生産方式の全体像は、いまだ公開されたことなく、“トヨタ生産方式”を標榜するコンサルタントによって断片的に知ることができるだけである、と言われている。 1980年代にアメリカで行われた日本の自動車産業研究でも、トヨタ生産方式を理想化し、リーン生産方式と名づけたが、トヨタ生産方式を理解しているかどうかは疑問である。 こんなエピソードがある。かつて米ビックスリーの１つだった旧クライスラーの会長兼最高経営責任者(ＣＥＯ)のロバート・イートンは、94年の年頭会見で、｢我々は日本メーカーに負けない生産効率を実現した。もはやトヨタに学ぶものはない｣と発言した。 コンサルタントを雇ってトヨタ生産方式を自社工場に導入し、大幅な生産性向上を果たすことに成功したからだ。 その数ヵ月後、クライスラーの１人の幹部が｢トヨタ生産方式を完全に学びとったかどうか確かめたい｣と、米ケンタッキー
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
CGIベースからHTMLベースへ移行する際のメモ
目次 2005年6月28日 - 時間がないときの朝の祈り / 2005年6月27日 - 仕事 / 2005年6月23日 - 失敗 / 2005年6月21日 - 今日も仕事 / 2005年6月20日 - 仕事のかけら / 2005年6月18日 - The Hyuki Support Team / 2005年6月16日 - Musical Baton (ミュージカル・バトン) / 2005年6月15日 - RSSに全文入れるときの注意点 / Yuki::Kakeraの修正 / CGIでRSSをフィードする工夫 / アクセスログで移行作業の効果調べ / 2005年6月14日 - 仕事 / 声のかけら。のRSSをファイル化 / 2005年6月13日 - まじめに仕事 / 2005年6月12日 - RSSフィードに全文を入れる / 2005年6月11日 - 二重の虹 / 2005年6月10日 - 自
先輩エンジニアが心得ておくべきこと（前編）
研修を終えた新人たちが現場にやってくる。皆さんの中には、先輩エンジニアとして彼らを指導する人も多いのではないだろうか。新人を迎え、指導するために必要なのは、相手を知り、自分を知ること。新人と自分との間にあるギャップを意識し、成長の手助けをしよう。それが先輩エンジニアとしての心得だ。 新入社員を迎えるに当たって こんにちは。「5月病」の時期も終わり、いよいよ梅雨に入ろうかという季節になりました。皆さんの部署には、今年は新入社員はいらっしゃいますか。ここ2～3年の緩やかな景気の回復に伴い、いままで凍結していた新卒採用を再開した企業も多いのではないかと思います。6月ともなると、研修を終えた新入社員たちが皆さんの部署にも配属されてくるのではないでしょうか。 新入社員を迎え入れる先輩となる皆さんの中には、メンターやOJTリーダーに任命される人もいらっしゃることと思います。新入社員を迎えるに当たって、
わたしが知らないスゴ本は、きっとあなたが読んでいる: ブログでプロジェクトマネジメントする10の方法
マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開
＠IT：初めてのプロジェクトリーダー（4）開発中、リーダーは何をしている？
1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン（イベント）も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。 納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表（ガントチャート）ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。 どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必
＠IT：開発プロセス標準化への道（2） 開発プロセスは継続的かつ段階的に改善すべし
今回は、継続的、段階的なプロセス改善についてお伝えしたいと思います。皆さんの中には、「継続的、段階的なプロセス改善」と聞くと、CMM（I）を瞬間的に連想される方もいると思います。そのように連想される方は、おそらくCMM（I）を正しく理解されている方だと思われます。ところが、いろいろな方と話をしていると、CMM（I）を何かライセンスのようなものと勘違いしている方が多く、せっかくの良いものが正しく理解、活用されていないなぁと残念に思うことがよくあるのです。ただ、今回は、CMM（I）に特化した内容ではありません。もっと基本的で、しかも、このことをみんなが理解したら、ITプロジェクトの現場がもっとハッピーになる、そんな話です。 究極の目的は、全員の成長 前回、「開発プロセスの標準化は、開発力を高めるための取り組みの1つにすぎない」ということを書きました。そして、標準プロセスは、参照はするけれど絶対
JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]
代表中山陽平 ブログ「苦手意識を無くせばWeb活用はうまくいく」弊社では「がんばる中小企業」のWeb活用をサポートしています。今の時代、第3者である、制作会社や代理店におまかせでは勝てません。同じような商品・サービスが溢れる中、選んでもらうためのコンセプトを立て、それを実現するためにネットもリアルも総動員しながら戦う必要があります。 みなさんが世の中に・自社の従業員に実現したい幸せや提供価値を、しっかりと実現していくためには、みなさん自身が主役になり、私達のような専門会社が側面支援するのがベストです。 このブログでは御社が中心となってウェブ活用できるヒントを配信しています。お悩みの方はお気軽に問い合わせフォームからご相談ください。 最新の記事一覧
![JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e43158a9b02ff4438d55128491865b833395bd4d/height=288;version=1;width=512/https%3A%2F%2Froundup-inc.co.jp%2Fwp-content%2Fuploads%2F2019%2F09%2F9106fa4d7b0fdf2534aa97dea102e186.png)
上司が求めるのは、「カイゼン」であって、「カイカク」ではない。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日のブログで、「上司の頭の中」という話をしたのですが、今日は、じゃあ、上司はなにを部下にもとめるのか？という話。 それは、結局 今ダメな状況を変えるのに、 新しいことや、追加して何かをやるカイカクではなく、 今やっていることを、「自分の権限の範囲で」よりよく変えていくカイゼン を求めているような気がします（自分が上だったとき、下のとき、両方比べて考えると） やっぱり、今の与えられた仕事がこなせないのに、「それは、いまの体制がわるい、こうかえるべきだ」と主張しても、仕事ができないから、言っているとしか思われないと思います。こう受け取られると、いいこといっても（その意見が正しくとも）評価さがると思います（＝自分のできないのを棚に上げて、言い訳してるように聞こえるから）。 今の仕事を
ITエンジニアを続けるうえでのヒント
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■ITエンジニアの経験年数と悩みとの関係 ITエンジニアとしてのキャリアは何年になりますか。連載の第1回の冒頭としては乱暴か書き方かもしれませんが、皆さん、いかがですか。 3年以下であれば、悩みはまだ少ないでしょう。石の上にも3年とはよくいったものです。まずは3年を目安に無我夢中でキャリアを磨いてください。3年持たない人はエンジニアに向いていないのでしょう。多くのITエンジニアを私は見てきました。その中で、ITエン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.lostway.org/~tko/cgi-bin/bakagaiku.rb?bakaid=200509082
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】(後半)
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】