発注者「簡単なアプリです」エンジニア「簡単か否かを決めるのはお前じゃない」
発注者「誰かiPhoneアプリ作ってくれませんか？簡単なアプリです！！」 エンジニア「簡単かどうかを決めるのはお前じゃない。」 — のり@食べるの大好きエンジニア (@sugi511) 2014, 11月 10 発注側と受注エンジニア側だけでなく、同一社内の営業と開発という部門間でも生じやすいギャップのお話。はた目にはシンプルそうに見える、ちまたに沢山出回っているから簡便そうに見える、だから作るのも簡単だろう。作ってくれませんかと発注側は語るけれど、実のところ開発が簡単か否かを決めるのは発注側では無くて開発側。 数枚、あるいは数行の仕様での発注案件でも、いざ開発してみると山ほどのリソースを投入して数か月かけても終わらないという事案も山ほどある。プログラム、アプリ開発周りで分かりにくければ、料理などが分かりやすいかな。シンプルに見えるけど目新しくて美味しい料理。そこにたどり着くまでにどれほど
芝浦工大など、蓋を開けやすい平行四辺形のガラス瓶を開発 ほか
芝浦工業大学デザイン工学部デザイン工学科教授の橋田規子氏と柏洋硝子（本社東京）は共同で、蓋を開けやすい新しい形のガラス瓶を開発した。さまざまな人による感性評価と計測値などによる客観的な評価で最適な形を模索し、胴体部分の断面を平行四辺形に近い形状とすることで、胴体部分を握った際に力を入れやすくした。力の弱い高齢者や女性、子どもなどでも蓋を開けやすいユニバーサルデザインとなっている。 橋田氏はまず、15種類の既存品を用いて20歳代から80歳代の男女に瓶の蓋の開閉を行ってもらい、「開けやすさ」と「持ちやすさ」について回答してもらう感性評価を行った。その結果、握ったときに手の形にフィットするのが「持ちやすい形状」であり、口から胴体までがなめらかになっているのが「開けやすい形状」であることが分かった。 次に、筋電計による、瓶の開閉時にかかる筋肉の動きの計測や、粘土を用いた力の入り具合の検証を実施。そ
工数の多さは、業務のわずらわしさとは別の話
前回はR&Dマネジメント対象全体を俯瞰し、各改革の一貫性を確保しながら進めることの重要性を包括的にお話しました。今回からは、R&Dマネジメントの体系（図1）に沿って、それぞれの観点におけるマネジメントの失敗事例と成功事例から、今後取り組んでいくべきマネジメントのポイントを見出していきたいと思います。 今回は、R＆D業務推進能力の1つの要素である、組織運営について見ていきます。組織運営の上で、その組織に属する技術者がどのような仕事にどの程度の工数を使っているのかを把握することは、基本的かつ、とても重要なことです。 一方で、このような業務工数管理を行うためには、技術者に工数の実績を計測してもらうことが必要となり、忙しい開発現場に負担を強いることにもつながります。 それでは、技術者にとって必要最低限の負担で、組織運営に必要となる工数管理を行うには、どのようなことに気をつければよいのでしょうか。今
実践！ 進化型すり合わせ開発
連載主旨 かつてものづくり大国と言われた日本が、欧米や中韓に追い上げられています。各社が激しい競争にさらされる中で、既にトップ争いから脱落しつつある業界、企業も見受けられます。韓国の素早いリバース・エンジニアリング（「模倣＋α」）や欧州の「標準化＋モジュール化」戦略に対して、従来の開発のやり方では勝てなくなっているのが現状です。この状況下で、日本の製造業が競争力を向上させるには、「すり合わせ」による差別化領域での技術の作り込み・ブラックボックス化と、「モジュール化」による非差別化領域での効率追求を組み合わせた「進化型すり合わせ開発」で、他国の追随を許さない技術品質と開発スピードの両立を実現することが必要だと考えています。また、それらを実践できる設計者の育成も必要です。本連載では開発現場の現状を共有しつつ、進化型すり合わせ開発について、どのように実践していけばよいかを開発プロセスと人の育成の
ITアーキテクトは何をしているのか
情報システムの「アーキテクチャー」にもっと目を向けるべきではないでしょうか。部分最適の積み上げで全体として必要以上に複雑で歪なアーキテクチャーになっているケース、性能問題など保守・運用上に課題を抱えて事業の採算が合わないケース。筆者の周りでもこうしたケースを見聞きすることは少なくありません。また、ビジネス上の本質的な目的を捉え、目覚ましい進化を遂げるハードウエアを活かすのもアーキテクチャー次第だといえます。 情報システムのアーキテクチャーに責任を持つのはITアーキテクトとされています。その重要性は増していますが、人数が少ないのが実情です。どうしたらなれるのでしょうか。どのように育てたらよいのでしょうか。一つの方法は、ITアーキテクトが実施していることを真似てみることだと思います。 ITアーキテクトが何かをするのであれば、そこには「成果物」が生まれます。そして成果物には必ず目的があります。そ
Team Foundation Server / ServiceでのGitサポート
Getting Started with Git in Visual Studio and Team Foundation Service 今、アメリカで行われているALM SummitでTFServer/TFServiceでGitサポートが発表され、Server向けにはCTPが、Serviceのほうは既にServiceが始まっています。Server側のCTPは現状英語版のみで、製品版では日本語のUIを含む他言語版としてリリースされる予定のようです。 と言うことで、TFServiceを使って早速Git対応プロジェクトを作ってみました。 ログオンすると以下の様にGitサポートのプロジェクト追加のボタンが追加されています。オレンジがまぶしいです。 追加します。 必要な項目を入力します。レポジトリの選択は当然Git。 追加中。 プロジェクトの追加完了。 こんな感じ、いつものTFSです。 Gitで
プログラミング用フォント Ricty
お知らせ Ricty および Ricty Diminished は、2010 年代前半には欧文・和文合成プログラミング用フォントとして先駆的でしたが、現在は前時代的な存在となっています。不具合もいくつか確認されています。良質なプログラミング用フォントが数多く登場していますので、それらの利用をおすすめします。 序文 Ricty（リクティ）は Linux 環境での研究・開発を想定したプログラミング用フォントです。テキストエディタやターミナルエミュレータ、プログラミング言語やマークアップ言語に対する使用に適しています。Inconsolata と Migu 1M の合成、および、プログラミング用フォントとしてのいくつかのチューニングを行う生成スクリプトを配布しています。Inconsolata 作者の Raph Levien 氏、Migu 1M 作者の itouhiro 氏、M+ M Type-1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カシオ:中東で人気 聖地メッカの方角指し示す腕時計 - 毎日新聞
超絶 凄ワザ！ - NHK
Azureテクノロジ入門 2016 目次 - 日経BP書店