サービス開発に不可欠な 3 つの想像力

私見ですが、サービス開発で最も重要なスキルは想像力です。

１）顧客を想像する力

顧客を知り、顧客の目線に立つことなく、よいサービスを開発することはできません。

２）他の開発者を想像する力

他の開発者が保守、拡張しやすいよう配慮して設計、実装することで、開発チームの生産性を上げることができます。

３）コミュニケーションの前後を想像する力

相手の言動の背景や、自分の言動が相手に与える印象に配慮することで、お互い気持ちよく働くことができます。

一般的には１）が一番遠い想像力で、３）が一番近い想像力でしょうか。

１）や２）ができれば３）もできると言いたいところですが、実際にはそうではありません。その逆もしかりです。例えば、顧客のことは必死に考えても、すぐ側にいる同僚やパートナーのことは道具のように扱ったり、逆に、自分や近しい人たちがよければ顧客のことはぞんざいに扱ったり、特定の誰かに対してできていることが、他の誰かに対してはできていなかったりすることが往々にしてあります。

つまるところ、想像するということはその人を自分と同じように人として考えるということであり、それが欠如するということは、人として（本当の意味では）考えていないということです。

私もよくやるのですが、ここまで読んで思うところのある方は、たまには初心に立ち返って、関わる人たちが何を思い、何を考え行動しているのか、想像してみるとよいと思います。様々な施策が本当に顧客を満足させているかどうか？独りよがりなコードを書いてしまっていないかどうか？自分の些細な言動で相手を不快にさせていないかどうか？

想像力は、心の筋肉の一種です。想像することを繰り返して、鍛えていくことをおすすめします。3 つの想像力が高い次元にある個人の集まったチームには、一長一夕では真似できない、サービス開発のための創造力が宿るはずです。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

ハートレイルズでは現在、新規のウェブサービス、スマートフォンアプリの受託開発、あるいは開発コンサルティング（顧問）案件を絶賛募集中です。どうぞお気軽にご相談ください！

会社として、英語にどう取り組むか

最近、ハートレイルズの社内では英語が流行っています。

具体的には、スタッフが英語でブログを書き始めたり、英語勉強用の Slack チャネルで英語で雑談したり、定例の会議を英語で進めたりしています。また、英語力の向上を支援する様々な仕組み、制度なども現在整備、拡充中です。

会社として英語に取り組む理由は明確で、世界（特に英語圏）で活躍していきたいからです。ハートレイルズは既にいくつかの自社サービスを英語圏に向けて提供していますが、私は自社の総合的な開発力に絶対の自信を持っていますから、サービス開発の仕事も世界中のクライアントから請われるようになりたいと考えています。

一方で、人として英語に取り組む理由はそれぞれです。中には取り組みたくない人もいるかもしれません。幸い、ヒアリングしてみると社内の意見は総じて前向きですが、とはいえ、純粋な英語力を人事評価に紐付けたりすると弊害も大きいので、会社としては英語に取り組むが、スタッフとしての取り組み方には裁量が持てるよう、（英語が苦手なスタッフに）過度のストレスがかからないよう、細心の注意を払っています。

私にとって、英語に取り組むということは、自分の価値観と可能性を広げることです。今後、英語の重要性は増すばかりで、英語ができるようになって困ることなどないと信じているので、スタッフにも会社の取り組みをバネにして、自分の価値観と可能性を広げていってもらえたら幸いと考えています。

会社として英語に取り組むことが一体何をもたらすのか、まだ始まったばかりですが、私自身、これから起こることが非常に楽しみです。随時、経過をここで報告していきたいと思います。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

ウォーターフォールとかアジャイルとか、一括請負とか準委任とか、重要なのはそんなことじゃない

最近また、開発プロセスや契約形態の良し悪しを語る記事をよく見かけます。

従来の SI 的なモデルから脱却しようといったコンテキストで、特定の開発プロセスや契約形態が云々と語るのは、それ自体すごく SI 的な匂いがして、個人的にはあまり好きではありません。何より、そういった記事の内容を盲信して、間違った開発会社を選定、あるいは開発会社の論理に振り回されてしまうお客様がいるかもしれないと考えると、辛いです。

以前、受託開発の限界について、という記事を書きましたが、ハートレイルズは開発プロセスや契約形態に特別な拘りはありません。というより、お客様の目的や状況によって適切なものは異なるので、お客様と一緒に適切なものを探すところから始めるのがハートレイルズです。

例えば、悪く言われがちなウォーターフォール、一括請負をフォローしておくと、これらは新規事業の初期開発には比較的向いています。新規事業では予算やローンチのタイミングに柔軟性がないことも多く、特に開発全体を開発会社に依頼する場合、準委任より一括請負の方が適切なことがあります。（なお、ウォーターフォール、一括請負だからといって、要件の変更に一切対応できないということはありません。もちろん、アジャイル、準委任ほど変更に強くはありませんが、程度問題です。）

一方で、同じ新規事業でも、要件が全く固まっていない場合、既に内製のチームがあり、チームの一員として開発に協力する場合、あるいはローンチ後の運用や継続開発などは、一括請負より準委任の方が望ましいことも多いです。

つまり、ハートレイルズにとって、開発プロセスや契約形態というのは、単なる手段だということです。重要なのは手段そのものではなく、適切な手段を見つけることです。そして、お互いへの信頼をベースに円滑に開発を行い、お客様と自社のビジネスの成長という目的を果たすことです。

開発における上流工程と下流工程の分断や多重下請け構造など、よく指摘される SI 的なモデルの問題点は、確かに問題は問題ですが、開発プロセスや契約形態などの手段とは何ら関係のないことです。（どちらかというと企業規模に起因するところでしょう。）

ハートレイルズや私とお付き合いのある会社さんの多くはそうした問題とは無縁ですが、そうした問題の原因として過度に特定の開発プロセスや契約形態をあげつらうのは、適切な手段を見つけられず、あるいは使いこなせずに駄々を捏ねている子供の責任転嫁のように感じてしまいます。

私はこれからも、手段に固執せず、目的を重視していきたいと思います。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

「それは仕様です」から卒業しよう

「こうこうこういう事情で困っているのですが、これは仕様でしょうか？」

特に新規のお客様から、本当に申し訳なさそうに、仕様かどうかを尋ねられることがあります。尋ねられた当方は仕様かどうかということより、困っているという事実の方がよほど気になるのですが、このような質問を度々される方は、過去に仕様を過剰に重んじる文化に付き合わされてしまった方が多く、当方で少しづつその文化から距離を置くよう、コミュニケーションを繰り返していきます。

仕様という言葉は、特にサービスのローンチ前には、確かに必要となる局面が多いです。そういう観点で、仕様とは、複数人が同じ目的に向かって制作を進めるためのもの、といって良いでしょう。

一方で、サービスのローンチ後には、逆に仕様という言葉が独り歩きをして、免罪符のごとき使われ方をされてしまうことがあるようです。つまり「それは仕様です」でその後の改善を封殺してしまうということですが、私はこの仕様という言葉の、実に使い勝手の良い、ディフェンシブな側面が大嫌いです。

本質的に向き合うべきは、仕様ではなく、仕様のその先の背景、そして、現実に起きている問題です。「それは仕様です」の一言で言葉を切ってステークホルダーをガッカリさせてしまったことのあるみなさん（私も気付かずにガッカリさせてしまったことはあるかもしれません）、いつしかそのことを自然と思うようになってしまったら、制作者としてのその先の成長はないと思います。そうなる前に「それは仕様です」から卒業しましょう。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

創業して 10 年弱を経て実感すること

時間が経つのは早いもので、ハートレイルズを創業してそろそろ 10 年になります。

創業当時は丁度「Web 2.0」というバズワードが流行っていて、ハートレイルズもその流れに乗って（今となってはどうやってマネタイズするのか全く見えない）ウェブサービスを量産していました。当時作ったいくつかのウェブサービスが今でも利用されていることは本当に素晴らしいことですが、当時はただただウェブサービスを作ってその反響と反応を見ることが楽しく、一方で経営は赤字続きで、会社としての体はあってないようなものでした。

その後は、ハートレイルズのウェブサービスを高く評価していただいたお客様から開発のご依頼をいただくことが徐々に増え、ハートレイルズは自社のウェブサービスを作りながら、お客様のウェブサービスやスマホアプリを作るようになりました。今ではお客様の評価が次のお客様を呼ぶという好循環でこのビジネスは伸び続けていますが、ビジネスの伸長に合わせてスタッフが増え始めたのもこの頃です。

振り返ると、会社として一番苦しかったのは、スタッフが増え始めたこの頃だったかもしれません。それまではただ単にウェブサービスを作っていれば何とか回っていたのが、ウェブサービスを作る前に会社を作る必要が出てきたからです。1 人、2 人、3 人とスタッフを雇用する度に会社の損益分岐点は上がっていきますし、創業当時のような赤字続きは許されない状況です。雇用を維持し、かつ待遇を向上していくためには、継続的に売り上げて利益を出す会社を作らなければなりませんでした。

それからは、会社を作ることに「真剣に」向き合っている自分がいます。

会社を作るという仕事はまだまだ道半ばで、おそらく終わることもないでしょうが、短くない年月を経て感じることは、この仕事に銀の弾丸はないということです。

おかげさまでここ数年、ハートレイルズは売り上げと利益を増やしていますが、これは一重にスタッフがお客様に誠実に向き合い、成果を出してきた結果です。その中で自分がすべきことは、スタッフが気持ち良く働けるように大小の問題解決を繰り返しながら、内外に対して会社の方向性を示し、少しでも良い会社にしていくことでした。

創業当時はウェブサービスを作る楽しさや価値提供の喜びを原動力に仕事をしていました。その楽しさや喜びは今も決して色褪せませんが、それと同時に、今は会社を作ることに真剣に向き合うことで、スタッフを雇用し、スタッフの多様な人生を支え、会社として体をなし継続的に売り上げて利益を出すことが、本当に素晴らしいことだと実感するようになりました。これは、ここまで続けてこなければ得られなかった感覚だと思っています。

今年は自社サイトの刷新や自社サービスのリリースを予定しており、次の 10 年の礎の年とするべく色々と頑張っています。スタッフやお客様と一緒に作っていくこれからのハートレイルズが、どんな会社になっていくのか、非常に楽しみでなりません。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

ダメなプロジェクトとダメダメなプロジェクトの傾向と対策

一つ前の記事で、開発者が開発するべきものは正しい「変化」と書きました。

私達が開発者として向き合うものは、事前に決められていない「変化」です。私達は進化に導く正しい「変化」の形を探し、仮定するところから始めて、仮定したらそれを素早く実現し、検証しなければなりません。開発するべきものは正しい「変化」です。

言うは易く行うは難しで、世の中にはこれが行い難いプロジェクトがたくさんあります。この記事では、そうしたダメなプロジェクトと、さらにダメな（ダメダメな）プロジェクトの陥りがちなパターンについて考えてみます。

背景が言語化、共有されない

何らか機能を追加、あるいは削除するなど、プロダクトを変更するには、必ずその背景があるはずです。背景とは、現状や現状の課題感（問題点）、変更により達成したい目的などです。

企画、プロダクトオーナー、プロダクトマネージャーなど、呼称は様々ですが、プロダクトの変更に責任を負うべき人は、まずこの背景を言語化し、開発者に共有する必要があります。また、背景の共有が不足していると感じられた場合には、開発者からもこれを要求すべきです。

背景の分からない状態でその手段となる機能を開発している、文章にしてみるとそれがいかに滑稽な状態か浮き彫りになりますが、このような状態では開発に最適化や提案の余地はなく、自分達の携わっていることに納得感も得られません。

当たり前のことではありますが、この当たり前のことが当たり前にできないプロジェクトは非常に多いです。このパターンに陥る根底には、プロジェクトにおける開発を工業製品をライン生産方式で処理するかのごとく扱う、大きな誤解があるのではと見受けられます。

プロジェクトで開発するものは大量生産品ではなく一点物です。この場合、必要となる人材は与えられた工程をただ単にこなす作業員ではなく、自ら考えて主体的に動ける人です。プロジェクトのメンバーを誰一人として単なる作業員にしないためにも、背景の言語化、共有は強く意識すべきことの一つになります。

成果が測定、検証されない

背景に基づいて実際にプロダクトを変更した後には、その成果を測定し、課題感を解決したのかどうか、目的を達成したのかどうか、検証する必要があります。

経験上、プロダクトの初期開発のフェーズでは、最低限の機能を揃えることに追われるため、この点が疎かになりがちです。ただし、どのようなプロジェクトでも、中長期的にはプロダクトに関わる様々な数字を測定し、重要な数字についてはプロジェクトのメンバー全員で日常的に追いかけていくべきです。

成果を測定し検証することで、プロジェクトのメンバーは自分達の加えた変更がどのような成果をもたらしたのかを把握し、それを元にユーザーの思考や行動を想定し、次の打ち手を考えることができます。逆に、成果が測定、検証されないということは、つまるところユーザーのことを見ていないということです。

このパターンに陥るプロジェクトも非常に多いです。ただし、背景の言語化や共有を強く意識するほど、背景に厚みを持たせるためには数字が必要となるため、「背景が言語化、共有されない」というパターンを脱却する過程で、同時に改善することがあるパターンとも言えます。

素早く開発できない

良いプロジェクトは、プロダクトの変更に際し、背景の言語化、共有から、実際に開発し、効果を測定、検証するまでの期間が比較的コンパクトです。同じ期間で他のプロダクトよりも多くの仮説検証を行えることは競争力の源泉となるため、素早く開発することが重要であることには疑いの余地はないでしょう。

バージョン管理がない、コードレビューがない、自動テストがない、ドキュメントがない、CI がない、テストエンジニアがいない、DevOps ナニソレ、などなど、素早く開発できないプロジェクトでは、素早く開発するためのプラクティスの導入に積極的でないパターンが多いです。

また、基本的にプロダクトの規模が大きくなるとコードの複雑性は増していくもので、その分リファクタリングやコンポーネント化の重要性も増していきますが、そのためのスケジュールが確保できず（されず）、いわゆるスパゲティな状態となり手に負えなくなっていくパターンもあります。

両方のパターンに共通して見受けられることは、プロダクトの変更に直接的に結びつかない作業への無理解です。プロダクトは一度変更すれば終わりではなく、変更し続けていくことが重要なはずです。にも関わらず、その場その場で変更することを優先し、変更しやすくすることを軽視する、この木を見て森を見ず的な判断の積み重ねが、いずれ取り返しのつかない規模の技術的負債として重くのしかかってくる場合があります。

こうしたパターンに陥ることを避けるためには、まず、素早く開発するためには素早く開発するための土台が必要であり、その土台を維持するためには相応の労力がかかる、ということを、プロジェクトのメンバー全員が理解し、また実際にそれを維持することを是とする合意（文化）が必要になります。

なお、技術的負債を一定レベルに抑えつつ、適度なバランスで開発を進めることは、経験がないとなかなか難しいことです。技術的負債をゼロにすることが重要なのではなく、素早く開発し続けることが重要なので、開発者は常にそのバランスを意識して開発に向き合うのが良いと思います。

ここまでが、ダメなプロジェクトの陥りがちなパターンです。ここで列挙したパターンに陥っているという認識がプロジェクトのメンバー全員で既に共有できている場合、少しづつ改善していけば良いでしょう。偉そうに書いていますが、私の携わるプロジェクトでもダメな部分は当然ありますし、それを少しづつでも改善していくことが私の仕事の一つでもあります。

しかし一番問題となるのは、問題を問題と認識できる人が周りにいないというパターンです。この記事を読んでいるあなただけが問題を認識している場合、まずは声を上げましょう。社内の力関係などにより一人ではどうしても声が響かない場合、私を含め、開発コンサルティングを行っている方々に助力を求めるのも一つの手です。

プロジェクトを少しづつでも改善していくためなのに、声を上げても、手を尽くしても一向に響かない、そうしたプロジェクトはダメダメです。メンバーの声に耳を傾けず、良い方向に変えていく努力ができないプロジェクトに未来はなく、そうした環境に身を置き続けることは不幸です。早めに身を引く準備を進めることをオススメします。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

私達開発者は何を開発しているのか？

ウェブサービスやスマホアプリにはその時々で形がありますが、その形は日々変化、進化（あるいは退化）します。

変化の背景は様々です。新規の顧客を獲得するため、既存の顧客とのエンゲージメントを強化するため、など、いずれにしても、ウェブサービスやスマホアプリを進化させ、ビジネスを拡大していくためには、変化を繰り返していく必要があります。

私達は開発者であり、かつ優れた開発者たらんとしていますが、こうした時流の中で、第三者に決められた「モノ」をただ単に開発する、ということは、最低限できて当たり前のことであり、私達を差別化する付加価値にはなり得ません。

私達が開発者として向き合うものは、事前に決められていない「変化」です。私達は進化に導く正しい「変化」の形を探し、仮定するところから始めて、仮定したらそれを素早く実現し、検証しなければなりません。開発するべきものは正しい「変化」です。そしてこれを体系立てて、品質とスピードを維持しながら回していくノウハウこそが、付加価値の一つであると考えています。

ウェブサービスやスマホアプリが死に至る原因は、ほぼ全て「変化しなかった」「変化したが進化でなかった」「変化するスピードが足りなかった」のいずれかです。最初から完璧なプロダクトなど望みようもないので当然のことですが、私達開発者はこの死に至るパターンに陥るのを全力で防がなければなりません。

私が受託開発の商談で初めてお客様と会ってお話しする時、私がプロダクトそのものの話だけでなくプロダクトを開発するに至った背景やビジネスの状況のヒアリングに時間を割いていると、稀に怪訝な顔をされるお客様がいらっしゃいます。ここまで読み進めていただいた方にはお分かりかと思いますが、私からすると、既にその時点で開発者として、ただ単に開発する以上に何ができるのか、探しているのです。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

これまでの 2 年間とこれから

実に 2 年近く、個人のブログを放置していました。

Tech Blog は細々と更新していたものの、対外的なアウトプットが少なくなっていたこの 2 年間、会社の中では様々なことがありました。

１）手掛けているサービスが増え、売り上げが大幅に伸びました

まず、手掛けているサービスが増えました。ハートレイルズは自社サービスと他社様の事業支援の 2 つの事業をしていますが、とりわけ後者で、新規事業の立ち上げに伴うウェブサービス、スマホアプリの開発について引き合いが増えました。

結果として、現在それなりの数のサービスを企画から開発、運用まで一貫して担っています。また、大半のサービスがビジネスとして伸びていることから、それに連動する形でハートレイルズの売り上げも大幅に、具体的には 100% 以上伸びました。

なお、ハートレイルズには、創業して約 10 年、様々な事業の支援に主に開発面で携わってきた、事業支援会社としての膨大なノウハウがあります。正直なところ、私はこの分野においてハートレイルズよりも “柔軟にやれる” 会社を他に見たことがありません。

中には自社に固有のプロセスを磨き上げ、お客様がそのプロセスに合わせるという前提下で “うまくやれる” 会社はありますが、ハートレイルズはお客様のプロセスに寄り添いながら都度最適解を模索していくスタイルで、属人的でスケールはしづらいものの、その分納得度の高いサービスを提供できていると自負しています。

２）リモートワークを維持しつつ、スタッフが増えました

残念ながら離れてしまったスタッフもいますが、増減を繰り返しながらスタッフが徐々に増え、現時点でパートナーを含めて 20 名程度の組織になりました。うち 8 割がエンジニアで、最近は事務のスタッフも増え、エンジニアリングだけでなくバックオフィスの業務もリモートで回すというチャレンジを進めています。（ハートレイルズのリモートワークについては別記事で紹介しています。気になる方はそちらを参照ください。）

振り返るとこの 2 年間は、会社の連続的成長に集中しつつ、非連続的成長のための基礎を築いてきた 2 年間だったと考えています。

ハートレイルズにとっての連続的成長とは、他社様の事業支援を伸ばすことであり、非連続的成長とは、自社サービスを伸ばすことです。そして今、ようやくこの 2 つの成長に同時にフルコミットできる体制（売り上げとスタッフ）が整いつつあります。

自社サービスと他社様の事業支援で培ったノウハウを相互に循環させて、共に押し上げることのできる環境を作ること、

自社サービスでエンドユーザーのみなさんに貢献できる喜びと、他社様の得意な事業ドメインに乗っかって様々な事業で貢献できる喜び、スタッフがこの 2 つの喜びを選択的に、もしくは両方噛みしめることのできる環境を作ること、

これらは私の長い間の目標で、体制が整いつつある今、これからがまさに正念場、勝負どころと考えています。（その勝負どころに張るために、いくつかの職種でスタッフ募集しています。ぜひ奮ってご応募ください。）

言うは易し、行うは難しで、目標の達成のためには、今ある会社を作り変えるくらいの意識とエネルギーが必要です。また、実際に目標を達成した暁には、ハートレイルズは作り変えられ、良い意味で今とは全く別の会社になっていると信じています。

創業し直すつもりで、頑張ります。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

受託開発の限界について

昨今、受託開発の限界だとか、SIer はオワコンだとか、その辺りの記事をよく見かけるのですが、どことなく白けた気分で眺めている自分がいます。それはなぜか？多分、ほとんどの記事が、人月契約がどうのこうの、下請けの多重構造がどうのこうの、納品がどうのこうの、といった、それこそ何回見かけたのか分からないような、ビジネスモデルの話に終始しているからです。

IT の世界は今後より細分化、高度化され、よりスピードが求められる時代になっていきます。そうした時代に、求められる要件を全て内製で賄おうというのはよほどの会社でなければ難しいことで、今後受託開発のニーズはなくなるどころか、ますます増えていくのではと思っています。

そうした時代に生き残れないのは、技術の細分化、高度化についていけず、変化に対応するスピードを持ち合わせていない会社です。受託開発を生業とする会社に求められるのは単純に開発力であり、スピードであり、クライアントのビジネスを成長させることに全力でコミットするマインドセットです。

ハートレイルズは自社サービスの企画運営と受託開発の両方を生業としていますが、受託開発については契約形態（ビジネスモデル）に拘りはありません。それは、契約形態に関わらずハートレイルズとクライアントが win-win な関係を構築できると信じているからです。実際に請負でも、準委任でも、レベニューシェアでも、今までに本当に多くの新規事業開発に携わってきました。

結局ハートレイルズが提供するものは開発リソースと成果であり、どのような契約形態であっても、ハートレイルズとクライアントの双方が適切と考える契約料金を設定できさえすれば、それで問題はないのです。

巷ではよく契約形態を諸悪の根源とする記事を見かけますが、「できるだけ短い期間でできるだけ高い成果を提供すること」が開発会社とクライアントの双方にとって最大の利益となるようにすることは、一般的な契約形態でも十分可能です。だからこそ、ハートレイルズは奇をてらわず、ただ純粋に開発力とスピードを追求し、クライアントのビジネスの成長に全力でコミットし続けます。

ハートレイルズは明確にクライアントや仕事を選びます。労働集約型な仕事になりがちな常駐は今までもこれからも一切受けませんし、CMS をちょっとカスタマイズして、、、みたいな、開発力を必要とされない仕事も一切受けません。上流とか下流とか、おかしなタグを付けて開発工程を分断される仕事も、多重の下請けで意味のない中抜きをしたりされたりする仕事も、受けません。

ハートレイルズの受託開発は新規事業に伴うウェブサービス、スマートフォンアプリの開発、運用に特化しており、その分野において世界一となれるような人材の育成と体制の構築に努めています。

ハートレイルズの受託開発のモデルが古いのか新しいのか、それはどうでも良いことですが、ハートレイルズは受託開発の限界などという、目に見えない、よく分からない空気のようなものは相手にしません。突き抜けた開発力とスピードの先には、素晴らしい景色が待っていると確信しているからです。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。

志を高く持ち続けること

夢の実現に向けて志を高く持ち続けること。
夢の実現への道筋をブレークダウンして、一歩一歩着実に前に進むこと。

会社のビジョンは何か、良い会社とは何か、日々反芻しながら、
あるべき理想とのギャップを少しでも埋めるべく、もがくこと。

志を高く持つ、高く持ち続けることの重要性は様々な場所で語られていますが、
年々、実感としてそれを感じるようになってきています。

志は、あらゆる挑戦や障害を乗り越える唯一の原動力です。
志は、自分や周囲を成長させる起爆剤です。

志がなければ、あらゆる過程で妥協や逃避が顔を出し、
そこには挑戦も成長もありません。
また、志を失えば、そこから停滞が始まります。

私も、色々なことにもがきながら、でも、前に進んでいます。
志の形は色々だと思いますが、みなさんも、ぜひ一緒に、頑張りましょう。

この記事を気に入ってくださった方は、ぜひいいね！していただけますと幸いです。

ハートレイルズのファンページはこちら。今後ともどうぞよろしくお願いいたします。