タグ

ソフトウェアと開発に関するtuneのブックマーク (9)

  • Amazonは最大のハックである「税ハック」と日本のソフトウェア産業の競争優位|決算が読めるようになるノート

    (日時間 2017年8月23日 8:55修正)2点追記しました。 1) 消費税の納税義務と日に恒久的施設を有するかどうかが関係ない点。詳細。 2) Amazon社があるワシントン州内では消費税が無料ではない点。 ご迷惑おかけいたしました。今日は、Amazonのあまり知られていない側面を、一つ読み解いてみたいと思います。それは、Amazonは、営業利益を出して税金を支払うよりも、大規模な投資を継続して、し続けてきたという点に関してです。 最初に申し上げておくと、私個人としてはAmazonがこれまでやってきたことは決して悪いことだとは思いませんし、決められたルールの中で最適な行動をとっていると思います。 従ってこのnoteの内容は、Amazonの税金逃れを批判するという趣旨ではありません。どちらかと言うと、日の自社開発ソフトウェアに対する税制のあり方が、今日の国際競争において、非常に不

    Amazonは最大のハックである「税ハック」と日本のソフトウェア産業の競争優位|決算が読めるようになるノート
    tune
    tune 2019/08/09
    自社利用ソフトか販売用ソフトかで財務上の扱いが違うから費やした工数を厳密に数えて報告しろと、さらなる足の引っ張り合いもかつて経験しました
  • カオスに満ちたソフトウェア開発からの脱却 “愛される職場”を作るためにできること Part1

    2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場であるイベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。1日目のKeynoteに登壇したのは、『ジョイ・インク 役職も部署もない全員主役のマネジメント』の著者であり、Menlo Innovations CEOのRich Sheridan氏。自身のビジネスマンとしての半生と、自社で取り組んでいる組織づくりの工夫を紹介しました。講演資料はこちら 『ジョイ・インク』著者による基調講演 Rich Sheridan氏:を執筆する際には、多くの人に読んでもらいたいと願いますが、ビジネス書の表題に「喜び

    カオスに満ちたソフトウェア開発からの脱却 “愛される職場”を作るためにできること Part1
  • マネジメント視点でのオープンソースソフトウェア貢献に対する取り組み

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、CTOの藤門(@mikanmarusan)です。 Yahoo! JAPANは、インフラレイヤーからユーザーの皆さんとのタッチポイントとなるフロントエンドレイヤーまですべて自社で開発しています。そのテクノロジーの大部分でオープンソースソフトウェア(以下、OSS)を利用しており、Yahoo! JAPANはOSSでできているといっても過言ではありません。そのため、OSSを正しく理解して利用することやOSSコミュニティと共存してさまざまな形で貢献していくことはYahoo! JAPANの持続的な成長につながると考えています。 Yahoo! JAPAN のテクノロジースタックとオープンソースソフトウェア(Yahoo! JAPAN

    マネジメント視点でのオープンソースソフトウェア貢献に対する取り組み
    tune
    tune 2019/02/23
    記事を読む前に想像していた以上にサポート体制を構築していて素直に素晴らしいと思った。自分が企業で推進する立場になった時もこのレベル以上を目標に設定したい。
  • オープンソース製品の「仕様」 - 赤帽エンジニアブログ

    Red Hatの佐藤匡剛です。昨日、Red Hat Forum / Tech Nightにお越しいただいた方、ありがとうございました。 昨日のRed Hat Tech Night冒頭のトークセッションで、id:nekopこと木村さんから面白い発言があり、Twitterでも話題になっていたようなので、ちょっとフォローアップの記事を書きたいと思います。 「これは仕様ですか?」 と聞かれても、たまたま開発者がそうしただけというケースもあり、答えにくいことが多々ある #rhtn2018— 転職しても肉の妖精だった件 (@nanodayo) November 8, 2018 仕様が先かコード書いた人の気持ちが先か #rhtn2018— えいご (@enagok) November 8, 2018 実装がたまたまそうなっているw とても分かる。#rhtn2018— 水無月 忠司 (@longyoru)

    オープンソース製品の「仕様」 - 赤帽エンジニアブログ
  • ANA、国内線の旅客システムをオープン化、34年間のメインフレームの歴史に終止符 | IT Leaders

    30年以上にわたり使い続けたシステムを入れ替える。企業ITに携わる人間ならば、その困難さを想像するのは難しくないはずだ。このほどANAは、8年間の歳月をかけて、国内線の予約、発券、搭乗業務を支える旅客システムをオープン化。34年間、ビジネスを支えたメインフレームに別れを告げた。プロジェクトの指揮官に話を聞く(文中敬称略)。 聞き手:田口 潤 IT Leaders発行人 Photo:陶山 勉 ――今回、8年間にわたる国内旅客システムの刷新という大規模プロジェクトを終えた訳ですが、もともと、いつ頃から検討を始めたのですか? 金子:“次”を考え始めたのは、2000年頃だったと思います。30年以上にわたって、メインフレームを使い続けてきましたが、そのころから限界を感じ始めていたのです。 コストについては、必要経費ですから、それほど問題視していませんでしたが、むしろ、技術者の確保には頭を悩ませていま

    ANA、国内線の旅客システムをオープン化、34年間のメインフレームの歴史に終止符 | IT Leaders
    tune
    tune 2013/11/23
    テスト20万件もあるのか。きっとオープンテストケースの流れが今後来るな
  • 継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)

    Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境

    継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
    tune
    tune 2012/11/02
    「Subversion/Git/Jenkins/xUnitワークの使用は、今日ではその開発組織の技術的な強みではありません。」その通りだけどできてるところは何割なんだろう。
  • ソフトウェア品質向上活動を分類した4レベル、今どのレベルですか?:森崎修司の「どうやってはかるの?」:オルタナティブ・ブログ

    講演や発表での事例、エンジニアコミュニティでの事例や雑談、ブログ、tweet, facebookを見聞きしていると、ソフトウェア開発の目的やソフトウェアの品質向上活動をいくつかのレベルに分けられるのではないかと感じていました。 講演の機会をいただいたので、これまでの私の考えを少し整理して、以下のとおり4+1レベルに分けました。タイトルとアブストを考えた時点では3レベルとしていたのですが、4+1が説明がしやすいと思い、変更しました。セッションの主旨がソフトウェア品質に関するものなので、品質向上活動としていますが、ソフトウェア開発の目的と考えることもできます。 レベル1: 開発関係者が各々の考えで品質向上活動を実施している 開発中のソフトウェアに求められる品質を共有できておらず各々の考えで取り組んでいる状態。使い勝手が最優先と考えて、ユーザビリティの向上に時間を使っているメンバもいれば、保守性

    ソフトウェア品質向上活動を分類した4レベル、今どのレベルですか?:森崎修司の「どうやってはかるの?」:オルタナティブ・ブログ
    tune
    tune 2012/10/15
    区分はまだ推敲の余地がありそう
  • アジャイル開発で『動くソフトウェア』による開発を始めるために必要な考え方 まとめ | mah365

    アジャイル開発においてもソフトウェアを作り始める以上、仕様を決める必要があります。いわゆる要件定義です。ただし、全く新しいものを作る場合と、古いものを新しく置き換える場合とで、やり方を変える必要があります。 新しいものを作る場合 ビジネスモデルはあるものの、それを実現するソフトウェア像はまだはっきりしない・・・新しいものを作る場合には、当然よくあるケースです。 ウォーターフォールとカウボーイスタイル この場合、「全部決めないと開発できませんよ!」というのが一般的ウォーターフォール開発であり、「とりあえず作りながら考えましょうか!」というのがカウボーイスタイルのアジャイル開発です。前者は冷静に考えて不可能(最初から決められたら誰も苦労しない)ですし、後者は手戻りすぎて永遠にローンチできません。 リーンスタートアップスタイル 新しいものを作り始める場合は、リーンスタートアップのスタイルを採用す

    アジャイル開発で『動くソフトウェア』による開発を始めるために必要な考え方 まとめ | mah365
  • ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!

    続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解:既にあるソフトウェアを流用し

    ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
  • 1