ChatWorkとPHPと私PHPConference 2017 ChatWork株式会社 田中佑樹
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
BPStudy#120の発表資料です。 board（https://the-board.jp/ ）を立ち上げて事業として成立するようになるまでの取り組みを発表しました。
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
「レイヤードアーキテクチャを意識したPHPアプリケーションの構築 ver2」を発表しました。 #DevKan
2015/09/14に行われたDevLove関西にて「レイヤードアーキテクチャを意識したPHPアプリケーションの構築 ver2」を発表してきました。 このセッションは、PHPカンファレンス福岡で発表したものですが、DevLove関西主催の @yohhatu さんからお声がけ頂いて、再演を行いました。ただ、同じ内容では面白くないので、Laravelアプリケーション構築時に意識した点を掘り下げて資料を改変しました。 発表資料 発表資料は以下です。 アプリケーションコードをレイヤ分けする際に、ただのグループとして分離するのではなく、レイヤの責務を明確にする、そしてレイヤ間の依存関係（処理の流れ）を一方向にするのがポイントです。 さいごに 今回は、3 人のスピーカーだったのですが、発表内容を事前に打ち合わせしたわけでもないのに、私、@s_kozake さん、@OkaHiromasa さんの順に抽象
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーの感想 #RDRAセミナー - プログラマの思索
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーに行ってきた。 要件定義の考え方がすごく参考になった。 感想をラフなメモ書き。 【元ネタ】 さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper 要件構造の見える化 #RDRAセミナー: ソフトウェアさかば リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索 【1】要件定義の問題。 いつまで経っても、システムの全体像が見えない。 大量のドキュメントばかりで、肝心のシステムが説明されない。 分析と言う名の転記作業ばかりで、要件定義が完了しない。 では、どうすればいい？ 要件定義、要件分析では、個人作業は非効率。 レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。 その場で皆で合意を積み上げて進める方がいい。 ステー
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
最近のおっさんたち - steps to phantasien
Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes
継続開発のススメ (@torufurukawa)
変更履歴 2013-02-06 はてなブログから Gist へ移動 はてな記法から reST に変更 概要 とりあえず書き出してみました、これから色々修正します。 こうしたら良いと思う、こうしたら良かったの両方がごちゃごちゃっとなってますが、あくまで考え方なので銀の弾丸ではありません。 @torufurukawa Python 温泉で @torufurukawa と色々話しをしました、いい機会なのでまとめてみます。 自分が色々やっている中で、こうした方がいいと思いますという内容がほとんどです。 @torufurukawa がエントリあげてました、実践的な話しなのでオススメです。 Python 温泉で開発プロセスの教えを乞う 銀の弾丸はない 開発手法にベストプラクティスはありません。環境、仕事内容、人によってそれぞれでしょう。 そのため、今回書かれていることが銀の弾丸になる事はありません。
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
アジャイルフィーバーによる死
アジャイルフィーバーは、一般的に、アジャイルベースのソフトウェア開発アプローチへの移行と関連する時間枠に沿った３つの段階の１つに属するように特徴づけることができる。初期、中期、最終段階である。多くの読者が正しく認識しているように、アジャイルフィーバーの一部は、非常に上手く段階に当てはまるかもしれないし、フィーバーの一部は、ある形で全段階に跨ぐかもしれない、という点で曖昧である。この記事は、 アジャイルフィーバーを完全に分類することにはあまり関心がなく、その症状を識別し、特徴づけることで、できるだけ早くそれらを認識することができ、治療することができるようにすることである。 初期段階のフィーバー 初期段階のアジャイルフィーバーは、集団的で全ての中で最も危険であり、最もかかる人が多く、簡単にかかってしまい、ソフトウェア開発の労力に損害を与える、最高の可能性を秘めている。アジャイルベースの??開発
フレームワークの選定の仕方 - がるの健忘録
いやまぁいろいろあちこちで議論が出てきたので、まとめて。 もちろん当然ながら、以下は「おいちゃんの見解」であって、それ以上でもそれ以下でもありませんので、その辺は踏まえたうえでご覧くださいませ。 端的に「おいちゃんが個人で自分用の物を作る」んなら議論の余地もなくMagicWeapon一択で終わるのですが(笑 つまりは「おいちゃんでない人」や「個人じゃないところで」とか「他人用のものを作る」場合、それ以外の選択肢の可能性も、十分にあるわけです。 ただンじゃ「選択基準」ってのもいろいろとあろうかと思うので、その辺の指針を考える上での、考察状のポイントを少しまとめたいなぁ、と。 とりあえず「一番多くて」「一番痛い目にあう」のが「＊＊ってフレームワークは有名だしよく目にするから」。 類似品として「＊＊さんがいいって言ってたから」。「＊＊のイベントで」とかそーゆーのも同根。 なんで駄目な論拠なのかは
アジャイルサムライ読書会で @troter 先生の話を聞いてきた - 新しいフォルダ (3)
イベントページ http://connpass.com/event/652/ もうだいぶ前なんですけど下書きしたまま清書するの忘れてたとか何とか言う…的なアレで、今更ですがエントリ化しておきます。 感想としては、やはり導入に際して先導者にはそれなりの覚悟とかリソースとか知識が求められるなー、と言う感じ。 とは言えCIというインフラ、自動化のための仕組みは未来の自分やプロジェクトを救うので、挑戦したり修得する価値は十二分以上にある、と言うかもう出来ないじゃ済まされないんだろうなぁ。 継続的インテグレーションって実際どう導入するの 資料 https://docs.google.com/presentation/d/1pfmrMYNS9t6f15TM8HKjGnRxECIaw1YxUNaW-KB_gjU/edit 継続的インテグレーションとは ツールではなくプラクティスの事 コミットするたびに結
スマフォ受託の工数はストーリーポイントで見積もると良い - レベルエンター山本大のブログ
iPhoneやAndroidoといったスマートデバイス向けアプリの受託開発をやっています。 簡単に言うとオーダーメイドのスマフォアプリ開発です。 こういった案件の見積をいくつかやっていて気付いた点は、ストーリーポイント法を使って見積もると効果があるということです。 前提としてスマフォ開発は小規模だということ まずスマートデバイス向けアプリ開発は、 企業情報システム開発やECサイトなどの企業Webサイトに比べて開発規模が小さいことが多いです。 ふつうは数十万円程度、大きな案件でも200〜300万円を超えるような案件は希です。 （それに対して、企業情報システムなどは軽く数千万から数億円に達します。） 小規模の案件ですので、プロジェクトの全工程の見通しが効きます。そのため見積精度を上げやすいという特徴があります。 しかしながら、金額が小さいので細かい見積ミスの影響でも、開発会社にとっては赤字プロ
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
Your mind is the scene of development
