読者です 読者をやめる 読者になる 読者になる

フルスクラッチで自分のサイトを作る日々 #0日目

やりたいこと

・最新テクノロジーの話題や、シンギュラリティに関する情報や、自分の意見を発信する。
・各種ニュースサイトやWebメディアの情報を収集し、1画面で横断検索できる情報収集ツール作り。
・最新のフロントエンド技術を自由に試せる環境づくり。

欲しい機能

優先的に欲しい機能

・基本的な記事管理・投稿機能
・登録したサイトの新着記事を自動で取得
・収集した記事の横断検索

余裕があれば欲しい機能

・ログインなしで投稿記事の配信機能
・1日1回の収集した新着記事配信
・サイト閲覧のオフライン対応
・記事投稿のオフライン対応

採用する(したい)技術

・サーバ:ConoHa VPSLAMP
・DB:MySQL
検索エンジン:ElasticSearch
・バックエンド:CakePHP
・フロントエンド:React.js

サイトマップ

トップページ
 - 自分が書いた記事一覧
  - 記事詳細
 - 収集した記事一覧
  - 記事詳細
 - 管理用ページ
  - ログインページ
  - 記事一覧
  - 記事投稿・編集

今後やること

記事収集関連の設計

  1. 対応サイト

環境構築

  1. 開発環境構築
  2. サーバ構築
  3. 自動デプロイ環境構築

記事収集機能の実装

先に作っておけばより多くストックできるので、先に作る。

記事関連の設計

  1. トップページの設計
  2. 記事一覧・記事詳細画面の設計
  3. 記事管理・投稿機能の設計

人生で3番目くらいにオススメしたい本『SOFT SKILLS ソフトウェア開発者の人生マニュアル』

ソフトスキル

『SOFT SKILLS ソフトウェア開発者の人生マニュアル』を読みました。キャリア、マーケティング、学習、生産性、お金、健康、心、の7つの観点から書かれていてすごく参考になりました。「オススメの本は何ですか?」と聞かれたら、『リーダブルコード』『ノンデザイナーズ・デザインブック』に加えて、この本もオススメしたいです。

ソフトウェア開発者の人生マニュアルというサブタイトルですが、ソフトウェア開発者やエンジニアに関わらず、全ての人にとって参考になる本だと思いました。中でも、私が参考になった部分、思ったことについて自分の備忘録も兼ねて書きます。

プロであることについて

『第10章 プロであること』より

プロになって変わるのはマインドセットだ。恐怖、自虐、先送り、自己不信などと戦っているときの問題は、アマチュアのような考え方をしていることにある。アマチュアは目立たない。アマチュアは休む。アマチュアは逆境に弱い。プロはそれとは異なる考え方をする。プロは、何があっても自分の姿を見せ、仕事を勧め、前進し続ける。

どこかで聞いたことあるな、と思いつつもこの章を読みました。働き始めてから2年が経過しましたが、未だに恐怖や先送りと戦っている瞬間があります。『第16章 うまくやり遂げるまではできたふりをしよう』と合わせて、自分がプロであるかのように行動する習慣を付けようと思いました。

恐怖と戦っていても誰のためにもなりませんし、自虐や自己不信は自分をプロからますます遠ざけてしまうと思います。ちょっとしたことから行動を変えて、徐々にプロのマインドセットを身に付けていく必要があると思います。やっぱり、エンジニアとして生きていくことを選んだ以上は本物のプロエンジニアになりたいですし。

ハードワークに対する考え方

私はハードワーク反対派です。長時間働き、仕事に拘束される必要は全くないと思っています。この本を読んでも、その部分については変わりませんでしたが、ハードワークに対する見方が少しだけ変わりました。

自分を会社員としてみた場合は、「長時間働き、仕事に拘束される必要は全くない」と思います。会社員としては、多少長い時間働いたところで、給料がほんの少し上がるくらいのものでしょう。残業したところで進まない仕事は進みません。そんなことしてる暇があったら、より効率的に仕事を進める方法を考えた方が、顧客に価値ある成果を届けるためにもなります。

一方、自分をエンジニアとしてみた場合は、ハードワークも必要だと思いました。とはいっても、会社の仕事を長時間行う、というハードワークではなく、プロのエンジニアになるためのハードワークです。例えば、ブログを書いたり、勉強会に出たり、コミュニティに参加したりなど、自分自身にとって必要だと思うことです。仕事のためではなく、自分自身のエンジニアとしてのスキルを磨くためには、そういうハードワークも厭わないぐらいの覚悟は必要なのかも、と思いました。

ポモドーロテクニック

25分を1ポモドーロとして、1ポモドーロごとに5分、4ポモドーロごとに15分の休憩を挟みながら、タスクを進めていく方法です。この方法自体は、本を読む前から知っていましたが、1回試して長続きせずに辞めてしまいました。

ポモドーロテクニックの本当の力は、作業量を見積もり、トラッキングするためのツールとして使ったときに現れる。

たぶんこれができていなかったので、続ける意味がわからなくなって辞めちゃったんだと思いました。実際、この章からポモドーロテクニックを使って、この本を読んでいくと、あと5時間ぐらいで読み終わる(ポモドーロテクニックについては38章で紹介されていて44章までに1ポモドーロあたり3章ぐらい読めたので、あと27章あり9ポモドーロが必要で、4ポモドーロで130分だから、260+25=285分)、ということがわかりました。実際にやってみると、休憩せずに読み続けたところもあったので、大体4時間ぐらいで読み終わりました。

以前は、Toggl - Free Time Tracking Softwareポモドーロテクニックを使っていましたが、KanbanFlow - Lean project management. Simplified.で試してみると、5分、15分の休憩も簡単にでき、ポモドーロ単位でのトラッキングもできて非常に使いやすかったです。

読みやすさ

『SOFT SKILLS』は付録などを除いた本編が420ページありますが、71章とかなり分割されて書かれています。このことについては、『第46章 ブレイクダウン:先延ばしを克服する方法』で触れられていますが、書いてある通り、少しずつ読み進められるので読みやすいです。技術書や参考書など、買って途中で読むのを諦めたことが何度もありましたが、『SOFT SKILLS』は土日で一気に読むことができました。

まとめ

独学の方法や、お金、健康に関することなど、ソフトウェア開発者に限らずとも必要なことがちりばめられていたので、困ったときに見返す本としてかなり有用だと思いました。あと、自分の観測範囲での、できるエンジニアと筋肉の関連性について、事例がまたひとつ増えました。どうしてエンジニアには筋肉をつけたがる人が多いのでしょうか。よくわかりません。

とにかく、エンジニアな人にも、そうじゃない人にもオススメの1冊です。

ウォーターフォールを徹底的にディスってみる

アジャイル ウォーターフォール

 

ウォーターフォールには何のメリットもありません。とはいえ、まだウォーターフォールを信じている人もいると思います。なので、徹底的にウォーターフォールをディスってみます。

※これは個人の意見であり、私は反対意見が存在することも理解しています。あくまで私はウォーターフォールになんのメリットも感じません、という主旨です。アジャイル信者でもありません。

 

ウォーターフォールとは 

そもそもウォーターフォールとはなんなのか、です。髪型のことではありません。

ウォーターフォールには次の要素があります。

ディスりポイント1 見積りの基準が人月

基本的に人月換算です。単位時間当たりのコストに、開発が終わるまでにかかる時間をかけます。

人間をバカにするな
人の能力ではなく、人が何時間働くかをコストに換算します。能力によって、単価に差はでません。もちろん、会社ごとに単価の値は違うとは思いますが、基本的に同じ単価であれば、誰が働こうが価値は変わりません。

日々、エンジニアとしてのスキルを磨くのがバカらしくなってきますよね。何もしてない人と価値が同じだといわれるのは辛いです。

利益率は向上するのか
これは顧客への提示方法次第ですが、すべての仕事に一律の利益率でお金をもらう場合を考えてみます。

単位時間当たり5000円だとして、利益率50%だと、顧客への提示は10000円になります。2時間で20000円。

俯瞰して考えると、仕事の効率が上がった場合、同じ仕事にかかる時間は少なくなります。顧客のコストは下がるので良いですが、その分提供する側は、数を多くしないと売り上げが伸びません。

同じ仕事なら3時間で1つこなすのと、1時間で3回こなすのとでは、売り上げは同じです。効率上げた意味はあるんでしょうか。より多くの顧客に提供できますが、顧客開拓にもコストがかかりますし、そもそもIT屋さんはたくさんいるので顧客の無駄な取り合いが発生します。

ディスりポイント2 手戻りにかかる時間が長い

時は金なり
手戻りが発生した場合、システムなどの成果物によってもたらされたはずの利益は失われます。

作るほうも辛いし、頼んだ方も辛い。なるべく手戻りによってかかる時間は少ない方がみんなハッピーです。

誰がお金を払うのか

もちろんお客さんです(場合によっては担当者がサービス残業します、ブラック恐い)。その上、お客さんとの関係性が悪化します。

「要件定義で決めた仕様、プログラミングしてみたらやっぱり無理そうなのが分かりました。設計やり直すんで追加で予算とってください。」

頼む側がどんだけ必死で予算とってると思ってるんだ、っていう話ですよね。たとえお客さん側にミスがあったとしても、お客さんはITの専門家とは限りません。ウォーターフォールは手戻りに時間かかるんです、とか言われてもじゃあもっと時間かからない方法でやってよー、となります。

とはいえ、契約はきちんとしましょう。瑕疵がどこにあるのかは重要です。身を守るためにも。

ディスりポイント3 上流が偉いという勘違いを生む

「上流・下流」ということばのイメージ

イメージ最悪です。「工程」の上下が「エンジニアとして」の上下に変換されていそうな人がたまにいます。工程は役割であって、エンジニアの上下を決めるものではありません。

要件定義の担当者だけではシステムは作れないし、プログラミングの担当者だけでもシステムは作れません。

下流に押し付けられがちな体制ができる

なぜか。顧客に対して約束するのが上流からだからです。この要件で作ります、この設計で作ります、と言っている場合、「やっぱりできませんでした」が言いにくくなります。

「この要件で作りますって約束してるから、がんばってね」みたいな人もいると思います。約束を果たすのは自分じゃないと思ってるタイプの人。自分の周りにいるわけではないですが、いたら地獄だなー、と思います。

ともかく、ウォーターフォールでは「できます」って言う人と、「できました」って言う人がわかれてるので、どうしても「がんばって作って」になりがちです。

まとめ

ウォーターフォールが悪いのか
ウォーターフォール自体は悪くないです。ウォーターフォールが適用できることが減った、もっと良い方法が見つかってきている、ということにしかすぎません。

じゃあどうすれば良いのか
結局それかよ、って感じですが、アジャイルでやってみましょう。最高ではないですが、ウォーターフォールよりはまだマシだと思えます。

 

とりあえずこんな感じです。
最後にもう一度書いときますが、個人の主観です。

コーヒーとルーティーンワーク

繰り返しばかりの毎日はつまらないけど、ルーティーンワークは人生を豊かにすると思います。

中でも、何かに集中する、意図的にゾーンに入れるようなルーティーンワークがあると、いろいろな場面で役に立ちます。

学生の時に行っていたルーティーンワーク

学生の頃は、18時に寝て24時に起きてテスト勉強し始め、6時から1時間仮眠を取る、というのがルーティーンワークでした。

割と集中できるようになってましたし、振り返るとけっこう自分に合ってるやりかただったと思います。働きはじめると、こんな生活はできませんでしたが。18時はまだ会社にいますしね。

とはいえ、今でも時間確保のために9時〜10時に寝て、5時に起きるのを習慣にしています。

最初に早起きし始めた時は、せっかく5時に起きたのに結局集中できずに1時間過ぎてるとかが、よくあるパターンでした。もったいないと思ったので、とりあえず眠気覚ましにコーヒー飲むようにしよう、という感じで徐々にコーヒーを飲むことで集中できるようになってきました。

コーヒーの効果

集中したいときや、眠気覚ましにコーヒーを飲む、というのはよく聞く話です。「コーヒー 集中力」で検索すると、集中できるやらできないやらの話がたくさん出ます。

科学的根拠については良くわりませんけど、自分の場合はコーヒーを飲むと集中できます。どちらかというと、カフェインの効果ではなく、コーヒーを飲むこと自体が、集中できるきっかけとして働いていると思います。プラシーボ効果みたいな感じですね。

 

自分の場合はコーヒーですが、コーヒーに限らず、集中力を高めるためのルーティーンワークは持っておくとけっこう使えるかもしれません。

Webエンジニアと勉強会

最近、勉強会に行くようになりました。 仕事でとあるコワーキングスペースに行って、すごく気に入って通い始めました。そこでいろんな人と会って、やっぱりこういう活動とかもした方が良いな、と思ったのがきっかけです。

勉強会に行き始めて良かったこと

いろんな人がいることがわかる

交流が広がります。自分とは違う分野にいる人でも、同じ勉強会に参加していたりします。そういう人たちと名刺交換してみるだけでも、話すきっかけにもなりますし、お互いに知らないことの情報交換などができます。

あと、みんな優しいです。たぶん自分よりも年上が多いからなんだと思いますが、いろんなことを教えてくれます。

自分よりもレベルが高い人の話を聞くことができる

技術を学ぶには仕事が一番だと思います。自分が仕事でやっていることだけで学んでいくのはなかなか大変ですし、自分がいる環境でだけ役立つものかもしれません。勉強会などで、他の人が仕事でどんなことをやっているのか、その中でどんなことを考えたのかを聞くことで、自分の仕事にも役立ちます。

世界は広いので、自分よりすごい人なんていっぱいいます。井の中の蛙にならないように、精進していこうという気持ちになれるので、それだけでも勉強会にいく意味を感じています。

大変だと思ったこと

平日の勉強会の帰りがつらい

勉強会はだいたい平日の19:00から1時間、2時間ぐらいのタイムテーブルです。

普段9:00に寝る生活してる自分からすると終わった時点でもう眠たいです。そこから電車で帰って、となると次の日なかなか大変です。

交通費

勉強会ってほとんど東京なんですよね。神奈川から参加してると往復1000円ぐらいかかっちゃいます。もちろん無料の勉強会でもそれ以上の価値があると思いますが、お財布からお金が飛んでいきますね。

まとめ

最後に、私が使っている勉強会を探すサービスを紹介しておきます。登録するとメールなどで勉強会の情報をお知らせしてくれるので、すごく便利です。

  • ATND
  • DoorKeeper

DevOpsの潮流とWeb制作

アジャイル

日本ではまだあんまりかもしれないが、DevOpsが世界中で流行っているようです。Jenkinsを使っての、自動ビルド・テストカバレッジ計測・自動デプロイなど、CIツールを使って、ユーザーに早く価値を届けることを実現しています。

「ユーザーに早く価値を届ける」このご時世では必須の考えかたです。システム開発の現場では、これを達成するため、様々なツールや開発手法が導入されています。

じゃあ、Web制作の現場ではどうなんでしょうね。

 

早く届ける

この観点においては、**Web制作>>>>>超えられない壁>>>>>システム開発** だと思います。HTMLさえ置けばWebサイトは見られます。多少ミスがあっても動くので、届けられない、ということ自体はほぼないです。

ビルドが必要なく、一瞬で全世界のユーザーに届けられるので、スピード的にはWebは最強のプラットフォームです。

価値を届ける

一方、価値を届けるのは、**Web制作 < システム開発**だと思います。

システム開発では、明確に必要な機能があって、自動テストを使えば、システムにミスがあるかどうかわかります。価値のある仕様になっているかは人間が判断していますが、仕様通りになっているかは機械的に判断できます。

Webサイトでは、明確な要望があり、自動テストすればある程度はミスがあるかわかります。リファクタリング前後でのスクリーンショットの比較とかできますし。

でも、Webサイトだと人間が判断することがシステム開発よりもかなり多いです。この点で、Webサイトはシステムに大きく引き離されていると思います。

Webサイト制作にDevOpsをもたらすには

ディープラーニングとか、AIとか流行ってますよね。そういうの活用して、システム開発と同じように、サイトが仕様通りかどうかを判断できるものがあればWebサイト制作の世界は大きく変わると思います。

Webサイトにとって仕様通りか、と言えるのは、ユーザーがお問い合わせなどのサイトの目的の箇所に行ってくれるか、ということです。何かしら人間の感性をもとに判定できれば、DevOpsを実現できるんじゃないでしょうか。

 

 

ウォーターフォール vs アジャイル

アジャイル

いったいいつまで日本はウォーターフォールで消耗しているんでしょうか。アジャイル開発に対しての日本の態度は、イノベーター理論で言うところのレイトマジョリティもしくはラガードだと考えざるを得ません。

Google検索しても出てくるのはアジャイルの導入について描かれている記事ばかりです。今は仕方ないとは思いますが、10年後になっても今と同じような状況だともう手遅れ感がありますね。

一応、タイトルでは「ウォーターフォール vs アジャイル」としているので、それぞれのメリットを書いておきます。個人の主観なので、反対意見もあると思います。

アジャイルのメリット

  • プロジェクト全体で手戻りを最小に抑えられるようにチームが機能すること

たくさんありますが、僕が1番メリットだと思うことです。プロジェクトが炎上している原因は、ひとことで言えば手戻りです。手戻りが発生するまでには、認識の齟齬や、顧客からの仕様変更、政治的な問題など様々あると思います。

アジャイルでは少なくとも、認識の齟齬はこまめな顧客レビューで解消し、仕様変更に際しても他の機能とのトレードオフを提案できます。政治的な問題に対しても、アジャイルなチームでは、チームの障害を取り除こうとする機能があるので、ある程度は緩和できるでしょう。

ウォーターフォールのメリット

ありません。少なくとも僕はウォーターフォールになにひとつメリットを感じませんでした。

最近、DevOpsエバンジェリストの牛尾さんがこんなブログを書いていました。

simplearchitect.hatenablog.com

日本でアジャイルするためには

アジャイルの導入にあたって最大の障害となるのは、組織の文化です。技術的な問題は些細なことでしかありません。プラクティスは現場でもある程度実践できます。

新しいやり方を受け入れられないといつまでたっても従来通りの方法しか取れません。従来通りやって従来通り失敗するぐらいなら、新しいことを取り入れてみた方がよっぽど改善に向かうと思うんですけどね。

多分、技術的なことやプラクティスを取り入れるよりは、まず人の考え方を動かすところからスタートするのがアジャイル導入のためには良いんだと思います。