サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
papanda.hatenablog.com
「組織を芯からアジャイルにする」の発刊に際して、新たなコミュニティを立ち上げます。 長らく組織というもの向き合ってきました。特に、この数年はデジタルトランスフォーメーションの名の元に行われる、組織の数々の取り組み支援を続けてきました。そこで垣間見たのは、日本の組織が直面する「組織的負債」とでも言うべき根本課題です。 次の話で示しているとおり、日本の組織はそれまでの判断基準、価値観である「効率への最適化」だけでは勝負にならなくなっている。しかも、その事実に気づいていながら、これまでのモメンタムに抗うことができずにいる。 www.docswell.com 多くの組織が「最適化」に代わるすべを必要としているのではないでしょうか。効率への最適化だけではなく、組織を取り巻く環境、状況の変化に対応できるようにする。それは、変化への適応力のことです。 変化への適応こそ、ソフトウェア開発の世界が先行して取
4月1日から政府CIO補佐官を拝命致しました。 補佐官とは? https://cio.go.jp/hosakan フルタイムではなく兼務です。メインは従前のとおりとなります。公の仕事になりますから、個人の属する組織とは全く別、関わりなく、業務にあたってまいります。 なぜ、政府CIO補佐官をつとめようと考えたのか、その理由はもちろん前回の記事に基づきます。 papanda.hatenablog.com 「日本のDXを進めていく方面は3つある。大企業と、地方アトツギと、そして残る一つが国である」と考えています。いずれもこれまでの日本社会を支えてきたプレイヤーです。そうした役割がとてつもない逆境に置かれている。それは、これまでの意思決定に基づくところであり、必然と言えるのでしょう。 ですが前回書いたとおり、「過去の栄光の中を、あるいは10年20年後の絶望の淵を生きているわけでもなく、今を生きてい
ギルドワークスの代表を2020年6月でもって退任いたします。 2014年4月からつとめてきたギルドワークス社の代表を退任することにいたしました。丸6年のつとめとなります。 「自分の会社を退任するってどういうこと?」と思われる方もおられると思います。ギルドワークスは創業メンバーおよびその設立を後押しして下さった事業会社の出資によって成り立っています。ここまで会社の代表としてその任を果たして参りましたが、ギルドワークス自体は私の個人会社ということではありません。後任についても定めております。その周知については、ギルドワークスの会社サイトで案内します。 退任を決めた理由は、自分の時間の使い方、優先度を変えるためとなります。具体的には2つあります。一つは、家族に向けた時間の優先度を上げることです。私は2006年に転職のため大阪から東京に出てきました。15年近い歳月が流れたことになります。この間、家
デブサミ2019で登壇していきました。 デブサミ2010 デブサミにはじめて登壇したのは2010年のこと。 タイムテーブル詳細|世界は変わった。開発の現場はどうか? Developers Summit 2010 もう10年も前のこと。10年! SIerのこれからのソフトウェアを創る from toshihiro ichitani www.slideshare.net デブサミ2011 それから、2011年。この年は野村恭彦さんと企画セッションをやったんだ。 【18-B-7】未来のために私たちの帆を立てよう from Developers Summit www.slideshare.net 2011年からコンテンツ委員をつとめていました。 創発 未来につながるために 世界に帆を立てるために Developers Summit 2011 2011年は3.11震災があり、東北初のデブサミにも行っ
10年愛用してきたmediamarkerが終わるので記録を眺めてみることにしました。 年別の読了を貼っていきます(登録ではない、読了)。ちなみにkindleで読んでてもたいてい紙で登録してしまってたりと分類はいい加減です。読了数とともに無作為にえいやで取り出した、その年の一冊を書いておきます。 2007年 最初は2007年。読了数は19冊。かわいいものですが12月だけで異常に読んでますね。 例えば、Google Gearsの本を読んでますね。懐かしい。 Google Gearsスタートガイド 作者: 白石俊平 出版社/メーカー: 技術評論社 発売日: 2007/12/06 メディア: 単行本(ソフトカバー) 購入: 1人 クリック: 41回 この商品を含むブログ (15件) を見る 2008年 2008年は14冊。4月以降何していたんでしょうね。デスマだった気がします。 例えば、アジャイル
2017年の後半は書籍づくりをしていました。「カイゼン・ジャーニー」という本が2018年2月7日に出る予定です。 プロダクトづくりを上手くやっていくためにはどうしたら良いか?いろんな問題に遭遇しますね。チームで開発するためにはどうやる、開発チームの外側にいる人達(プロダクトオーナー、ステークホルダーetc)とはどうやる。 しかも、まだこれから周りを巻き込んでいかないといけない、なんて状況(つまり一人きり)だと何からどうやって始めるのか難しく感じることでしょう。 「でも、やるんだ」と。思いに駆られている人に向けて書きました。自分自身のこれまでを思い起こしながら。一人のときはどうしていただろう。はじめてチーム開発をしたときは? チームの外へ越境したときは何が助けになったのか、と。 カイゼン・ジャーニーはソフトウェア開発、チーム仕事するためのガイドラインであり、置かれている状況を変えるための越境
越境という行為は、本当のところ、誰にとっての幸せなのか?と考えていた頃があった。 例えば、現場を変えるために、もっと納得のいくソフトウェアが作れるようになるために、現場改善をはじめる。あるいは、組織内の活動をはじめる。自分の時間を、情熱を、一点に注ぐ。 そして、他の現場は、他の組織は、どうなっているのかと、見聞を広げようとし始める。内のために、外に目を向ける。外との関わりの場にも出かける。結果、世界が一気に、広がる。 広がった世界を前にして、悩みが生まれる。自分が、ここで努めていることは、本当に合っているのかと。実は、ムダなことをしているのではないかと。現場を変えるのか、会社を替えるのか。 意識が高まり、何とかしようと様々活動していた人にほど、延長線上には無かった違う一歩を踏み出す、ということが起きたりする。私がかつていたある組織では、たくさんの尖った仲間たちがいた。当時の社内とSNSには
「仕事に追われない仕事術」これは、なかなか良い本。 仕事に追われない仕事術 マニャーナの法則・完全版 作者: マーク・フォースター 出版社/メーカー: ディスカヴァー・トゥエンティワン 発売日: 2016/10/22 メディア: Kindle版 この商品を含むブログ (1件) を見る 仕事術系の本はとんと読まなくなったけども、知人が紹介しているのを見て久々に手に取る。マニャーナの法則とは、新しく発生した仕事は「明日やる」と決めること。なぜそれで上手く仕事がはかどるのかは、本書を読んでいただくとして、刺さったワードをあげてみる。 ・効率 = 創造力 ☓ 整理 ・忙しいだけの仕事、本当の仕事(目標に近づくための仕事) ・「すぐやる」と忙しいだけの仕事ばかりが進む ・新しく発生した仕事は「明日やる」 ・タスク・ダイアリー ・緊急度の低いタスクからとりかかる ・仕事を片付けることと、仕事に向き合う
デブサミ関西でお話をしてきました。 テーマは、正しいものを正しくつくるです。ギルドワークスという会社を立ち上げて2年半。3年目を終え、4年目に向かうために、一度自分の身をふりかえるにも良い機会になるだろうと、快諾させて頂きました。このエントリーは、発表のふりかえりです。 正しいものを正しくつくる from toshihiro ichitani 今、このエントリを書こうとして気づきましたが、今回の私のお話は、この話のアンサーになっています。 papanda.hatenablog.com 目的に叶うプロダクトをつくるためには「越境する開発」が求められる、という仮説。その検証を2年半続けた結果の報告。それが今回の「正しいものを正しくつくる」でした。 検証はまだ半ばですが(というか、検証を終える時は私がソフトウェア開発から引退する時のように思えますが)、越境という御旗はまだ立ち続け、これからも私達
この夏は、シンゴジラを5回みました。 なぜ、5回も同じ映画を見たのか、そしてこれからも見ようとしているのか、正直なところまだ良く分かっていません。観るたびに何かを思う。何かを思いつきそうな限り、足を運ぶんじゃないかと思います。 5回の内訳は、以下のとおり。 1度目、辻堂の109シネマズ湘南で、IMAX。 2度目、川崎のTOHOシネマズで、4DX。 3度目、飛んで名古屋茶屋のイオンモールで、ULTIRA。 4度目、立川のシネマシティで、極上爆音上映。 5度目、横浜ブルグで、帰ってきたIMAX。 年間通じて、あまりシアターで映画をみることはないので、最初にふらっと入った映画館がたまたまIMAXなだけでした。後から気づくことになるのですが、IMAX素晴らしいですね。大スクリーンとクリアサウンド。確かに音が違うと素人でも分かる。 IMAX上映が終わってしたために選んだULTIRAも良かったし、極上
ペコッターがとってもよく出来ていたのでご紹介。 この時期、と言わず、誰かと美味しいお店に行きたいというのは日常的によくありますよね。それなりにおっさんになってきたので、それなりのお店にいきたい。場所はああでこうで、日本酒が美味しくて...なんて言っているとなかなか決められない。 そう、探せるのは探せる。ぐるなびさんや食べログさんがそれはもうたくさんの候補を教えてくれる。しかし、そこから決めるのが実は厄介。ペコッターというアプリを使ってみると、この悩みを上手いこと解決してくれました。 ペコッターとは? 自分に代わって、他人がお店を探してくれるサービスです。詳しくはこちら。 チャットで希望のお店を即レスしてもらえるグルメ系Q&Aアプリ「ペコッター」 - THE BRIDGE(ザ・ブリッジ) ペコッターの良いところ1 PUSH通知の入れ方が上手い 職業柄、たくさんのアプリを日常的に試していますし
先日、数年前に在籍していたSIer(もともと東京湾の海岸沿いにあったため、仲間内で「海岸沿いのSIer」と呼んでいた)の社内カンファレンスにお呼ばれし、話をしてきました。この社内カンファレンス、元をたとれば私が当時の仲間と拵えたもので、ボトムアップからいきなり立ち上げた、社内ではちょっとした名物イベントになっていたのでした。内容は各回テーマを決めて、社員が技術話や経験談を語るものでした。私が在籍している間に3回開催し、その後は長らく途絶えていたのですが、自分たちなりにリビルドして立ち上げ直した若者たちがおり、最近になって活発に開催されるようになっていたのでした。 「元社員にこんなのがおったよ。何を考えて、何をし、いまこうしているよ」そんな話をして欲しいと依頼をもらい、辞めて久しい私にいまだ声をかけてくれる同朋に感謝し、一も二もなく快諾しました。自分が元居た場所に、何かおみやげを持っていけな
世の中には様々な境界があり、それによって個別が生まれ、成り立っている。境があるからこそ、認識・理解できる範囲を絞り込める。その中で何をすべきかわかりやすくなる。 境の外側に踏み出した時は、何がおきるのかすら分からない。外側には不確実性とリスクと危険が待ち構えている。内側にいればおおよその予測ができ安全だ、といえるかもしれない。 本当にそうだろうか?本当に内側は安全なのか。内側こそが自分の住むべき場所だと、いつ自分で決めたのだろうか? 一つの部門にのみいると、部門の外は見えづらくなるだろう。 一つの組織にのみいると、組織の外は見えづらくなるだろう。 一つの働き方だけだと、その働き方以外は見えづらくなるだろう。 一つの生き方だけだと? いったいぜんたい、私達は何をしたいのだろうか。 どこに行きたいのか、どこまで行きたいのかによって、どうすべきかなのか変わるはずだ。そもそも外か内かは、自分を含め
本日登記をし、会社を設立しました。 ギルドワークス株式会社 引き続き、ご指導ご鞭撻のほど宜しくお願いします。
デブサミ2014で「越境する開発」という話をしました。発表時に使用した背景画像はslideshareに置いてあります。こうして読み返すと、デブサミで伝えたかったことは、このスライド自体には無いように感じます。伝えたかったことは、あの日の雅叙園のあの場所に置いてこれたのだと思います。 越境する開発 -Final Bordar- from toshihiro ichitani デブサミ2014のテーマは、「Story」だったので全編自分の物語を話しました。自分自身の話をするのだから、所属ではなく自分の身一つで話そうと思い、今回は「所属無し」で発表者情報を事務局に出していました。ところが、当日の発表5分前、壇上にあがって、気が変わりました。急いで、袖にいた方に伝えました。 「所属は、永和システムマネジメントとしてください。」 この物語は、私が永和システムマネジメントに居たからこそ紡げたものでした
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術 作者: 細川義洋 出版社/メーカー: 日本実業出版社 発売日: 2013/09/27 メディア: 単行本(ソフトカバー) この商品を含むブログ (4件) を見る 献本頂きました。なぜシステム開発は必ずモメるのか(以下、モメごと本と記す)。実は馴染みがある本です。というのも、「リーン開発の現場」を探して書店を回っていたとき、結構な頻度で隣に配置してもらっていたためです。 さて、こちらの書籍、書き手はIT訴訟の調停委員をされていた方ということで、法的観点からソフトウェア開発のさまざまな問題やリスクを評価、対策を解説する内容になっています。当然ながら法的な解釈については説得力があり、だいたいにおいて「まぁ、そういう判断になるんやろうなぁ」という妥当感があります。 モメごと本の中で主人公がたびたび口にするように、法的判
2つのお話をしました。「越境する開発」と「境界なき現場を、行け」の2話です。 越境する開発 from toshihiro ichitani 境界なき現場を行け from toshihiro ichitani どちらも「リーン開発の現場」から最も届けたい言葉を元に作っています。「越境する開発」の方は、現職の2年半で積み上げてきたことをまとめた内容になっています。ふりかえる良い機会になりました。「越境」するための作戦を述べたものが「越境する開発」のお話です。 一方、「境界なき現場を、行け」はAgileSamuraiBaseCampというカンファレンスの締めのセッションで、参加された方の明日の一歩を少しでも支えられるようにと作ったお話です。何かを現場で始めよう、試そうとするその一手が難しいことはよく分かっています。だからこそ、ああせいこうせい、信じていけばいいんだ、とカンタンに締めるわけにはいか
「各自頑張ってください。」 やや照れくさそうに、トークの最後はその言葉で締められた。10月28日にサイバーエージェントさんをお借りして開催した「リーン開発の現場」の出版イベントでのことだ。最後の言葉がしばらく耳に残った。その言葉を頼りに自分の記憶を辿ってみると、ある出来事が思い出された。 それは2008年10月31日のことだった。出版イベントの実に5年前だ。当時私は友人の同僚と2人で「アジャイルプラクティス」の読書会を社内で開催していた。その締めくくりとして監訳者の2人を会社にお招きしたのだった。最後の読書会も終えて、その懇親会で私は恐る恐る監訳者の1人に話しかけた。その時、監訳者の方とは"持ち場"の話をした。自分たち一人一人が"持ち場"を持っている。それぞれが大切にするものは違うかもしれない。それを大切にすることは、決して楽ではないはずだ。様々な問題が待ち構えている。しかし、自分の抱える
2009年ごろ、所属していた海外沿いのSIerにて、社内の組織を超えた繋がりを作る目的で、社内イベントを開催していた。この開催の後に、自分が残してたエントリを覗いてみて驚いた。 このイベントに込めた思いが、この会社が続く限り、 生きていて欲しいと願う。 これを読むと、すでに自分がこの回で社内イベントの開催を最後にするつもりだったのが伺い知れる。この社内イベントは、100名くらいが参加する、手作りのカンファレンスで、もともとデブサミに触発されて始めたものだ。社内にデブサミのような、自分たちの技術や知識や経験、そして熱さを存分に語る機会を設けようという思いから始めて、この2009年で第3回目を迎えていた。 2008年にはenterprisezineに取り上げてもらった。 身近な仲間と繋がり、刺激を与えあう「社内デブサミ」はいかにして生まれたか 実際のところ、2009年以降社内版デブサミが開かれ
わかりやすいアジャイル開発の教科書を読みました。この本の著者の皆さんは関西の方で、いずれの方ともコミュニティにて繋がった方々でした。前川さんには、私が企画した東京の方のイベントでお話を頂いたり、細谷さんとも同じくイベントや本作りでお世話になっています。西河さんには、昔私が関西で開いたイベントに来て頂いたことがありました。お三方ともソフトウェア開発に真摯に向き合っている方々で、私が開発コミュニティに顔を出し始める前から活動をされていて、尊敬する先輩諸氏です。身近に感じる方々がアジャイル開発の、教科書と銘打った書籍を出されると知って、これはどうしても読みたいと思いました。先輩諸氏がアジャイル開発についてどんな言葉を残すのか。どんな言葉を日本の開発現場に届けるのか。楽しみでした。 本には、様々な工夫が凝らされていました。まずは、構成から。冒頭のテーマは「なぜアジャイル開発なのか」です。Start
既にサービスの企画書があって、ソフトウェアとして何を作るべきかを考える状況でも、LeanCanvasが使える(LeanCanvasの詳細についてはこちらをどうぞ)。企画書の内容をLeanCanvasの各エリアに書き出していって、空欄のままになっているエリアや、内容が不足しているエリアを特定する。これから作ろうとしているサービスに、該当エリアの検討は必要ではないか、企画者と会話すべきポイントになる。 Canvasがある程度埋まった状態で、その内容を揺さぶる際には、どの課題がどの提供価値に対応し、どの提供価値がどの手段で実現できると想定しているのか、関係を確認したくなる。Canvasのままで関連を確認するのはやや煩雑になるので、関連表を別途用意してチェックしてみると、理解がすっきりした。 まず、軸は課題に置く。CanvasのProblemから課題を移してきて、今挙がっている課題の他にそもそも抜
私が今の会社に入ってすぐに始めた活動に、ソフトウェア開発の入口を揃えるというものがあった。開発の入口を揃えるとは、どういうことかというとお客様と開発会社がソフトウェア開発を始めるときの認識や状況を整えましょうということ。たいてい、必要なソフトウェアについての何らかの企画・コンセプトがあって、さらにブレイクダウンされた要求が記述されたドキュメントがあったり、もっというと画面仕様書までお客様が用意している場合がある。ただし、それらを開発側が受け取りすぐに開発に取り掛かれる状態になっているかというと、なかなか難しい。「画面設計まで終わっていて後は作るだけです」というフレーズをこの世界に居る人達なら、たいてい聴いたことがあるのではないだろうか。現実には、要件定義とは何だったのか、から考え直すことを迫られるわけだが。とかく、この認識と状況と期待がお客様と開発で一致していないことには、引き受ける開発も
2012年8月、Agile2012に参加してきました。Agile Conferenceはその名のとおりAgileをテーマとしたカンファレンスで、世界中から参加者が集まるグローバルなカンファレンスです。書籍の中でしか会えないと思っていた著名な方々も多数集まる。スコット・アンブラー、ジム・ハイスミス、メアリー・ポッペンディーク、ヘンリック、エトセトラエトセトラ。いずれも、最高のヒーローたちだ。そう、Agile Conferenceは、Agileのアベンジャーズが集まる場なのだ。そういう人たちが、たいていセッションを持っていて、成果や新しい発見について披露する。参加者は、5日間さまざまなAgileストーリーに浸かることになる。極上の時間だ。 会期中のセッションやカンファレンスの様子についてはManasLinkのレポートページで確認することができる。今回、私は、藤原大、伊藤さん、及部くんとレポート
常々、主催者の岩切さんが言っていた「デブサミは10年続けようと思って始めた。」の10年目を迎えるということで何とか全力で打ち返せるよう、今年もコンテンツ委員を務めました。思い起こせば、私がデブサミに初めて参加したのは、まさにその初回にあたるデブサミ2003なのである。驚いたことに、デブサミ2003のサイトが今も残っている。 Developers Summit 2003 デブサミとは何だろうか。10年前は今ほど勉強会のような場は無かった。それが今やカンファレンスのような大規模イベントが月に何回も開催されたりしている。こういう状況で、講演者が基本的に一方的に話す、デブサミはどういう役割を持っているのだろうと何度となく考えてきた。コミュニティの立場で参加するようになってからは、そんなことに考えを巡らすことも少なくなっていた("コミュニティとして参加する"という理由があるから)。 ところが、今年の
HangarFlightでの発表でも話したけど、インセプションデッキがあの時あれば…ということに 気づくことがある。例えば、顧客が開発における要求の、優先事項を決めるという話。 何が優先事項となっているかは、顧客が中心となって決める。ところが、顧客がその判断のために 十分な情報を集めているという保証は当然ながら無い。判断のために十分な情報を得ているか 確認する、さらに、仮に情報量が不足しているならばそれを補うよう、顧客側に働きかけるまで 開発側が動くことは、なかなか容易なことではない。なぜなら、自分自身で作っている前提 (この場合だと、"顧客は自分が判断するために必要な情報を得ている、という前提")を発見し、それを 揺さぶれるかどうかなのだから。 ところが、2011年の開発の現場を生き抜く、我々はインセプションデッキを既に手にしている。 インセプションデッキを構築する過程で、このシステム開
1年前のことだったが、とある事情で東京を離れる覚悟をしたことがあった。 そうなると、DevLOVEをどうするかを、自ずと考えることになる。 DevLOVEというコミュニティは、いろいろな人が船頭役となって活動を行っている。 多様性を保存しながら、結集性も持ち合わせる。相反する状態のバランスを取る ことに、注意を払ってきた。 持続可能な勉強会エコシステム View more presentations from toshihiro ichitani だから、パンダが一匹居なくなったとしても、DevLOVEというコミュニティがたちまち 活動を止めることは、ありえない。 ただ、様々な活動は、その躍動と調和を生み出すために、注意を払う必要がある*1。 なすがまま、放っておけば良いほど、人の集まりは簡単に成熟しないことを 開発の現場でも、他のコミュニティでも、学んできた。 割れた窓はやがて大きな事件
via kakutani 永和システムマネジメントに入社した経緯は140文字では足りないし、それが1200文字になっても 足りなさそうなので、まずは、このあたりでお茶を濁しときます。 大事なことは、私にとってこれから上野で仕事をすることはとてもウキウキで、もう週明けが楽しみ だってことさ。
先日、とある集まりで出会った方と 「ダイアログは確かに良いものだけど、なかなか次の行動に繋がらないのでは。」 という話をしたところ、確かにそういう面はあるかもしれないとして、なので、 「体験することで、行動に繋がることもあるかもしれない。」 という言葉を返してもらった。 ああ、なるほど、それは昨今よく開かれている「ブートキャンプ」*1を指すの かもしれないな、と思い、自分たちがどうやって学んでいるのか、 整理したくなった。 幸いにして、コミュニティの運営に長く携わっているので、その切り口だと 考え易い。 結果、こういうイメージになった。 インプットと、アウトプット。机上でやること、実地にやること。 この4つのパラメータの度合いに基づく、4象限で整理してみる。 すると、まず、インプット・アウトプットどちらの面も持ち合わせる ものがあり、これをインアウトとしてプロットした。 図のとおり、「机上
先日、就職先をきめた大ちゃんと仲間何人かで飲んでいて、彼の 「なんでみんなブログ書かないんだ。」 という一言を受けて、そういえばブログを書く習慣が無くなって、久しいことに 気づいた。ブログを書かない代わりに、twitterやfacebookで何かを書く欲を 消費している。 Google Readerで、ときどき他の方のブログは見ているのだけども、一頃に 比べると未読の数があまりたまらなくなった。 1週間も放置すると、爆発的にたまっていた未読が今は1ヶ月でも読める程度に しかたまらない。 確実に皆、書く量は減っているよね。まーいいじゃない、twitterとかあればさ。 なんて、大ちゃんに言おうとしたら、彼は 「友人知人の近況とか何考えているか知りたいからね。」 だから皆ブログ書こうよ、と言う。 なるほど、確かに、twitterやfacebookでは見逃していることの方が多いからなぁ。 それに
次のページ
このページを最初にブックマークしてみませんか?
『The Dragon Scroll』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く