【書評】「業務システム開発モダナイゼーションガイド」を手に取ろう
非効率な日本のSIと聞いては私も反応してしまうので、読みました。結論から言うと、グレートでした。
業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
- 作者:赤間 信幸
- 発売日: 2018/02/16
- メディア: 単行本
本書の主題
「はじめに」で書かれている内容を、私なりに要約します。
日本のエンプラ系SIの商慣習(多重請負構造)における『上流』の仕事のやり方が、ほとんど進化していない。多重請負構造におけるエンドユーザーやIT部門、SI関連会社、SIerが近代化しているソフトウェア開発技術の活用を『妨げる』ようなことをしていては、いつまでたってもその恩恵を「エンジニア」が享受できない。変えるべきは開発の現場だ。
上流工程と下流工程という工程の分断は、そこに属する技術者に対してデメリットが非常に強いのは事実です。自分もSIer時代に、プライムで請けた案件と2次請けのSES案件に入った時では、圧倒的に前者のほうが身になりました。エンドユーザーと同じ目的に向かい、ITプロジェクトを近代化したソフトウェア開発技術や手法で成功させてほしいという筆者の思いが、ビンビンに伝わります。
また、「開発」と名を打ってあるように、要件定義〜テストまで幅広く網羅され、「ここだけは抑えておけ、知っておけ」とポイントをまとめたTipsが列挙されており、新人教育にはこの1冊があれば充分ではないかと思います。Microsoftの方が書いた本なので、大人の事情で要素技術についてはMicrosoftテクノロジーを中心に解説されていますが、この本で学ぶべきでは要素技術ではなく開発手法や考え方なので、問題ありません。
本書に書かれている内容を実践している会社はまだまだ少ないと思いますが、「この開発の進め方はどうなの」と疑問を持った若い方に、是非手にとって欲しい本でした。
人月見積が効率化を阻害するのかも
エンドユーザーに対して人月見積をして売値を決めているので、期間短縮すると売上が落ちます。当社はめっちゃ近代化した開発プロセスになったので、今までより30%速く出来るようになりました。なので、30%引かせて頂きます！とはね、なかなか。効率化を促進すれば生産原価が下がるはずので利幅が大きくなるように思いますが、そういうビジネスモデルをエンプラ系SI関連会社が採用していないのではないでしょうか。
「エンド⇔SIer⇔協力(下請)会社」という商慣習も、極端に言えばエンドユーザーが「この技術を使ってこっちで要件出してプロジェクト管理すれば、SIer挟む必要ないね」となれば良いですが、エンド側にITプロジェクトを運営する体制がない気がします。自分の業務があるので、兼務ですよね。兼務だと手を動かすことが少ないので、ノウハウ残らない印象が強い。我々のようにプロジェクトワークだけに100%のリソースを当てられないので、だったら内製すればってなるんですけどね。
製造原価が人件費である以上、人月をやめるのはかなり難しい。顧客企業の課題を個別のシステムを作って解決するのが受託開発なので、サブスクのように「ちゃりんちゃりん」とお金が降りてくるモデルは極めて難しい。効率化するのであれば「要件からリリースまでの デリバリ・プロセス」しか無いのでしょう。
なので、本書が提起してるように、非効率を解消する鍵は開発プロセスにあるだろうなと感じた次第です。DXを推進するには、この本に書かれているように、要件定義〜リリースまでの一つ一つの工程を見直して、チューンナップすることが「急がば回れ」の解決策かもしれませんね。
業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
- 作者:赤間 信幸
- 発売日: 2018/02/16
- メディア: 単行本
日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について
先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。
でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。
アジャイルと受託開発の相性は最悪では
ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。
10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。
日本のIT業界の未来はSESが切り開くのである
ガイドラインによれば、ビジネスモデルとしてはSESですよね。内訳が個人単位・サービス単位なのかは知りませんが、単価と工数を見積を出して作業委託という体になりますし。レベニューシェア的なモデルは絶対無理だと思います。仮説検証段階で何のレベニューが見込めるのかという単純な話で。DXの実現にアジャイルのプラクティスが必須で、そのための契約スキームは準委任がベストって話を大きく言うと、SESが正義であると聞こえます。
「SESは死ね」派の皆さんはこの動きをどう考えるんでしょうか。「人月商売のIT業界ははっきり言って、まともな産業ではない。」「日本のIT業界のためにSESは消滅するべき」という意見ありました。良いSESと悪いSESがあるのです、みたいな話になるのかなぁ。ダブスタ感が。
ITで達成できる選択肢が格段に増えたことでビジネスゴールを設定する事自体が高度化するので、「双方が同じコンテキストを共有して要件定義をしないと成果出せません、そして、価値を決めるのはユーザー側！イニシアチブを取ろう！」は100%同意です。それがいかに難しいかは、受託開発の現場で奮闘される皆さんにはお分かり頂けると思います。
POを立てられる会社がどれだけいるのだろう
DX実現のための仮説検証型アジャイル的な取り組みで最も難しいのが、ユーザー企業にPOが立てられるかどうかだと感じました。ハイスペックな人材がPOとして立ち回らないと成果出せませんよね、これ。ビジネス要件もシステム要件もどっちも策定・判断・意思決定できるような人材が、失礼ながらITが本業でないユーザー企業に潤沢にいるだろうか？ ITプロジェクトを切り盛りした経験がない・要件定義をやったことがない人が大多数だと思います。
エンジニアを育てることには皆さんやっきになってますけど、POを育てるみたいな話ってアジャイルに造形が深い方々の間でどんな議論をされているだろう。PdM(プロダクト・マネージャ)に集約されるのかな。
自分の理解ではボトルネックになるのはITエンジニアじゃなくてPOだという理解なのですが、違うのだろうか？違ってたら追記して直すので、こっそり教えて。 ガイドラインの策定に貢献された木下さんのnoteにも以下のような記述があったので、自分はそう感じました。
ユーザ企業の担当者が忙しくPOを立てられない場合があるのではないかというような意見もあがったが、そもそもそういったケースではアジャイル開発をスタートしてはいけないのではないかというところに落ち着いた。
IPA の アジャイル開発版「情報システム・モデル取引・契約書」｜木下史彦｜note
このガイドラインを是として推進をされる現場の方には、「正しくプロジェクトを切り盛りするPOを俺たちが育成する、そういうロールを作る」という方向での議論を盛り上げて欲しいです。エンジニアがいくら頑張っても、ITプロジェクトの成功の是非は価値をデザインするロールの人たちの動き方で決まってしまいますよ。
人類に要件定義は速すぎたのかもしれない
業務設計・要件定義等の支援を生業としている中で間違いなく言えるのは、「いきなり！要件定義！」は死に至りやすいこと。ビジネス要件整理してないのにITの話をしても虚無だよねっていう話ですが、「ビジネス要件を整理できる」というこの一文に至るまでの断崖絶壁を感じました。
その背景について掘り下げていきたいと思います。
コーポレートITの本質は情報共有
営業/製造/生産/研究開発/受発注/出荷/人事/経理/総務/法務/情シス... 企業組織にはとっても多くの業務が存在します。業務単位で皆さんが異なる仕事をしているけど、連携は取らねばなりません。その連携を行うためにITシステムがある。メールやOfficeソフトから、業務特化型のシステムやSaaS、グループウェア、古き良き最高のツールである紙媒体。
自分以外の誰かと情報共有しないと仕事が回らないという必然性があるから、使うわけですよね。一人だけでSlack使う必然性は限りなくゼロ。自分だけなら使わないITシステムはたくさんあるはず。なので、コーポレートITの存在意義は情報共有です。
その情報のレベル感や質は、別の議論になります。要件定義の壁だな〜と感じるのは「自分が行っている仕事を分解することが出来ない」という点です。
業務改善＝「自分の時間の使い方を変える」
話を単純化します。
出社して「今日のToDoは...よし、何の依頼も一切ない！今日は自由にやりたいことをやろう！」というケースは、基本ない。メールを打つ、資料を作る、会議に出る、お客様先にいく、色んなToDoがありますけれど、誰かの依頼を起点としているという共通点があります。もう1つあるのが、皆さんのお仕事の結果を待ってくれる人がいる点。誰かに動いて貰う必要がある事が多い。
皆さんお一人お一人が日々業務で使ってる時間は、皆さんの自由意思で決まるものではなく、「誰かに依頼され、終わらせて、引き渡す」という一連の流れで決定されます。まずこれが、大前提。
業務改善を一言で言えば「自分の時間の使い方を変える」になります。先程の「誰かに依頼され、終わらせて、引き渡す」という流れ(プロセス)を変えないと、時間の使い方を変えるのはかなり難しい。自分の自由意思で使える時間は少ないし、自分だけやり方変えるのも難しい。
自分の時間の使い方を振り返って一連の流れで仕事が生まれてくることが見えてくると「ここで良くないことが起きてる」「こんな時間の使い方をしたらアカン」等の「想い」が出てくるはず。PCはだるい、スマホでサクサクやりたいとかでも、全然OKです。多分、わんさかでてくるはずです。
時間の使い方を変えたいという想いがないと、業務改善のコンセプトが決まらないのです。それを最近、痛感しています。
で、時間の使い方を変えるシステム企画を生み出すには、自分の時間の使い方を振り返ることで、ここの道順が良くないのか〜という問題意識がクリアになって、問題の解像度が一定レベルまで上がらないと、ダメなんです。
要件定義？まだ速すぎるのでは？
要件定義という工程は、業務改善のコンセプトが決まり、時間の使い方を変えるオペレーションが設計できて、その上で初めて行うものです。前段の内容が全く煮詰まっていないと、要件定義やっても死ぬ確率は高い。目的と手段が乖離するから。
人類に要件定義はまだまだ速い、だが、やりきりたい。そう思います。
バックオフィスや業務系の話を主眼にしましたが、UXも同じじゃないですか。時間の使い方を変えるおもてなしを提供するもんだと思ってました。
kintoneを活用したシステム内製化支援を開始しました
使いこなせるITを手に入れるシステム企画のノウハウを提供しますので、業務システムをkintoneで作りませんか？ というサービスになります。
今北産業(tl; dr)
- kintoneを使った内製化支援を行います。
- 月額定額制です。
- 使いこなせるITを手に入れるためのシステム企画のノウハウを提供します。
kintoneを選んだ理由
- 初心者でもアプリが作れ、サーバ構築や環境構築が不要。ミドルウェアの管理とかしなくていい。
- 上級者はJavaScriptによるカスタマイズを行うことで、より高度なシステムを構築でき、そのノウハウも多く公開されている。
- マーケットシェアも伸びており、プラグインによるエコシステムの拡大に今後も期待できる。
- kintoneが今後すぐにサービス終了となる可能性は限りなく低い。
初めて触ったのが5年半ぐらい前。その時は「ExcelをWeb化するだけのものか」ぐらいの感覚しか持っていなかったのですが、再入門してみてkintoneの制約が腹落ちし、カスタマイズ方法も確立できたのでkintoneを活用して業務で使うシステム内製化支援ができると判断しました。色んな業務システムを経験する中で「kintoneでいける業務が多い」と強く感じています。
また、当社のような小さい会社は企業継続性の面において弱いのですが、kintoneであればその点も安心です。
月額定額制にしたわけ
定額制にしたのは、システムという動くターゲットをコントロールするためです。
目に見えない成果物を構想ベースだけで見積もって、「これは仕様にありません」「これじゃ業務が回らない」「でも納期は変わらないし料金据え置きでやりきれ」みたいな「ババ抜きのババ」の押し付け合い的なやり取りに終始するのはお互いに不幸なので。
例えば当初は3アプリだけで、3アプリで一旦作って検証して頂くうちに、もう少し管理するアプリを増やして合計8アプリまで行きたいですというような、工数増によって日程が延長する場合は期間延長。これだけ。判断基準を簡単にしたかった。kintone標準では出来ないので、別途工数かかります。工数を計算すると月をまたぎますが、やりますかやりませんか？だけのコミュニケーションです。
プロジェクトのイメージ
- お問い合わせ頂いて、初回MTG。この時は課題のヒアリングを中心に行います。
- 初回MTGのあと、プロジェクト設計及び進め方のご提案を行います。
- 業務ヒアリング・課題抽出・コンセプト決め・業務設計までの構想立案で4w
- 要件定義〜設計〜kintoneアプリ作成〜検証並びに稼働までが、4w〜8w
最大3ヶ月の単位で一旦終えたい。先を見据えた状態だとしても、どこかで「一旦終わり」が必要です。業務アプリケーションは、作ってからしばらく運用しないと次の改善点が見えませんので、リリース出来る最小の単位で段階的リリースを行い、検証を重ねていきます。開発後の運用保守についてはチャットサポートベースですが、応相談。
IT企画力を上げるためのkintone
この内製化支援の主たる成果物は「システム企画のノウハウ」＋「kintoneで動くアプリ」です。自分自身やチームの業務をITを使って変革し狙った成果を出す武器としてkintoneを使い、使いこなすために必要なノウハウ(主に現状分析->構想立案->要件定義->kintoneアプリ設計と実装)を提供します。
kintoneにも限界はあるけど、使いこなせるITという武器を皆さんが持たないと、会社を変える・業務改革をする・働き方を変えるのは、極めて難しいです。
デモを見ただけや無料期間でのお試しをするだけでは、自社にあったかサービスなのかを判断するのは難しい。どの業務にFit&Gapをしているかを見極めるには、現状分析と構想立案という準備が必要ですし、合うか合わないか判断困難なSaaSを使うのであれば、kintoneで袖にあうものを一緒に構築しませんか？
システム企画のノウハウについては公開した資料があるので、参照して頂けたらと思います。
詳しいサービス内容は公開資料として出しています。あわせてご覧ください。
どうぞよろしくお願い致します。
お問い合わせ
- TwitterのDM
- https://quality-start.in/contact までお問い合わせを頂く
- michitaka [at] quality-start.in までメールを頂く
SQL学習オンラインサービス「Start-SQL」をリリースしました
こんな感じで、ブラウザでSQLを書いて環境構築一切不要でSQLを学べるというWebサービスです。
今北産業
- SQL言語のみをサポートしています。
- 環境構築一切不要で、無料でお試し出来ます。
- コンテンツには無料と有料の2つがあり、有料版は”買い切り”で、5000円です。全てのコンテンツがお楽しみ頂けます。
圧倒的にアカウントを買うニーズが強かった
2019年8月頃に「研修サービスのプラットフォームとして」告知をしたのですが、結論から言うと「講師や研修は別にいらん、アカウントだけ売ってくれ」が個人 / 法人共に、圧倒的に多かったため、会員登録/ログイン/マイページ/コンテンツ購入/パスワードリマインダなどの機能を別途付与して、Webサービスとしてリリースしました。
買い切りにした理由
コンテンツを定期的に追加する予定が全く無いためです。月額制にするならほっといてもコンテンツが増えていかねばなりませんが、SQL言語に新しい標準構文等が出てくる気配がありません。このサービスを作るにあたりSQLの入門書はあらかた目を通しましたが、初版10年前の本と今年に出た本で書いてある内容、ほとんど変わっていないですしね...
Merry Chrismas!!
年末年始の自学自習に間に合うよう、12月25日のリリースを目指して準備して参りました。SQLは学習コストが低いのに応用の効く言語ですし、みなさんがお使い or 運営に携わっているWebサービスや業務システムへの理解も深まると思います。SQLを学べば、システムから好きなデータを取得できるようになります。
サービス案内ページはこちら
突撃! 隣のコーポレート・エンジニアリングっていう連載企画、どうでしょう。
あるWebメディアさんに「色んな会社がどうやって組織を円滑回すためのITを組んで会社を回しているのか、総務的かつ技術的な視点で刺激を与えるシブ知な連載どうですか」と持ちかけたんですが、まずは取材先や読者層がどれだけいてくれるのかってのが知りたくて、このブログで取材先を公募をすることにしました。
コーポレート・エンジニアリング is 何
非常に簡単に言えば、会社の運営上の問題をITを使ってどうやって解決して、組織の運営を最適化していくのか、それを支えるエンジニアリング組織をどう作るか、という活動です。私は、そのように定義しています。プロダクト開発のあり方を考えるのではなく、組織運営のオペレーション設計やあり方を考えるのが主眼です。
で、まぁ結局すべきことって1つしか無くて「オペレーションの改善と改革」です。自分達がやっているタスクを、正しいやり方に再定義して、みんなが働きやすい環境を作り、会社の運営をヘルシーにする。こういう流れというかサイクルを作って回す仕組みを、ITで用意する。そのITがハックする対象が、コーポレート(会社組織)になるわけです。
「IT技術を使って、人に依存することなく働き方を変えて、会社を変える・良くする仕組みを考えて、実行に移すこと」
自分がずっとご業務システム畑にいたこともあってか、こういうITの使い方をもっとやりたいな、知りたいなっていう思いが、とても強いです。
業務のDXと事業のDX
ITを手の内に入れる(企画から運用改善までのサイクルを、自社で管理できるような体制をつくる)のが、DXなるものを実現するための骨子。これは及川さんの著書「ソフトウェア・ファースト」で書かれていた定義です。
ただ、私の中では「事業やプロダクトを開発するDX」と「業務やオペレーションを改善し、組織運営のインフラを開発するDX」の2つがあると思っています。前者と後者は、どこかで融合するといいますか、結節するポイントがあると思ってて。ラグビーでいうとフォワードとバックスのような、そんなイメージを持っています。バックスがトライを上げるために、コーポレートが前でスクラムを組むわけですわ。プロダクトが生み出す価値と、組織改革として生み出す価値が交差する議論をしていく中で、エンジニアリングの幅を広げていける刺激を提供したい、そんな風に思っています。
取材先の会社さんを募集します
取材させて頂きたい内容としては、以下の通りです。
- 事業内容
- 総務部門の体制
- コーポレート系のエンジニアの主な業務内容・キャリアパス
- 会社運営上、特にITで解決したいと思っているエリア
- バックオフィス運営のやりがい
- 業務運営でウチはここを工夫しているぜ！っていうアピールポイント
- コーポレート・エンジニアリングに期待すること
- 今後の抱負
これがテンプレになっていて、これをベースに1時間〜1.5時間枠程度で、いろんな議論が取り交わせればと思っています。私が話し手となって、ショーンKのごとく色んな話を引き出させて頂ければと思います。コーポレート部門でエンジニアを活用している会社さんが最も関心が高いと思いつつも、ウチの創意工夫を聞いてもらって手伝ってくれる人を探したい方、一緒にこの企画を運営したい方からのお声がけをお待ち申し上げております。
来週以降、私から個別にDMが飛ぶこともあるかと思いますので、引き続きよろしくおねがいします...!!
掲載先
企業メディアさんが当該企画にJOINしていただけるのであれば、そちらに掲載しようと思っています。特にいらっしゃらない場合は、私が運営しているnoteに掲載します。
プロフィール
「ITプロジェクトの歩き方」の勉強会をやります
先日公開した、下記の資料に対する解説というか、セミナー形式での勉強会を行います。
11.25(月) 19:00〜 場所は赤坂です。
お申し込みは、下記のConnpassよりどうぞ。完全無料です、予約も要りません。入退室自由です。
色んな方にお会いできるのを楽しみにしています〜！
ITプロジェクトの歩き方という資料を作りました
おかげさまで、色んな方に読んで頂けています。参考になれば幸いです。
コーポレート・エンジニアリングに花束を
「コーポレート・エンジニアリング」という言葉があるのを知ったのは、1ヶ月ほど前のことでした。この資料を作っている時に、SpeakerDeckを漁っていたら、メルカリのsorarokさんの資料がヒットして、我が意を得たり、でした。
直訳すれば、「対象が会社のエンジニアリング」となるかと思います。その会社の事業の拡大に耐えうるプロセスを作ったり、円滑に回せるようにしたり、利用するツールやインフラを変えて会社の働き方を変えていく。そういった活動のことをコーポレート・エンジニアリングだと解釈しています。
サービス内容をパクられることは世の常ですが、オペレーションをパクることは極めて困難です。ECを始めるだけなら簡単ですが、仮に毎日のようにネットからの注文があった場合、どうやってそれの在庫を確保して・ラッピングや梱包・出荷・フォローアップ・キャンセル・欠品時の入荷案内などをしていくのかというオペレーションは、皆さんの業務インフラというベースがあり、そこからの創意工夫の結果に生み出されます。それが会社を強くする源だと、私は考えています。
良質なオペレーションを作るには、業務の現場に向き合って価値を作るロールを担うITエンジニアが必要で、先鋒となるのは情シス部門のエンジニアなのかなと思っています。ヘルプデスクで終わってはならない。
とはいっても、アイデアを形にするのは準備が必要だし、仲間を集める必要もあります。エンジニアがいない会社のほうが圧倒的に多いですし。折角立ちあがったITプロジェクトの離着陸がなるべくスムースにできるように、上記の資料を作りました。ここまで事業会社側で準備すれば、描いたToBeとのギャップを最小化できると思います。私のノウハウでよければおいておきますので、好きなようにご賞味頂ければ。1歩でも進む会社が増えたら最高です。
このリリースを見たのも、資料を作るモチベーションの1つでした。XaaSの時代こそ、システム企画のあり方が見直されてほしいです。
案件のご相談はいつでもWelcomeです
企業組織のオペレーション(働き方を)をITで変革するお手伝いをしています。SIerにいたときも、一人情シスやってたときも、独立してからも、一貫してそれをやってきました。組織構成・業務内容・IT環境をヒアリングさせて頂いて「どのような業務"システム"がこの会社にあるべきか」を、共創させて頂けたら。
お手伝いの内容については、こんな感じです。状況によって期待値も異なると思うので、まずは期待値のすり合わせができれば。
アドバイザリー系
手は動かさなくてよく、レビュー中心の立ち回りをご希望されるケース。
デリバリー系
何かしら成果物を作る or 案件やプロジェクトをデリバリーすることをご希望ケース。
- 業務設計からSaaS/システム導入まで、一貫してやってほしい
- プロジェクトを立ち上げてデリバリーまで手伝ってほしい
- システム作って欲しい(パートナーさん紹介することも
ウチじゃ出来ないケースや、より適任の会社さんがあった場合は、そちらをご紹介させて頂きます。
国内アパレルブランド「Hummingbird Project」のオウンドメディアをはじめました
前々から文章やコンテンツを作るのは好きで、それが好じて今のブログをやっている所もあります。
純粋に自分が表現してみたい世界観を実現できるWebメディアを始めてみたいとぼんやりとしていたところ、前職が立ち上げたブランドがとても良い商品を作っているので、オウンドメディアを立ち上げました。
Hummingbirdとは
国内の生産工場や職人さんと、靴下・バッグ・シューズ・帽子等を作っており、そのブランド名称です。主に女性向け。取扱商品は、こんな感じです。一般の方もお求め頂けます。
コーポレートサイトはこちらにあります。見てやってくださいませ。
この商品が埋もれて消えていく＝職人技が消えていく
きっかけは、GW頃に前職の社長と会ってじっくり話したこと、サンプルの商品（一足の靴下）をもらってその品質の良さに驚いたことです。おいおい、オレがいたころはこんな物作ってなかったじゃないか、新しいブランド立ち上げたとは聞いてはいたけどなんでこんな物が作れるようになったんだという驚きがありました。
同時に、ブランド立ち上げまでの七転八倒、疲弊した国内アパレル生産現場、凄い職人さんがあってはじめて出来た商品開発の話を改めて伺って、僕の好奇心に火が付きました。
１つは単純に布モノが好き。微妙な違いを教えてもらってから、好奇心が湧いてきました。生産現場や品質への取り組み、デザインや企画などの裏話を、脚色無く伝えていくことが布モノが好きな方には楽しいはずだと思ったこと。もう１つは、エンジニアと同様に卓越した技術が無いと出来ない商品が多くあったので、その技の凄さを伝えたいと思ったこと。話を聞くまでは機械回して作るだけと思っていたけど、そうではなかった。
人件費の安い国への生産拠点の移動（産業の空洞化）とファストファッションの台頭で、作る人は単価が下がる一方。食うために品質の良くない安物をたくさん作るのは嫌だったと、ある職人さんは言ってました。「大量生産で似たような商材を安く作ってばらまく→同質化が激しくなり消費されるスピードも上がってすぐ飽きられる→ものが売れない」という負のサイクル真っ只中で、今更になって国内の産地に目を向けようとか言っているのは草も生えない。だって捨てたのあなた達でしょう。向けたところで横に倣えでセレクトするだけのメーカーに新しい商材を作り上げる力があるとも、思えない。
職人さんの技術があってはじめて出来る仕事があるのなら、僕が出来るのはそれを伝えていくことだなと思った。国内のアパレル生産現場(アパレルは98%が輸入生産)が活性化することはもう無いでしょう。工芸品のような世界になると思います。それならそれで、自分が好きな衣料品を作ってくれる現場にスポットライトを当てていくまで。
ブログを始めた頃のような業界に対する問題提起へをやっていくアツさが、戻ってきました。
本音の情報開示の少ない企業に対する、消費者の不信
梶祐輔さんの「広告の迷走」という本に、こんな記述があるそうです。
「消費の低迷は、本音の情報開示の少ない企業に対する、消費者の不信の表れだ。企業自身の社会的存在証明のためには、自らを語り続けなければならない。」
それだけなのかと思う部分もあれば、確かにと思う部分もあります。おそらく本音とは、自分たちが目指す世界はこうで、そのためにこういう商品を作って、その品質を守るために何をしているのか、を包括的に語ったストーリーなんだと思います。
というわけで、Hummingbird Projectをどうぞよろしくお願いいたします。
ブラウザで学ぶSQL学習・研修サービス「Start-SQL」を作りました
こんな感じで、ブラウザでSQLを書いて環境構築一切不要でSQLを学べるというものです。
PyQ - 本気でプログラミングを学びたい人のPythonオンライン学習サービスで提供した教材の作成、PyQを使った研修を通じて、ブラウザで実行できる環境があると学習効率がすごく良いことを痛感したので、SQL版を用意しました。
「学習コストの少なさと実用性のバランスが最も良いのはSQL」だと考えています。Start-SQLを使えば1日でSQLの基本をマスターできます。
一般個人向けではなく、研修用途に使うサービスです
SQLは言語仕様も20年前と変わらない上にやれることは集合演算しか無いので、定期的に新たな学習コンテンツを提供できないと判断したので、Start-SQLは当社のSQL研修を実行するプラットフォームになります。私が講師をやって、生徒さんがStart-SQL使いながらSQL学ぶという格好です。
個別のRDBMSの環境構築・データベース運用みたいな所は、一切載っていません。純粋に、主要RDBMSで実行可能な標準のSQLを学ぶためのものです。
Start-SQLで学べること
これらを1日で学習できます。また、復習したい時はいつでも復習できます。当たり前ですけど。
- データの選択(SELECT, DISTINCT, CASE-WHEN)
- データの絞込(WHERE, IN, AND, OR, LIKE, NOT, BETWEEN)
- データ集計(GROUP BY、HAVING、SUM/MIN/MAX/AVG/COUNT)
- 複数テーブルの操作(JOIN、EXIST、UNION、副問合せ)
- データ登録(INSERT、SELECT〜INSERT)
- データ更新(UPDATE、JOINを伴うUPDATE、CASE-WHENを使ったUPDATE)
- データ削除(DELETE)
